Hi Mark, > Both of these pieces of information would be very useful to me as I'm > squirting the output back from a webserver, and it would be ideal to add > text/html, text/xml to the Content-Type: header, along with the appropriate > charset parameter. getOutputEncoding does exist, but it is the pair to > setOutputEncoding AFAICT -- which overrides what's specified in the > stylesheet, rather than reporting the actual encoding used during the (last) > transformation. Would there be any (reasonably easy, preferably!) way to > eek this information out?
This information doesn't come out of the transformation, so we would really have to figure out a way to return it that wouldn't disrupt the current interfaces. We cannot use XalanTransformer::getOutputEncoding(), as you pointed out, because that does something else. We cannot modify the XSLTResultTarget to return it, because we accept that as a const reference. We can't change that to a non-const reference, because that would prevent the compiler from creating temporaries, and would break auto-conversion to XSLTResultTarget. One thing we could do would be to put another accessor on XalanTransformer to return the actual encoding of the last transformation. If that sounds reasonable to you, please file a bugzilla request for an enhancement. I would welcome other opinions as to how to approach this. As a temporary workaround, you can determine the output encoding by trying to create a transcoder for the encoding specified in the stylesheet (or for the encoding specified in XSLTResultTarget or XalanTransformer, if you're trying to force the encoding). If that fails, because we cannot support the encoding, you can then assume the encoding is UTF-8. Thanks! Dave
