xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: getURL and UFT-8
Date Sat, 12 Nov 2005 16:19:28 GMT
Hi André

"Andre M. Winter - Carto.net" <ml.winter@carto.net> wrote on 11/12/2005 
08:05:35 AM:

> thank you for that "3rd parameter" it seems to work and that way 
> different encodings could be parsed into the document.
> 
> at <http://svg.carto.net/temp/req7.svg> i have added this to the 
> functions and function calls.
> 
> i was only guessing the parameter's values and used 'UTF-8' and 'ANSI'. 
> do you have a list of values used in Batik for this?

   We just pass the given encoding to Java's charset stuff
you can read the full thing for JDK 1.4 at:

        
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/Charset.html

Standard charsets

Every implementation of the Java platform is required to support the 
following standard charsets. Consult the release documentation for your 
implementation to see if any other charsets are supported. 

Charset Description
US-ASCII        Seven-bit ASCII, a.k.a. ISO646-US, a.k.a. the Basic Latin 
block of the Unicode character set 
ISO-8859-1      ISO Latin Alphabet No. 1, a.k.a. ISO-LATIN-1 
UTF-8   Eight-bit UCS Transformation Format 
UTF-16BE        Sixteen-bit UCS Transformation Format, big-endian byte 
order 
UTF-16LE        Sixteen-bit UCS Transformation Format, little-endian byte 
order 
UTF-16  Sixteen-bit UCS Transformation Format, byte order identified by an 
optional byte-order mark

> 
> andré
> 
> 
> 
> thomas.deweese@kodak.com wrote:
> > Hi all,
> >
> >   So the situation is that there is actually a third parameter to 
'getURL' 
> > which is
> > the encoding to use on the returned content.  If this is not provided 
then 
> > Batik
> > uses the 'default' java encoding for your system (in your case 
obviously 
> > ASCII).
> >
> >    Since there is no spec for getURL it probably makes sense to mimic 
the
> > behavior of Adobe.  I will say that the choice to use UTF-8 
essentially 
> > makes
> > it impossible to transfer 'binary' data with getURL (although in this 
case 
> > I
> > suppose one could specify a no-op type encoding).
> >
> >    Cameron is also correct that it should look at the HTTP header (if 
> > present)
> > as I recall there were some nontrivial issues in parsing the 
Content-Type
> > (as I recall it actually is a list of tagged values, so some sort of 
hash 
> > table
> > would have to be exposed on ParsedURL (only populated by the HTTP
> > subclass) - this would also mean that you might have differences 
between
> > reading a file locally and reading the file from a server).
> >
> > "Andre M. Winter - Carto.net" <ml.winter@carto.net> wrote on 
11/12/2005 
> > 05:19:59 AM:
> >
> > 
> >> hi andreas and cameron,
> >>
> >> there are 3 static files and nothing else. the problem is the same 
> >> locally and from the server.
> >>
> >> - req5.svg (encoded UTF-8 and calling two others with getURL 
onclick):
> >> - req_utf8.xml (encoded UTF-8)
> >> - req_ascii.xml (encoded ASCII or basically no encoding at all)
> >>
> >> 
> 
> 
> 
> >> content of both xml files is:
> >> <tspan xmlns="http://www.w3.org/2000/svg"> éäö<tspan 
> >> fill="red">ß</tspan> </tspan>
> >>
> >>
> >> in Squiggle loading the
> >> ASCII renders "éäöß"
> >> UTF-8 renders "éäöß".
> >>
> >> in firefox and ASV3 it is the contrary, and that is the expected 
result 
> >> (as you say)
> >>
> >> ASCII renders placeholders
> >> UTF-8 renders "éäöß"
> >>
> >> this causes problem when laoding text data...
> >>
> >> give it a try,
> >> andré
> >>
> >>
> >>
> >> ps: the links to the both files in the original mail had a wrong 
> >> extension, here the right ones:
> >> <http://svg.carto.net/temp/req_utf8.xml>
> >> <http://svg.carto.net/temp/req_ascii.xml>
> >>
> >>
> >>
> >>
> >> Andreas Neumann wrote:
> >> 
> >>> Hi Andre,
> >>>
> >>> in Batik, if the original SVG file that you load has a certain 
> >>> encoding, all other linked files (scripts, css, document fragments 
> >>> that are loaded, etc.) need to have the same encoding.
> >>>
> >>> I think this is a valid behaviour and makes sense.
> >>>
> >>> So, in your case, if req5.svg is utf8, then the fragment to be 
loaded 
> >>> needs to be utf8 as well - makes sense, doesn't it?
> >>>
> >>> Andreas
> >>>
> >>> Andre M. Winter - Carto.net wrote:
> >>> 
> >>>> hello,
> >>>>
> >>>> i am testing getURL/XMLHttpRequest in Squiggle, Firefox and ASV and

i 
> >>>> 
> >
> > 
> >>>> run into a problem with UTF-8-encoded files
> >>>>
> >>>> in Firefox and AS anything works fine if all involved files are 
UFT-8 
> >>>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 

Mime
View raw message