SVG snippet like the following: <text> <tspan font-size="0.5in" x="1in" y="251in" font-family="Avenir LT 35 Light">Avenir LT 35 Light : lte50336.ttf</tspan> <tspan font-size="0.5in" x="1in" y="252in" font-family="Avenir LT 35 Light"> The Quick Red Fox Jumped Over The Lazy Dog </tspan> </text> Will cause batik to throw the following exception: org.w3c.dom.DOMException: file:/home/djoyce/Desktop/Batik_Font_Testing/fonts/fontsampler.svg: The attribute "font-family" represents an invalid CSS value ("Avenir LT 35 Light"). Original message: The "font-family" property does not support integer values. at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(CSSEngine.java:784) at org.apache.batik.css.engine.CSSEngine.getComputedStyle(CSSEngine.java:876) at org.apache.batik.bridge.CSSUtilities.getComputedStyle(CSSUtilities.java:82) at org.apache.batik.bridge.CSSUtilities.convertDisplay(CSSUtilities.java:564) at org.apache.batik.bridge.SVGTextElementBridge.fillAttributedStringBuffer(SVGTextElementBridge.java:881) at org.apache.batik.bridge.SVGTextElementBridge.fillAttributedStringBuffer(SVGTextElementBridge.java:936) at org.apache.batik.bridge.SVGTextElementBridge.buildAttributedString(SVGTextElementBridge.java:856) at org.apache.batik.bridge.SVGTextElementBridge.computeLaidoutText(SVGTextElementBridge.java:636) at org.apache.batik.bridge.SVGTextElementBridge.buildGraphicsNode(SVGTextElementBridge.java:292) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:224) at org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:171) at org.apache.batik.bridge.GVTBuilder.build(GVTBuilder.java:82) at org.apache.batik.swing.svg.GVTTreeBuilder.run(GVTTreeBuilder.java:96) And instead of using the specified font, a default system font will be used. Font Family names can contain punctuation AND numerical digits, batik needs to properly handle these cases. This is the correct font family as reported by the operating system. It seems batik is being a little too specific when verifying attribute values for font-family. From the w3c: http://www.w3.org/TR/REC-CSS2/fonts.html#font-family-prop
> <text> > <tspan font-size="0.5in" x="1in" y="251in" font-family="Avenir LT 35 > Light">Avenir LT 35 Light : lte50336.ttf</tspan> > <tspan font-size="0.5in" x="1in" y="252in" font-family="Avenir LT 35 Light"> > The Quick Red Fox Jumped Over The Lazy Dog > </tspan> > </text> Quick Update: surrounding the attribute value of font-family with single quotes fixes this exception font-family="'Avenir LT 35 Light'" But this still seems weird.
You are correct that quotes shouldn't be required for this font family name (but can be used to work around the bug).
(In reply to comment #2) > You are correct that quotes shouldn't be required for this font family name > (but can be used to work around the bug). > I don't know alot about the internals of batik, but it seems to try and map everything to a CSS style for internal storage, from a cursory glance at the code base. So it converts the font-family into a @font-face CSS element. In a @font-face element, font-families with spaces in them SHOULD be single quoted So perhaps what is happening, is that batik is barfing on @font-face: Some Font Name With Digits 123 Which technical under w3c should still be okay, as commas are used to seperate multi fonts. But perhaps batik's css compliance is overly strict. And single quoting injects the quotes, so batik is then processing... @font-face: 'Some Font Name With Digits 123' And batik's overly strict CSS impl is then ok with that.
I think the issue is that in org.apache.batik.css.engine.value.css2.FontFamilyManager.createValue() it is assumed that (non-generic, non-quoted) a font family name is parsed just as a sequence of CSS "identifier" tokens, when in fact they it should be parsed as a sequence of any token (except the ones listed in the spec as needing to be quoted (such as brackets, braces, etc.)).
This will be fixed by another ongoing bug (see bug 49968 comment 3). *** This bug has been marked as a duplicate of bug 49968 ***
(In reply to comment #5) > This will be fixed by another ongoing bug (see bug 49968 comment 3). > > *** This bug has been marked as a duplicate of bug 49968 *** Humm, maybe I could have marked this issue to depend on that bug instead (specially because usually newer bugs are marked duplicate of older ones), but I guess the duplication notation is reasonable in this case (as it will be fixed by that and also because the patch and further information is lying there). :-)