> Why don't you make the encoding match? When I create InputStream I do not know what will be encoding type.
> I'm pretty sure if you just remove the 'UTF-8' in the creation of > the InputStream the parser will do the right thing as well... Then the default encoding "Cp1252" (in my situation) will be used... ----- Original Message ----- From: "Thomas E Deweese" <[EMAIL PROTECTED]> To: "Batik Users" <[EMAIL PROTECTED]> Sent: Monday, October 14, 2002 14:25 Subject: Re: Encoding missmatch problem > >>>>> "ML" == Martynas Lelevicius <[EMAIL PROTECTED]> writes: > > ML> The problem is in "org.apache.batik.dom.util.SAXDocumentFactory" > ML> class "void warning(SAXParseException ex)" method. In my opinion > ML> the method should not throw exception as it does now. It could > ML> print error message and/or stack trace or smth... > > Why don't you make the encoding match? Isn't this 'The Right > Thing' (TM) to do?' > > I'm pretty sure if you just remove the 'UTF-8' in the creation of > the InputStream the parser will do the right thing as well... > > >> It seems that Crimson parser drops warning when declared encoding > >> does not match to InputStreamReader encoding. But the document > >> parsing should be processed through to the end. Is this Batik > >> "feature" that parsing is stopped? > >> > >> -- > >> marte > >> > >> ----- Original Message ----- From: "Martynas Lelevicius" > >> <[EMAIL PROTECTED]> To: "Batik Users" <[EMAIL PROTECTED]> > >> Sent: Monday, October 07, 2002 18:07 Subject: Re: Encoding > >> missmatch problem > >> > >> > >> > Hi, > >> > > >> > I attached the sample java source and the svg image file. > Try > >> to run sample and you'll get exception: > java.io.IOException: > >> Declared encoding "ISO-8859-1" does not match > ML> actual > >> > one "UTF8"; this might not be an error. > at > > >> org.apache.batik.dom.util.SAXDocumentFactory.createDocument(Unknown > >> Source) > at > > >> org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(Unknown > >> > Source) > at SvgTest.main(SvgTest.java:18) > >> > > >> > Interesting that changing encoding to "UTF-8" doesn't help, only > >> if encoding > is is set to "UTF8" or removed at all exception does > >> not occurs. > >> > > >> > Thanks. > >> > -- > >> > marte > >> > > >> > > >> > > >> > ----- Original Message ----- > From: "Thomas E Deweese" > >> <[EMAIL PROTECTED]> > To: "Batik Users" > >> <[EMAIL PROTECTED]> > Sent: Monday, October 07, 2002 13:46 > >> > Subject: RE: Encoding missmatch problem > >> > > >> > > >> > > >>>>> "ML" == Martynas Lelevicius <[EMAIL PROTECTED]> writes: > >> > > > >> > > ML> Hi, I try to create SVGOMDocument from the SVG file: > >> > > > >> > > ML> <...> SAXSVGDocumentFactory df = new > >> SAXSVGDocumentFactory(...); > > ML> SVGOMDocument doc = > >> df.createDocument(uri, inputStreamReader); > > ML> <...> > >> > > > >> > > ML> If the encoding declared in SVG (xml) file does not match > > >> > ML> InputStreamReader used encoding exception occurs: > > ML> > >> java.io.IOException: Declared encoding "ISO-8859-1" does not match > >> > > ML> actual one "UTF8"; this might not be an error. at > > ML> > ML> org.apache.batik.dom.util.SAXDocumentFactory.createDocument(Unknown > >> > > ML> Source) at > > ML> > >> org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(Unknown > >> > > ML> Source) <...> > >> > > > >> > > ML> How can I avoid this? > >> > > > >> > > This isn't my area of expertese, but it looks to me like the > > >> > InputSource was created incorrectly or the SVG file was created > > >> > incorrectly (I believe UTF8 files can have a 'magic number' that > >> > > starts them, it's possible that the XML parser picks this up > >> and then > > notices that this doesn't match the encoding declared > >> in the file it's > > self, the '<?xml version="1.0" ...>' tag). > >> > > > >> > > I've never seen this error myself, so it isn't a FAQ, and you > > >> > didn't really give a lot of information to go on (the SVG file > >> would > > be useful - putting it in a zip archive would help ensure > >> it's > > encoding didn't get munged during transport, and a > >> complete stack > > trace with line numbers would probably also help > >> - to see where the > > InputSource is being created). > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
