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:[email protected]] > Sent: Monday, March 18, 2013 11:50 PM > To: [email protected] > 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
