Arabic text being 'transformed' into something that looks Arabic but is not exactly the same as what I put in

2011-05-05 Thread Bas van den Broek
Hi all,

I recently received a ticket from an Arabic client that text being transformed 
using FOP was not quite the same as the input was. So I made a testproject and 
this is the XSL I'm putting into FOP:

?xml version=1.0 encoding=UTF-8?fo:root 
xmlns:fo=http://www.w3.org/1999/XSL/Format;
  fo:layout-master-set
fo:simple-page-master master-name=MyPage page-height=11.693in 
page-width=8.268in
  fo:region-body margin-bottom=0.5in margin-left=0.5in 
margin-right=0.5in margin-top=0.5in/
  fo:region-before display-align=before extent=0.5in 
region-name=xsl-region-before/
  fo:region-after display-align=after extent=0.5in 
region-name=xsl-region-after/
  fo:region-start extent=0.5in/
  fo:region-end extent=0.5in/
/fo:simple-page-master
  /fo:layout-master-set
  fo:page-sequence master-reference=MyPage
fo:flow flow-name=xsl-region-body
  fo:block color=#00 font-family=tahoma font-size=10pt 
font-style=normal font-weight=normal
fo:block
  fo:table border-collapse=separate border-spacing=0pt 
padding=0pt table-layout=fixed text-align=left width=100%
fo:table-column column-width=50%/
fo:table-column column-width=50%/
fo:table-body
  fo:table-row
fo:table-cell display-align=before text-align=left
  fo:block white-space-collapse=false wrap-option=wrap
fo:block linefeed-treatment=preserve 
white-space-collapse=false wrap-option=wrapعربي/fo:block
  /fo:block
/fo:table-cell
fo:table-cell display-align=before text-align=left
  fo:block white-space-collapse=false wrap-option=wrap/
/fo:table-cell
  /fo:table-row
  fo:table-row
fo:table-cell display-align=before text-align=left
  fo:block white-space-collapse=false wrap-option=wrap
fo:block linefeed-treatment=preserve 
white-space-collapse=false wrap-option=wrapعربي/fo:block
  /fo:block
/fo:table-cell
fo:table-cell display-align=before text-align=left
  fo:block white-space-collapse=false wrap-option=wrap/
/fo:table-cell
  /fo:table-row
/fo:table-body
  /fo:table
/fo:block
fo:block id=terminator/
  /fo:block
/fo:flow
  /fo:page-sequence
/fo:root

(Apologies for the overly long XSL, this is being generated)

