DO NOT REPLY [Bug 46823] LayoutException when rendering ./examples/fo/basic/blockcontainer.fo
https://issues.apache.org/bugzilla/show_bug.cgi?id=46823 --- Comment #5 from Simon Pepping spepp...@apache.org 2009-03-24 03:26:54 PST --- The spec says: error-if-overflow: This value implies the same semantics as the value hidden with the additional semantic that an error shall be indicated; implementations may recover by clipping the region. The code says: boolean canRecover = (getBlockContainerFO().getOverflow() != EN_ERROR_IF_OVERFLOW); (BlockContainerLayoutManager, line 533). Does that not mean that the code is wrong: it should recover, but issue an ERROR instead of a WARNING? -- 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 46823] LayoutException when rendering ./examples/fo/basic/blockcontainer.fo
https://issues.apache.org/bugzilla/show_bug.cgi?id=46823 --- Comment #6 from Jeremias Maerki jerem...@apache.org 2009-03-24 04:11:44 PST --- (In reply to comment #5) The spec says: error-if-overflow: This value implies the same semantics as the value hidden with the additional semantic that an error shall be indicated; implementations may recover by clipping the region. The code says: boolean canRecover = (getBlockContainerFO().getOverflow() != EN_ERROR_IF_OVERFLOW); (BlockContainerLayoutManager, line 533). Does that not mean that the code is wrong: it should recover, but issue an ERROR instead of a WARNING? The spec says may recover, it doesn't say should recover, so it isn't technically wrong. That doesn't mean it can't be changed. But my personal expectation is an error if I explicitely say error-if-overflow instead of hidden. If I say hidden I don't care if any content is lost. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: svn commit: r757681 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/ src/java/org/apache/fop/render/intermediate/ test/ test/java/org/apache/fop/intermediate/
Author: jeremias
Date: Tue Mar 24 08:08:54 2009
New Revision: 757681
URL: http://svn.apache.org/viewvc?rev=757681view=rev
Log:
Amendment to revision 755894:
The mimicking fix didn't work for all output formats.
snip/
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/intermediate/IFUtil.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/intermediate/IFUtil.java?rev=757681r1=757680r2=757681view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/intermediate/IFUtil.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/intermediate/IFUtil.java
Tue Mar 24 08:08:54 2009
@@ -153,6 +153,13 @@
if (fontInfo == null) {
fontInfo = new FontInfo();
}
+if (documentHandler instanceof IFSerializer) {
+IFSerializer serializer = (IFSerializer)documentHandler;
+if (serializer.getMimickedDocumentHandler() != null) {
+//Use the mimicked document handler's configurator to set up
fonts
+documentHandler = serializer.getMimickedDocumentHandler();
+}
+}
IFDocumentHandlerConfigurator configurator =
documentHandler.getConfigurator();
if (configurator != null) {
configurator.setupFontInfo(documentHandler, fontInfo);
That sounds wrong. That smells like a procedural way of solving
a problem that could be solved more easily and elegantly by using
a proper object-oriented approach. The use of instanceof almost always
indicates that something’s wrong anyway.
Why not directly declare a setupFonts method on IFDocumentHandler? It
could then be defined in concrete classes to do whatever is needed.
Plus, since the getEffectiveMIMEType method is no longer of use, it can
as well be removed IMO.
Vincent
DO NOT REPLY [Bug 46823] LayoutException when rendering ./examples/fo/basic/blockcontainer.fo
https://issues.apache.org/bugzilla/show_bug.cgi?id=46823 --- Comment #7 from Simon Pepping spepp...@apache.org 2009-03-24 05:42:14 PST --- Created an attachment (id=23407) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23407) Proposed patch Would the attach patch solve the problem in a good way? -- 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 46905] New: [PATCH] Implement keep-*.within-column
https://issues.apache.org/bugzilla/show_bug.cgi?id=46905 Summary: [PATCH] Implement keep-*.within-column Product: Fop Version: all Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: vhenneb...@gmail.com Created an attachment (id=23411) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23411) Start of an implementation of keep.within-column At the moment no distinction is made between keep.within-column and keep.within-page. I've started to hack support for keep.within-column into the Trunk but don't have time to finish the task. Posting my changes here as a patch so that anyone who's interested can take over the job. The idea is to make use of the break class of KnuthPenalty (which then becomes a 'keep context'). A keep.within-page will lead to an infinite penalty of class Constants.EN_PAGE. When a break is being considered, the break class will hint at whether it is allowed or not. For example, if the break is not at the last column of the page and the break class is page, the break may be considered. At some point the breaking algorithm will run out of nodes because of forbidden page breaks that make the content pile up on the last column of a page. When such a situation is detected, the whole content is deferred to the next page (if that hasn't been already done) and column breaking is re-started. The hope is that a new, blank page will provide enough space to make all the content fit on one page. If it's still not the case, then the page break prohibition will be relieved to allow the content to flow to the next page. Current limitations: * keeps have been implemented such that a keep.within-line implies a keep.within-column, which implies a keep.within-page. This is almost always true except if, for example, keep.within-page is set to always and keep.within-column to an integer value. The integer value from the column component will override the always value from the page component, possibly leading to an 'illegal' page break. * some javadoc must be updated * there are 10 failing test cases in the test suite * at the moment no warning is issued when the content is too big to fit on one page alone * in PageBreakingAlgorithm, the deferred and overridePageKeep fields need to be reset 'at the right moment' * the overridePageKeep mechanism should actually be completely removed; if there's too much content to fit on a page then the usual overflow mechanism should be used instead. I initially set it up because the algorithm was reverting to starting the content on the same page instead of a new blank page. This needs to be investigated * the new deferring mechanism clashes with fitRecoveryCounter; both should be merged somehow * the deferring mechanism may also conflict with regular node recovery (restarting from the last deactivated/too short/too long node when the number of active nodes falls to zero). See commented out code in BreakingAlgorithm. It's not clear yet what may happen when. * the use of break class from KnuthPenalty is very hacky and a new characteristic should probably be defined. Using an infinite penalty with a tweaked break class leads to too many changes at too many places. Maybe it can be done the other way round: use a zero penalty with break class properly set to indicate when this penalty must be considered as infinite (or infinite - 1). * at the moment penalties are discarded at page breaks until the end of the keep.within-column zone has been reached. At that point the content may already have been overflowing the last column for a long time. This might lead to performance issues. -- 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 46905] [PATCH] Implement keep-*.within-column
https://issues.apache.org/bugzilla/show_bug.cgi?id=46905 --- Comment #1 from Adrian Cumiskey d...@cumiskey.com 2009-03-24 09:03:02 PST --- That is a real shame that you will not have time to finish this, certainly looks like really good useful work :). It will not be easy, but I really hope someone will be able to pick it up where you left off. -- 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 46823] LayoutException when rendering ./examples/fo/basic/blockcontainer.fo
https://issues.apache.org/bugzilla/show_bug.cgi?id=46823 --- Comment #8 from Jeremias Maerki jerem...@apache.org 2009-03-24 10:24:51 PST --- (In reply to comment #7) Created an attachment (id=23407) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23407) [details] Proposed patch Would the attach patch solve the problem in a good way? I think you're doing pretty much the same thing I did there, only in reverse. I specified the event for FATAL level, and canRecover can lower the severity to WARN. Your change would set the default level to WARN and increase it to ERROR if it's error-on-overflow. The only difference is that the error cause used FATAL before and uses ERROR after the change which would effectively not stop the formatting and allow the user to increase the event severity to FATAL if he so chooses. You could skip the isError attribute and just set all overflow events to ERROR level by default (Javadoc @event.severity). That would have the same effect. Don't forget that the block-container case is not the only overflow where an error is possible. As I said before I'm not opposed to lowering FATAL to ERROR for error-if-overflow. A custom event handler can always throw an exception. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
