No, I am not sure about that, not 100%. :-) But 7.15.12 does say that
"white-space-treatment" and "linefeed-treatment" happen during refinement,
but that "white-space-collapse" happens during area tree generation.
Considering the meaning and intent of the property it seems to make more
sense at the time of area generation, anyway. But the language bears me out,
I think.

Arved

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Karen Lease
Sent: March 1, 2002 5:49 PM
To: [EMAIL PROTECTED]
Subject: Re: [REDESIGN] TextLayoutManager whitespace handling


Arved, are you sure about that? It's a bit confusing since the spec
(actually it's 7.15.12 not 7.5.12 as I mistakenly wrote last time) says
white-space-collapse happens during area building but only talks about
adjacent flow objects not at all about areas. Well actually it does. It
says that the collapsed space doesn't "generate an area".
I thought only the "suppress-at-line-break" (7.16.3) was actually based
on areas.

I agree about the definition of ajacent areas (4.2.5) and I don't
believe there is a clear definition of ajacent FO, so maybe it's best to
follow your interpretation.

In fact, my white-space-collapse code in the new Fop is currently
collapsing them during FO tree construction (== refinement) after doing
the white-space and linefeed handling. So if it's supposed to deal with
areas it's not right.


-Karen


Arved Sandstrom wrote:
>
> I should add, if the 2 spaces end up on the same line, of course. Until we
> do layout we don't know.
>
> -----Original Message-----
> From: Arved Sandstrom [mailto:[EMAIL PROTECTED]]
> Sent: February 28, 2002 7:03 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: [REDESIGN] TextLayoutManager whitespace handling
>
> Comments below.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Karen Lease
> Sent: February 28, 2002 6:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [REDESIGN] TextLayoutManager whitespace handling
>
> [ SNIP ]
>
> That's one thing. In your example, even supposing we are doing
> white-space collapse, the issue is which one gets thrown out. In 7.5.12
> (white-space-collapse), the spec says: ".. [if] the immediately
> preceding flow object is a character flow object with a character
> classified as white space in XML ... that flow object shall not generate
> an area."
>
> So if we think that the the space after "text" and the one before "more"
> are adjacent, which is strictly speaking not the case, I'd say the one
> before "more" disappears. If we aren't collapsing or we decide that the
> intervening newline makes them not adjacent, there are two spaces and
> the second is underlined.
>
> -Karen
>
> Keiron Liddle wrote:
> >
> > Hi Karen,
> >
> > I seem to be having a bit of trouble getting that text parsing right. I
> > was mainly just trying to get something to work to see on the output.
> > It should be able to be simplified thanks to the earlöier whitespace
> > handling.
> > I still wonder what should be done in a situation like:
> > <block>some text <inline text-decoration="underline"> more
> > text<inline><block>
> > Is the space before "more" underlined or not?
>
> Pursuant to my earlier post on this question, I think we are all agreed
that
> "score-spaces" dictates whether or not the space immediately preceding the
> word "more" in the example gets underlined or not, _assuming_ that that
> space survives.
>
> As Karen points out, initial value for "white-space-collapse" will make
the
> second space go away (leastways I concur in that interpretation).
Adjacency
> is based on whether or not the 2 areas have a block- or
> inline-stacking-constraint, and the two spaces in question have an
> inline-stacking-constraint by 3a in Inline Stacking Constraints, Section
> 4.2.5, so are adjacent.
>
> Regards,
> AHS
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

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


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

Reply via email to