Re: [xsl] Grouping text nodes

[David Carlisle <davidc@xxxxxxxxx>]

> But the bit that makes my
> head ache is where you do most of the work:

Note that I made things much simpler by doing two passes, first unwrap
your nested divs into the empty milestone markers without worrying about
the possibly overlapping line markup, then come back in a second pass
with the lg mode putting in lines where both of your examples are in the
simpler case where everything to be put in a single l element is already
a sibling.

some of the coding may well be a bit mre complicated than need be 
(it does appear to have been sent at 1 in the morning:-)

In particular I'm not sure that I am quite using for-each-group
in the most fluent way yet. (I still don't use xslt2 in the day job, too
scary to change:-)


with a group like

<xsl:for-each-group select="node()" group-adjacent="empty(self::span[@class='vn'])">

then each node is tested for empty(self::span[@class='vn']) which will
be true() on spans of that form and false on everything else.
As you are grouping-adjacent each group will be a span
(which you can ignore) which will have current-grouping-key of false()
as self::span is not empty or the group you want which is all nodes
between one span and the next, which will have a grouping key of
false().

but I'd rather i didn't have to do this:

<xsl:when test="current-grouping-key() and(current-group()/self::* or
normalize-space(string-join(current-group(),'')))">

which was mainly about not generating an empty line at the beginning
with just the white space before the first span.

> <xsl:template match="*[span[@class='vn']]" mode="lg">

> What are the extra [ ] doing in this case?

*[span] is all elements that have a span child.
*[span[@class='vn']] is all elements that have a soan child with that
 class. It is only for such an eleemnt taht lg mode does anything
 interesting, grouping on the span[@class='vn'] (which you know are
 there)


> when  a milestone and not the current-group make a copy of it without
> the br... (hrmmm, that doesn't sound right...told you I was confused.)

the milestone test was because othewise I was generating
<l xml:id=".."><milestone/></l>
as the line grouping code just sees milestone as a normal part of the
text run, so if I detect that the group just consists of a milestone 
don't wrap it in a line element.

> It is all working fine (though <milestone>s are sometimes appear
> immediately before </l> instead of just outside where I might suspect
> would be more usual).

that could probably be fixed, but it might be simpler to just have a
third pass that does final cleanup moving milestones out of lines, if
that's what you want. in that case you could probaby remove teh above
test for milestone in teh main grouping loop and allow that to generate
<l><milestone/></l> and then just let the third pass sort that out.

I was reading some reviews of extreme (chaired by the same folks who keep
this list in order:-) yesterday was all about overlapping markup, it
seems..

eg
http://www.cafeconleche.org/


David



________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________