[BATIK-1010] ttf2svg produces invalid XML when #0x0 control character is included in source font file

• Type: Bug
• Status: Open
• Resolution: Unresolved
• Affects Version/s: 1.7
• Component/s: Utilities
• Environment: Operating System: All; Platform: Macintosh
• Assignee: Batik Developer's Mailing list
• Reporter: Sean McBride
• Created: 09/Apr/12 23:51
• Updated: 09/Apr/12 23:51

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.