On 3/18/13 9:04 AM, Vincent Hennebert wrote:
Please revert this patch as it introduces too many inaccuracies. See
inline comments.
On 16/03/13 01:27, lbernardo wrote:
Author: lbernardo
Date: Sat Mar 16 00:27:00 2013
New Revision: 1457180
URL: http://svn.apache.org/r1457180
Log:
FOP-2221: Make overflow messages easier to read and fix wrong/
missing messages; patch submitted by Simon Steiner.
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockLevelEventProducer.xml
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/InlineLevelEventProducer.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/InlineLevelEventProducer.xml
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java?rev=1457180&r1=1457179&r2=1457180&view=diff
==============================================================================
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java
Sat Mar 16 00:27:00 2013
@@ -1040,6 +1040,9 @@ public class BlockContainerLayoutManager
/** {@inheritDoc} */
public boolean handleOverflow(int milliPoints) {
+ if (width.getEnum() == EN_AUTO) {
+ return false;
+ }
If the idea is to not issue a warning in this case, then it fails
because the warning will be issued by LineBreakingAlgorithm.updateData2
instead.
The idea was in fact the opposite. To issue a warning in a situation
where it made sense to do so but it was not happening. Simon had sent me
an example but I cannot find it now. Simon, can you attach the example?
if (milliPoints > this.horizontalOverflow) {
this.horizontalOverflow = milliPoints;
}
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockLevelEventProducer.xml
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockLevelEventProducer.xml?rev=1457180&r1=1457179&r2=1457180&view=diff
==============================================================================
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockLevelEventProducer.xml
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockLevelEventProducer.xml
Sat Mar 16 00:27:00 2013
@@ -22,9 +22,9 @@
<message
key="tableFixedAutoWidthNotSupported">table-layout="fixed" and
width="auto", but auto-layout not supported => assuming
width="100%".{{locator}}</message>
<message key="objectTooWide">The extent in
inline-progression-direction (width) of a {elementName} is bigger
than the available space ({effIPD}mpt >
{maxIPD}mpt).{{locator}}</message>
<message key="overconstrainedAdjustEndIndent">An {elementName}
{{locator}} is wider than the available room in
inline-progression-dimension. Adjusting end-indent based on
overconstrained geometry rules (XSL 1.1, ch. 5.3.4)</message>
- <message key="viewportIPDOverflow">Content overflows the viewport
of an {elementName} in inline-progression direction by {amount}
millipoints.{clip,if, Content will be clipped.}{{locator}}</message>
+ <message key="viewportIPDOverflow">The contents of {elementName}
exceed its 'width' value by {amount} millipoints.{clip,if, Content
will be clipped.}{{locator}}</message>
Inline-progression direction != width. For text written from top to
bottom the inline-progression direction actually is the height.
Yes, you are correct. But instead of just reverting the change can you
provide an example and maybe Simon can adapt the changes to consider
those situations?
Thanks,
Luis
- <message key="viewportBPDOverflow">Content overflows the viewport
of an {elementName} in block-progression direction by {amount}
millipoints.{clip,if, Content will be clipped.}{{locator}}</message>
+ <message key="viewportBPDOverflow">The contents of {elementName}
exceed its 'height' value by {amount} millipoints.{clip,if, Content
will be clipped.}{{locator}}</message>
Same here.
- <message key="regionOverflow">Content overflows the viewport of
the {elementName} on page {page} in block-progression direction by
{amount} millipoints.{clip,if, Content will be
clipped.}{{locator}}</message>
+ <message key="regionOverflow">The contents of {elementName} on
page {page} exceed its 'extent' value by {amount}
millipoints.{clip,if, Content will be clipped.}{{locator}}</message>
Extent does not apply to region-body. If the overflow occurs in the
region-body the message will be misleading. Also, if the overflow occurs
in the block-progression direction of region-start or region-end, then
that has nothing to do with the extent.
<snip/>
Thanks,
Vincent
