Hi Daniel,
If you're having problems building Xerces, then you should post something
on the Xerces list -- we can't help you with that.
As far as the problems you're seeing with tracing -- it's not surprising,
but we should be handling it a bit better. The issue is that transcoding
to the local code page to display trace events is always going to be dodgy.
If a character can't be represented, then it's pretty hard to display it on
the console. So, I guess I'd have to say that you shouldn't try to trace
when the document contains characters that are not representable in the
local code page. Linux is especially bad with regard to this, while other
platforms with better support for Unicode, like Solaris or Windows NT/2000,
aren't nearly as problematic.
As for the CGI problem -- I can't help you there. Maybe someone else on
the list has some experience in that area?
By the way, please don't cross-post to the general list -- these questions
are very Xerces and Xalan specific.
Dave
"Daniel Crown"
<daniel@mailgrat To: <[EMAIL PROTECTED]>
is.com.ar> cc: <[EMAIL PROTECTED]>,
(bcc: David N
Bertoni/CAM/Lotus)
08/09/2001 02:15 Subject: Xalan/ICU integration bugs?
AM
Please respond
to xalan-dev
Hello there,
I'm running Xalan-1.1 with Xerces-1.4 and ICU 1.6, and I'm having some
weird
problems that I think that might be bugs on the ICU integration.
Please note that I performed the installation _exactly_ as it is specified
on the docs and I tried to compile all the things on two separate servers
with different Linux versions (RH 6.2 and 7.0). I also tried using
combinations of Xerces 1.5.1 and ICU 1.8.1.
Here goes the problems that I'm having with ICU and Xalan/Xerces:
- If I compile Xerces using the icu message loader with 'runConfigure -p
linux -m icu -t icu', the file
$XERCESCROOT/src/util/Platforms/Linux/LinuxPlatformUtils.cpp fails to
compile and is not included on the xerces shared object.
The only way to create a working shared object is to compile Xerces using
the inmem message loader.
And below are some strange behaviors:
- This is what happens testing testXSLT on a XML / XSL files encoded with
UTF-8:
Using <xsl:output method="html" encoding="iso-8859-1"/>:
[root@neo bin]# ./testXSLT -IN salida.xml -OUT salida.out -TTC
========= Parsing salida.xml ==========
Parse of salida.xml took 10 milliseconds
========= Parsing and preparing http://neo/neo/ab.xsl ==========
Parsing and init of http://neo/neo/ab.xsl took 110 milliseconds
=============================
Transforming...
Line #4, Column #25: xsl:template match="/"
Line #5, Column #7: html
...
Line #21, Column #47: font
Line #27, Column #32: #text XSL Warning: Unknown Exception
XSLException Type is : TranscodingException
Message is : An error occurred while transcoding!
Using <xsl:output method="html" encoding="big5"/> gives a segfault: (or
other shift-jis, etc)
[root@neo bin]# ./testXSLT -IN salida.xml -OUT salida.out -TTC
========= Parsing salida.xml ==========
Parse of salida.xml took 20 milliseconds
========= Parsing and preparing http://neo/neo/ab.xsl ==========
Parsing and init of http://neo/neo/ab.xsl took 120 milliseconds
=============================
Transforming...
Line #4, Column #25: xsl:template match="/"
Line #5, Column #7: html
...
Line #21, Column #47: font
Line #27, Column #32: #text XSL Warning: Unknown Exception
Segmentation fault
However, if I run testXSLT without any tracing arguments, the file is
generated correctly for all output encodings.
- I have the following CGI test shell script:
#!/bin/sh
echo Content-type: text/plain
echo
/usr/local/src/xml-xalan/bin/testXSLT -IN
/usr/local/src/xml-xalan/bin/salida.xml -OUT /tmp/salida.out
The interesting thing here is that if I run this script from the prompt,
the
output file is created correctly.
However, if I run it as a CGI, the generated output file is a zero bytes
file. Same happens using Standard Output.
(I have all the ICU and Xalan/Xerces libraries on the path)
Do you have any ideas about what can be causing this?
TIA,
~ Daniel C.
UTN FRBA
