13 Jun
2012
13 Jun
'12
9:27 p.m.
On Wed, 13 Jun 2012 15:20:25 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
All,
After tweaking the go.svg file a couple of days ago Darrell mentioned that
when rendered in TDE, the svg file showed artifacts which I couldn't explain as
the original inkscape file looked fine. Long story short, I was using konqueror
file manager on a suse box (3.5.10 on opensuse 11.4) and I noticed black
artifacts in an svg file preview. Here is a screenshot of the actual svg file in
inkscape:
http://www.3111skyline.com/dl/dt/trinity/ss/svg-artifact-error-2.jpg
Here is the preview in konqueror (3.5.10)
http://www.3111skyline.com/dl/dt/trinity/ss/svg-artifact-error-1.jpg
The svg file had a black fill on the rectangle below the image, so I changed
it to white to see if that made any difference on the artifact -- it didn't.
Here is a link to the svg file itself:
http://www.3111skyline.com/dl/dt/trinity/ss/firstTest.svg
So, it looks like there is something that KDE did not handle correctly in svg
preview that now shows up in TDE as well. I have no clue where to go with this,
but I would like to start with asking "Has anyone else seen this type of
artifact with svg files?"
Then "does anybody have any experience working with svg file rendering in
KDE/TDE who would know what part of the code is responsible for generating the
svg previews?"
What say the graphic file format wizards on the list? What is going on in
these images? Is it a svg format change causing problems with old rendering code
or what? Obviously this isn't a blocker type issue, but right now, I don't know
enough about it to author an intelligent bug report...
In the case of this particular sample SVG, I think I do know what's going on, and
it's an Inkscape bug/unfeature, not anything to do with Trinity.
Specifically, the portion of the SVG standard which deals with multiline text was
changed fairly late in the draft process, and Inkscape implements a version from
one of the earlier drafts rather than what made it into the standard. Therefore,
Inkscape's handling of flowed text is technically incorrect, and if you save a
file as "Inkscape SVG" there may be problems with some text. (There's a
second set of save options for something like "Plain SVG" or "Standard
SVG"
which should be used for images containing text, or convert text to object before
exporting the file if it's going to be opened in something other than Inkscape.)
In this case, if I render the SVG directly in Firefox, the line of black text near the
bottom doesn't show up at all, and the two text blocks appear as different element
types in the SVG source: "This is Big Text" is a <text> element, but
"I don't know!"
is a <flowRoot>. Therefore, you've got one flowed and one unflowed text, and
the flowed text is incorrectly specified. Konqueror appears to be inserting a black
background block rather than ignoring the element, which may or may not be
contrary to the SVG specification.
I know all of this because I got bitten on the arse once by it myself, trying
to transfer an Inkscape file to Adobe Illustrator.
The thing with the go.svg, however, is not the same bug, given that there was no
text in that file in the first place.