Notice the Arabic text in 2 of the cells (I don't know what the word means btw)
I'm using Tahoma which is capable of showing these characters, and this font 
has been put into the font options.

font kerning=yes embed-url=tahoma.ttf
  font-triplet name=tahoma style=normal weight=normal/
  font-triplet name=tahomaMT style=normal weight=normal/
  /font

I used other fonts this way and this does not seem to be the problem anyway.

Also, using rl-tb instead of lr-tb does not solve the issue, it only does what 
you would expect, reverse the text.

The result looks like this:

يبرع
يبرع

Which certainly looks Arabic but is not quite the same as what I put in.

If I use another library (XFC) to transform the XSL to Word, it does show the 
Arabic text correctly.


Would be appreciated if anyone could help me out here.

Kind regards,

Bas van den Broek

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



Re: Arabic text being 'transformed' into something that looks Arabic but is not exactly the same as what I put in

2011-05-05 Thread Pascal Sancho
Hi Bas,

FOP currently doesn't support non-latin scripts.
Fortunately, Glenn Adams is working on this topic and has made a great job.

You can download sources from various locations (you'll have to build
FOP yourself):
 - complex scripts FOP branch:
https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ComplexScripts

 - Glenn's GIT:
git://github.com/skynavga/fop.git.


You can get further information here:
 - Glenn's Wiki:
https://skynav.trac.cvsdude.com/fop/wiki/ComplexScripts

 - Bugzilla FOP complex scripts entry:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687




Le 05/05/2011 11:03, Bas van den Broek a écrit :
 Hi all,
 
 I recently received a ticket from an Arabic client that text being 
 transformed using FOP was not quite the same as the input was. So I made a 
 testproject and this is the XSL I'm putting into FOP:
 
 ?xml version=1.0 encoding=UTF-8?fo:root 
 xmlns:fo=http://www.w3.org/1999/XSL/Format;
   fo:layout-master-set
 fo:simple-page-master master-name=MyPage page-height=11.693in 
 page-width=8.268in
   fo:region-body margin-bottom=0.5in margin-left=0.5in 
 margin-right=0.5in margin-top=0.5in/
   fo:region-before display-align=before extent=0.5in 
 region-name=xsl-region-before/
   fo:region-after display-align=after extent=0.5in 
 region-name=xsl-region-after/
   fo:region-start extent=0.5in/
   fo:region-end extent=0.5in/
 /fo:simple-page-master
   /fo:layout-master-set
   fo:page-sequence master-reference=MyPage
 fo:flow flow-name=xsl-region-body
   fo:block color=#00 font-family=tahoma font-size=10pt 
 font-style=normal font-weight=normal
 fo:block
   fo:table border-collapse=separate border-spacing=0pt 
 padding=0pt table-layout=fixed text-align=left width=100%
 fo:table-column column-width=50%/
 fo:table-column column-width=50%/
 fo:table-body
   fo:table-row
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap
 fo:block linefeed-treatment=preserve 
 white-space-collapse=false wrap-option=wrapعربي/fo:block
   /fo:block
 /fo:table-cell
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap/
 /fo:table-cell
   /fo:table-row
   fo:table-row
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap
 fo:block linefeed-treatment=preserve 
 white-space-collapse=false wrap-option=wrapعربي/fo:block
   /fo:block
 /fo:table-cell
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap/
 /fo:table-cell
   /fo:table-row
 /fo:table-body
   /fo:table
 /fo:block
 fo:block id=terminator/
   /fo:block
 /fo:flow
   /fo:page-sequence
 /fo:root
 
 (Apologies for the overly long XSL, this is being generated)
 
 Notice the Arabic text in 2 of the cells (I don't know what the word means 
 btw)
 I'm using Tahoma which is capable of showing these characters, and this font 
 has been put into the font options.
 
   font kerning=yes embed-url=tahoma.ttf
   font-triplet name=tahoma style=normal weight=normal/
   font-triplet name=tahomaMT style=normal weight=normal/
   /font
 
 I used other fonts this way and this does not seem to be the problem anyway.
 
 Also, using rl-tb instead of lr-tb does not solve the issue, it only does 
 what you would expect, reverse the text.
 
 The result looks like this:
 
 يبرع
 يبرع
 
 Which certainly looks Arabic but is not quite the same as what I put in.
 
 If I use another library (XFC) to transform the XSL to Word, it does show the 
 Arabic text correctly.
 
 
 Would be appreciated if anyone could help me out here.
 
 Kind regards,
 
 Bas van den Broek

-- 
Pascal

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



RE: Arabic text being 'transformed' into something that looks Arabic but is not exactly the same as what I put in

2011-05-05 Thread Bas van den Broek
Thanks, I'll look around a bit to see if I can get this to work.
Will this be integrated into FOP at some point? Any timeline that you know of?

Kind regards,

Bas van den Broek



-Original Message-
From: Pascal Sancho [mailto:pascal.san...@takoma.fr] 
Sent: Thursday, May 05, 2011 11:30
To: fop-users@xmlgraphics.apache.org
Subject: Re: Arabic text being 'transformed' into something that looks Arabic 
but is not exactly the same as what I put in

Hi Bas,

FOP currently doesn't support non-latin scripts.
Fortunately, Glenn Adams is working on this topic and has made a great job.

You can download sources from various locations (you'll have to build
FOP yourself):
 - complex scripts FOP branch:
https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ComplexScripts

 - Glenn's GIT:
git://github.com/skynavga/fop.git.


You can get further information here:
 - Glenn's Wiki:
https://skynav.trac.cvsdude.com/fop/wiki/ComplexScripts

 - Bugzilla FOP complex scripts entry:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687




Le 05/05/2011 11:03, Bas van den Broek a écrit :
 Hi all,
 
 I recently received a ticket from an Arabic client that text being 
 transformed using FOP was not quite the same as the input was. So I made a 
 testproject and this is the XSL I'm putting into FOP:
 
 ?xml version=1.0 encoding=UTF-8?fo:root 
 xmlns:fo=http://www.w3.org/1999/XSL/Format;
   fo:layout-master-set
 fo:simple-page-master master-name=MyPage page-height=11.693in 
 page-width=8.268in
   fo:region-body margin-bottom=0.5in margin-left=0.5in 
 margin-right=0.5in margin-top=0.5in/
   fo:region-before display-align=before extent=0.5in 
 region-name=xsl-region-before/
   fo:region-after display-align=after extent=0.5in 
 region-name=xsl-region-after/
   fo:region-start extent=0.5in/
   fo:region-end extent=0.5in/
 /fo:simple-page-master
   /fo:layout-master-set
   fo:page-sequence master-reference=MyPage
 fo:flow flow-name=xsl-region-body
   fo:block color=#00 font-family=tahoma font-size=10pt 
 font-style=normal font-weight=normal
 fo:block
   fo:table border-collapse=separate border-spacing=0pt 
 padding=0pt table-layout=fixed text-align=left width=100%
 fo:table-column column-width=50%/
 fo:table-column column-width=50%/
 fo:table-body
   fo:table-row
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap
 fo:block linefeed-treatment=preserve 
 white-space-collapse=false wrap-option=wrapعربي/fo:block
   /fo:block
 /fo:table-cell
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap/
 /fo:table-cell
   /fo:table-row
   fo:table-row
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap
 fo:block linefeed-treatment=preserve 
 white-space-collapse=false wrap-option=wrapعربي/fo:block
   /fo:block
 /fo:table-cell
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap/
 /fo:table-cell
   /fo:table-row
 /fo:table-body
   /fo:table
 /fo:block
 fo:block id=terminator/
   /fo:block
 /fo:flow
   /fo:page-sequence
 /fo:root
 
 (Apologies for the overly long XSL, this is being generated)
 
 Notice the Arabic text in 2 of the cells (I don't know what the word means 
 btw)
 I'm using Tahoma which is capable of showing these characters, and this font 
 has been put into the font options.
 
   font kerning=yes embed-url=tahoma.ttf
   font-triplet name=tahoma style=normal weight=normal/
   font-triplet name=tahomaMT style=normal weight=normal/
   /font
 
 I used other fonts this way and this does not seem to be the problem anyway.
 
 Also, using rl-tb instead of lr-tb does not solve the issue, it only does 
 what you would expect, reverse the text.
 
 The result looks like this:
 
 يبرع
 يبرع
 
 Which certainly looks Arabic but is not quite the same as what I put in.
 
 If I use another library (XFC) to transform the XSL to Word, it does show the 
 Arabic text correctly.
 
 
 Would be appreciated if anyone could help me out here.
 
 Kind regards,
 
 Bas van den Broek

-- 
Pascal

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org


Overflow Exception

2011-05-05 Thread Marcos.Garcia

Hi everyone,

I'm working with FOP embedded in a Java project. During a transformation of
an XML file I get the following exception:

java.lang.StackOverflowError
at
org.apache.xpath.VariableStack.getLocalVariable(VariableStack.java:345)
at org.apache.xpath.operations.Variable.execute(Variable.java:214)
at org.apache.xpath.operations.Variable.execute(Variable.java:186)
at
org.apache.xpath.axes.FilterExprIteratorSimple.executeFilterExpr(FilterExprIteratorSimple.java:114)
at
org.apache.xpath.axes.FilterExprWalker.setRoot(FilterExprWalker.java:129)
at
org.apache.xpath.axes.WalkingIterator.setRoot(WalkingIterator.java:154)
at
org.apache.xpath.axes.LocPathIterator.asNode(LocPathIterator.java:298)
at org.apache.xpath.axes.LocPathIterator.bool(LocPathIterator.java:318)
at org.apache.xpath.XPath.bool(XPath.java:410)
at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:124)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
at
org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java:392)
at
org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java:246)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:139)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
   
