[jira] [Commented] (FOP-3141) - unexpected vertical position when bottom is provided instead of top
[ https://issues.apache.org/jira/browse/FOP-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750415#comment-17750415 ] Jan Tošovský commented on FOP-3141: --- Btw, this code was added by [~jerem...@apache.org] in revision [1721462|https://github.com/apache/xmlgraphics-fop/commit/17214623febc22024f3cc24491b4ea7669697641] titled Fixed block containers now working properly. > - unexpected vertical position > when bottom is provided instead of top > > > Key: FOP-3141 > URL: https://issues.apache.org/jira/browse/FOP-3141 > Project: FOP > Issue Type: Improvement > Components: layout/block >Affects Versions: 2.8 >Reporter: Jan Tošovský >Priority: Minor > Attachments: bottom.fo, bottom_absolute_fop.pdf, > bottom_absolute_xep.pdf, bottom_auto_fop.pdf, bottom_auto_xep.pdf, > bottom_current.pdf, bottom_expected.pdf, bottom_fixed_fop.pdf, > bottom_fixed_xep.pdf > > > When the block container is to be placed on the bottom edge, it is necessary > to specify the top position even if the bottom and height attributes are > specified (so the top position could be auto-calculated). > I actually try generating some FO files originally designed for XEP, but for > FOP I have to tweak all these top positions. It is straightforward, but I am > losing the original semantics (top="18.8cm" instead of more clear bottom="0"). > I could locate the possible place for tweaking: > [https://github.com/apache/xmlgraphics-fop/blob/main/fop-core/src/main/java/org/apache/fop/fo/properties/CommonRelativePosition.java] > In the constructor, if the top is zero, but both the bottom and the height > are non-zero, the top could be calculated. Same for the left and right + > width). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3141) - unexpected vertical position when bottom is provided instead of top
[ https://issues.apache.org/jira/browse/FOP-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tošovský updated FOP-3141: -- Summary: - unexpected vertical position when bottom is provided instead of top (was: - auto-calculating top/left positions based on bottom/right when height/width is provided) > - unexpected vertical position > when bottom is provided instead of top > > > Key: FOP-3141 > URL: https://issues.apache.org/jira/browse/FOP-3141 > Project: FOP > Issue Type: Improvement > Components: layout/block >Affects Versions: 2.8 >Reporter: Jan Tošovský >Priority: Minor > Attachments: bottom.fo, bottom_absolute_fop.pdf, > bottom_absolute_xep.pdf, bottom_auto_fop.pdf, bottom_auto_xep.pdf, > bottom_current.pdf, bottom_expected.pdf, bottom_fixed_fop.pdf, > bottom_fixed_xep.pdf > > > When the block container is to be placed on the bottom edge, it is necessary > to specify the top position even if the bottom and height attributes are > specified (so the top position could be auto-calculated). > I actually try generating some FO files originally designed for XEP, but for > FOP I have to tweak all these top positions. It is straightforward, but I am > losing the original semantics (top="18.8cm" instead of more clear bottom="0"). > I could locate the possible place for tweaking: > [https://github.com/apache/xmlgraphics-fop/blob/main/fop-core/src/main/java/org/apache/fop/fo/properties/CommonRelativePosition.java] > In the constructor, if the top is zero, but both the bottom and the height > are non-zero, the top could be calculated. Same for the left and right + > width). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3141) - auto-calculating top/left positions based on bottom/right when height/width is provided
[
https://issues.apache.org/jira/browse/FOP-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750385#comment-17750385
]
Jan Tošovský commented on FOP-3141:
---
I made some experiments and found the behavior of "fixed" is driven by
deliberate breaking out of the viewport in
[IFRenderer|https://github.com/apache/xmlgraphics-fop/blob/main/fop-core/src/main/java/org/apache/fop/render/intermediate/IFRenderer.java]:
{code:java}
//For FIXED, we need to break out of the current viewports to the
//one established by the page. We save the state stack for restoration
//after the block-container has been painted. See below.
List breakOutList = null;
if (bv.getPositioning() == Block.FIXED) {
breakOutList = breakOutOfStateStack();
}
AffineTransform positionTransform = new AffineTransform();
positionTransform.translate(bv.getXOffset(), bv.getYOffset());
{code}
{{bv.getYOffset()}} stores the desired "top" coordinate but that transformation
is not applied by that breakage. This handling is suspicious.
> - auto-calculating top/left
> positions based on bottom/right when height/width is provided
>
>
> Key: FOP-3141
> URL: https://issues.apache.org/jira/browse/FOP-3141
> Project: FOP
> Issue Type: Improvement
> Components: layout/block
>Affects Versions: 2.8
>Reporter: Jan Tošovský
>Priority: Minor
> Attachments: bottom.fo, bottom_absolute_fop.pdf,
> bottom_absolute_xep.pdf, bottom_auto_fop.pdf, bottom_auto_xep.pdf,
> bottom_current.pdf, bottom_expected.pdf, bottom_fixed_fop.pdf,
> bottom_fixed_xep.pdf
>
>
> When the block container is to be placed on the bottom edge, it is necessary
> to specify the top position even if the bottom and height attributes are
> specified (so the top position could be auto-calculated).
> I actually try generating some FO files originally designed for XEP, but for
> FOP I have to tweak all these top positions. It is straightforward, but I am
> losing the original semantics (top="18.8cm" instead of more clear bottom="0").
> I could locate the possible place for tweaking:
> [https://github.com/apache/xmlgraphics-fop/blob/main/fop-core/src/main/java/org/apache/fop/fo/properties/CommonRelativePosition.java]
> In the constructor, if the top is zero, but both the bottom and the height
> are non-zero, the top could be calculated. Same for the left and right +
> width).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3142) Fatal error when compiling large xsl templates
[
https://issues.apache.org/jira/browse/FOP-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750367#comment-17750367
]
Joshua Marquart commented on FOP-3142:
--
As an aside, I see secure-processing is being set, which causes failed XML
attribute generation issues since Xalan 2.7.2 (bug XALNJ-2591;
https://issues.apache.org/jira/browse/XALANJ-2591 ). This bug was resolved in
a servicemix release for Xalan 2.7.2, but the fix was not ported to Xalan
2.7.3. Not certain it affects, but caution should be considered.
> Fatal error when compiling large xsl templates
> --
>
> Key: FOP-3142
> URL: https://issues.apache.org/jira/browse/FOP-3142
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Huy Ho
>Priority: Critical
>
> After we updated from FOP 2.6 to the latest FOP 2.8 version, our application
> is running into the following error when compiling our stylesheets (stack
> trace below). To get around this issue, we downloaded the latest xalan-j
> 2.7.3 library from [https://xalan.apache.org/xalan-j/index.html] and drop
> them in the fop/lib directory.
>
> {{java.lang.RuntimeException: XPATH_LIMIT}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseTopLevel(Parser.java:1165)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseExpression(Parser.java:1112)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.VariableBase.parseContents(VariableBase.java:250)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Param.parseContents(Param.java:106)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:587)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Import.parseContents(Import.java:132)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:597)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.createAST(Parser.java:398)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:496)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:576)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:1018)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:817)}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:274)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
>
> {{ERROR: 'JAXP0801003: the compiler encountered XPath expressions with an
> accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{FATAL ERROR: 'JAXP0801003: the compiler encountered XPath expressions with
> an accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{[ERROR] FOP - Exception javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.>org.apache.fop.apps.FOPException:
> javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:296)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.mai
[jira] [Commented] (FOP-3142) Fatal error when compiling large xsl templates
[
https://issues.apache.org/jira/browse/FOP-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750355#comment-17750355
]
Huy Ho commented on FOP-3142:
-
Yes, that goes for any dependency library you're using. But considering that
xalan has not been updated until very recently, I am not sure I follow that
reasoning. The previous time this library was updated was over 9 years ago.
Xalan-Java 2.7.3 was released in April 2023.
Xalan-Java 2.7.2 was released in April 2014.
> Fatal error when compiling large xsl templates
> --
>
> Key: FOP-3142
> URL: https://issues.apache.org/jira/browse/FOP-3142
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Huy Ho
>Priority: Critical
>
> After we updated from FOP 2.6 to the latest FOP 2.8 version, our application
> is running into the following error when compiling our stylesheets (stack
> trace below). To get around this issue, we downloaded the latest xalan-j
> 2.7.3 library from [https://xalan.apache.org/xalan-j/index.html] and drop
> them in the fop/lib directory.
>
> {{java.lang.RuntimeException: XPATH_LIMIT}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseTopLevel(Parser.java:1165)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseExpression(Parser.java:1112)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.VariableBase.parseContents(VariableBase.java:250)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Param.parseContents(Param.java:106)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:587)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Import.parseContents(Import.java:132)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:597)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.createAST(Parser.java:398)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:496)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:576)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:1018)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:817)}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:274)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
>
> {{ERROR: 'JAXP0801003: the compiler encountered XPath expressions with an
> accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{FATAL ERROR: 'JAXP0801003: the compiler encountered XPath expressions with
> an accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{[ERROR] FOP - Exception javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.>org.apache.fop.apps.FOPException:
> javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:296)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
> {{Caused by: javax.xml.transform.
[jira] [Commented] (FOP-3142) Fatal error when compiling large xsl templates
[
https://issues.apache.org/jira/browse/FOP-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750352#comment-17750352
]
Simon Steiner commented on FOP-3142:
Bundling xalan mean we have to make a new fop release for every xalan security
fix
> Fatal error when compiling large xsl templates
> --
>
> Key: FOP-3142
> URL: https://issues.apache.org/jira/browse/FOP-3142
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Huy Ho
>Priority: Critical
>
> After we updated from FOP 2.6 to the latest FOP 2.8 version, our application
> is running into the following error when compiling our stylesheets (stack
> trace below). To get around this issue, we downloaded the latest xalan-j
> 2.7.3 library from [https://xalan.apache.org/xalan-j/index.html] and drop
> them in the fop/lib directory.
>
> {{java.lang.RuntimeException: XPATH_LIMIT}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseTopLevel(Parser.java:1165)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseExpression(Parser.java:1112)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.VariableBase.parseContents(VariableBase.java:250)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Param.parseContents(Param.java:106)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:587)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Import.parseContents(Import.java:132)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:597)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.createAST(Parser.java:398)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:496)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:576)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:1018)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:817)}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:274)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
>
> {{ERROR: 'JAXP0801003: the compiler encountered XPath expressions with an
> accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{FATAL ERROR: 'JAXP0801003: the compiler encountered XPath expressions with
> an accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{[ERROR] FOP - Exception javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.>org.apache.fop.apps.FOPException:
> javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:296)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
> {{Caused by: javax.xml.transform.TransformerConfigurationException:
> JAXP0801003: the compiler encountered XPath expressions with an accumulated
> '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.}}
> {{ at
>
[jira] [Commented] (FOP-3142) Fatal error when compiling large xsl templates
[
https://issues.apache.org/jira/browse/FOP-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750351#comment-17750351
]
Huy Ho commented on FOP-3142:
-
Please re-consider your decision to stop providing xalan as part of your
standard distribution when the one that comes bundled with JDK has this
internal issue. Such a decision forces us to have to update JDK eventually at
some point when the fix becomes available in the future just to use FOP. This
is not an ideal situation.
> Fatal error when compiling large xsl templates
> --
>
> Key: FOP-3142
> URL: https://issues.apache.org/jira/browse/FOP-3142
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Huy Ho
>Priority: Critical
>
> After we updated from FOP 2.6 to the latest FOP 2.8 version, our application
> is running into the following error when compiling our stylesheets (stack
> trace below). To get around this issue, we downloaded the latest xalan-j
> 2.7.3 library from [https://xalan.apache.org/xalan-j/index.html] and drop
> them in the fop/lib directory.
>
> {{java.lang.RuntimeException: XPATH_LIMIT}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseTopLevel(Parser.java:1165)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseExpression(Parser.java:1112)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.VariableBase.parseContents(VariableBase.java:250)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Param.parseContents(Param.java:106)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:587)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Import.parseContents(Import.java:132)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:597)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.createAST(Parser.java:398)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:496)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:576)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:1018)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:817)}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:274)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
>
> {{ERROR: 'JAXP0801003: the compiler encountered XPath expressions with an
> accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{FATAL ERROR: 'JAXP0801003: the compiler encountered XPath expressions with
> an accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{[ERROR] FOP - Exception javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.>org.apache.fop.apps.FOPException:
> javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:296)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
> {{Caused by: javax.xml.
[jira] [Commented] (FOP-3142) Fatal error when compiling large xsl templates
[
https://issues.apache.org/jira/browse/FOP-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750343#comment-17750343
]
Huy Ho commented on FOP-3142:
-
Thanks for the explanation. Here's the java we are running.
> java -version
Picked up _JAVA_OPTIONS: -Djava.io.tmpdir="/tmp" -XX:-UsePerfData -Xms128M
-Xmx2048m -Xss3M
openjdk version "11.0.19" 2023-04-18 LTS
OpenJDK Runtime Environment (Red_Hat-11.0.19.0.7-2) (build 11.0.19+7-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-11.0.19.0.7-2) (build 11.0.19+7-LTS, mixed
mode, sharing)
We have already tried adding the java definitions mentioned in the
stackoverflow link above to bypass the XPATH limit, however, it results in a
different error below. We initially thought it was a JDK issue and have
updated the JDK to the mentioned version, but that did not fix it either. The
only solution we have found to be working thus far is to drop in the xalan.jar
library.
Picked up _JAVA_OPTIONS: -Djava.io.tmpdir=/usr2/vdxfiles/vtmpgsql/rms/tmp
-XX:-UsePerfData -Xms2048m -Xmx2048m -Xss32m -Djdk.xml.xpathExprGrpLimit=0
-Djdk.xml.xpathExprOpLimit=0 -Djdk.xml.xpathTotalOpLimit=0
OpenJDK 64-Bit Server VM warning: Option AggressiveOpts was deprecated in
version 11.0 and will likely be removed in a future release.
FOP Version 2.8
ERROR: 'Could not compile stylesheet'
FATAL ERROR: 'Internal XSLTC error: a method in the translet exceeds the Java
Virtual Machine limitation on the length of a method of 64 kilobytes. This is
usually caused by templates in a stylesheet that are very large. Try
restructuring your stylesheet to use smaller templates.'
:Internal XSLTC error: a method in the translet exceeds the Java
Virtual Machine limitation on the length of a method of 64 kilobytes. This is
usually caused by templates in a stylesheet that are very large. Try
restructuring your stylesheet to use smaller templates.
[ERROR] FOP - Exception org.apache.fop.apps.FOPException:
javax.xml.transform.TransformerConfigurationException: Internal XSLTC error: a
method in the translet exceeds the Java Virtual Machine limitation on the
length of a method of 64 kilobytes. This is usually caused by templates in a
stylesheet that are very large. Try restructuring your stylesheet to use
smaller templates.
javax.xml.transform.TransformerConfigurationException: Internal XSLTC error: a
method in the translet exceeds the Java Virtual Machine limitation on the
length of a method of 64 kilobytes. This is usually caused by templates in a
stylesheet that are very large. Try restructuring your stylesheet to use
smaller templates.
> Fatal error when compiling large xsl templates
> --
>
> Key: FOP-3142
> URL: https://issues.apache.org/jira/browse/FOP-3142
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Huy Ho
>Priority: Critical
>
> After we updated from FOP 2.6 to the latest FOP 2.8 version, our application
> is running into the following error when compiling our stylesheets (stack
> trace below). To get around this issue, we downloaded the latest xalan-j
> 2.7.3 library from [https://xalan.apache.org/xalan-j/index.html] and drop
> them in the fop/lib directory.
>
> {{java.lang.RuntimeException: XPATH_LIMIT}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseTopLevel(Parser.java:1165)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseExpression(Parser.java:1112)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.VariableBase.parseContents(VariableBase.java:250)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Param.parseContents(Param.java:106)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:587)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Import.parseContents(Import.java:132)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:597)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.createAST(Parser.java:398)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:496)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:576)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactory
[jira] [Closed] (FOP-3142) Fatal error when compiling large xsl templates
[
https://issues.apache.org/jira/browse/FOP-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch closed FOP-3142.
---
Resolution: Not A Bug
As mentioned in the previous comments, this is not a bug in FOP. We merely
stopped providing Xalan as part of the standard distribution and we now use the
one bundled with Java, or you can provide your own version if required
> Fatal error when compiling large xsl templates
> --
>
> Key: FOP-3142
> URL: https://issues.apache.org/jira/browse/FOP-3142
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Huy Ho
>Priority: Critical
>
> After we updated from FOP 2.6 to the latest FOP 2.8 version, our application
> is running into the following error when compiling our stylesheets (stack
> trace below). To get around this issue, we downloaded the latest xalan-j
> 2.7.3 library from [https://xalan.apache.org/xalan-j/index.html] and drop
> them in the fop/lib directory.
>
> {{java.lang.RuntimeException: XPATH_LIMIT}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseTopLevel(Parser.java:1165)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseExpression(Parser.java:1112)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.VariableBase.parseContents(VariableBase.java:250)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Param.parseContents(Param.java:106)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:587)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Import.parseContents(Import.java:132)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:597)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.createAST(Parser.java:398)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:496)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:576)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:1018)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:817)}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:274)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
>
> {{ERROR: 'JAXP0801003: the compiler encountered XPath expressions with an
> accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{FATAL ERROR: 'JAXP0801003: the compiler encountered XPath expressions with
> an accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{[ERROR] FOP - Exception javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.>org.apache.fop.apps.FOPException:
> javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:296)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
> {{Caused by: javax.xml.transform.TransformerConfigurationException:
> JAXP0801003: the compiler encountered XPath expressions with an accumulated
[jira] [Updated] (FOP-3141) - auto-calculating top/left positions based on bottom/right when height/width is provided
[ https://issues.apache.org/jira/browse/FOP-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tošovský updated FOP-3141: -- Attachment: bottom_absolute_fop.pdf bottom_absolute_xep.pdf bottom_auto_fop.pdf bottom_auto_xep.pdf bottom_fixed_fop.pdf bottom_fixed_xep.pdf > - auto-calculating top/left > positions based on bottom/right when height/width is provided > > > Key: FOP-3141 > URL: https://issues.apache.org/jira/browse/FOP-3141 > Project: FOP > Issue Type: Improvement > Components: layout/block >Affects Versions: 2.8 >Reporter: Jan Tošovský >Priority: Minor > Attachments: bottom.fo, bottom_absolute_fop.pdf, > bottom_absolute_xep.pdf, bottom_auto_fop.pdf, bottom_auto_xep.pdf, > bottom_current.pdf, bottom_expected.pdf, bottom_fixed_fop.pdf, > bottom_fixed_xep.pdf > > > When the block container is to be placed on the bottom edge, it is necessary > to specify the top position even if the bottom and height attributes are > specified (so the top position could be auto-calculated). > I actually try generating some FO files originally designed for XEP, but for > FOP I have to tweak all these top positions. It is straightforward, but I am > losing the original semantics (top="18.8cm" instead of more clear bottom="0"). > I could locate the possible place for tweaking: > [https://github.com/apache/xmlgraphics-fop/blob/main/fop-core/src/main/java/org/apache/fop/fo/properties/CommonRelativePosition.java] > In the constructor, if the top is zero, but both the bottom and the height > are non-zero, the top could be calculated. Same for the left and right + > width). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3141) - auto-calculating top/left positions based on bottom/right when height/width is provided
[ https://issues.apache.org/jira/browse/FOP-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750236#comment-17750236 ] Jan Tošovský commented on FOP-3141: --- FYI, FOP outputs for variants with absolute-position="auto" or absolute-position="absolute" are identical to those generated by XEP. The only difference is for absolute-position="fixed". According to the [spec|https://www.w3.org/TR/xsl11/#absolute-position], I would expect it to be similar to absolute. > - auto-calculating top/left > positions based on bottom/right when height/width is provided > > > Key: FOP-3141 > URL: https://issues.apache.org/jira/browse/FOP-3141 > Project: FOP > Issue Type: Improvement > Components: layout/block >Affects Versions: 2.8 >Reporter: Jan Tošovský >Priority: Minor > Attachments: bottom.fo, bottom_absolute_fop.pdf, > bottom_absolute_xep.pdf, bottom_auto_fop.pdf, bottom_auto_xep.pdf, > bottom_current.pdf, bottom_expected.pdf, bottom_fixed_fop.pdf, > bottom_fixed_xep.pdf > > > When the block container is to be placed on the bottom edge, it is necessary > to specify the top position even if the bottom and height attributes are > specified (so the top position could be auto-calculated). > I actually try generating some FO files originally designed for XEP, but for > FOP I have to tweak all these top positions. It is straightforward, but I am > losing the original semantics (top="18.8cm" instead of more clear bottom="0"). > I could locate the possible place for tweaking: > [https://github.com/apache/xmlgraphics-fop/blob/main/fop-core/src/main/java/org/apache/fop/fo/properties/CommonRelativePosition.java] > In the constructor, if the top is zero, but both the bottom and the height > are non-zero, the top could be calculated. Same for the left and right + > width). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3141) - auto-calculating top/left positions based on bottom/right when height/width is provided
[ https://issues.apache.org/jira/browse/FOP-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tošovský updated FOP-3141: -- Summary: - auto-calculating top/left positions based on bottom/right when height/width is provided (was: Block container - auto-calculating top/left positions based on bottom/right when height/width is provided) > - auto-calculating top/left > positions based on bottom/right when height/width is provided > > > Key: FOP-3141 > URL: https://issues.apache.org/jira/browse/FOP-3141 > Project: FOP > Issue Type: Improvement > Components: layout/block >Affects Versions: 2.8 >Reporter: Jan Tošovský >Priority: Minor > Attachments: bottom.fo, bottom_current.pdf, bottom_expected.pdf > > > When the block container is to be placed on the bottom edge, it is necessary > to specify the top position even if the bottom and height attributes are > specified (so the top position could be auto-calculated). > I actually try generating some FO files originally designed for XEP, but for > FOP I have to tweak all these top positions. It is straightforward, but I am > losing the original semantics (top="18.8cm" instead of more clear bottom="0"). > I could locate the possible place for tweaking: > [https://github.com/apache/xmlgraphics-fop/blob/main/fop-core/src/main/java/org/apache/fop/fo/properties/CommonRelativePosition.java] > In the constructor, if the top is zero, but both the bottom and the height > are non-zero, the top could be calculated. Same for the left and right + > width). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3141) Block container - auto-calculating top/left positions based on bottom/right when height/width is provided
[ https://issues.apache.org/jira/browse/FOP-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tošovský updated FOP-3141: -- Summary: Block container - auto-calculating top/left positions based on bottom/right when height/width is provided (was: Auto-calculating top/left positions based on bottom/right when height/width is provided) > Block container - auto-calculating top/left positions based on bottom/right > when height/width is provided > - > > Key: FOP-3141 > URL: https://issues.apache.org/jira/browse/FOP-3141 > Project: FOP > Issue Type: Improvement > Components: layout/block >Affects Versions: 2.8 >Reporter: Jan Tošovský >Priority: Minor > Attachments: bottom.fo, bottom_current.pdf, bottom_expected.pdf > > > When the block container is to be placed on the bottom edge, it is necessary > to specify the top position even if the bottom and height attributes are > specified (so the top position could be auto-calculated). > I actually try generating some FO files originally designed for XEP, but for > FOP I have to tweak all these top positions. It is straightforward, but I am > losing the original semantics (top="18.8cm" instead of more clear bottom="0"). > I could locate the possible place for tweaking: > [https://github.com/apache/xmlgraphics-fop/blob/main/fop-core/src/main/java/org/apache/fop/fo/properties/CommonRelativePosition.java] > In the constructor, if the top is zero, but both the bottom and the height > are non-zero, the top could be calculated. Same for the left and right + > width). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3141) Auto-calculating top/left positions based on bottom/right when height/width is provided
[ https://issues.apache.org/jira/browse/FOP-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750217#comment-17750217 ] Jan Tošovský commented on FOP-3141: --- In my case, actually, [CommonAbsolutePosition|https://github.com/apache/xmlgraphics-fop/blob/main/fop-core/src/main/java/org/apache/fop/fo/properties/CommonAbsolutePosition.java] is invoked, but it lacks the parent context so it is impossible to determine the container dimensions (and perform the calculation) here. So the [BlockContainerLayoutManager|https://github.com/apache/xmlgraphics-fop/blob/main/fop-core/src/main/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java] turned out to be the better place. There is already some handling in the setupAreaDimensions method, but this method is not called for either fixed or absolute values of the absolute-position attribute. TBH I am not familiar with the spec to decide whether the current code conforms or not. > Auto-calculating top/left positions based on bottom/right when height/width > is provided > --- > > Key: FOP-3141 > URL: https://issues.apache.org/jira/browse/FOP-3141 > Project: FOP > Issue Type: Improvement > Components: layout/block >Affects Versions: 2.8 >Reporter: Jan Tošovský >Priority: Minor > Attachments: bottom.fo, bottom_current.pdf, bottom_expected.pdf > > > When the block container is to be placed on the bottom edge, it is necessary > to specify the top position even if the bottom and height attributes are > specified (so the top position could be auto-calculated). > I actually try generating some FO files originally designed for XEP, but for > FOP I have to tweak all these top positions. It is straightforward, but I am > losing the original semantics (top="18.8cm" instead of more clear bottom="0"). > I could locate the possible place for tweaking: > [https://github.com/apache/xmlgraphics-fop/blob/main/fop-core/src/main/java/org/apache/fop/fo/properties/CommonRelativePosition.java] > In the constructor, if the top is zero, but both the bottom and the height > are non-zero, the top could be calculated. Same for the left and right + > width). -- This message was sent by Atlassian Jira (v8.20.10#820010)
