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:lmpmberna...@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 =&gt; 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 &gt; 
>> {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


Reply via email to