4xx / svg-edit

Automatically exported from code.google.com/p/svg-edit
MIT License
0 stars 0 forks source link

Image library element moves on save as svg #659

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. create a simple element in svg-edit
2. insert a vector image from image library and position close to other element 
for reference
3. Save as svg

What is the expected output? What do you see instead?
Should be in the same position as on the svg-edit canvas, but the image library 
element is moved, usually rightwards, but sometimes also down.

In what browser did you experience this problem? (ALL, Firefox, Opera 10
Alpha, etc)

Please provide any additional information below.
I wanted to test to see if the problem remained once the imported image had 
been "break link to reference element"'d, but that is currently broken.

Original issue reported on code.google.com by adrianbj...@gmail.com on 31 Aug 2010 at 7:11

GoogleCodeExporter commented 9 years ago
Just tested and everything is fine if the element has been converted by "break 
link to reference element". Although, the weird thing is that it looks fine in 
Inkscape. So not sure if it is an Illustrator bug. Regardless it would be nice 
to figure out if there is a way to keep Illustrator happy.

Original comment by adrianbj...@gmail.com on 1 Sep 2010 at 5:42

GoogleCodeExporter commented 9 years ago
I just manually edited the exported SVG. I replaced the <svg></svg> within the 
<def> with <symbol></symbol> and illustrator shows everything as expected. I 
wonder if the best option would be to keep them as <svg> in svg-edit, but do a 
replace when exporting - that would deal with the FF gradient bug that you 
mentioned here (http://code.google.com/p/svg-edit/issues/detail?id=71#c46), 
while ensuring compatibility with other vector packages once exported?

Original comment by adrianbj...@gmail.com on 1 Sep 2010 at 6:04

GoogleCodeExporter commented 9 years ago
Yeah, I thought about doing that, but the problem is that it would still show 
the problem to anyone using the exported SVG in firefox. Since we don't know 
what the user will want to support most, I think this is something we ought to 
leave to issue 297 (an export option).

Original comment by adeve...@gmail.com on 1 Sep 2010 at 8:18

GoogleCodeExporter commented 9 years ago
Yeah, good point. I also read through your Mozilla bug report too - doesn't 
look like they are really understanding the issue, so maybe there won't be 
resolution on that front for a while. 

I am pretty sure that the majority of my users will simply want to export to 
PNG (and so obviously this is not relevant), but I think the next most common 
path would be for them to want to open the illustration in 
Illustrator/Corel/Inkscape. To that end, I decided to do a quick hack of the 
filesave.php file to convert the <svg> tags to <symbol>. 

Illustrator actually treats these symbol elements as they do their own symbols, 
so the break link to symbol button does what it's meant to do. Also, Inkscape 
has the option to Edit>Clone>Unlink Clone, which does the same thing.

This is great, but it highlighted a couple of new bugs, but I am not sure where 
the problem(s) really lie - ie svg-edit or Illustrator bug?

1) Positioning of the symbols is still not completely perfect in all 
circumstances - two symbols positioned close together ended up overlapping.

2) Symbols appear in the Illustrator symbol palette upside-down.

3) Minor improvement, but it would be nice if the label in the illustrator 
symbol palette showed the title of the symbol, rather than "svg_x". To do this 
we'd need to have svg-edit use the title as the id, which is what Illustrator 
does when exporting to svg. ie: 
id="Branta_bernicla__x28_Atlantic_Brant_Goose_x29_" which shows up in the 
palette as: Branta bernicla (Atlantic_Brant_Goose). If there isn't a title, 
then svg-edit could fallback to a numbered id.

Would you like me to raise two new bugs for points 2 and 3 above?

Original comment by adrianbj...@gmail.com on 2 Sep 2010 at 9:59

GoogleCodeExporter commented 9 years ago
Do these bugs happen after your <symbol> conversion or with just the <svg>s? 

#2 seems really weird...not sure why that would happen.

#3 Guess we can do that, sure...feel free to open a new bug on that.

Original comment by adeve...@gmail.com on 16 Sep 2010 at 6:04

GoogleCodeExporter commented 9 years ago
Well the positioning is really off in Illustrator when using the default <svg>, 
but when I convert them to <symbol>, it is sometimes ok, but sometimes 
positioning is still off. I actually ended up removing my svg to symbol patch 
because I have a lot of users now wanting to save draft versions of diagrams 
they are working on so they can open them again in svg-edit at a later time and 
continue. I actually posted something about this on the adobe forums, but 
haven't had any responses. I still think <symbol> is the most logical wrapper, 
but not much we can do at the moment, short of getting rid of the wrapper 
altogether, although at the moment it is actually helping to mask the 
userspaceonuse issues. 

Original comment by adrianbj...@gmail.com on 16 Sep 2010 at 6:23

GoogleCodeExporter commented 9 years ago
Now that you're using the <symbol> wrapper (which is awesome btw), it would be 
great to sort out the upside-down symbol in the Illustrator palette issue, 
although it may just be an Illustrator bug that is out of our hands. I did post 
on the Adobe forums, but nothing so far.

Original comment by adrianbj...@gmail.com on 10 Oct 2010 at 11:12

GoogleCodeExporter commented 9 years ago
Think you could provide an example image that shows the issues (position being 
off/upside-down in illustrator)? 

Original comment by adeve...@gmail.com on 26 Oct 2010 at 11:11

GoogleCodeExporter commented 9 years ago
Take a look at the screenshots. The first one shows the positioning in SVG edit 
and the second what it looks like in Illustrator. Note the slight change in 
position of the birds relative to each other and also the upside-down versions 
in the illustrator symbol palette.

When opened in Inkscape, it looks just like the original in SVGedit though, so 
this still may be an Illustrator only bug, but annoying nonetheless.

Original comment by adrianbj...@gmail.com on 18 Nov 2010 at 5:22

Attachments:

GoogleCodeExporter commented 9 years ago
Well, I have figured out the upside down issue in the Illustrator symbol 
palette. Basically you need to define the symbol with a matrix along the lines 
of:
transform='matrix(1,0,0,-1,0,0)'. This flips the symbol for use in the symbol 
palette and then you need to include a similar negative matrix in the <use> tag 
to flip it back again. The only catch seems to be that it messes up the y 
co-ordinate positioning in Illustrator because it is now calculating from the 
visual bottom of the symbol, rather than the top. Inkscape however seems to 
handle things fine, so I found that adding a viewbox to the symbol tag gets 
both behaving. I have attached a server generated file (from the image library 
database) with all the symbols from one of the library albums all laid out 
(contact sheet style). Take a look at it in Ilustrator to see the now proper 
(right side up) handling of the symbols in the symbols palette (complete with 
labels from the symbol id). My motivation behind this is to be able to save 
these svg files to .ai so that they can be placed in the illustrator 
presets>symbols folder for direct access to the symbols.

I am sure that the correct way to do this would be to remap the position of the 
nodes, rather than the initial flip, but it seems to work for my purposes. The 
only catch is that the files won't open in svg-edit (doesn't really matter in 
this case), and the w3c validator doesn't like the viewbox on the symbol tag.

Anyway, not super important for svg-edit, but thought it might be worthwhile 
posting my findings anyway.

Original comment by adrianbj...@gmail.com on 2 Feb 2011 at 2:19

Attachments: