W3C home > Mailing lists > Public > xsl-editors@w3.org > July to September 2001

Re: XSL-FO: space/border/paddings and conditionality

From: MURAKAMI Shinyu <murakami@nadita.com>
Date: Mon, 2 Jul 2001 21:16:42 -0400 (EDT)
To: alrb@us.ibm.com
Cc: xsl-editors@w3.org
Message-Id: <200107031016.FII31720.SLBJBVNN@nadita.com>
At Mon, 2 Jul 2001 15:08:08 -0400, Anders Berglund wrote:
...
> This is an error; the same text with "is-first" and "is-last"
> should be added in 4.3.1.
> 
> >(BTW in the last paragraph why "reference-area or" ?)
> >
> >If the condition "is-first/last value of false" is missing, the
> >conditional border/padding has different behavior. For example:
> >
> >  <fo:block>
> >    <fo:inline border-style="solid"
> >         border-start-width="1mm"
> >         border-start-width.conditionality="discard"
> >         border-end-width="1mm"
> >         border-end-width.conditionality="discard">
> >This inline begins a line, has conditional border-start/end, and
> >continues to the next line.
> >    </fo:inline>
> >    <fo:inline>Here is another inline.</fo:inline>
> >  </fo:block>
> >
> >(of course .conditionality="discard" need not to be specified since it
> >is the default)
> >
> >The expected result is:
> >
> >  +-------------------------------------------------------------
> >  | This inline begins a line, has conditional border-start/end,
> >  +-------------------------------------------------------------
> >  --------------------------------+
> >  and continues to the next line. | Here is another inline.
> >  --------------------------------+
> >
> >The border-start of the first inline-area is not discarded because this
> >inline-area has the is-first value of "true".
> 
> Which is the expected result. Correct?

Sorry, "the first inline-area" is "the first inline-area in the first 
line-area" which has the text "This inline begins...".
No problem here since 4.3.1 is fixed.

> 
> >The is-first/last problem is not only about border/paddings but also
> >about spaces. However the problem is different.
> >
> >Example of conditional spaces:
> >
> >  <fo:block>
> >    <fo:inline space-start="1cm"
> >               space-start.conditionality="discard"
> >               space-end="1cm"
> >               space-end.conditionality="discard">
> >This inline begins a line, has conditional space-start/end, and
> >continues to the next line.
> >    </fo:inline>
> >    <fo:inline>Here is another inline.</fo:inline>
> >  </fo:block>
> >
> >The expected result is:  (here [SPACE-*] represents spaces)
> >
> >  This inline begins a line, has conditional space-start/end,
> >  and continues to the next line.[SPACE-END]Here is another inline.
> >
> >
> >Note that the space-before of the first inline-area is discarded
> >(different from conditional padding/borders). Spaces are normally used
> >as separator and should be descarded at the first and last.
> >
> >Example of non-conditional spaces:
> >
> >  <fo:block>
> >    <fo:inline space-start="1cm"
> >               space-start.conditionality="retain"
> >               space-end="1cm"
> >               space-end.conditionality="retain">
> >This inline begins a line, has non-conditional space-start/end, and
> >continues to the next line.
> >    </fo:inline>
> >    <fo:inline>Here is another inline.</fo:inline>
> >  </fo:block>
> >
> >A possible result is:
> >
> >  [SPACE-START]This inline begins a line, has non-conditional[SPACE-END]
> >  [SPACE-START]space-start/end, and continues to the next[SPACE-END]
> >  [SPACE-STAET]line.[SPACE-END]Here is another inline.
> >
> >According to the current XSL CR spec this seems to be correct, but
> >probably the following is more reasonable.
> >
> >  [SPACE-START]This inline begins a line, has non-conditional space-
> >  start/end, and continues to the next line.[SPACE-END]Here is another
> >  inline.
> >
> >An important point is that the latter is compatible with CSS margins and
> >the former is not.
> >
> >Therefore, I think the rule should be changed.
> >
> >Any space-before and space-start should not have effect on areas that
> >have an is-first value of "false".
> >Any space-after and space-end should not have effect on areas that have
> >an is-last value of "false".
> >(i.e., when an area is split, spaces have no effect where the split
> >occurs.)
> 
> The intended usage of space-start and space-end is for effects
> like letter-spacing and for that usage I think that the semantics
> as defined in the CR are correct (notably that they are INDEPENDENT
> of the is-first and is-last value). The functionality that you
> seem to be looking for appears to me covered by generating an
> fo:character (with code U+0020 or another "space" value if "20" is
> a candidate for removal) with appropriate properties before and after
> the first fo:inline.


The problem is compatibility with CSS margins.
You wrote in another reply ("Re: XSL-FO: corresponding margin and space 
properties"):

|We will add text, in the refinement section, that the mapping
|from margins includes setting .conditionality to "retain".

But the CSS spec says that margins have no effect where the split occurs.

(Of course it is not only inline-level spaces problem but also block-
level's although I omitted the example.)

The CSS margin/border/padding's implicit conditionality is:

  <conditionality-at-first-and-last> = "retain"
  <conditionality-at-break> = "discard"

In XSL, border/padding's conditionality:

  <conditionality-at-first-and-last> = "retain"
  <conditionality-at-break> = can be specified

And space's conditionality (my proposal):

  <conditionality-at-first-and-last> = can be specified
  <conditionality-at-break> = "discard"

or both types of conditionality should be able to be specified.
  e.g.
     space-before.conditionality-at-first-and-last="retain"
     space-before.conditionality-at-break="discard"

     (it is compatible with CSS margin)

If you reject this proposal, you should withdraw the margin to space 
mapping with setting .conditionality to "retain".


Best regards,

Shinyu Murakami
Antenna House XSL Formatter team
Received on Tuesday, 3 July 2001 04:42:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:52 GMT