Re: Char node-type

["Dave Hartnoll" <Dave_Hartnoll at 3b2 dot com>]

I have an idea that will alleviate your depth of recursion problem, but as
I'm a relative newcomer to XSL, so I'm not fluent enough to express this
idea in XSL itself yet.

The idea is that your character processing template should first check the
length of it's string. When it's exactly 1 then process the character as you
do now. Otherwise, call yourself recursively, once for the 1st half of the
string, then again for the 2nd half.

Dave.

----- Original Message -----
From: "Richard Light" <richard@light.demon.co.uk>
To: <xsl-list@mulberrytech.com>
Sent: Thursday, November 23, 2000 8:05 AM
Subject: Char node-type


>
> When transforming e.g. scientific articles to HTML, we often encounter
> characters which browsers cannot represent directly.  These have to be
> 'translated' to <img> elements which call in a suitable GIF.  Precisely
> which GIF to use (bold, superscript, etc.) depends on the ancestry of
> the string containing the element.  Similar techniques are required to
> resolve and render Unicode combining characters.
>
> Since the translate function only deals with one-to-one character
> mappings, we have written a template to process text() nodes which
> processed the first character, then calls itself recursively to process
> the rest of the string.  This works fine so long as you don't have more
> than about 600 characters in a single element - with a long enough
> string you get stack overflows.
>
> It wouldn't be necessary to use this unpleasant and inefficient
> technique if XPath defined in its data model, and XSLT supported, a char
> node-type.  (Isolating a single character would also allow us to access
> its character value via the number function, which would be handy for
> processing classes of Unicode characters.)
>
> I know that asking XSLT processors to process single characters is less
> efficient than working on strings, but given the need to process single
> characters, surely it makes sense to give the XSLT processor the job and
> do it in a way that won't blow the stack?
>
> ... or is there a clever way of doing this sort of thing in XSLT that I
> haven't thought of?  (There usually is!)
>
> Richard Light
> SGML/XML and Museum Information Consultancy
> richard@light.demon.co.uk
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list