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]
