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 bu...@apache.org on 2008/06/19 14:12:58 UTC
DO NOT REPLY [Bug 45237] New: Call order of FOEventHandler method is
incorrect
https://issues.apache.org/bugzilla/show_bug.cgi?id=45237
Summary: Call order of FOEventHandler method is incorrect
Product: Fop
Version: 1.0dev
Platform: All
URL: http://markmail.org/message/7p7jgxff6zx2gvss
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: fo tree
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: jeremias@apache.org
Created an attachment (id=22143)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22143)
Test case showing the problem
See thread on fop-dev:
http://markmail.org/message/7p7jgxff6zx2gvss
or
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200806.mbox/%3C20080619092704.BFBA.DEV@jeremias-maerki.ch%3E
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 45237] Call order of FOEventHandler method is
incorrect
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45237
--- Comment #3 from Glenn Adams <gl...@skynav.com> 2012-04-07 01:44:29 UTC ---
resetting P2 open bugs to P3 pending further review
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 45237] Call order of FOEventHandler method is
incorrect
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45237
Glenn Adams <gl...@skynav.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P3
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 45237] Call order of FOEventHandler method is
incorrect
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45237
Glenn Adams <ga...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
--- Comment #4 from Glenn Adams <ga...@apache.org> 2012-04-11 06:16:27 UTC ---
change status from ASSIGNED to NEW for consistency
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 45237] Call order of FOEventHandler method is
incorrect
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45237
Andreas L. Delmelle <ad...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #2 from Andreas L. Delmelle <ad...@apache.org> 2008-06-22 06:41:32 PST ---
Looked closer at this one, and simply swapping the call-sequence of
startOfNode() and addChildNode() broke some table-related testcases, since the
table-code relied on startOfNode() being called before addChildNode() (leading
to some dubious lines of code in AbstractRetrieveMarker.cloneSingleNode()...)
Proposed solution: introduction of a public finalizeNode() method in FONode,
whose main purpose will be to perform 'finishing' tasks. The default
endOfNode() implementation in FONode invokes this method without registering
any event. Subclasses can then add overrides like:
...
super.endOfNode(); // trigger finalizeNode();
getFOEventHandler().endXXX(); // send endOfNode() notification
...
As such, AbstractRetrieveMarker can then call finalizeNode() to avoid sending
the event twice.
The initialization code for the table-related FOs would be moved to a
processNode() override (which is already public), so that the calls to
startOfNode() can also be avoided, and both methods can retain their protected
visibility in the table-FOs.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 45237] Call order of FOEventHandler method is
incorrect
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45237
--- Comment #1 from Andreas L. Delmelle <ad...@apache.org> 2008-06-19 06:46:54 PST ---
Just had an idea. To be considered together with the already mentioned swapping
startOfNode() and addChildNode():
The problem is that FOText.endOfNode() (and subsequentially
FOEventHandler.characters()) is called before handleWhiteSpace().
If we remove the endOfNode() call from flushText(), and instead call
endOfNode() for the text-nodes upon addChildNode() for the following node
(after handleWhiteSpace()), the issue should be partly alleviated. The
FOEventHandler will then receive characters() for text-nodes that have been
treated and the ignorable white-space is no longer reported in those events...
For fo:characters, we could move the call to FOEventHandler.character() to
endOfNode(). We would then only need to make sure that this particular
endOfNode() call is skipped in FOTreeBuilder (?)
For inline-level FOs, there would still need to be some sort of deferral (since
the XMLWhiteSpaceHandler also has to wait until either the next node or
Block.endOfNode() to finish them).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.