.
at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:139)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
at
org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java:392)
at
org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java:246)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)

Seems like Xalan is doing a lot of recursive calls and the stack memory
overflows. Is there any way to overcome this problem?

Thanks in advance.

-- 
View this message in context: 
http://old.nabble.com/Overflow-Exception-tp31549235p31549235.html
Sent from the FOP - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



Re: Arabic text being 'transformed' into something that looks Arabic but is not exactly the same as what I put in

2011-05-05 Thread Pascal Sancho
I cannot say yes or no.

This feature is a big one, still in development, and needs always feedback.

Le 05/05/2011 12:02, Bas van den Broek a écrit :
 Thanks, I'll look around a bit to see if I can get this to work.
 Will this be integrated into FOP at some point? Any timeline that you know of?
 
 Kind regards,
 
 Bas van den Broek
 
 
 
 -Original Message-
 From: Pascal Sancho [mailto:pascal.san...@takoma.fr] 
 Sent: Thursday, May 05, 2011 11:30
 To: fop-users@xmlgraphics.apache.org
 Subject: Re: Arabic text being 'transformed' into something that looks Arabic 
 but is not exactly the same as what I put in
 
 Hi Bas,
 
 FOP currently doesn't support non-latin scripts.
 Fortunately, Glenn Adams is working on this topic and has made a great job.
 
 You can download sources from various locations (you'll have to build
 FOP yourself):
  - complex scripts FOP branch:
 https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ComplexScripts
 
  - Glenn's GIT:
 git://github.com/skynavga/fop.git.
 
 
 You can get further information here:
  - Glenn's Wiki:
 https://skynav.trac.cvsdude.com/fop/wiki/ComplexScripts
 
  - Bugzilla FOP complex scripts entry:
 https://issues.apache.org/bugzilla/show_bug.cgi?id=49687
 
 
 
 
 Le 05/05/2011 11:03, Bas van den Broek a écrit :
 Hi all,

 I recently received a ticket from an Arabic client that text being 
 transformed using FOP was not quite the same as the input was. So I made a 
 testproject and this is the XSL I'm putting into FOP:

 ?xml version=1.0 encoding=UTF-8?fo:root 
 xmlns:fo=http://www.w3.org/1999/XSL/Format;
   fo:layout-master-set
 fo:simple-page-master master-name=MyPage page-height=11.693in 
 page-width=8.268in
   fo:region-body margin-bottom=0.5in margin-left=0.5in 
 margin-right=0.5in margin-top=0.5in/
   fo:region-before display-align=before extent=0.5in 
 region-name=xsl-region-before/
   fo:region-after display-align=after extent=0.5in 
 region-name=xsl-region-after/
   fo:region-start extent=0.5in/
   fo:region-end extent=0.5in/
 /fo:simple-page-master
   /fo:layout-master-set
   fo:page-sequence master-reference=MyPage
 fo:flow flow-name=xsl-region-body
   fo:block color=#00 font-family=tahoma font-size=10pt 
 font-style=normal font-weight=normal
 fo:block
   fo:table border-collapse=separate border-spacing=0pt 
 padding=0pt table-layout=fixed text-align=left width=100%
 fo:table-column column-width=50%/
 fo:table-column column-width=50%/
 fo:table-body
   fo:table-row
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap
 fo:block linefeed-treatment=preserve 
 white-space-collapse=false wrap-option=wrapعربي/fo:block
   /fo:block
 /fo:table-cell
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap/
 /fo:table-cell
   /fo:table-row
   fo:table-row
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap
 fo:block linefeed-treatment=preserve 
 white-space-collapse=false wrap-option=wrapعربي/fo:block
   /fo:block
 /fo:table-cell
 fo:table-cell display-align=before text-align=left
   fo:block white-space-collapse=false wrap-option=wrap/
 /fo:table-cell
   /fo:table-row
 /fo:table-body
   /fo:table
 /fo:block
 fo:block id=terminator/
   /fo:block
 /fo:flow
   /fo:page-sequence
 /fo:root

 (Apologies for the overly long XSL, this is being generated)

 Notice the Arabic text in 2 of the cells (I don't know what the word means 
 btw)
 I'm using Tahoma which is capable of showing these characters, and this font 
 has been put into the font options.

  font kerning=yes embed-url=tahoma.ttf
   font-triplet name=tahoma style=normal weight=normal/
   font-triplet name=tahomaMT style=normal weight=normal/
   /font

 I used other fonts this way and this does not seem to be the problem anyway.

 Also, using rl-tb instead of lr-tb does not solve the issue, it only does 
 what you would expect, reverse the text.

 The result looks like this:

 يبرع
 يبرع

 Which certainly looks Arabic but is not quite the same as what I put in.

 If I use another library (XFC) to transform the XSL to Word, it does show 
 the Arabic text correctly.


 Would be appreciated if anyone could help me out here.

 Kind regards,

 Bas van den Broek
 

