You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by lb...@apache.org on 2013/03/16 01:27:00 UTC
svn commit: r1457180 - in
/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr:
BlockContainerLayoutManager.java BlockLevelEventProducer.xml
inline/InlineLevelEventProducer.java inline/InlineLevelEventProducer.xml
inline/LineLayoutManager.java
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 (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="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="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="viewportIPDOverflow">The contents of {elementName} exceed its 'width' value 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>
+ <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>
<message key="flowNotMappingToRegionBody">Flow "{flowName}" does not map to the region-body in page-master "{masterName}". FOP presently does not support this.{{locator}}</message>
<message key="pageSequenceMasterExhausted">Subsequences exhausted in page-sequence-master "{pageSequenceMasterName}", {canRecover,if,using previous subsequence,cannot recover}.{{locator}}</message>
<message key="missingSubsequencesInPageSequenceMaster">No subsequences in page-sequence-master "{pageSequenceMasterName}".{{locator}}</message>
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/InlineLevelEventProducer.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/InlineLevelEventProducer.java?rev=1457180&r1=1457179&r2=1457180&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/InlineLevelEventProducer.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/InlineLevelEventProducer.java Sat Mar 16 00:27:00 2013
@@ -59,11 +59,12 @@ public interface InlineLevelEventProduce
/**
* A line overflows.
* @param source the event source
+ * @param elementName the formatting object
* @param line the number number
* @param overflowLength the length by which the content overflows the available space (in mpt)
* @param loc the location of the error or null
* @event.severity WARN
*/
- void lineOverflows(Object source, int line, int overflowLength, Locator loc);
+ void lineOverflows(Object source, String elementName, int line, int overflowLength, Locator loc);
}
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/InlineLevelEventProducer.xml
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/InlineLevelEventProducer.xml?rev=1457180&r1=1457179&r2=1457180&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/InlineLevelEventProducer.xml (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/InlineLevelEventProducer.xml Sat Mar 16 00:27:00 2013
@@ -19,5 +19,5 @@
<catalogue xml:lang="en">
<message key="locator">[ (See position {loc})| (See {#gatherContextInfo})| (No context info available)]</message>
<message key="leaderWithoutContent">fo:leader is set to "use-content" but has no content.{{locator}}</message>
- <message key="lineOverflows">Line {line} of a paragraph overflows the available area by {overflowLength,choice,50000#{overflowLength} millipoints|50000<more than 50 points}.{{locator}}</message>
+ <message key="lineOverflows">The contents of {elementName} line {line} exceeds the available area by {overflowLength,choice,50000#{overflowLength} millipoints|50000<more than 50 points}.{{locator}}</message>
</catalogue>
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java?rev=1457180&r1=1457179&r2=1457180&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java Sat Mar 16 00:27:00 2013
@@ -397,8 +397,13 @@ public class LineLayoutManager extends I
InlineLevelEventProducer eventProducer
= InlineLevelEventProducer.Provider.get(
getFObj().getUserAgent().getEventBroadcaster());
- eventProducer.lineOverflows(this, bestActiveNode.line,
- -lack, getFObj().getLocator());
+ if (curChildLM.getFObj() == null) {
+ eventProducer.lineOverflows(this, getFObj().getName(), bestActiveNode.line,
+ -lack, getFObj().getLocator());
+ } else {
+ eventProducer.lineOverflows(this, curChildLM.getFObj().getName(), bestActiveNode.line,
+ -lack, curChildLM.getFObj().getLocator());
+ }
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org
Re: svn commit: r1457180 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr:
BlockContainerLayoutManager.java BlockLevelEventProducer.xml inline/InlineLevelEventProducer.java
inline/InlineLevelEventProducer.xml inline/LineLayoutManager.java
Posted by Luis Bernardo <lm...@gmail.com>.
On 3/20/13 10:52 PM, Vincent Hennebert wrote:
> On 19/03/13 00:49, Luis Bernardo wrote:
>> On 3/18/13 9:04 AM, Vincent Hennebert wrote:
> <snip/>
>>>> 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?
>>
> In that case, I’m not too sure what the fact that the width has been
> left to auto has to do with that. If the width has been set to some
> value and text overflows, and the block is not absolutely positioned,
> then still no warning will be issued. Or did I miss something?
>
>
> <snip/>
>
> Vincent
I did some more testing and I agree that this particular change can be
reverted in trunk. It leads to a redundant message that is already taken
care somewhere else in the code.
Re: svn commit: r1457180 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr:
BlockContainerLayoutManager.java BlockLevelEventProducer.xml inline/InlineLevelEventProducer.java
inline/InlineLevelEventProducer.xml inline/LineLayoutManager.java
Posted by Vincent Hennebert <vh...@gmail.com>.
On 19/03/13 00:49, Luis Bernardo wrote:
> On 3/18/13 9:04 AM, Vincent Hennebert wrote:
<snip/>
>>> 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?
>
In that case, I’m not too sure what the fact that the width has been
left to auto has to do with that. If the width has been set to some
value and text overflows, and the block is not absolutely positioned,
then still no warning will be issued. Or did I miss something?
<snip/>
Vincent
Re: svn commit: r1457180 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr:
BlockContainerLayoutManager.java BlockLevelEventProducer.xml inline/InlineLevelEventProducer.java
inline/InlineLevelEventProducer.xml inline/LineLayoutManager.java
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Simon,
On 19/03/13 11:35, Simon Steiner wrote:
> Hi,
>
> I made fix for 'extent' comment.
Could you upload a new patch so that we can have a look?
> For other issue, I say height or width based on the effect attributes in fo have on content rather than page width or height, which to me makes more sense as it give the user an indication of how to fix the issue.
>
> Example:
>
> <fo:block-container background-color="yellow" font-size="60pt" reference-orientation="90" >
> <fo:block>Nokia switched from their ageing and declining Symbian platform and chose Windows Phone as their primary smartphone OS. This partnership with Microsoft was confirmed on February 11, 2011. Symbian, which was for many years the leading smartphone OS, dropped below Android in Q4 2010, at a time when many manufacturers used Android's open source OS. Nokia continued to develop and release Symbian smartphones as well as MeeGo when the Lumia line was released.</fo:block>
> </fo:block-container>
>
> The contents of fo:block-container exceed its 'height' value by 773280 millipoints.
This makes sense in this case, however if you render Chinese text in
top-to-bottom writing mode, then the inline-progression direction will
be from top to bottom, yet I doubt that a user would consider that to be
the width.
This is the reason why the ‘inline-progression’ and ‘block-progression’
terms were introduced. While they do sound a bit like specialist jargon,
they have the merit of being non-ambiguous. The same can’t be said of
‘width’ and ‘height’ unfortunately.
> Thanks
>
> -----Original Message-----
> From: Luis Bernardo [mailto:lmpmbernardo@gmail.com]
> Sent: Monday, March 18, 2013 11:50 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: svn commit: r1457180 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr: BlockContainerLayoutManager.java BlockLevelEventProducer.xml inline/InlineLevelEventProducer.java inline/InlineLevelEventProducer.xml inline/LineLayoutManager.java
>
> 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/BlockContaine
>>> rLayoutManager.java
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockLevelEve
>>> ntProducer.xml
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/Inline
>>> LevelEventProducer.java
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/Inline
>>> LevelEventProducer.xml
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLa
>>> youtManager.java
>>>
>>> Modified:
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContaine
>>> rLayoutManager.java
>>> URL:
>>> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apach
>>> e/fop/layoutmgr/BlockContainerLayoutManager.java?rev=1457180&r1=14571
>>> 79&r2=1457180&view=diff
>>> =====================================================================
>>> =========
>>>
>>> ---
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContaine
>>> rLayoutManager.java
>>> (original)
>>> +++
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContaine
>>> rLayoutManager.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/BlockLevelEve
>>> ntProducer.xml
>>> URL:
>>> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apach
>>> e/fop/layoutmgr/BlockLevelEventProducer.xml?rev=1457180&r1=1457179&r2
>>> =1457180&view=diff
>>> =====================================================================
>>> =========
>>>
>>> ---
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockLevelEve
>>> ntProducer.xml
>>> (original)
>>> +++
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockLevelEve
>>> ntProducer.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
Vincent
RE: svn commit: r1457180 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr: BlockContainerLayoutManager.java BlockLevelEventProducer.xml inline/InlineLevelEventProducer.java inline/InlineLevelEventProducer.xml inline/LineLayoutManager.java
Posted by Simon Steiner <si...@gmail.com>.
Hi,
I made fix for 'extent' comment.
For other issue, I say height or width based on the effect attributes in fo have on content rather than page width or height, which to me makes more sense as it give the user an indication of how to fix the issue.
Example:
<fo:block-container background-color="yellow" font-size="60pt" reference-orientation="90" >
<fo:block>Nokia switched from their ageing and declining Symbian platform and chose Windows Phone as their primary smartphone OS. This partnership with Microsoft was confirmed on February 11, 2011. Symbian, which was for many years the leading smartphone OS, dropped below Android in Q4 2010, at a time when many manufacturers used Android's open source OS. Nokia continued to develop and release Symbian smartphones as well as MeeGo when the Lumia line was released.</fo:block>
</fo:block-container>
The contents of fo:block-container exceed its 'height' value by 773280 millipoints.
Thanks
-----Original Message-----
From: Luis Bernardo [mailto:lmpmbernardo@gmail.com]
Sent: Monday, March 18, 2013 11:50 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: svn commit: r1457180 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr: BlockContainerLayoutManager.java BlockLevelEventProducer.xml inline/InlineLevelEventProducer.java inline/InlineLevelEventProducer.xml inline/LineLayoutManager.java
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/BlockContaine
>> rLayoutManager.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockLevelEve
>> ntProducer.xml
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/Inline
>> LevelEventProducer.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/Inline
>> LevelEventProducer.xml
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLa
>> youtManager.java
>>
>> Modified:
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContaine
>> rLayoutManager.java
>> URL:
>> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apach
>> e/fop/layoutmgr/BlockContainerLayoutManager.java?rev=1457180&r1=14571
>> 79&r2=1457180&view=diff
>> =====================================================================
>> =========
>>
>> ---
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContaine
>> rLayoutManager.java
>> (original)
>> +++
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContaine
>> rLayoutManager.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/BlockLevelEve
>> ntProducer.xml
>> URL:
>> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apach
>> e/fop/layoutmgr/BlockLevelEventProducer.xml?rev=1457180&r1=1457179&r2
>> =1457180&view=diff
>> =====================================================================
>> =========
>>
>> ---
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockLevelEve
>> ntProducer.xml
>> (original)
>> +++
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockLevelEve
>> ntProducer.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
Re: svn commit: r1457180 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr:
BlockContainerLayoutManager.java BlockLevelEventProducer.xml inline/InlineLevelEventProducer.java
inline/InlineLevelEventProducer.xml inline/LineLayoutManager.java
Posted by Luis Bernardo <lm...@gmail.com>.
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
Re: svn commit: r1457180 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr:
BlockContainerLayoutManager.java BlockLevelEventProducer.xml inline/InlineLevelEventProducer.java
inline/InlineLevelEventProducer.xml inline/LineLayoutManager.java
Posted by Vincent Hennebert <vh...@gmail.com>.
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.
> 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.
> - <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