You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Adam Strzelecki <on...@java.pl> on 2005/12/16 15:58:26 UTC
Hyphetation broken with last commits
I'm using fop-hyph.jar built along with offo.sourceforge.net/
hyphetation XML files put into /hyph in SVN trunk. So everything is
fresh.. and since today I got following error when fop-hyph.jar is enabled:
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.get(Unknown Source)
at
org.apache.fop.layoutmgr.inline.TextLayoutManager.addALetterSpaceTo(TextLayoutManager.java:559)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager$Paragraph.addALetterSpace(LineLayoutManager.java:360)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager$Paragraph.access$700(LineLayoutManager.java:190)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LineLayoutManager.java:745)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:643)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:98)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextKnuthElements(PageSequenceLayoutManager.java:224)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:440)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextBlockList(PageSequenceLayoutManager.java:216)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:204)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:148)
at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:293)
at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:156)
at
org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:324)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1101)
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:484)
at
org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:141)
at org.apache.fop.cli.InputHandler.render(InputHandler.java:101)
at org.apache.fop.cli.Main.startFOP(Main.java:167)
at org.apache.fop.cli.Main.main(Main.java:201)
Thanks,
--
Adam Strzelecki |: nanoant.com :|
Re: Hyphetation broken with last commits
Posted by Adam Strzelecki <on...@java.pl>.
Hi Jeremias,
> Adam, that sounds a lot like you need to do an "ant clean", followed by
> a new build in FOP's root directory. Running "ant newPDF" in the
> examples/fo directory doesn't crash on any test file.
Well... I messed up with SVN.. you're right.. no examples/fo crash anymore.
>> Just wanted to let you know that it is not really related to the
>> hyphetation 8-O
>>
>> I just found other file that crashes FOP without using hyphetation....
>>
>> Seems addALetterSpaceTo is fetching element index -1 without checking if
>> it is -1...
>>
>> java.lang.ArrayIndexOutOfBoundsException: -1
>> at java.util.ArrayList.get(Unknown Source)
>> at
>> org.apache.fop.layoutmgr.inline.TextLayoutManager.addALetterSpaceTo(TextLayoutManager.java:559)
But this one still exists... at last I'm not the only one having this
problem (See Andreas posts).
Regards,
--
Adam Strzelecki |: nanoant.com :|
Re: Hyphetation broken with last commits
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Adam, that sounds a lot like you need to do an "ant clean", followed by
a new build in FOP's root directory. Running "ant newPDF" in the
examples/fo directory doesn't crash on any test file.
On 16.12.2005 17:24:32 Adam Strzelecki wrote:
> Just wanted to let you know that it is not really related to the
> hyphetation 8-O
>
> I just found other file that crashes FOP without using hyphetation....
>
> Seems addALetterSpaceTo is fetching element index -1 without checking if
> it is -1...
>
> java.lang.ArrayIndexOutOfBoundsException: -1
> at java.util.ArrayList.get(Unknown Source)
> at
> org.apache.fop.layoutmgr.inline.TextLayoutManager.addALetterSpaceTo(TextLayoutManager.java:559)
<snip/>
> ---------------------
>
> Also on examples/fo "ant" I get:
> java.lang.NoSuchMethodError:
> org.apache.fop.fonts.FontInfo.fontLookup([Ljava/lang/String;Ljava/lang/String;I)Ljava/lang/String;
> at
> org.apache.fop.fo.properties.CommonFont.getFontState(CommonFont.java:167)
> at
<snip/>
Jeremias Maerki
Re: Hyphetation broken with last commits
Posted by Adam Strzelecki <on...@java.pl>.
Hi Jeremias,
> Well, I'm really wondering why I couldn't reproduce the problem. Shrug.
Seems that Manuel fixes cured the problem.
Thanks Manuel !!!
New FOP build is pretty stable for me now, tested on several documents
(some of them over 100 pages) :)
>
>> I also spotted that after this SVN update that introduced this bug FOP
>> started to complain:
>>
>>> The extent in inline-progression-direction (width) of a table is bigger than the available space (468000mpt > 420000mpt) (fo:table, location: 323/133)
>>> The extent in inline-progression-direction (width) of a table is bigger than the available space (468000mpt > 420000mpt) (fo:table, location: 440/124)
>> ... when the margin-left="-4pc" for fo:block is set like that:
>
> Thanks for spotting that. I've just fixed it.
> http://svn.apache.org/viewcvs?rev=357674&view=rev
No more errors like that in new build.
Thanks a lot & regards,
--
Adam Strzelecki |: nanoant.com :|
Re: Hyphetation broken with last commits
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 16.12.2005 19:28:37 Adam Strzelecki wrote:
> Hi Andreas,
>
> Thanks for support. At last I'm not daydreaming about this bug ;)
Well, I'm really wondering why I couldn't reproduce the problem. Shrug.
> I also spotted that after this SVN update that introduced this bug FOP
> started to complain:
>
> > The extent in inline-progression-direction (width) of a table is bigger than the available space (468000mpt > 420000mpt) (fo:table, location: 323/133)
> > The extent in inline-progression-direction (width) of a table is bigger than the available space (468000mpt > 420000mpt) (fo:table, location: 440/124)
>
> ... when the margin-left="-4pc" for fo:block is set like that:
Thanks for spotting that. I've just fixed it.
http://svn.apache.org/viewcvs?rev=357674&view=rev
> > <fo:block font-family="Garamond,Symbol,ZapfDingbats" margin-left="-4pc">
> > <fo:table table-layout="fixed" width="100%" border-bottom-width="0.5pt" border-bottom-style="solid" border-bottom-color="black">
> > <fo:table-column column-number="1" column-width="proportional-column-width(1)" />
> > <fo:table-column column-number="2" column-width="proportional-column-width(1)" />
> > <fo:table-column column-number="3" column-width="proportional-column-width(1)" />
> > <fo:table-body>
> > <fo:table-row height="14pt">
> > <fo:table-cell text-align="left" display-align="before">
> > <fo:block>
> > <fo:block />
> > </fo:block>
> > </fo:table-cell>
> > <fo:table-cell text-align="center" display-align="before">
> > <fo:block>
> > <fo:block />
> > </fo:block>
> > </fo:table-cell>
> > <fo:table-cell text-align="right" display-align="before">
> > <fo:block>
> > <fo:block />
> > </fo:block>
> > </fo:table-cell>
> > </fo:table-row>
> > </fo:table-body>
> > </fo:table>
> > </fo:block>
>
> I don't know if it is a really something that a should care about... but
> now I receive lot of this errors (warnings ?).
They are warnings but as you can see by my fix above the checks were not
100% correct. The checks are a recent addition and are intended to help
identify problems in a stylesheet.
Jeremias Maerki
Re: Hyphetation broken with last commits
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 16, 2005, at 19:51, Andreas L Delmelle wrote:
> On Dec 16, 2005, at 18:26, Andreas L Delmelle wrote:
>
> Another detail that might be significant. If you move the space
> after the fo:inline to the end of the inline, the error doesn't
> seem to occur... Can anyone confirm? (Problem seems to be the
> element lists for the spaces following an fo:inline, IIC)
A quick FYI: Just confirmed that Manuel's hack indeed solved the
problem.
Gotta go now.
Later,
Andreas
Re: Hyphetation broken with last commits
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 16, 2005, at 18:26, Andreas L Delmelle wrote:
> To make up for it, I ran a few tests, managed to reduce the example
> provided by Adam, and the error (on my side, at least) seems to be
> caused by this fragment:
>
> <snip />
>
> As for the exact cause, I haven't figured that out yet...
Another detail that might be significant. If you move the space after
the fo:inline to the end of the inline, the error doesn't seem to
occur... Can anyone confirm? (Problem seems to be the element lists
for the spaces following an fo:inline, IIC)
Cheers,
Andreas
Re: Hyphetation broken with last commits
Posted by Adam Strzelecki <on...@java.pl>.
Hi Andreas,
Thanks for support. At last I'm not daydreaming about this bug ;)
I also spotted that after this SVN update that introduced this bug FOP
started to complain:
> The extent in inline-progression-direction (width) of a table is bigger than the available space (468000mpt > 420000mpt) (fo:table, location: 323/133)
> The extent in inline-progression-direction (width) of a table is bigger than the available space (468000mpt > 420000mpt) (fo:table, location: 440/124)
... when the margin-left="-4pc" for fo:block is set like that:
> <fo:block font-family="Garamond,Symbol,ZapfDingbats" margin-left="-4pc">
> <fo:table table-layout="fixed" width="100%" border-bottom-width="0.5pt" border-bottom-style="solid" border-bottom-color="black">
> <fo:table-column column-number="1" column-width="proportional-column-width(1)" />
> <fo:table-column column-number="2" column-width="proportional-column-width(1)" />
> <fo:table-column column-number="3" column-width="proportional-column-width(1)" />
> <fo:table-body>
> <fo:table-row height="14pt">
> <fo:table-cell text-align="left" display-align="before">
> <fo:block>
> <fo:block />
> </fo:block>
> </fo:table-cell>
> <fo:table-cell text-align="center" display-align="before">
> <fo:block>
> <fo:block />
> </fo:block>
> </fo:table-cell>
> <fo:table-cell text-align="right" display-align="before">
> <fo:block>
> <fo:block />
> </fo:block>
> </fo:table-cell>
> </fo:table-row>
> </fo:table-body>
> </fo:table>
> </fo:block>
I don't know if it is a really something that a should care about... but
now I receive lot of this errors (warnings ?).
Regards,
--
Adam Strzelecki |: nanoant.com :|
Re: Hyphetation broken with last commits
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 16, 2005, at 17:57, Andreas L Delmelle wrote:
> Sorry, ignore this. Removed the props in question, and still
> received the error...
>
> Sorry for the noise.
To make up for it, I ran a few tests, managed to reduce the example
provided by Adam, and the error (on my side, at least) seems to be
caused by this fragment:
<fo:block id="id373754">
<fo:block>
<fo:block>
<fo:block keep-together.within-column="always" margin-left="-4pc"
font-family="Garamond,Symbol,ZapfDingbats">
<fo:block xmlns:axf="http://www.antennahouse.com/names/XSL/
Extensions"
keep-with-next.within-column="always">
<fo:block font-family="Garamond" font-weight="bold"
keep-with-next.within-column="always"
space-before.minimum="0.8em" space-
before.optimum="1.0em"
space-before.maximum="1.2em" text-align="left"
start-indent="-4pc">
<fo:marker marker-class-name="section.head.marker">1.1.
Image Web Server modifications</fo:marker>
<fo:block font-size="17pt">1.1. <fo:inline font-
style="italic">Image Web Server</fo:inline> modifications</fo:block>
</fo:block>
</fo:block>
</fo:block>
</fo:block>
</fo:block>
<!-- rest of the block put in comment -->
</fo:block>
As for the exact cause, I haven't figured that out yet...
Cheers,
Andreas
Re: Hyphetation broken with last commits
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 16, 2005, at 17:51, Andreas L Delmelle wrote:
Sorry, ignore this. Removed the props in question, and still received
the error...
Sorry for the noise.
Cheers,
Andreas
> On Dec 16, 2005, at 17:24, Adam Strzelecki wrote:
>
> Hi fellas,
>
>> Just wanted to let you know that it is not really related to the
>> hyphetation 8-O
>>
>> I just found other file that crashes FOP without using
>> hyphetation....
>>
>> Seems addALetterSpaceTo is fetching element index -1 without
>> checking if
>> it is -1...
>
> Just as a heads-up:
> This error looked familiar to me. I encountered it while playing
> with the whitespace-handling algorithm (changes not committed yet).
> A quick search showed that there are two blocks in the FO file that
> have linefeed-treatment="preserve"... If I remember correctly,
> that's what this error is related to.
>
> Funny... My locally modified version --whitespace-handling moved up
> in the FO class hierarchy to FObjMixed--reports the same error, but
> for a zero index.
>
> Still not sure what the exact cause is, but this may point someone
> in the right direction (I hope).
>
> Cheers,
>
> Andreas
>
>
Re: Hyphetation broken with last commits
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 16, 2005, at 17:24, Adam Strzelecki wrote:
Hi fellas,
> Just wanted to let you know that it is not really related to the
> hyphetation 8-O
>
> I just found other file that crashes FOP without using hyphetation....
>
> Seems addALetterSpaceTo is fetching element index -1 without
> checking if
> it is -1...
Just as a heads-up:
This error looked familiar to me. I encountered it while playing with
the whitespace-handling algorithm (changes not committed yet). A
quick search showed that there are two blocks in the FO file that
have linefeed-treatment="preserve"... If I remember correctly, that's
what this error is related to.
Funny... My locally modified version --whitespace-handling moved up
in the FO class hierarchy to FObjMixed--reports the same error, but
for a zero index.
Still not sure what the exact cause is, but this may point someone in
the right direction (I hope).
Cheers,
Andreas
Re: Hyphetation broken with last commits
Posted by Adam Strzelecki <on...@java.pl>.
Just wanted to let you know that it is not really related to the
hyphetation 8-O
I just found other file that crashes FOP without using hyphetation....
Seems addALetterSpaceTo is fetching element index -1 without checking if
it is -1...
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.get(Unknown Source)
at
org.apache.fop.layoutmgr.inline.TextLayoutManager.addALetterSpaceTo(TextLayoutManager.java:559)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager$Paragraph.addALetterSpace(LineLayoutManager.java:360)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager$Paragraph.access$700(LineLayoutManager.java:190)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LineLayoutManager.java:745)
at
org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:643)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:272)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:104)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:98)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextKnuthElements(PageSequenceLayoutManager.java:224)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:440)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextBlockList(PageSequenceLayoutManager.java:216)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:204)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:148)
at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:293)
at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:156)
at
org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:324)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1101)
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:484)
at
org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:141)
at org.apache.fop.cli.InputHandler.render(InputHandler.java:101)
at org.apache.fop.cli.Main.startFOP(Main.java:167)
at org.apache.fop.cli.Main.main(Main.java:200)
---------------------
Also on examples/fo "ant" I get:
java.lang.NoSuchMethodError:
org.apache.fop.fonts.FontInfo.fontLookup([Ljava/lang/String;Ljava/lang/String;I)Ljava/lang/String;
at
org.apache.fop.fo.properties.CommonFont.getFontState(CommonFont.java:167)
at
org.apache.fop.layoutmgr.BlockLayoutManager.initialize(BlockLayoutManager.java:72)
at
org.apache.fop.layoutmgr.AbstractLayoutManager.getChildLM(AbstractLayoutManager.java:109)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:68)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextKnuthElements(PageSequenceLayoutManager.java:224)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:440)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextBlockList(PageSequenceLayoutManager.java:216)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:204)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:148)
at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:293)
at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:156)
at
org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:307)
at
com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:261)
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
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:611)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:709)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313)
at
org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:141)
at org.apache.fop.cli.InputHandler.render(InputHandler.java:101)
at org.apache.fop.tools.anttasks.FOPTaskStarter.render(Fop.java:544)
at org.apache.fop.tools.anttasks.FOPTaskStarter.run(Fop.java:505)
at org.apache.fop.tools.anttasks.Fop.execute(Fop.java:293)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
at
org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:107)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
Regards,
--
Adam Strzelecki |: nanoant.com :|
Re: Hyphetation broken with last commits
Posted by Manuel Mall <mm...@arcus.com.au>.
On Sun, 18 Dec 2005 08:21 pm, Simon Pepping wrote:
> On Sun, Dec 18, 2005 at 11:10:37AM +0100, Andreas L Delmelle wrote:
> > On Dec 18, 2005, at 06:16, Manuel Mall wrote:
> > >Does it mean because the Knuth algorithm removes all glues after a
> > >linebreak (and we also remove all glues at the end of a paragraph)
> > > a nbsp should not be modelled not like this:
> > >
> > > pen p=INF
> > > glue w=...
> > >
> > >but like this:
> > >
> > > box w=0 aux=true
> > > pen p=INF
> > > glue w=...
> > > box w=0 aux=true
> > >
> > >with the leading box preventing removal at the beginning of a
> > > line, the
> > >trailing box prevents removal at the end of a paragraph, and the
> > >penalty prevents a line break.
> >
> > As far as my understanding of the Knuth algorithm goes, that might
> > be a way to solve it. Even better would be to make the creation of
> > the auxiliary zero-width boxes conditional --depending on whether
> > there are already other boxes surrounding the nbsp (if at all
> > possible). It's really only in the cases where there are no
> > preceding/following boxes that we need special treatment, no? In
> > case of surrounding non- whitespace, the first model would seem to
> > be sufficient.
>
> That is indeed the way to solve it.
>
> The more I think about this, the more complicated it becomes.
>
> Maybe the Knuth algorithm requires that when there are multiple
> characters which are suppressed at linebreak, they are considered
> together, much like we do in space resolution in page breaking. One
> should avoid the situation glue - glue, if the first glue is to be
> suppressed when the second glue is a chosen line break. It should be
> a single glue, or a sequence like glue #1 - penalty - glue #2 - box -
> PENALTY - glue #3 if glue #1 and glue #3, i.e. the glues that remain
> around a line break, are not zero.
>
The simple glue - glue is not a problem as only glue elements directly
following a box are legal break points. But the other scenarios above
are tricky and yes I agree that consecutive whitespace should be
accumulated into a single glue element even if they cross inline
boundaries. Which is an interesting problem in itself especially as
this may involve a change in font(-size) and the individual spaces we
accumulate may have different widths. A particularly interesting
scenario is an inline with a border:
...<fo:inline border="..."> text1 </fo:inline> text2
Here we don't want to break at the space after text1 because that would
push a solitary border to the next line but if we break at the space
before text2 the space after text1 must also be removed (assuming the
default whitespace related property settings). Currently we generate
something like (simplified):
box for text1
glue
box for border
glue
but what is needed is more like:
box for text1
box for border
glue for both spaces
This reorders / merges elements across inline boundaries and makes the
mapping of the Knuth elements back to the inline text fragments for
area tree generation very interesting (or shall we say challenging?).
You are probably aware of my discussions with Luca on this topic
(redesigning the Knuth element generation for paragraphs). Its these
messy situations which so far have eluded my attempts to come up with a
clean solution.
> Simon
Manuel
Re: Hyphetation broken with last commits
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Sun, Dec 18, 2005 at 11:10:37AM +0100, Andreas L Delmelle wrote:
> On Dec 18, 2005, at 06:16, Manuel Mall wrote:
> >Does it mean because the Knuth algorithm removes all glues after a
> >linebreak (and we also remove all glues at the end of a paragraph) a
> >nbsp should not be modelled not like this:
> >
> > pen p=INF
> > glue w=...
> >
> >but like this:
> >
> > box w=0 aux=true
> > pen p=INF
> > glue w=...
> > box w=0 aux=true
> >
> >with the leading box preventing removal at the beginning of a line,
> >the
> >trailing box prevents removal at the end of a paragraph, and the
> >penalty prevents a line break.
>
> As far as my understanding of the Knuth algorithm goes, that might be
> a way to solve it. Even better would be to make the creation of the
> auxiliary zero-width boxes conditional --depending on whether there
> are already other boxes surrounding the nbsp (if at all possible).
> It's really only in the cases where there are no preceding/following
> boxes that we need special treatment, no? In case of surrounding non-
> whitespace, the first model would seem to be sufficient.
That is indeed the way to solve it.
The more I think about this, the more complicated it becomes.
Maybe the Knuth algorithm requires that when there are multiple
characters which are suppressed at linebreak, they are considered
together, much like we do in space resolution in page breaking. One
should avoid the situation glue - glue, if the first glue is to be
suppressed when the second glue is a chosen line break. It should be a
single glue, or a sequence like glue #1 - penalty - glue #2 - box -
PENALTY - glue #3 if glue #1 and glue #3, i.e. the glues that remain
around a line break, are not zero.
Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Hyphetation broken with last commits
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 18, 2005, at 06:16, Manuel Mall wrote:
Hi Manuel / Simon,
> On Sun, 18 Dec 2005 03:30 am, Simon Pepping wrote:
>>
>> It is not a formal contradiction, but it feels like one: nbsp should
>> not have a linebreak around it, but here we have to solve the problem
>> how to deal with it when it does have a linebreak preceding or
>> following it.
>>
> <snip />
> While I still don't quite agree with the statement
> 'nbsp should not have a linebreak around it' because nbsp
> surrounded by
> whitespace (and therefore surrounded by possible linebreaks) for
> example is perfectly legal and sensible in some situations this really
> is not important here.
Good point, although that is again a very exceptional situation...
<fo:inline>   </fo:inline>
Very theoretical. Although one can imagine this occurring, I believe
the probability is extremely low.
> Does it mean because the Knuth algorithm removes all glues after a
> linebreak (and we also remove all glues at the end of a paragraph) a
> nbsp should not be modelled not like this:
>
> pen p=INF
> glue w=...
>
> but like this:
>
> box w=0 aux=true
> pen p=INF
> glue w=...
> box w=0 aux=true
>
> with the leading box preventing removal at the beginning of a line,
> the
> trailing box prevents removal at the end of a paragraph, and the
> penalty prevents a line break.
As far as my understanding of the Knuth algorithm goes, that might be
a way to solve it. Even better would be to make the creation of the
auxiliary zero-width boxes conditional --depending on whether there
are already other boxes surrounding the nbsp (if at all possible).
It's really only in the cases where there are no preceding/following
boxes that we need special treatment, no? In case of surrounding non-
whitespace, the first model would seem to be sufficient.
Andreas
Re: Hyphetation broken with last commits
Posted by Manuel Mall <mm...@arcus.com.au>.
On Sun, 18 Dec 2005 03:30 am, Simon Pepping wrote:
> On Sat, Dec 17, 2005 at 05:46:42PM +0100, Andreas L Delmelle wrote:
> > On Dec 17, 2005, at 16:29, Manuel Mall wrote:
> >
> >
> > Hi,
> >
> > >On Sat, 17 Dec 2005 11:07 pm, Simon Pepping wrote:
> > >>On Sat, Dec 17, 2005 at 11:43:36AM +0800, Manuel Mall wrote:
> > >
> > ><snip/>
> > >
> > >>The case is contradictory in itself, and quite unique. A nbsp
> > >> will never occur at the end of a line by its very definition,
> > >> except in this case!
> > >
> > >Simon,
> > >
> > >I don't quite get it what you are trying to say.
> > >
> > ><fo:block> </fo:block>
> > >
> > >is perfectly legal and sensible in both XSL-FO (and HTML) and
> > > doesn't that mean a nbsp does occur at the end (and beginning) of
> > > a line.
> >
> > I guess what Simon is referring to is that if the line-breaking
> > algorithm does its job adequately, there will be no line-break
> > preceding/following a non-breaking-space, except when it is the
> > first/ last character in a block. Other break-possibilities should,
> > in theory at least, always be considered more favorable than
> > breaking before/after the nbsp... Correct, Simon?
>
> That is precisely what I tried to say.
>
> > >What is contradictory or unique about this?
> >
> > That indeed is a bit overstating the case. It's not contradictory,
> > but it is a rather special situation. Not taking into account the
> > number of times such a construct is used in practice... It is more
> > of an HTML/XSL-FO trick to make a block appear non-empty --used
> > mainly in the context of table-cells, to have their borders drawn
> > despite the fact that there is no visible content.
>
> It is not a formal contradiction, but it feels like one: nbsp should
> not have a linebreak around it, but here we have to solve the problem
> how to deal with it when it does have a linebreak preceding or
> following it.
>
Simon,
sorry Simon (and thanks Andreas) I was a bit slow in understanding what
you were saying. While I still don't quite agree with the statement
'nbsp should not have a linebreak around it' because nbsp surrounded by
whitespace (and therefore surrounded by possible linebreaks) for
example is perfectly legal and sensible in some situations this really
is not important here.
Does it mean because the Knuth algorithm removes all glues after a
linebreak (and we also remove all glues at the end of a paragraph) a
nbsp should not be modelled not like this:
pen p=INF
glue w=...
but like this:
box w=0 aux=true
pen p=INF
glue w=...
box w=0 aux=true
with the leading box preventing removal at the beginning of a line, the
trailing box prevents removal at the end of a paragraph, and the
penalty prevents a line break.
> Simon
Manuel
Re: Hyphetation broken with last commits
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Sat, Dec 17, 2005 at 05:46:42PM +0100, Andreas L Delmelle wrote:
> On Dec 17, 2005, at 16:29, Manuel Mall wrote:
>
>
> Hi,
>
> >On Sat, 17 Dec 2005 11:07 pm, Simon Pepping wrote:
> >>On Sat, Dec 17, 2005 at 11:43:36AM +0800, Manuel Mall wrote:
> ><snip/>
> >>The case is contradictory in itself, and quite unique. A nbsp will
> >>never occur at the end of a line by its very definition, except in
> >>this case!
> >>
> >Simon,
> >
> >I don't quite get it what you are trying to say.
> >
> ><fo:block> </fo:block>
> >
> >is perfectly legal and sensible in both XSL-FO (and HTML) and doesn't
> >that mean a nbsp does occur at the end (and beginning) of a line.
>
> I guess what Simon is referring to is that if the line-breaking
> algorithm does its job adequately, there will be no line-break
> preceding/following a non-breaking-space, except when it is the first/
> last character in a block. Other break-possibilities should, in
> theory at least, always be considered more favorable than breaking
> before/after the nbsp... Correct, Simon?
That is precisely what I tried to say.
> >What is contradictory or unique about this?
>
> That indeed is a bit overstating the case. It's not contradictory,
> but it is a rather special situation. Not taking into account the
> number of times such a construct is used in practice... It is more of
> an HTML/XSL-FO trick to make a block appear non-empty --used mainly
> in the context of table-cells, to have their borders drawn despite
> the fact that there is no visible content.
It is not a formal contradiction, but it feels like one: nbsp should
not have a linebreak around it, but here we have to solve the problem
how to deal with it when it does have a linebreak preceding or
following it.
Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Hyphetation broken with last commits
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 17, 2005, at 16:29, Manuel Mall wrote:
Hi,
> On Sat, 17 Dec 2005 11:07 pm, Simon Pepping wrote:
>> On Sat, Dec 17, 2005 at 11:43:36AM +0800, Manuel Mall wrote:
> <snip/>
>> The case is contradictory in itself, and quite unique. A nbsp will
>> never occur at the end of a line by its very definition, except in
>> this case!
>>
> Simon,
>
> I don't quite get it what you are trying to say.
>
> <fo:block> </fo:block>
>
> is perfectly legal and sensible in both XSL-FO (and HTML) and doesn't
> that mean a nbsp does occur at the end (and beginning) of a line.
I guess what Simon is referring to is that if the line-breaking
algorithm does its job adequately, there will be no line-break
preceding/following a non-breaking-space, except when it is the first/
last character in a block. Other break-possibilities should, in
theory at least, always be considered more favorable than breaking
before/after the nbsp... Correct, Simon?
> What is contradictory or unique about this?
That indeed is a bit overstating the case. It's not contradictory,
but it is a rather special situation. Not taking into account the
number of times such a construct is used in practice... It is more of
an HTML/XSL-FO trick to make a block appear non-empty --used mainly
in the context of table-cells, to have their borders drawn despite
the fact that there is no visible content.
Cheers,
Andreas
Re: Hyphetation broken with last commits
Posted by Manuel Mall <mm...@arcus.com.au>.
On Sat, 17 Dec 2005 11:07 pm, Simon Pepping wrote:
> On Sat, Dec 17, 2005 at 11:43:36AM +0800, Manuel Mall wrote:
<snip/>
> The case is contradictory in itself, and quite unique. A nbsp will
> never occur at the end of a line by its very definition, except in
> this case!
>
Simon,
I don't quite get it what you are trying to say.
<fo:block> </fo:block>
is perfectly legal and sensible in both XSL-FO (and HTML) and doesn't
that mean a nbsp does occur at the end (and beginning) of a line.
What is contradictory or unique about this?
As far as I understand nbsp is not subject to any whitespace handling,
i.e. it is not collapsed, removed, replaced, .... However it does take
part in justification, word spacing, etc. and therefore needs to be
modelled a glue and not as box.
> Simon
Manuel
Re: Hyphetation broken with last commits
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Sat, Dec 17, 2005 at 11:43:36AM +0800, Manuel Mall wrote:
> It is not a special situation at all. Simply having a in your
> text is enough to trigger this regression. And yes, it is an regression
> caused by the "fix" for the disappearing empty line problem:
> <fo:block> </fo:block>
>
> After some debugging it is obvious to me what is happening. However, it
> is much less obvious how to fix it. In brief:
>
> The fix added a zero width Knuth box to the element list created for a
> nbsp. This was done for two reasons:
> a) to avoid it being removed by the removeElementsForTrailingSpaces()
> method. That method is wrong in the first place as it knowingly tries
> to remove non breaking spaces which IMO should never be removed.
In Knuth's situation spaces were always suppressed at a
linebreak. Therefore suppressing glues around a linebreak is built
into the algorithm. For FO, we need glues that are not suppressed
around a linebreak. Perhaps a boolean member 'suppress-at-line-break'
of KnuthGlue?
> b) However, changing that method to not remove nbsp would give us Knuth
> paragraphs containing only Glue and Penalty elements. This then causes
> our implementation of the Knuth algorithm to 'spit the dummy'. Luca,
> why does our line breaking algorithm insist on having at least one Box
> in a paragraph? Is that inherent in the Knuth algorithm, i.e. can't it
> deal with empty paragraphs, that is paragraphs containing only Glue/Pen
> elements?
The above proposed member would not solve this problem.
The case is contradictory in itself, and quite unique. A nbsp will
never occur at the end of a line by its very definition, except in
this case!
Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Hyphetation broken with last commits
Posted by Manuel Mall <mm...@arcus.com.au>.
On Fri, 16 Dec 2005 11:40 pm, Adam Strzelecki wrote:
> Hi Jeremias,
>
> > All test cases pass, so it's a special situation. Please send a
> > test file. Thanks.
>
> Attached.
>
> Seems that I'm all of special situations ;)
It is not a special situation at all. Simply having a in your
text is enough to trigger this regression. And yes, it is an regression
caused by the "fix" for the disappearing empty line problem:
<fo:block> </fo:block>
We don't have test cases in our test suite for non breaking spaces and
therefore this regression wasn't caught.
After some debugging it is obvious to me what is happening. However, it
is much less obvious how to fix it. In brief:
The fix added a zero width Knuth box to the element list created for a
nbsp. This was done for two reasons:
a) to avoid it being removed by the removeElementsForTrailingSpaces()
method. That method is wrong in the first place as it knowingly tries
to remove non breaking spaces which IMO should never be removed.
b) However, changing that method to not remove nbsp would give us Knuth
paragraphs containing only Glue and Penalty elements. This then causes
our implementation of the Knuth algorithm to 'spit the dummy'. Luca,
why does our line breaking algorithm insist on having at least one Box
in a paragraph? Is that inherent in the Knuth algorithm, i.e. can't it
deal with empty paragraphs, that is paragraphs containing only Glue/Pen
elements?
However, this now causes consecutive Knuth boxes being created when the
nbsp is for example between two words. This then triggers the
addALetterSpaceMethod but it fails because the Knuth sequences are not
any more like what it expects.
It is well documented and acknowledged in other threads on this mailing
list that the design of this area of the code (generating of the Knuth
sequences for inline's) is flawed and this is just another
manifestation of the inherent design problems here.
I'll see if I can find another hack to workaround this particular
problem but I don't feel comfortable with the whole scenario.
>
> BTW. Maybe it is worth to put some special message at
> src\java\org\apache\fop\cli\Main.java line 185
>
> options.getLogger().error("This is probably bug of FOP version blah
> bla... contact us at blah blah or send bug report at blah blah.", e);
> e.printStackTrace();
>
> instead options.getLogger().error("Exception", e);
>
> .. coz I needed to modify Main.java in order to see the stack trace.
>
> Cheers,
Manuel
Re: Hyphetation broken with last commits
Posted by Adam Strzelecki <on...@java.pl>.
> That's how its meant to work. If you want the stack trace then specify
> the -d option when running from the command line.
I'm embarrassed... you are right.. Forgot about debug option ;)
BTW. Does all explamples/fo tests run OK.. coz I'm getting some
riddiculous errors ?
Thanks,
--
Adam Strzelecki |: nanoant.com :|
Re: Hyphetation broken with last commits
Posted by Chris Bowditch <bo...@hotmail.com>.
Adam Strzelecki wrote:
<snip/>
> instead options.getLogger().error("Exception", e);
>
> .. coz I needed to modify Main.java in order to see the stack trace.
That's how its meant to work. If you want the stack trace then specify
the -d option when running from the command line.
Chris
Re: Hyphetation broken with last commits
Posted by Adam Strzelecki <on...@java.pl>.
Hi Jeremias,
> All test cases pass, so it's a special situation. Please send a test
> file. Thanks.
Attached.
Seems that I'm all of special situations ;)
BTW. Maybe it is worth to put some special message at
src\java\org\apache\fop\cli\Main.java line 185
options.getLogger().error("This is probably bug of FOP version blah
bla... contact us at blah blah or send bug report at blah blah.", e);
e.printStackTrace();
instead options.getLogger().error("Exception", e);
.. coz I needed to modify Main.java in order to see the stack trace.
Cheers,
--
Adam Strzelecki |: nanoant.com :|
Re: Hyphetation broken with last commits
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
All test cases pass, so it's a special situation. Please send a test
file. Thanks.
On 16.12.2005 15:58:26 Adam Strzelecki wrote:
> I'm using fop-hyph.jar built along with offo.sourceforge.net/
> hyphetation XML files put into /hyph in SVN trunk. So everything is
> fresh.. and since today I got following error when fop-hyph.jar is enabled:
>
> java.lang.ArrayIndexOutOfBoundsException: -1
> at java.util.ArrayList.get(Unknown Source)
> at
> org.apache.fop.layoutmgr.inline.TextLayoutManager.addALetterSpaceTo(TextLayoutManager.java:559)
> at
> org.apache.fop.layoutmgr.inline.LineLayoutManager$Paragraph.addALetterSpace(LineLayoutManager.java:360)
> at
<snip/>
Jeremias Maerki