-- 
Pascal

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: 

Re: Overflow Exception

2011-05-05 Thread Pascal Sancho
Hi Marcos,

As you read the trace, this is not directly related to FOP (FOP
delegates the XSLT stage to Xalan).

You should have a look into your XSLT, probably an infinite loop nested
somewhere.

Note that better list for XSLT related questions can be found (see [1])

That said, you should provide a short XML+XSLT material reproducing the
described issue, whatever the list you choose.

[1] http://www.mulberrytech.com/xsl/xsl-list

Le 05/05/2011 12:51, Marcos.Garcia a écrit :
 
 Hi everyone,
 
 I'm working with FOP embedded in a Java project. During a transformation of
 an XML file I get the following exception:
 
 java.lang.StackOverflowError
 at
 org.apache.xpath.VariableStack.getLocalVariable(VariableStack.java:345)
 at org.apache.xpath.operations.Variable.execute(Variable.java:214)
 at org.apache.xpath.operations.Variable.execute(Variable.java:186)
 at
 org.apache.xpath.axes.FilterExprIteratorSimple.executeFilterExpr(FilterExprIteratorSimple.java:114)
 at
 org.apache.xpath.axes.FilterExprWalker.setRoot(FilterExprWalker.java:129)
 at
 org.apache.xpath.axes.WalkingIterator.setRoot(WalkingIterator.java:154)
 at
 org.apache.xpath.axes.LocPathIterator.asNode(LocPathIterator.java:298)
 at org.apache.xpath.axes.LocPathIterator.bool(LocPathIterator.java:318)
 at org.apache.xpath.XPath.bool(XPath.java:410)
 at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:124)
 at
 org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
 at
 org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java:392)
 at
 org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java:246)
 at
 org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
 at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:139)
 at
 org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)

 .
 at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:139)
 at
 org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
 at
 org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java:392)
 at
 org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java:246)
 at
 org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
 
 Seems like Xalan is doing a lot of recursive calls and the stack memory
 overflows. Is there any way to overcome this problem?
 
 Thanks in advance.
 

