search

jbosboom / svg-tiler

tiles SVGs from ASCII input (deprecated: use edemaine/svgtiler instead)
1 stars 0 forks source link

Investigate Inkscape's mishandling of tiler output #2

Open jbosboom opened 9 years ago

jbosboom commented 9 years ago

Inkscape doesn't handle (some) outputs of the tiler very well, typically duplicating each element dozens of times at varying offsets from their actual locations. This will be a problem for us if we want to use Inkscape's PDF+LaTeX export functionality to get nice-looking text.

My current hypothesis is that Inkscape gets confused by its own sodipodi-namespaced metadata, which it may not expect to survive enclosure in a <symbol>. (I can't reproduce the bug on files not containing sodipodi metadata, but I haven't tried very hard.)

If removing that metadata doesn't fix the problem, we should find an XML testcase reducer and find minimal tiler outputs that make Inkscape's rasterization differ from rsvg-convert's by more than N%.

jbosboom commented 9 years ago

Stripping all sodipodi and inkscape namespace references did not fix it.

In the affected files, Inkscape's symbols pane shows elements from multiple symbols in each symbol. On the hypothesis that Inkscape expects each symbol to contain a single element, I added a group inside the symbol enclosing all the nested elements. This did not fix the problem either.

jbosboom commented 9 years ago

Looking at Inkscape's SVG output after creating a symbol and some uses of it, Inkscape nests the symbols in a <defs> element. The SVG specification admits this isn't necessary for elements that do not produce a graphical result, but recommends it anyway. An upcoming commit will change svg-tiler's output to emit symbols in <defs>, but this does not fix Inkscape's difficulties opening/rendering tiler output.

jbosboom commented 9 years ago

With no references to the symbols, Inkscape renders an empty document. With even a single reference, Inkscape renders the referenced symbol, plus the symbols themselves (even though <symbol>s are never rendered). I haven't reproduced the copying behavior (multiple occurrences of each symbol) on a handcrafted example yet, so I don't know what causes that.

I'm giving up on this for now; we'll come back to it later if we really need Inkscape rendering.

jbosboom commented 9 years ago

The issue seems to occur when the included files contain elements that should be clipped away by their viewBox attribute. It's not clear why Inkscape isn't clipping properly, but it suggests we could just fix our input files not to contain such extraneous elements.