https://issues.apache.org/bugzilla/show_bug.cgi?id=53051
Bug #: 53051
Summary: ttf2svg produces invalid XML when #0x0 control
character is included in source font file
Product: Batik
Version: 1.7
Platform: Macintosh
Status: NEW
Severity: normal
Priority: P2
Component: Utilities
AssignedTo: [email protected]
ReportedBy: [email protected]
Classification: Unclassified
Created attachment 28567
--> https://issues.apache.org/bugzilla/attachment.cgi?id=28567
Free font lobster with #0x0 null character added so it triggers the bug
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]