Hi Jan, >> > Is there any chance to test it on font as local file, not in the system? > >> Font.createFont(int fontType, java.io.InputStream src); > > Really so easily? Ok.
Well, apparently not [1] that easy, at least not for OpenType... :-| > After conversion into TTF everything works fine (even with original Batik > code) - also characters with weird codes are rendered properly... Glad to know it worked. ;-) > So I have to convert all font variants into TTF... > ... and to file a new feature request to Java developers :-) Maybe not -- the same post [1] states that Apache FOP should have support for these (maybe Jeremias can provide some input here). As the post is a few years old, I'm not sure if Batik already integrated that functionality and this may be as well be a bug in the OpenType support implementation and/or the font(s) may not conform to the OpenType specification... > One question remains. WHY I can see in the Batik renderer output in case of > OTF any characters with this font applied? I would suppose either nothing or > everything, nothing between... Humm, I guess this is the (font) fall-back mechanism kicking in: as no supported font is found for the rendering, the default one is used. I guess this is the same for all unsupported attributes in SVG, which should be ignored for the lacuna value [2]. One might argue that this was a case of (in)validity (but that is far beyond my knowledge of SVG and font handling). I see this mechanism as a Good thing, though -- or else, anyone without a specific font locally available and/or a broken font URI might render a document unusable. :-) Regards, Helder [1] http://www.javakb.com/Uwe/Forum.aspx/java-gui/2060/Loading-OpenType-fonts [2] http://www.w3.org/TR/SVGTiny12/intro.html#TermLacunaValue --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