-- 
Pascal

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



Stackoverflow exception

2011-05-05 Thread Marcos García
Using FOP Trunk

Hi everyone,

I'm working with FOP embedded in a Java project. During a transformation of
an XML file I get the following exception:

java.lang.StackOverflowError
at
org.apache.xpath.VariableStack.getLocalVariable(VariableStack.java:345)
at org.apache.xpath.operations.Variable.execute(Variable.java:214)
at org.apache.xpath.operations.Variable.execute(Variable.java:186)
at
org.apache.xpath.axes.FilterExprIteratorSimple.executeFilterExpr(FilterExprIteratorSimple.java:114)
at
org.apache.xpath.axes.FilterExprWalker.setRoot(FilterExprWalker.java:129)
at
org.apache.xpath.axes.WalkingIterator.setRoot(WalkingIterator.java:154)
at
org.apache.xpath.axes.LocPathIterator.asNode(LocPathIterator.java:298)
at org.apache.xpath.axes.LocPathIterator.bool(LocPathIterator.java:318)
at org.apache.xpath.XPath.bool(XPath.java:410)
at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:124)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
at
org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java:392)
at
org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java:246)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:139)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)

.
at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:139)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
at
org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java:392)
at
org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java:246)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)

Seems like Xalan is doing a lot of recursive calls and the stack memory
overflows. Is there any way to overcome this problem?

Thanks in advance.


RE: Stackoverflow exception

2011-05-05 Thread Dan Gorst
Hey Marcos,
 
Out of interest, do you have log4j on your classpath?  I seem to remember 
having a similar problem a while back which was fixed by removing the log4j 
jars from my app. Actually, after upgrading my jre to a later release I was 
able to reinclude log4j without getting this issue so either way forward is 
worth trying...
 
Of course, this maybe something completely different.
 
Thanks,
Dan
 
 

Using FOP Trunk

Hi everyone,

I'm working with FOP embedded in a Java project. During a transformation of an 
XML file I get the following exception:

