Details
-
Bug
-
Status: Open
-
Resolution: Unresolved
-
1.7
-
None
-
None
-
Operating System: All
Platform: Macintosh
Description
When processing a font file with Batik's ttf2svg tool, it's possible to end up with an SVG file that's not valid XML. This seems to happen when the original source font contains a null character at the #0x0 codepoint.
This happens when running the jar with options: -l 0 -h 65535. Of course, in that case, I'm requesting the #0x0 codepoint, but I would still expect that the ttf2svg tool would always generate a valid XML document. When the font file isn't valid XML, it is ignored by browsers and doesn't render the font successfully. Characters that will cause the XML document to be invalid should be omitted or (perhaps) mapped to other valid codepoints.
We process many fonts into SVG and many of those have control characters that fall within this range. This caused problems for us. In the meantime, we've altered the command line options we use to -l 32 -h 65535, but it would be nice if ttf2svg was guaranteed to generate valid XML files.