Hi Mark, > > 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. > Yes, that's about the only reasonable way that I could think of. I'd like > to get hold of the output method as well as encoding (as it's perfectly > feasible for someone to transform a document to text/xml or text/plain), but > that can be handled in the same way.
You can do this by compiling the stylesheet and querying that information. The only caveat is that if there is no output method specified in the stylesheet, and the initial element generated is "html", the processor will use the html method, rather than the xml method. So, perhaps we can do the same enhancement for the output method. > > 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. > > > Part of the issue is that I don't have a clue what that encoding is. To get > at that, I'd need to parse the stylesheet and then go digging around in it. > Alternatively I can go grepping around the meta tags in the output (assuming > that it is html), but that's really fuggly. Again, you can get this by compiling the stylesheet for the transformation yourself, rather than letting the the XalanTranformer instance do it automatically. Thanks! Dave
