> I managed to get this working.. > I have to provide a mapping for the input characters from the user to the > unicode lookup. > If anyone is interested i exported all glyphs from illustrator and then > replaced the input characters with the unicode equivilants.
I believe this has to do with the encoding declared in the top level XML preamble. For example, if you use something like: <?xml version="1.0" encoding="utf-8"?> Then AFAIK the parser will only expect UTF-8 encoded characters and not their HTML-like encoded entities [1]. According to a somehow related message/thread [2] in the Amaya mailing list, you may be able to use the encoded entities if you set the "encoding" property to, for example, "iso-8859-1": <?xml version="1.0" encoding="iso-8859-1"?> Note that I haven't actually verified Batik behavior in this situation. >> Could it be that i need to convert the oslash to a unicode character or >> something similar? Note that Unicode and UTF-8 are not the same: UTF-8 [3] is merely a way to express Unicode characters. From my experiments, UTF-8 seems to be quite well supported cross SVG implementations and therefore I would recommend using it; nevertheless, other encoding(s) may better suite your needs. :-) Some additional information available at internationalization section [4] of the SVG specification. If you (still) feel the behavior you experienced is unexpected, I'd recommend creating the smallest SVG file which triggers the exception (basically, a reduced test case [5]) and attaching it in a reply to this thread. Hope this helps, Helder Magalhães [1] http://htmlhelp.com/reference/html40/entities/ [2] http://lists.w3.org/Archives/Public/www-amaya/2008JulSep/0073.html [3] http://en.wikipedia.org/wiki/UTF-8 [4] http://www.w3.org/TR/SVG/i18n.html [5] http://webkit.org/quality/reduction.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
