Hi! I just spoke with bryce on IRC and he told me to go ahead and email the list.
I have an issue in inkscape that only happens when I choose an object, copy, cut, and then paste that object back into the same file. Whenever I perform these tasks in a row, the object that I have just pasted disappears in any preview or use mode, such as in nautilus, gimp, gnome-panel, gnome icon themes, etc. but whenever I look at the file in inkscape, the object is still there.
I can edit the object, distort it, reshape it, etc. and as long as I do not cut-copy-paste, the object remains visible. And nothing I do after the copy-cut-paste makes the object visible again. I have reviewed the xml files and I cannot see a difference that would make the object invisible.
I have included two sample files: the original gnome-fs-directory.svg file, and then the modified gnome-fs-directory-issue.svg file that has a major object that has been copied-cut-pasted, that no longer appears visible.
I can repeat this issue on any file with the same results. I've scoured google looking for any hints, and the only thing I could find was regarding Nautilus 2.1.5, and I'm on 2.10.0.
Is there anything I can do to repair the object to make it visible again?
On 6/20/05, linux peach <linuxpeach@...400...> wrote:
I have included two sample files: the original gnome-fs-directory.svg file, and then the modified gnome-fs-directory-issue.svg file that has a major object that has been copied-cut-pasted, that no longer appears visible.
Both files contain 7 objects. Of these 7, one is a group of 0 objects and is therefore invisible and unselectable (except by Ctrl+A) - in both files. The only difference is that in -issue, two of the paths are distorted by node-editing and have different z-order. There's no other difference between the files.
Both files display the same in Batik/Adobe as in Inkscape.
So, can you explain what exactly is missing, and why you are sure it's still there? And which version of Inkscape?
Quoting bulia byak <buliabyak@...400...>:
Both files contain 7 objects. Of these 7, one is a group of 0 objects and is therefore invisible and unselectable (except by Ctrl+A) - in both files. The only difference is that in -issue, two of the paths are distorted by node-editing and have different z-order. There's no other difference between the files.
Both files display the same in Batik/Adobe as in Inkscape.
Have you checked in something using librsvg (e.g. gimp)? I suspect we might be seeing another rendering bug in librsvg...
-mental
Yeah, gimp shows it ncorrectly as well.
On 6/20/05, mental@...3... <mental@...3...> wrote:
Quoting bulia byak <buliabyak@...400...>:
Both files contain 7 objects. Of these 7, one is a group of 0 objects and is therefore invisible and unselectable (except by Ctrl+A) - in both files. The only difference is that in -issue, two of the paths are distorted by node-editing and have different z-order. There's no other difference between the files.
Both files display the same in Batik/Adobe as in Inkscape.
Have you checked in something using librsvg (e.g. gimp)? I suspect we might be seeing another rendering bug in librsvg...
-mental
Ok. I'm on .40 in Ubuntu. When I look at the -issue file, or if I use it as an actual icon, rect337 is missing, completely from all views within gnome. When I open inkscape, rect337 appears just fine. The result of using the icon in gnome/nautilus et al is that I do not see that one object at all in the icon. So if I go to correct the icon in inkscape, the object is already there and visible.
I can change gradients, I can do anything and everything inside of inkscape without a single issue, *except* copy-cut-paste. The instant I use those three commands to an object that's already in the file, that object disappears in gnome/nautilus/gimp/gtk/etc.
On 6/19/05, bulia byak <buliabyak@...400...> wrote:
On 6/20/05, linux peach <linuxpeach@...400...> wrote:
I have included two sample files: the original gnome-fs-directory.svgfile, and then the modified gnome-fs-directory-issue.svg file that has a major object that has been copied-cut-pasted, that no longer appears visible.
Both files contain 7 objects. Of these 7, one is a group of 0 objects and is therefore invisible and unselectable (except by Ctrl+A) - in both files. The only difference is that in -issue, two of the paths are distorted by node-editing and have different z-order. There's no other difference between the files.
Both files display the same in Batik/Adobe as in Inkscape.
So, can you explain what exactly is missing, and why you are sure it's still there? And which version of Inkscape?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Quoting linux peach <linuxpeach@...400...>:
I can change gradients, I can do anything and everything inside of inkscape without a single issue, *except* copy-cut-paste. The instant I use those three commands to an object that's already in the file, that object disappears in gnome/nautilus/gimp/gtk/etc.
Does this also happen for objects that don't have gradients? Or just objects with gradients?
-mental
Any and all objects that are copy-cut-pasted.
On 6/20/05, mental@...3... <mental@...3...> wrote:
Quoting linux peach <linuxpeach@...400...>:
I can change gradients, I can do anything and everything inside of inkscape without a single issue, *except* copy-cut-paste. The instant I use those three commands to an object that's already in the file, that object disappears in gnome/nautilus/gimp/gtk/etc.
Does this also happen for objects that don't have gradients? Or just objects with gradients?
-mental
Quoting linux peach <linuxpeach@...400...>:
Any and all objects that are copy-cut-pasted.
I can't replicate this, and there are too many changes between the first two documents you sent for me to be able to tell which change might be the problem.
Try this:
1. take a document that looks OK in gimp, saved with the version of Inkcape you are testing with
2. copy and paste an object in it, making no other changes
3. save the result as another document
4. see if the copy-and-pasted object disappears in gimp
5. if so, send us both documents
if not we can look into other causes
-mental
I only changed the one object in the -issue file, but ok.
Oh wait, no, there isn't a problem copying and pasting in an image from another source, there is only the problem of taking an object inside of a current drawing copying it, cutting it, and pasting it back into the same illustration.
I can copy and paste into an drawing just fine, I simply can't copy-cut-paste an object that's already in the drawing.
On 6/20/05, mental@...3... <mental@...3...> wrote:
Quoting linux peach <linuxpeach@...400...>:
Any and all objects that are copy-cut-pasted.
I can't replicate this, and there are too many changes between the first two documents you sent for me to be able to tell which change might be the problem.
Try this:
- take a document that looks OK in gimp, saved with the version of
Inkcape you are testing with
copy and paste an object in it, making no other changes
save the result as another document
see if the copy-and-pasted object disappears in gimp
if so, send us both documents
if not we can look into other causes
-mental
Ok, gnome-fs-directory is the original file.
I opened the file, selected the light front object of the folder, copied it, cut it, and pasted it back in as if I had never even touched it. I saved the file as -ccp.
The front object I copied-cut-pasted has disappeared from all views in gnome/gimp/nautilus except inkscape.
On 6/20/05, linux peach <linuxpeach@...400...> wrote:
I only changed the one object in the -issue file, but ok.
Oh wait, no, there isn't a problem copying and pasting in an image from another source, there is only the problem of taking an object inside of a current drawing copying it, cutting it, and pasting it back into the same illustration.
I can copy and paste into an drawing just fine, I simply can't copy-cut-paste an object that's already in the drawing.
On 6/20/05, mental@...3... <mental@...3...> wrote:
Quoting linux peach <linuxpeach@...400...>:
Any and all objects that are copy-cut-pasted.
I can't replicate this, and there are too many changes between the first two documents you sent for me to be able to tell which change might be the problem.
Try this:
- take a document that looks OK in gimp, saved with the version of
Inkcape you are testing with
copy and paste an object in it, making no other changes
save the result as another document
see if the copy-and-pasted object disappears in gimp
if so, send us both documents
if not we can look into other causes
-mental
On 6/20/05, linux peach <linuxpeach@...400...> wrote:
I can copy and paste into an drawing just fine, I simply can't copy-cut-paste an object that's already in the drawing.
My advice is, don't concentrate on copy/paste. If you really want to do the job of librsvg developers for them, try to analyze the SVG code. Eliminate the differences between the files one by one until you find the minimal change that triggers it.
Found the problem.
librsvg doesn't like visibility:visible
If you go into the XML editor, and remove ";visibility:visible" from that path's style attribute, it should begin showing up in GIMP etc.
Since visibility:visible is legal (see http://www.w3.org/TR/SVG/painting.html#VisibilityProperty), this indicates a bug in librsvg (which most GNOME apps use for rendering SVG, GIMP included).
I'm not sure what the best workaround is yet, or whether it's worth doing (versus getting librsvg to fix their code *sigh*). Bulia?
-mental
On 6/20/05, mental@...3... <mental@...3...> wrote:
I'm not sure what the best workaround is yet, or whether it's worth doing (versus getting librsvg to fix their code *sigh*). Bulia?
Remembering the amount of effort it took us to code the visibility management which is both valid and works the way we want, I'd say forget it. Everyone must fix their own bugs; it's not a bug of ours.
Quoting bulia byak <buliabyak@...400...>:
Remembering the amount of effort it took us to code the visibility management which is both valid and works the way we
want,
I'd say forget it. Everyone must fix their own bugs; it's not a
bug
of ours.
Would you mind filing a bug against librsvg in gnome bugzilla?
-mental
On 6/20/05, mental@...3... <mental@...3...> wrote:
Would you mind filing a bug against librsvg in gnome bugzilla?
The original reporter: will you please do it?
At this point, as long as I have a work around that means I don't need to redo my entire week-long illustration, I'm cool. :)
At least when I go to the librsvg list this time, I'll have definite answers to give them. :) Thanks guys!
On 6/20/05, bulia byak <buliabyak@...400...> wrote:
On 6/20/05, mental@...3... <mental@...3...> wrote:
I'm not sure what the best workaround is yet, or whether it's worth doing (versus getting librsvg to fix their code *sigh*). Bulia?
Remembering the amount of effort it took us to code the visibility management which is both valid and works the way we want, I'd say forget it. Everyone must fix their own bugs; it's not a bug of ours.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Completely fixed the problem with viewing. Thank you!!
On 6/20/05, mental@...3... <mental@...3...> wrote:
Found the problem.
librsvg doesn't like visibility:visible
If you go into the XML editor, and remove ";visibility:visible" from that path's style attribute, it should begin showing up in GIMP etc.
Since visibility:visible is legal (see http://www.w3.org/TR/SVG/painting.html#VisibilityProperty), this indicates a bug in librsvg (which most GNOME apps use for rendering SVG, GIMP included).
I'm not sure what the best workaround is yet, or whether it's worth doing (versus getting librsvg to fix their code *sigh*). Bulia?
-mental
participants (3)
-
unknown＠example.com -
bulia byak -
linux peach