Re: Reader buggy for transformation? (Was: Re: Force encoding of resultdoc)

[Gary L Peskin <ga...@firstech.com>]

Scott_Boag@lotus.com wrote:
> 
> > It seems to me when you ask for a Writer output, you're asking
> > for a specific encoding
> 
> It's a little deeper than that even.  We can't set the encoding of a
> writer, nor can we tell what encoding it is (we only know we have a Writer,
> not an OutputStreamWriter).  The bottom line is, don't use Writers unless
> you have a specific reason to.  Xalan has zero control over the encoding in
> this case.

Yes, I meant conceptually when you create your own Writer which you pass
in to Xalan, you are asking for a specific encoding which, in my opinion
should override your instructions to Xalan.  Since we can't do much
else, I like my interpretation of the semantic meaning of passing in
your own Writer.  :)

> > System.setProperty("file.encoding", "UTF-8");
> 
> This won't do anything for Xalan, unless your method is "text" and your
> result is an OutputStream.  Otherwise the default is always UTF-8.

No, this was meant to affect the creation of your own Writer before
creating the StreamResult.  I don't know why it didn't work but that is
a problem for another day.

> > Now, if I
> > change the output encoding to "iso-8859-1" in <xsl:output />, the
> > streams do the job and output the utf-8 'ä' as iso-8859-1 'ä', but
> > the FileWriter doesn't!
> 
> If you pass in a Writer, the result is in the encoding of that Writer.  It
> can not be changed.

Yes.  As stated above.

> 
> > So if the FAQ entry would state that changing the encoding is only
> > safe with streams set for the StreamResult, everything's fine.
> 
> I thought the documentation did say that.  Not sure about the FAQ.  Don?
> 
> -scott

I thought I saw it in the docs as well but after looking for it, I can
only find it in the StreamResult(Writer) javadoc, generally considered a
write only document with respect to users :).  Don, perhaps you could
add something to the FAQ or a caution in the Usage Patterns.

Gary

> 
> 
>                     Bjoern Martin
>                     <mabj0011@fh-kar        To:     xalan-j-users@xml.apache.org
>                     lsruhe.de>              cc:     (bcc: Scott Boag/CAM/Lotus)
>                                             Subject:     Re: Reader buggy for transformation? (Was: Re: Force
>                     07/13/01 03:10          encoding of result  doc)
>                     AM
>                     Please respond
>                     to bjoern.martin
> 
> 
> 
> > Thanks, Bjoern.  I looked at Cmdline.java and this was the first
> > thing that jumped out at me.  I'm sure I'll be able to reproduce
> > it on my machine.  If this is a bug, I think it is mostly a bug
> > with the documentation but probably Scott and Joe should comment
> > on this since I haven't really thought it through.
> 
> Are they reading on this list? Or are we alone here? :)
> 
> > It seems to me when you ask for a Writer output, you're asking
> > for a specific encoding.  The one argument constructor for
> > FileWriter assumes an encoding of the java system property
> > file.encoding and that's what you used.  This overrides the
> > encoding requested in the XSLT.
> 
> I just added the line
> 
>  System.setProperty("file.encoding", "UTF-8");
> 
> in the beginning of the sample app, but nothing changed, as the line
> 
>  System.out.println(out1.getEncoding());
> 
> added after the file's written still returns "cp1252" :(
> 
> > I do think this merits a FAQ entry but I wouldn't change XalanJ.
> > What do you think?
> 
> That would be sufficient, as this only occurs if you change the
> encoding. Just to check I used an UTF-8 input and UTF-8 style,
> creating UTF-8 output - worked fine with the streams and FileWriter,
> though I still get encoding "cp1252" for the FileWriter. Now, if I
> change the output encoding to "iso-8859-1" in <xsl:output />, the
> streams do the job and output the utf-8 'ä' as iso-8859-1 'ä', but
> the FileWriter doesn't!
> So if the FAQ entry would state that changing the encoding is only
> safe with streams set for the StreamResult, everything's fine.
> 
> Regards.
> 
> --
> Bjoern Martin                                bjoern.martin@gmx.net