>My perl at run-time does not know what the name of the slide/file
>is going to be. But it can NAME that filename: it can plant a
>tag that will be turned into it. So the perl could return
>
> <A HREF='\REFID{name="Section 2"}'
> onmouseover="alert('Read this first')">The Second Section</A>
>
>knowing that it would turn into...
>
> <A HREF='slide0012' onmouseover="alert('Read this first')">The Second Section</A>
>
>or whatever...
Hm, I never wrote HTML into a source directly, but yes, it should work
.... and then, you could include such a tag and the results would be as
described, indeed.
Nevertheless, as you might expect ;-), I'm searching for a more common
solution not restricted to HTML ...
If the HTML code would be embedded by \EMBED, an included PerlPoint tag
would *not* be solved (because it would not be parsed and detected).
That's what I thought of. If we embed it directly, the tag is parsed,
but the HTML goes into all target formats (unless it is placed in
conditional parts or a \HIDE tag with a condition which is always true
except for the target format HTML). So what if we'd combine those
approaches and pp2html would provide wildcard replacement within
embedded HTML? Something like:
\EMBED{lang=html}
<A HREF='REFID(Section 2)'>
onmouseover="alert('Read this first')">The
Second Section</A>
\END_EMBED
But reading this, I notice that we can already combine \EMBED *and* tag
usage. Just by joining several elements:
\EMBED{lang=html}<A HREF="\END_EMBED
\REFID{name="Section 2"}
\EMBED{lang=html}" onmouseover=
"alert('Read this first')">The
Second Section</A>
\END_EMBED
This way we get the greatest flexibility: the target code is marked as
such, *and* we can use tags. All we need is a new tag \REFID or/and a
new \REF option "id".
Of course, there are several ways to do things - but if HTML (or
another language) is "embedded" directly into a document, I strongly
recommend to make it detectable by conditions or \HIDE.
>
> > Ways I currently see to achieve what you are looking for, links build
> > according to personal preferences:
>
> > * pp2html templates provide a keyword/syntax ...
>
> > * pp2html implements certain wished configurations ...,
>So I, of course, want both of these:-)
Let's see what Lorenz says. Implementing several more link types
directly seems possible to me. In the long term, however, a generic
solution would relieve him more.
>Perhaps something like:
> Any unknown tag "\FOO"
> causes PerlPoint to call the function FOO with two arguments:
> a hash of the arguments given to the tag, and
> the body of the tag.
> The string returned by the tag is taken as its expansion.
This would imply that everything looking like a tag has to be treated
as a tag, different to the current approach where only declared tags
are recognized and document authors are free to use any other
\UPPERCASED constructs.
It also implies that a document author can deal with a complex body
structure.
But I like the idea of user defined handlers. To keep things simple and
documents interchangable, those definitions must be part of the source
- it is hard for a document author to rely on a certain library added
to a local PerlPoint installation. So the functions should not be
passed to a converter but be placed within a document. (They may be
hidden in a library included via \INCLUDE.)
So I suggest a new basic tag \FREESTYLE (name may be changed) that may
be invoked like this:
// define your own backend handling
\EMBED{lang=perl}
sub privateTagHandler {...}
\END_EMBED
\FREESTYLE{callback=privateTagHandler more=options}<body>
The callback handler could then be invoked by the backend framework
automatically - so it would be transparent to converter authors.
The most difficult part in my eyes is the definition of a clear and
flexible interface. An (even advanced) document author does not
necessarily know how a converter works, and this is a PerlPoint design
rule - he does not need to. But to write such a handler, he needs to
access and provide data.
The handler, by the way, needs to be able to handle two situations: the
opening and the completion of a \FREESTYLE tag (because the
intermediate format is a stream).
Well, that's a fruitful discussion! ;-)
Jochen