Hi Kerion,
I agree it's better to have some output. Like my choir director says, we
can't know if you're singing the wrong note if we can't hear it :-)
I had some code written for this, but it's set up to return a
BreakPosition and it's incomplete.
I haven't gone back to the white-space handling code in a couple of
months, but I remember that after I had written it, I went through some
soul-searching about what should be done about text runs across
fo:inline, wrappers etc. I actually wrote to the xsl-editors about this.
<quote date="26nov2001">
1a. white-space-treatement: the values which ignore whitespace before,
after or surrounding a linefeed, use the phrase "any character flow
object ... whose character is classified ... as white space in XML (or
any sequence of such character flow objects) that immediately
precedes/follows a character flow object whose Unicode code point ...
is U+000A".
By immediately preceding (or following) is it your intention
that the sequence of character FOs in question are siblings, or that
they are adjacent in a traversal of character FO leaves? In the first
(literal) interpretation, in the following example the spaces after
"abc" will not be ignored, because the following linefeed is in the
wrapper and not an immediate sibling.
<fo:block>Text abc abc <fo:wrapper font-weight="bold">
xxx </fo:wrapper>......</fo:block>
1b. white-space-collapse: same question for the "true" value concerning
collapse of immediately preceding/following or "consecutive".
The literal interpretation is certainly easier to implement. If I use
the "leaf-node" interpretation (ie, what is visible on the paper), there
are some fuzzy cases where the value of the property can change in the
middle of a sequence of white-space, which makes it hard to know what
shold be done. On the other hand, in the case of fo:wrapper which is
often used simply to change the font-style or weight, it seems logical
that white-space handling should transparently cross the boundary.
</quote>
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?
>
> Keiron.
>
> On 2002.02.23 18:30 [EMAIL PROTECTED] wrote:
> > Keiron,
> >
> > I see you've actually started to make TextLayoutManager do something. I
> > noticed during my CTM testing with the PDF renderer, that it's "eating"
> > the first character of my text, ie. "Hello world" came out as "ello
> > world". Since I don't think you're French which could account for not
> > pronouncing the 'h', I thought it might be due to the 'wordStart + 1'
> > used to set the text for the Word Area.
> >
> > I also noticed there's a lot of whitespace handling in the code still. A
> > few months ago I put some white-space handling into the FO tree building
> > logic. In fo.flow.Block.end(), it basically iterates over all its kids
> > and tries to get rid of all the unnecessary white-space before it gets
> > to the layout manager.
> > The idea was that the LM would only see the whitespace it was actually
> > supposed to layout and the linefeeds which were real line-break
> > characters.
> >
> > I haven't studied the new TextLM code in detail, but I would think it
> > could be simplified based on that approach.
> >
> > Regards,
> > Karen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