java.lang.StackOverflowError
at org.apache.xpath.VariableStack.getLocalVariable(VariableStack.java:345)
at org.apache.xpath.operations.Variable.execute(Variable.java:214)
at org.apache.xpath.operations.Variable.execute(Variable.java:186)
at 
org.apache.xpath.axes.FilterExprIteratorSimple.executeFilterExpr(FilterExprIteratorSimple.java:114)
at org.apache.xpath.axes.FilterExprWalker.setRoot(FilterExprWalker.java:129)
at org.apache.xpath.axes.WalkingIterator.setRoot(WalkingIterator.java:154)
at org.apache.xpath.axes.LocPathIterator.asNode(LocPathIterator.java:298)
at org.apache.xpath.axes.LocPathIterator.bool(LocPathIterator.java:318)
at org.apache.xpath.XPath.bool(XPath.java:410)
at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:124)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
at org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java:392)
at 
org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java:246)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:139)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)

.
at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:139)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
at org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java:392)
at 
org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java:246)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)

Seems like Xalan is doing a lot of recursive calls and the stack memory 
overflows. Is there any way to overcome this problem?

Thanks in advance.

Disclaimer: 

This e-mail (and any attachment) is confidential and may also be privileged. It 
is intended solely for the use of the individual to whom it is addressed. Any 
views or opinions presented are solely those of the author and do not 
necessarily represent those of Conveyancing Direct. Conveyancing Direct accepts 
no liability for the contents of this e-mail or of any attachment. If you are 
not the intended recipient, be advised that you have received this e-mail in 
error and that any use, dissemination, forwarding, disclosure, printing or 
copying is expressly prohibited. Further, if you are not the intended 
recipient, you are strictly prohibited from acting or refraining from acting in 
reliance on this e-mail. 

If you have received this mail in error please delete this e-mail and any 
attachments and notify the Conveyancing Direct IT Department by telephone on 
01525 244 555 or email to helpd...@cdpll.co.uk If you would prefer not to 
receive future mailings please email unsubscr...@cdpll.co.uk

This message has been checked for all known viruses by Webroot Virus Scanning 
Service.
Registered in England, Registration number: 04152278
Registered Office: The Bailey, Skipton, North Yorkshire, BD23 1DN
VAT Registration No. 500 2481 05

Re: Arabic text being 'transformed' into something that looks Arabic but is not exactly the same as what I put in

2011-05-05 Thread Simon Pepping
A build of the complex scripts branch can be found at
http://people.apache.org/~spepping/. Glenn's GIT repository contains
new work beyond the code that is in the complex scripts branch.

Feedback is very welcome.

Simon

On Thu, May 05, 2011 at 01:33:06PM +0200, Pascal Sancho wrote:
 I cannot say yes or no.
 
 This feature is a big one, still in development, and needs always feedback.
 
 Le 05/05/2011 12:02, Bas van den Broek a écrit :
  Thanks, I'll look around a bit to see if I can get this to work.
  Will this be integrated into FOP at some point? Any timeline that you know 
  of?
  
  Kind regards,
  
  Bas van den Broek
  
  
  
  -Original Message-
  From: Pascal Sancho [mailto:pascal.san...@takoma.fr] 
  Sent: Thursday, May 05, 2011 11:30
  To: fop-users@xmlgraphics.apache.org
  Subject: Re: Arabic text being 'transformed' into something that looks 
  Arabic but is not exactly the same as what I put in
  
  Hi Bas,
  
  FOP currently doesn't support non-latin scripts.
  Fortunately, Glenn Adams is working on this topic and has made a great job.
  
  You can download sources from various locations (you'll have to build
  FOP yourself):
   - complex scripts FOP branch:
  https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ComplexScripts
  
   - Glenn's GIT:
  git://github.com/skynavga/fop.git.
  
  
  You can get further information here:
   - Glenn's Wiki:
  https://skynav.trac.cvsdude.com/fop/wiki/ComplexScripts
  
   - Bugzilla FOP complex scripts entry:
  https://issues.apache.org/bugzilla/show_bug.cgi?id=49687
  
  
  
  
  Le 05/05/2011 11:03, Bas van den Broek a écrit :
  Hi all,
 
  I recently received a ticket from an Arabic client that text being 
  transformed using FOP was not quite the same as the input was. So I made a 
  testproject and this is the XSL I'm putting into FOP:
 
  ?xml version=1.0 encoding=UTF-8?fo:root 
  xmlns:fo=http://www.w3.org/1999/XSL/Format;
fo:layout-master-set
  fo:simple-page-master master-name=MyPage page-height=11.693in 
  page-width=8.268in
fo:region-body margin-bottom=0.5in margin-left=0.5in 
  margin-right=0.5in margin-top=0.5in/
