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: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

Vincent

Reply via email to