Michael, David:
We are not using Xalan. We are using Saxon 9 (jar obtained from
Saxonica/Source Forge) as our transformation engine, which takes
precedence in the classpath from the XEP lib directory.
Apparently, the saxon.jar bundled in XEP has less functionality than
ours (some XPATH related errors appear).
So far, we have done the PDF generation in a single step using an XSLT
using saxon9.jar, in Windows 32-bit and Linux without problems. The
problem appears in 64-bit, but I'm not sure where the problem is.
Using the XEP saxon.jar is not an option in the current generation
mechanism. I've downloaded the last version of saxon (saxon HE
9.3.0.4j), but I've got errors in the PDF generation even in 32-bit:
* [java] error: formatting failed: java.lang.NullPointerException:
Null content handler
*
or
*(document [system-id
file:/T:/development/cctool/cctool-dev/trunk/project-samples/bsi23/ase/ese01.fo]*
* [java] Parse error: Null content handler*
A workaround for the moment might be to split the generation process in
two steps, first generate a interim FO file using our transformation
sheet with saxon 9, and then generating the PDF with the bundled
saxon.jar (which I believe it works based on your tests on xep.bat).
So to summarize:
- What's the difference between the bundled saxon.jar with the
saxon9.jar you can obtain from Saxonica/Source Forge (XPATH?)
- I would believe that the problem then is in the saxon9.jar in 64-bit
platforms... but the new version does not work either
Thanks,
Alejandro
On 2/16/2011 10:22 AM, Michael Bradbury wrote:
> David,
>
> Before sending the FO file we ask that you provide:
>
> 1. Both ant script processes, the ant-controlled PDF generation and the
> version that generates the FO file.
> 2. Search your complete machine for xep.xml to make sure you don't have more
> than one copy. If you do have more than one please send by renaming them to
> identify which is which.
> 4. Search your complete machine for xep.bat to make sure you don't have more
> than one copy. If you do have more than one please send by renaming them to
> *.txt and identify which is which.
> 3. Which XML to XSL FO transformer are you using?
>
> As to determining which transformer you are using in my xep.bat the
> statement:
>
> set CP=C:\Program Files (x86)\RenderX\XEP\lib\xep.jar;C:\Program Files
> (x86)\RenderX\XEP\lib\saxon.jar;C:\Program Files
> (x86)\RenderX\XEP\lib\xt.jar
>
> contains 'saxon.jar' as the transformer.
>
> Regards,
>
> Michael Bradbury
> Dir Major Accounts, Bus Development
>
> the future of YOUR document is here
>
> RenderX, Inc.
>
> The future of YOUR document is here
>
> +1 (619) 692-9698 Direct & Voice Mail (San Diego, CA, USA)
> +1 (650) 327-1000
> +1 (650) 328-8008 Fax
> Skype: brad765
> bradbury@renderx.com
> sales@renderx.com
> http://www.renderx.com
>
>
>
>
> -----Original Message-----
> From: David Ochel [mailto:david@atsec.com]
> Sent: Tuesday, February 15, 2011 3:40 PM
> To: bradbury@renderx.com
> Cc: Alejandro Masino
> Subject: Re: FW: [renderx #22766] unstable validation errors in Win7/2008 @
> x64 JRE
>
> Hi Michael,
>
> Thanks for your and Kevin's time. Here is some news:
>
> 1. I have been able to generate a basic document that fails as described and
> doesn't contain any of our customer's information. So if you wanted I could
> send you our NDA template to sign and I could then share a FO with you.
> HOWEVER:
>
> 2. Running our "normal" ant-controlled PDF generation process with
> validation set to true, the generation fails with a validation error. But if
> I cause our framework to generate a FO file instead, and then run 'xep.bat
> foo.fo', it validates fine and generates a PDF file fine. And this with both
> 32-bit or 64-bit Java!
>
> So, it appears that I need to figure out what the difference is between
> invoking xep via xep.bat and invoking it via our ant framework. I've copied
> Alejandro, who is our framework mastermind, as I've no clue how to go about
> that... ;-)
>
> Cheers,
> David
>
> Michael Bradbury said the following on 2/15/2011 5:18 PM:
>> Hi David,
>>
>> Thank you for your time today.
>>
>> Since I have Sun Java 32 and 64-bit installed, and XEP is installed in
>> C:\Program Files (x86)\RenderX\XEP, I have two variations of my
>> xep.bat file, one calls Java 32 and the other Java 64.
>>
>>
>> My xep.bat that calls Java 32 consist of:
>>
>> @echo off
>> rem This batch file encapsulates a standard XEP call.
>>
>> set CP=C:\Program Files (x86)\RenderX\XEP\lib\xep.jar;C:\Program Files
>> (x86)\RenderX\XEP\lib\saxon.jar;C:\Program Files
>> (x86)\RenderX\XEP\lib\xt.jar
>>
>> if x%OS%==xWindows_NT goto WINNT
>> "C:\Program Files (x86)\Java\jre6\bin\java" "-Xmx1024M" -classpath "%CP%"
>> com.renderx.xep.XSLDriver "-DCONFIG=C:\Program Files
>> (x86)\RenderX\XEP\xep.xml" %1 %2 %3 %4 %5 %6 %7 %8 %9 goto END
>>
>> :WINNT
>> "C:\Program Files (x86)\Java\jre6\bin\java" "-Xmx1024M" -classpath "%CP%"
>> com.renderx.xep.XSLDriver "-DCONFIG=C:\Program Files
>> (x86)\RenderX\XEP\xep.xml" %*
>>
>> :END
>>
>> set CP=
>>
>> ===============================
>>
>> My xep64.bat that calls Java 64 consist of:
>>
>> @echo off
>> rem This batch file encapsulates a standard XEP call.
>>
>> set CP=C:\Program Files (x86)\RenderX\XEP\lib\xep.jar;C:\Program Files
>> (x86)\RenderX\XEP\lib\saxon.jar;C:\Program Files
>> (x86)\RenderX\XEP\lib\xt.jar
>>
>> if x%OS%==xWindows_NT goto WINNT
>> "C:\Program Files\Java\jre6\bin\java" "-Xmx8192M" -classpath "%CP%"
>> com.renderx.xep.XSLDriver "-DCONFIG=C:\Program Files
>> (x86)\RenderX\XEP\xep.xml" %1 %2 %3 %4 %5 %6 %7 %8 %9 goto END
>>
>> :WINNT
>> "C:\Program Files\Java\jre6\bin\java" "-Xmx8192M" -classpath "%CP%"
>> com.renderx.xep.XSLDriver "-DCONFIG=C:\Program Files
>> (x86)\RenderX\XEP\xep.xml" %*
>>
>> :END
>>
>> set CP=
>>
>> ===============================
>>
>>
>> You will note the differences are:
>>
>> - "C:\Program Files (x86)\Java\jre6\bin\java" vs. "C:\Program
>> Files\Java\jre6\bin\java"
>> - "-Xmx1024M" vs. "-Xmx8192M" (NOTE: 32-bit maximum value is 1024M
>> [M=mbytes]. You don't need 1024M given the size of the document's page
>> count. The Xmx value should not exceed 75% of the actual RAM (memeory)
>> in your machine).
>> - The remaining statements assume XEP was installed in C:\Program
>> Files (x86)\RenderX\XEP\
>>
>>
>> Regards,
>>
>> Michael Bradbury
>> Dir Major Accounts, Bus Development
>>
>> the future of YOUR document is here
>>
>> RenderX, Inc.
>>
>> The future of YOUR document is here
>>
>> +1 (619) 692-9698 Direct & Voice Mail (San Diego, CA, USA)
>> +1 (650) 327-1000
>> +1 (650) 328-8008 Fax
>> Skype: brad765
>> bradbury@renderx.com
>> sales@renderx.com
>> http://www.renderx.com
>>
>>
>>
>>
>> -----Original Message-----
>> From: David Ochel (via Support) [mailto:support-team@renderx.com]
>> Sent: Tuesday, February 15, 2011 2:09 PM
>> Cc: support-staff@renderx.com
>> Subject: Re: [renderx #22766] unstable validation errors in Win7/2008
>> @ x64 JRE
>>
>> Hi Michael,
>>
>> Michael Sulyaev (via Support) said the following on 2/11/2011 5:09 PM:
>>
>>> This is the dedicated support list. When replying please preserve the
>>> [renderx #22766] pattern on the subject line.
>>>
>>> I need to reproduce the issue in proper environment first of all, so
>>> please send a FO file where you observe unstable validation errors.
>> Working with proprietary customer data here, so this will be difficult.
>>
>>> David,
>>> what is your XEP version?
>> Version 4.18 build 20101125
>>
>>> I think I'll just find a Win7/2008 x64 machine and install x64 JDK
>>> from Sun there, play around and expect your FO files.
>> Let me know whether you get anywhere with the FO files from Jan and
> Tobias.
>> If not, I need to take some time to strip confidential data from one
>> of mine. I'm very short on time right now, though.
>>
>>> Spotting the reason would not take long if it is in XEP. But I am
>>> afraid it may happen to be between Java and XEP, which is worse.
>> Thanks, I really appreciate your help!
>>
>> Cheers,
>> David
>>
>> --
>> David Ochel, atsec information security mailto:david@atsec.com -
>> http://www.atsec.com - tel:+1.512.615.7376
>>
>>
>>
> --
> David Ochel, atsec information security
> mailto:david@atsec.com - http://www.atsec.com - tel:+1.512.615.7376
>
>
>
>
>
-- ______________________________________________________ Alejandro Fabio Masino atsec information security Visit our web-site at: www.atsec.com @sec: the information security provider Project=General ***SPAM*** !DSPAM:87,4d5dbbf963737522915389!
_______________________________________________
(*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support
(*) By using the Service, you expressly agree to these Terms of Service http://w
ww.renderx.com/terms-of-service.html
Received on Thu Feb 17 16:23:44 2011
This archive was generated by hypermail 2.1.8 : Thu Feb 17 2011 - 16:23:52 PST