fo:region-before display-align=before extent=0.5in 
  region-name=xsl-region-before/
fo:region-after display-align=after extent=0.5in 
  region-name=xsl-region-after/
fo:region-start extent=0.5in/
fo:region-end extent=0.5in/
  /fo:simple-page-master
/fo:layout-master-set
fo:page-sequence master-reference=MyPage
  fo:flow flow-name=xsl-region-body
fo:block color=#00 font-family=tahoma font-size=10pt 
  font-style=normal font-weight=normal
  fo:block
fo:table border-collapse=separate border-spacing=0pt 
  padding=0pt table-layout=fixed text-align=left width=100%
  fo:table-column column-width=50%/
  fo:table-column column-width=50%/
  fo:table-body
fo:table-row
  fo:table-cell display-align=before text-align=left
fo:block white-space-collapse=false 
  wrap-option=wrap
  fo:block linefeed-treatment=preserve 
  white-space-collapse=false wrap-option=wrapعربي/fo:block
/fo:block
  /fo:table-cell
  fo:table-cell display-align=before text-align=left
fo:block white-space-collapse=false 
  wrap-option=wrap/
  /fo:table-cell
/fo:table-row
fo:table-row
  fo:table-cell display-align=before text-align=left
fo:block white-space-collapse=false 
  wrap-option=wrap
  fo:block linefeed-treatment=preserve 
  white-space-collapse=false wrap-option=wrapعربي/fo:block
/fo:block
  /fo:table-cell
  fo:table-cell display-align=before text-align=left
fo:block white-space-collapse=false 
  wrap-option=wrap/
  /fo:table-cell
/fo:table-row
  /fo:table-body
/fo:table
  /fo:block
  fo:block id=terminator/
/fo:block
  /fo:flow
/fo:page-sequence
  /fo:root
 
  (Apologies for the overly long XSL, this is being generated)
 
  Notice the Arabic text in 2 of the cells (I don't know what the word means 
  btw)
  I'm using Tahoma which is capable of showing these characters, and this 
  font has been put into the font options.
 
 font kerning=yes embed-url=tahoma.ttf
font-triplet name=tahoma style=normal weight=normal/
font-triplet name=tahomaMT style=normal weight=normal/
/font
 
  I used other fonts this way and this does not seem to be the problem 
  anyway.
 
  Also, using rl-tb instead of lr-tb does not solve the issue, it only does 
  what you would expect, reverse the text.
 
  The result looks like this:
 
  يبرع
  يبرع
 
  Which certainly looks Arabic but is not quite the same 

Problem with Trunk - or is it

2011-05-05 Thread Theresa Jayne Forster
Hi Guys, 

I just pulled trunk and tried to create a PDF, unfortunately it doesn't seem
to work as the org.apache.fop.apps.MimeConstants.MIME_PDF is missing along
with some of the other entries. All we now have in there is 

 

/** Apache FOP's AWT preview (non-standard MIME type) */

String MIME_FOP_AWT_PREVIEW = application/X-fop-awt-preview;

/** Apache FOP's Direct Printing (non-standard MIME type) */

String MIME_FOP_PRINT   = application/X-fop-print;

/** Apache FOP's area tree XML */

String MIME_FOP_AREA_TREE   = application/X-fop-areatree;

/** Apache FOP's intermediate format XML */

String MIME_FOP_IF  = application/X-fop-intermediate-format;

 

Is this right or is this an oversight?

 

 

Kindest regards

 


Theresa Forster

Senior Software Developer

 mailto:ther...@inbrand.co.uk ther...@inbrand.co.uk
 http://www.inbrand.co.uk/ www.inbrand.co.uk

Tel: 01483 266500

 



 

IMPORTANT NOTE: This transmission has been sent by or on behalf of In Brand
Software Ltd. The information in this transmission is for the intended
addressee only and is confidential to that intended addressee. If either you
know or you ought reasonably to conclude that you are not, or may not be,
the intended addressee, you are hereby given notice that any unauthorised
dissemination or copying of this transmission and any disclosure or use of
the information
transmitted is strictly prohibited and may be illegal. In such circumstances
we ask for your assistance in notifying us immediately by e-mail, telephone
or letter.

InBrand Software Ltd Registered in England No. 5131004 Registered Office:
The Old Barn, Ewhurst Road, Cranleigh GU6 7EF 

 

image001.png