> >   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.

This conversation raises some basic questions:

* Will we ever be able to use karbon14 as a basic tool for supporting our own svg(z) images? We're talking basics and not exotic or professional needs.

* Your reference to konqueror actually is a reference to the embedded svg viewer. As you mentioned svg specifications, do you feel comfortable looking at that code to provide a report of sorts whether the TDE embedded svg viewer is up to snuff with those specifications and what needs to be done to update the code?

* In an effort to help us support our own svg(z) images, do you feel comfortable writing a basic how-to at our wiki outlining the basics of svg support? The app used is not as important as the fundamentals of what needs to be done to avoid problems and errors. For example, you mentioned different Save As options that would alleviate the problem reported by David, but my guess is you are the only person on this list who knew those distinctions. :-) I'm willing to help if writing is something you dislike.

Darrell