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@...
ReportedBy:
liam@...
QAContact:
xsl-editors@...
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.
