FOs. The serious showstoppers. [1]. start-indent/end-indent

Dear WG.

Oh, how weird and arcane are start-indents/end-indents in XSL FO!

Recently, we have re-read the whole part related to lists -
and it turned out that the most standard list patterns are
simply invalid according to the specs. Consider the following:

Axioms:
1) WD 3.4.2.1, first note: "Indents are inheritable"
2) WD 4.7.1, note: " the indents on all objects within
    them [sc. fo:list-item-body and fo:list-item-label]
    are measured relative to the area-container that
    holds the content of the fo:list-block.

Applying this to the following construction:

  <fo:list-block>
      <fo:list-item-label>
          <fo:block> 1. </fo:block>
      </fo:list-item-label>
      <fo:list-item-body>
           <fo:block> first item </fo:block>
      </fo:list-item-body>
  </fo:list-block>

we obtain that fo:list-item-label and fo:list-item-body
have the same (=inherited) values for start-indent
and end-indent and therefore they should overlap;
and "it is an error if the areas overlap" (WD 4.7.1).

To prevent this, you have to specify end-indent (or,
alternatively, margin-right) on every fo:list-item-label,
and start-indent (or margin-left) on every fo:list-item-body.
You cannot escape: there is no common parent from which
to inherit indent values to item-labels only, bypassing
item-bodies, or vice versa.

Neither we at RenderX nor James Tauber in FOP have
noteiced it before (both our FO examples and James's
abound with lists like the aforementioned one); the only
excuse for us is that *this is really bizarre*. However, the
WD seems to insist on it.

A mechanism for setting common indents for item-labels and
item-bodies can be provided by 'provisional-label-separation' and
'provisional-distance-between-starts' attributes. However, the
way these properties are treated in the WD is another mighty
arcane: instead of shifting the reference position for calculating
indents, they just give you values of two magic variables, end-label
and start-body, that can further be used FOR EXPLICITLY
SPECIFYING THE INDENT VALUES (end-indent="end-label()").
I'm desperate; instead of alleviating my pains, this utterly destroy
every hope of conciseness.

Am I missing something? Is it really what was meant by the WG?
Or is it just a misprint, and provisional-* do adjust the reference
position for calculating indents (as all decent people are inclined
to presume until they read the WD carefully)?

> Date: Wed, 06 Oct 1999 03:42:05 GMT
> From: pandeng@xxxxxxxxxxxx (Steve Schafer)
> Subject: start-indent/end-indent vs. absolute positioning
>
> I'm having trouble coming to grips with the idea of start-indent and
> end-indent in the context of absolutely-positioned blocks. With CSS2
> and its margins, it all makes sense, more or less (see CSS2 section
> 10.3.7). But now we have the New and Improved (tm) start-indent and
> end-indent instead of margins, and the model kind of falls apart: The
> start-indent is supposed to be measured from the edge of the
> area-container, while the "left" property is measured from the edge of
> the containing block. This suggests that the "left" value will be
> absorbed into the margin; "left" and "right" effectively become
> superfluous (assuming lr-tb writing-mode, of course). At least, I
> can't think of any way to achieve consistent results while continuing
> to take them into account. Similar ambiguities arise when considering
> the perpendicular direction.

> As a workaround, I'm temporarily ignoring start-indent, end-indent,
> space-before, and space-after on absolutely-positioned blocks, but
> still paying attention to the margins, if explicitly set. I have to
> say, however, that I'm not at all comfortable with this. My feeling is
> that XSL needs to choose: Do things one way (block-relative, a la
> CSS2) or the other (area-container-relative), but don't try to mix the
> two; that path leads to chaos, anarchy, and possibly even plagues of
> locusts.
>
>- -Steve Schafer

Rgds.Paul.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 paul@xxxxxxxxx   www.renderx.com   www.pault.com
 XMLTube * Perl/JavaConnector * PerlApplicationServer
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list