any pi.xsl hackers out there?

[naglists]

Hi,

I am attempting to wire pi.xsl to recognize and /_touchup?> and treat them like and /_font?> and while I'm having fun hacking around, I'm not having any
success. This is for Compose HTML Help using a previously exported from
Styler .xsl stylesheet.

Has anyone done anything like this in the past? The trick, of course, is to
emit proper XML despite having to fire templates for the start and end tag
which are not recognized as a single object like "real" XML. I had some code
someone volunteered a long time ago for processing the nolinebreak PIs but I
can't find it (and frankly I never quite got it to work).

Hopefully I'm missing something very simple and obvious!

--
Paul Nagai

[ClayHelberg]

Hi Paul--

You can kluge this using something like this:

<xsl:text disable-output-escaping="yes">]]></xsl:text>

and of course a parallel construction for the closing tag.

--Clay

[naglists]

On Mon, Mar 24, 2008 at 7:27 PM, Clay Helberg <clay.helberg@mathworks.com>
wrote:

> Hi Paul--
> You can kluge this using something like this:
> <xsl:text disable-output-escaping="yes">> color="magenta">]]></xsl:text>
> and of course a parallel construction for the closing tag.


I've been trying variants of that (and just tried your coding exactly) and
the HTML Help displays the tag and attribute/value in-line. View source
reveals a processing instruction wrapping "<" and ">" in all the
places you'd rather have the < > 😞

Specifically:
<font<br/>color="magenta">

And for the close
?>

I'm not sure where that's coming from.

--
Paul Nagai

[steve.thompson4]

Paul,
In similar situations in other XSL, using <xsl:text<br/>disable-output-escaping="yes">color="magenta">]]></xsl:text> has solved that problem. It tells the
parser to use the actual '<' and '>'. And yes, I see the 'disable'.
Still suggest you try this (if you haven't already).

If it doesn't work, this thread then suggests a partial answer to
difficulties we're having with a custom app received from PTC that has
two sections of the pipeline coded in JAVA. Hmmm...

Regards,
Steve T

[jsulak]

Paul,

In my experience, the "
<xsl:when test="starts-with($pi," '_newline')&quot;=">
<xsl:text disable-output-escaping="yes"></xsl:text>
</xsl:when>

While this is creating a processing instruction, you get the idea. If that the or previous suggestions don't work, I'm curious which XSL transformer you're using.

-James


-----
James Sulak
Electronic Publishing Developer
Jones McClure Publishing

[PaulGrosso]

Paul,

The javax PIs get inserted by the XSLT process as part of
disable-output-escaping; the XSLT serializer is then responsible for
noting those PIs and serializing the result accordingly, but not all
XSLT serializers do this. Disable output escaping in general does not
work interoperably in all cases (it even says that in the XSLT spec).

You mention pi.xsl (which is in the Arbortext distribution at
$aptpath/lib/xsl/html/pi.xsl). That has some special code to handle the
_font PI. Your best bet is to add code to handle _touchup that parallels
that code.

If you are using the Arbortext Compose HTMLFile/HTMLHelp pipeline, there
are special atievent elements that get inserted and then serialized
correctly. If you are instead using Compose using XSL or another XSLT
process, then it is up to that process' serializer to know how to handle
disable-output-escaping.

One test you might do is to see if _font is working correctly for you.
If it is, then what you need to do is make your _touchup code parallel
to the _font code. If it isn't, then something about your pipeline or
serializer isn't working properly (and if you're using the Arbortext
pipeline, I'm not sure what that might be at this point).

paul

[ClayHelberg]

Hi Paul-



I hope things are going well for you! Do you know yet if you'll be going
to the PTC/USER World Event in June? I certainly hope to see you
there-you were sorely missed last year.



I'm not sure if you heard, but I recently started a new job at The
MathWorks. But I'm doing very similar work here, so I'll still be
attending (and presenting), and soaking up as much Arbortext info as my
brain can handle.



--Clay

[naglists]

Thanks, Paul. You got me there. I actually used the processing for
nolinebreak. It was a little simpler than the font handling. Here's my code:

<xsl:when test="starts-with($pi," '_touchup')&quot;=">
<xsl:call-template name="atievent-startelement">
<xsl:with-param name="atievent-element-name" select="span"/">
<xsl:with-param name="atievent-attrname" select="style"/">
<xsl:with-param name="atievent-attrvalue" select="color:&lt;br"/>#FF0000;"/>
</xsl:call-template>
</xsl:when>
<xsl:when test="starts-with($pi," '=" _touchup')&quot;=">
<xsl:call-template name="atievent-endelement">
<xsl:with-param name="atievent-element-name" select="span"/">
</xsl:call-template>
</xsl:when>

You should make a copy of and then modify:

$aptpath/lib/xsl/html/pi.xsl

(Aside: I have an .XSL for HTML Help and an XSL/FO for RTF Export. These are
forks begun by exporting them from a Styler .style stylesheet. These exports
contain literal pathing to pi.xsl (and others). Because I want all
stylesheets to run locally (peservices=off) or on PE, I had to create copies
of several .XSLs from the html and fo subdirectory in the path above, edit
their references, rename them where they overlapped, and store them in the
doctype directory in my client and PE custom folders. For example,
my_rtf.xsl calls pi_rtf.xsl and tbl_rtf.xsl. my_htmlhelp.xsl calls similarly
named pi and tbls stylesheets.)
By the way, the red is just a tester color ... I've asked the authors what
color they think ADDs should be. I'm not sure if I'm going to support
DELetes yet.

[naglists]

Oh yeah, one last heads-up: Editor holds onto the first use of pi.xsl. You
must stop/start Editor for changes to be re-read. (This is different from
FOSI, for example, which can be re-read by close/opening the XML instance.)

[ClayHelberg]

Hi Paul--



This (having to close/reopen Epic to refresh a modified imported
stylesheet) was a pain for me too, but they recently added a utility
function to address it: just run "clear_stylesheet()" from the Arbortext
command line and voila! A fresh up-to-date stylesheet is loaded. Very
convenient for XSL hackers. 🙂



--Clay

[PaulGrosso]

When composing using a modularized XSL stylesheet, the editor will
reread and "recompile" the stylesheet if it detects that the top level
(root) file changes. It does not look at all the files than may be
included or imported.

So if you change pi.xsl, which isn't your root xsl stylesheet file,
rather than stop/start the Editor, you could just "touch" (i.e., change
the last mod date by whatever method you wish) the root file if that's
easier for you.

paul

[naglists]

Excellent tip. Thanks.

[naglists]

Also nice. Thanks, Clay.

On Wed, Apr 9, 2008 at 2:29 PM, Clay Helberg <clay.helberg@mathworks.com>
wrote:

> Hi Paul--
>
>
>
> This (having to close/reopen Epic to refresh a modified imported
> stylesheet) was a pain for me too, but they recently added a utility
> function to address it: just run "clear_stylesheet()" from the Arbortext
> command line and voila! A fresh up-to-date stylesheet is loaded. Very
> convenient for XSL hackers. 🙂
>
>
>
> --Clay
>
>