...

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

So far, the only conclusion I've reached about Karbon is that it badly needs a UI redesign to compact the mass of options docked at the right, and some additional tooltips here and there. I need to do some cross- evaluation of saved files with other programs, but I suspect it's capable of supporting the simple shapes, gradients, and non-flowed text needed for basic vector work. In fact, if it uses the same rendering engine as everything else, it may be the safest choice for modifying Trinity assets.

I believe the user interface is shared among all koffice apps. I think karbon and chalk (nee krita) share some interface components too. I doubt we can remedy the interface issues any time soon, so we would focus on documentation, tool tips, etc.

I've never actually read the SVG spec, but the file format is XML (which I am fairly familiar with), so yes, I can probably figure out what options there are and whether or not we support them. Might be a little while before I have the time, though.

As karbon, and koffice in general, was long ago neglected and shoved aside, we do the best we can with what we inherited. As long as we remember our project goal of maintaining koffice as a light-weight office suite, I think we can tweak karbon.

Hmm. There are two aspects to that: what parts of the standard does the embedded viewer support, and what parts of the standard do the most common editors mangle? (Fortunately, in the case of two of those editors, I already know the quirks, so I just have to examine the GIMP and Karbon.)

Great. You're already way ahead of me. :-)

Writing is not a problem, although you may want to go back over whatever I produce and dumb it down a little--I'm prone to long sentences and rampaging m-dashes, so while what I produce is grammatically correct, it may be difficult to follow for people whose first language isn't English.

Editing and proofreading would happen naturally when the text is transformed to docbook, which is needed to create the help handbook. I'm pretty good at "dumbing down" technical information --- been doing that for many years. :-) Just write whatever you want. We'll handle the editing and refining later.

I'll learn much about karbon by helping with editing and docbook transformation because I'll actually have to test what we write. :-)

Thank you for helping. If we get something crafted for R14 then great, but let's not let the R14.0.0 release dictate this particular project. We can always push a new karbon handbook in R14.1.0 or R14.2.0.

Darrell

On Fri, 15 Jun 2012 18:38:08 -0500 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:

but it doesn't explain the go.svg issue as E pointed out.

And that issue has just become a little murkier again.

I just took the time to have a look at the original SVG, as posted at http://www.3111skyline.com/dl/dt/tde/img/tdeaccessibility/go.svg , and there's no artefact. I tried both 3.5.10 Konqueror and the corresponding version of Karbon14, and I can tell that it's not my revised SVG because I thickened up the T somewhat as Darrell requested at one point.

Several possibilities suggest themselves: 1. Konqueror and Karbon use a different renderer than the dialogs. 2. The artefact is a regression introduced between 3.5.10 and current GIT, in which case We Have A Real Bug and need to find out which patch introduced it. 3. The artefact is due to something else on Darrell's system, possibly a video driver bug, and is not Trinity's fault at all. 4. This isn't the original file after all.

So the immediate questions are, Darrell, is this the faulty file, and does the artefact show up for you in Konqueror/Karbon, or is it only visible in the shutdown dialog?

The diff between the two files isn't very enlightening either. Boilerplate in mine suggests that I saved as Inkscape SVG (since there were no text elements, that shouldn't make a difference), and I can see how David's file was grouped and tell which XML element corresponds to what shape, but there's nothing obviously *wrong*--the two documents are basically similar and everything appears to be well-formed XML, although I haven't yet checked to see if it's valid. [1]

[1] "Well-formed", with respect to XML, means that the document follows the general syntax of XML as outlined in the XML standard. "Valid" means that the document is well-formed *and* the elements and attributes match what's in the DTD(s) or schema(s) that define the document type, in this case SVG. $DEITY, I haven't thought about this stuff in years.