[Bug 6210] New: [XSLFO] Rotated block container inline-progression-dimension error condition

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6210

           Summary: [XSLFO] Rotated block container inline-progression-
                    dimension error condition
           Product: XSLFO
           Version: 1.1
          Platform: PC
               URL: http://lists.w3.org/Archives/Public/xsl-
                    editors/2008OctDec/0000
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSL-FO
        AssignedTo: alb.w3c@gmail.com
        ReportedBy: liam@w3.org
         QAContact: xsl-editors@w3.org


6.5.3 fo:block-container states that the inline-progression-dimension 
of a block container may not be "auto" if the 
inline-progression-direction is different from that of the parent of 
the container.

Fine, but if a user neglects to specify the 
inline-progression-dimension on a block container rotated 90 then the 
initial value of "auto" applies, which I then assume is an error condition.

I note that the Antenna House tool treats the dimension as narrow as 
it can be:  as if it were an fo:float in that it is the length of the 
widest of the children areas.

I note that the RenderX tool treats the dimension as wide as it can 
be:  as if it were an fo:block in a parent region area in that it is 
the width of the parent, not the width of the content.

The answer impacts on the position of the next formatting object 
after the block container:  after the narrow container on the same 
page, or after the wide container on the next page.

My intuition is that when not specified the error condition should 
treat the dimension as a region in which the blocks are placed, that 
is, the rotated block container is as wide as it can be.

This is because while neither fo:float nor fo:block allow 
inline-progression-dimension to be specified, fo:float explicitly 
talks about the width of the child areas while fo:block makes 
assumptions about the width.

Can you cite a definitive decision in the specification, or can you 
explain which of the two interpretations of the recovery from the 
error condition is "right" (unless, of course, it is just up to the 
implementation to recover from the error by making its own interpretation).

Thanks!


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 6 November 2008 21:35:50 UTC