[jira] [Commented] (FOP-2520) Empty elements consume space
[
https://issues.apache.org/jira/browse/FOP-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14714197#comment-14714197
]
Björn Kautler commented on FOP-2520:
Ah, the profiling xsl had {{indent=yes}} for {{xsl:output}} and thus
formatted the output.
But I'm still unsure whether this is correct behaviour of FOP.
Shouldn't the space be insignificant in XML except within a text node?
I guess the problem is, that in this case there is mixed content, but afair the
parsed XML should have
{noformat}
fo:block-node
text-node without anything but whitespaces, or maybe even with empty
text
fo:wrapper-node
text-node without anything but whitespaces, or maybe even with empty
text
fo:wrapper-node
text-node without anything but whitespaces, or maybe even with empty
text
fo:wrapper-node
text-node without anything but whitespaces, or maybe even with empty
text
fo:wrapper-node
text-node with You can customize most tables in the product...
{noformat}
So shouldn't the empty text nodes be ignored instead of producing a slight
offset (without any characters like space character added) in the produced PDF
each?
Empty elements consume space
Key: FOP-2520
URL: https://issues.apache.org/jira/browse/FOP-2520
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Reporter: Björn Kautler
Attachments: empty space that should not be there.png
If you use {{indexterm}} tags in DocBook, the DocBook XSL stylesheets
generate empty {{fo:wrapper}} or {{fo:block}} elements with an {{id}}
attribute. These elements take up visible space if processed with FOP. Using
XEP, those empty tags do not consume any space.
Here an example excerpt from a FO file in question and [attached|^empty space
that should not be there.png] the result.
{code:xml}
fo:block space-before.optimum=0.6em space-before.minimum=0.4em
space-before.maximum=0.8em
fo:wrapper id=N1004F!--table, customize columns--/fo:wrapper
fo:wrapper id=N10056!--customize, table--/fo:wrapper
fo:wrapper id=N1005D!--filter, table--/fo:wrapper
fo:wrapper id=N10064!--table, filter--/fo:wrapperYou can customize
most tables in the product. The configured table view is saved in your user
profile and will be restored when you start the prouct the next time.
/fo:block
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
buildbot success in ASF Buildbot on fop-trunk
The Buildbot has detected a restored build on builder fop-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/fop-trunk/builds/49 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: orcus_ubuntu Build Reason: The Nightly scheduler named 'fopNightly' triggered this build Build Source Stamp: [branch xmlgraphics/fop/trunk] HEAD Blamelist: Build succeeded! Sincerely, -The Buildbot
[jira] [Closed] (FOP-2520) Empty elements consume space
[
https://issues.apache.org/jira/browse/FOP-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Sancho closed FOP-2520.
--
Resolution: Invalid
Hi,
text nodes are taken into account by both FOP and XEP.
if you want to discard spaces, you have to do it by yourself at XSLT stage,
depending on what XSLT engine (and options) you are using (FOP comes with Xalan
for convenience, but your may use your own).
As a good practice, you should not mix text nodes and FO elements in your XSLT
template, this prevent Xalan (or other) to keep blank text nodes in final
XSL-FO:
use an xsl:text to wrap the text You can customize ... the next time., and
all blank text nodes will magically disappear.
Empty elements consume space
Key: FOP-2520
URL: https://issues.apache.org/jira/browse/FOP-2520
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Reporter: Björn Kautler
Attachments: empty space that should not be there.png
If you use {{indexterm}} tags in DocBook, the DocBook XSL stylesheets
generate empty {{fo:wrapper}} or {{fo:block}} elements with an {{id}}
attribute. These elements take up visible space if processed with FOP. Using
XEP, those empty tags do not consume any space.
Here an example excerpt from a FO file in question and [attached|^empty space
that should not be there.png] the result.
{code:xml}
fo:block space-before.optimum=0.6em space-before.minimum=0.4em
space-before.maximum=0.8em
fo:wrapper id=N1004F!--table, customize columns--/fo:wrapper
fo:wrapper id=N10056!--customize, table--/fo:wrapper
fo:wrapper id=N1005D!--filter, table--/fo:wrapper
fo:wrapper id=N10064!--table, filter--/fo:wrapperYou can customize
most tables in the product. The configured table view is saved in your user
profile and will be restored when you start the prouct the next time.
/fo:block
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2520) Empty elements consume space
[
https://issues.apache.org/jira/browse/FOP-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14713551#comment-14713551
]
Björn Kautler commented on FOP-2520:
Ah, thanks for your help guys.
Actually it is the preprocessing of the file.
The profiling step we do before the DocBook-FOP for making the Doku customer-
and build-specific actually inserts newlines between the indexterms, so the
input DocBook for the DocBook XSL is
{noformat}
para
indexterm significance=normal
primarytable/primary
secondarycustomize columns/secondary
/indexterm
indexterm significance=normal
primarycustomize/primary
secondarytable/secondary
/indexterm
indexterm significance=normal
primaryfilter/primary
secondarytable/secondary
/indexterm
indexterm significance=normal
primarytable/primary
secondaryfilter/secondary
/indextermYou can customize most tables in the product. The
configured table view is saved in your user profile and will be restored when
you start the prouct the next time./para
{noformat}
I'll try to find out whether I can prevent this.
But still I wonder why it does not work even with that input and why it works
fine with XEP.
Empty elements consume space
Key: FOP-2520
URL: https://issues.apache.org/jira/browse/FOP-2520
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Reporter: Björn Kautler
Attachments: empty space that should not be there.png
If you use {{indexterm}} tags in DocBook, the DocBook XSL stylesheets
generate empty {{fo:wrapper}} or {{fo:block}} elements with an {{id}}
attribute. These elements take up visible space if processed with FOP. Using
XEP, those empty tags do not consume any space.
Here an example excerpt from a FO file in question and [attached|^empty space
that should not be there.png] the result.
{code:xml}
fo:block space-before.optimum=0.6em space-before.minimum=0.4em
space-before.maximum=0.8em
fo:wrapper id=N1004F!--table, customize columns--/fo:wrapper
fo:wrapper id=N10056!--customize, table--/fo:wrapper
fo:wrapper id=N1005D!--filter, table--/fo:wrapper
fo:wrapper id=N10064!--table, filter--/fo:wrapperYou can customize
most tables in the product. The configured table view is saved in your user
profile and will be restored when you start the prouct the next time.
/fo:block
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2520) Empty elements consume space
[
https://issues.apache.org/jira/browse/FOP-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14713410#comment-14713410
]
Björn Kautler commented on FOP-2520:
Actually I formatted the code a bit, yes.
Here the original code that is given to FOP:
{noformat}
fo:block space-before.optimum=0.6em space-before.minimum=0.4em
space-before.maximum=0.8em
fo:wrapper id=N10119!--table, customize columns--/fo:wrapper
fo:wrapper id=N10120!--customize, table--/fo:wrapper
fo:wrapper id=N10127!--filter, table--/fo:wrapper
fo:wrapper id=N1012E!--table, filter--/fo:wrapperYou can
customize most tables in the product. The configured table view is saved in
your user profile and will be restored when you start the prouct the next
time./fo:block
{noformat}
And here the oritinal code that is given to XEP:
{noformat}
fo:block space-before.optimum=0.6em space-before.minimum=0.4em
space-before.maximum=0.8em
fo:wrapper id=N10120
xmlns:rx=http://www.renderx.com/XSL/Extensions; rx:key=table, customize
columns/
fo:wrapper id=N10127
xmlns:rx=http://www.renderx.com/XSL/Extensions; rx:key=customize, table/
fo:wrapper id=N1012E
xmlns:rx=http://www.renderx.com/XSL/Extensions; rx:key=filter, table/
fo:wrapper id=N10135
xmlns:rx=http://www.renderx.com/XSL/Extensions; rx:key=table, filter/You
can customize most tables in the product. The configured table view is saved in
your user profile and will be restored when you start the prouct the next
time./fo:block
{noformat}
Both are produced like that by DocBook XSL stylesheets.
If I manually change the code given to FOP to this:
{noformat}
fo:block space-before.optimum=0.6em space-before.minimum=0.4em
space-before.maximum=0.8emfo:wrapper id=N10119!--table, customize
columns--/fo:wrapperfo:wrapper id=N10120!--customize,
table--/fo:wrapperfo:wrapper id=N10127!--filter,
table--/fo:wrapperfo:wrapper id=N1012E!--table,
filter--/fo:wrapperYou can customize most tables in the product. The
configured table view is saved in your user profile and will be restored when
you start the prouct the next time./fo:block
{noformat}
Then there is no space produced.
Also there are no actual space characters in the produced PDF, as you can see
in the screenshot.
Text selection shows that there are no space characters, just blank space that
is present.
Empty elements consume space
Key: FOP-2520
URL: https://issues.apache.org/jira/browse/FOP-2520
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Reporter: Björn Kautler
Attachments: empty space that should not be there.png
If you use {{indexterm}} tags in DocBook, the DocBook XSL stylesheets
generate empty {{fo:wrapper}} or {{fo:block}} elements with an {{id}}
attribute. These elements take up visible space if processed with FOP. Using
XEP, those empty tags do not consume any space.
Here an example excerpt from a FO file in question and [attached|^empty space
that should not be there.png] the result.
{code:xml}
fo:block space-before.optimum=0.6em space-before.minimum=0.4em
space-before.maximum=0.8em
fo:wrapper id=N1004F!--table, customize columns--/fo:wrapper
fo:wrapper id=N10056!--customize, table--/fo:wrapper
fo:wrapper id=N1005D!--filter, table--/fo:wrapper
fo:wrapper id=N10064!--table, filter--/fo:wrapperYou can customize
most tables in the product. The configured table view is saved in your user
profile and will be restored when you start the prouct the next time.
/fo:block
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2520) Empty elements consume space
[
https://issues.apache.org/jira/browse/FOP-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14713413#comment-14713413
]
Björn Kautler commented on FOP-2520:
And there is no space between the indexterms in the source DocBook File. Here
the corresponding part:
{noformat}
paraindexterm
primarytable/primary
secondarycustomize columns/secondary
/indextermindexterm
primarycustomize/primary
secondarytable/secondary
/indextermindexterm
primaryfilter/primary
secondarytable/secondary
/indextermindexterm
primarytable/primary
secondaryfilter/secondary
/indextermYou can customize most tables in the product. The configured
table view is saved in your user profile and will be restored when you start
the prouct the next time./para
{noformat}
Empty elements consume space
Key: FOP-2520
URL: https://issues.apache.org/jira/browse/FOP-2520
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Reporter: Björn Kautler
Attachments: empty space that should not be there.png
If you use {{indexterm}} tags in DocBook, the DocBook XSL stylesheets
generate empty {{fo:wrapper}} or {{fo:block}} elements with an {{id}}
attribute. These elements take up visible space if processed with FOP. Using
XEP, those empty tags do not consume any space.
Here an example excerpt from a FO file in question and [attached|^empty space
that should not be there.png] the result.
{code:xml}
fo:block space-before.optimum=0.6em space-before.minimum=0.4em
space-before.maximum=0.8em
fo:wrapper id=N1004F!--table, customize columns--/fo:wrapper
fo:wrapper id=N10056!--customize, table--/fo:wrapper
fo:wrapper id=N1005D!--filter, table--/fo:wrapper
fo:wrapper id=N10064!--table, filter--/fo:wrapperYou can customize
most tables in the product. The configured table view is saved in your user
profile and will be restored when you start the prouct the next time.
/fo:block
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2518) NullPointerException
[
https://issues.apache.org/jira/browse/FOP-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14713351#comment-14713351
]
Björn Kautler commented on FOP-2518:
I applied the patch that was attached to FOP-2461 locally and it works again,
so I think this was just a true duplicate, thanks.
NullPointerException
Key: FOP-2518
URL: https://issues.apache.org/jira/browse/FOP-2518
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Reporter: Björn Kautler
Priority: Blocker
FOP throws the following NPE when trying to transform a DocBook document to
PDF:
{noformat}
Caused by: java.lang.NullPointerException
at
org.apache.fop.layoutmgr.list.ListItemLayoutManager.getCombinedKnuthElementsForListItem(ListItemLayoutManager.java:405)
at
org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(ListItemLayoutManager.java:326)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:498)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
at
org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(ListBlockLayoutManager.java:103)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:223)
at
org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:147)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:116)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:69)
at
org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:252)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:643)
at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:178)
at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:158)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:384)
at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:112)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:138)
at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:267)
at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:130)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:360)
at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:190)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
at
