DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=39927>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39927 ------- Additional Comments From [EMAIL PROTECTED] 2006-08-02 12:15 ------- (In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #7) > > > In the meantime, it looks as if there's another bug in GCJ's 'transform' > > > package, or it's not being passed an option it requires. The generated > > > CodePointMappings.java contains lot's of XML entities such as '<', '>' and > > > '&'. So, for whatever reason, they're not getting resolved to their > > > respective '<', '>' & '&' characters! > > > > Ouch. That's a pretty basic thing. > > Well, having had a quick look at code-point-mapping.xsl and the XSLT spec at > http://www.w3.org/TR/xslt#disable-output-escaping I think GNU's transform is > actually conformant as there is no explicit instruction, that I can see, to > tell > it to not output conformant XML. But disable-output-escaping is for the XML output method and we're using the text output method. And it's not the output that's wrong, I think it's the parsing of the stylesheet that's not happening as it should. The XSLT should internally work with unescaped characters. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
