Hello all,
I recently made an attempt at implementing Unicode TR14
as well as proper linefeed-treatment, wrap, overflow
and whitespace-treatment.
Here are a few musing which arose during this:

  Common assuption: the line and therefore the whole block does not generate
  an area, or only an area with a BPD=0.
  There are several possibilities to arrive at this conclusion:
  1. The space is discarded. This is not supported by white-space-treatment
     nor white-space-collapse nor suppress-at-line-break. In either case, this
     leaves the quistion open whether formally a line area with line-height=0
     and IPD=0 is generated or no line area is generated at all.
  2. The space is kept but is assumed to have zero height. Obviously, formally
     a line area  with a space glyph has to be generated.

  <fo:block font-size="12pt" line-stacking-strategy="font-height"
  Same as above, only in case the space is not discarded, a zero BPD cannot
  be easily justified.

  The space is ignored (default white-space-treatment), then the LF is changed
  into a space (default linefeed-treatment), and we have the same situation as

  <fo:block white-space-treatment="ignore-if-after-linefeed">&sp;&lf;</fo:block>
  The space is kept, then the LF is changed into a space, and default
  white-space-collapse drops the space turned LF, and we have the situation as

  <fo:block white-space-treatment="ignore-if-after-linefeed"
  More fun: is the space discarded? I think so: we should get two space
  turned LFs, which are collapsed into one space.

  <fo:block white-space-treatment="preserve">&lf;<fo:wrapper
  Is the space discarded? (I still think so)

  <fo:block white-space-treatment="ignore-if-before-linefeed">&sp;<fo:wrapper
  This is real fun: the second space is preserved and then collapsed to the
  first. Is  the first space now discarded, as it now precedes the linefeed?
  I don't think so, collapsing is done after white space treatment.

  <fo:block white-space-treatment="ignore-if-after-linefeed"
  Both the linefeed and the space are dropped. Is there still a break
  opportunity between the two characters?

  <fo:block>&sp;<fo:wrapper text-decoration="underline">&sp;</fo:wrapper
  Is the first space kept? It probably should.

  <fo:block>&sp;<fo:wrapper text-decoration="underline">a</fo:wrapper
  Is the first space kept? Common stance seems to be that it is discarded,
  but we have essentially the same situation as above.

  <fo:block text-decoration="underline">&sp;a</fo:block>
  Is the space kept?

  <fo:block text-decoration="underline">&sp;</fo:block>
  Do we get a standard boring line with an underlined space?

  <fo:block>&sp;<fo:wrapper text-decoration="underline"
  Is there something underlined in this case? Actually, what *is* the glyph
  of a LF? The spec mentions that a LF generates an area, thoug details
  are sadly lacking.

  <fo:block>&sp;<fo:wrapper white-space-collapse="false">&sp;&sp;</fo:wrapper
  Is the first space kept? (actually, the second)

  <fo:block white-space-collapse="false">&sp;<fo:wrapper
  How many spaces do we get? One or two?

  <fo:block width="1em" white-space-collapse="false">m&sp;&sp;&sp;</fo:block>
  Do we get an overflow or an automatic line break? Spaces are automatically
  discarded at line breaks (before and after), therefore if there is a line
  break, the spaces disappear, and so does the need for a line break...

  <fo:block width="1em" white-space-collapse="false">a&sp;&sp;&sp;<fo:character
  character="&sp;" suppress-at-line-break="false"/></fo:block>
  Does the space in the fo:character cause the other spaces not to be
  discarded? Or is the line break before the first space, and the following two
  are discarded because of default suppress-at-line-break?

  <fo:block width="1em" white-space-collapse="false">a<fo:character
  character="&lf;" suppress-at-line-break="false"/></fo:block>
  Where does the space turned LF go, a then end of the first line or at the
  beginning of the second line?



To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to