Sorry -- I didn't intend to send this to the list. An answer would still
be appreciated if anyone has one.
shap
On Sat, 2005-04-09 at 14:14 -0400, Jonathan S. Shapiro wrote:
> Dominique:
>
> I seem to recall a note from you saying that you had built a transformer
> that generated LaTeX from some form of XML input. If I am confused,
> please forgive me.
>
> I am running into a problem with my OSDoc XSLT transformers. It is one
> of those problems where the solution will be obvious in hindsight, and
> if you have done a LaTeX transformer you will know the answer.
>
> For readability in the input, we tend to have the habit of writing with
> extra newlines, as in:
>
> <p>
> mumble mumble mumble.
> </p>
>
> When transforming P tags, in our current transformer, this leads to four
> paragraph-related newlines in the output: the two in the input and an
> additional one above and below inserted by the transformer.
>
> In certain contexts this is quite bad. For example, when generation a
> \footnote{...}, the extra newline at the top causes errors and in tables
> the extra newline at the bottom also causes strange things to happen.
>
> So my easy questions:
>
> 1. I know that there is some mechanism to canonicalize whitespace in
> XSLT, which eliminates embedded newlines and collapses multiple spaces
> into a single space. Do you know how this is done?
>
> 2. How did you emit intentional newlines when you handled paragraphs? In
> particular, note that in
>
> <footnote>
> <p>
> abc.
> </p>
> </footnote
>
> one wants to get out:
>
> \footnote{abc.}
>
> but given
>
> <footnote>
> <p>
> abc.
> </p>
> <p>
> def.
> </p>
> </footnote
>
> one must get out:
>
> \footnote{abc.
>
> def.}
>
> note newline separator, but not newline before or after. I already know
> how to identify whether a paragraph is first or last, but I would
> appreciate any sense you may have of what the rule should be for when to
> emit the newline.
>
> 3. Once the above problem is "solved", I will then need to discover how
> to restore literal (raw) input processing in verbatim environments.
>
> Any suggestions you may have would be very welcome.
>
>
> shap
>
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
