Re: Question

>Separate frames would be a possibility.  
>
>So, too, I guess, would be "matched pairs" of documents
>     slide1-slide.html    and   slide1-notes.html
>where each slide would have a link to "notes".

Yes, this would be another way to make use of streams.

>But my simple-minded idea was just to put the notes further down the same
>document as the slide.  This also makes life easy for producing a printed 
>form of a presentation: notes and slides always come out together...

I agree that it should always be possible to make notes appear
*together* with related slides, and that putting them below the slide
contents is a good and intuitive way to do this.

Nevertheless, we might even go a step further. There might be people
wishing to place notes *above* the slides, or besides, or to set up a
crazy layout. Whether this makes sense or not, I'm always trying to
make things (programs ;-) as flexible as possible ...

Additionally, a source document does not need to be written with a
certain output format (like HTML) in mind necessarily. Therefore I
prefer a more common solution on the source language side, suitable for
HTML as well as for PDF or StarImpress or whatever the target format
may be.
pp2html and its template system, on the other hand, can be *very* HTML
specific.

>I think you could achieve most of what I would like with a much more
>"lightweight" mechanism.  Give PerlPoint a richer page model:
>      CURRENT TEMPLATES             NEW TEMPLATES
>              ...                        ...
>
>Then a \NOTES command that would
>      - include the bottom-of-slide and bottom navigation templates
>      - include a top-of-notes template
>      - call the user's "START_NOTES" macro (to set sizes or whatever)
>      - ensure that the end-of-page processing used the bottom-of-notes
>        template in place of the bottom-of-slide ones.

The only problem I have with this proposal is that it addresses a very
specific HTML layout. I'd prefer to let layout configurations to be
specified for a converter call, not within the document source, so that
one and the same source can still be layouted one way or the other (by
switching a pp2html style, for example).

There's no problem with an HTML specific \NOTES tag at first sight
(which could be ignored by converters to other languages like the
\BOX... tags today, for example). I could be thought of as a first
intermediate solution, but configuration could become complicated if
pp2html shall provide flexibility in how to place the notes (above
slide text or below, or on linked pages usually hidden in presentation,
or in a two column format, or ...)

More, \NOTES would need to become a built-in-tag like \INCLUDE, because
it would start a notes section. It would be a tag, but to be placed at
very special positions, so it would need to become part of the grammar.
That's more like a paragraph.

So thinking about all this and searching for a solution, I currently
imagine a pp2html template system made of parts with user chosen names
(instead of the fixed frame names today). Each of them could be
associated to a document stream and consist of

   * a base where the streams content (of the current
     chapter) goes into,

   * navigation templates up and below,

   * possibly templates for start/end of a part?

This would result in a hierarchical, very general system. A part
*could* be transformed into an HTML frame, but not necessarily. A user
could compose a frame by combining the parts. Maybe Template:: modules
(or something like them) can be used, but I only heard of them, so I do
not
know more than the name which seems to fit into the these thoughts.

These are just ideas/suggestions. I don't know how well JavaScript and
applet navigation could be integrated, for example.



>Maybe it would even work better as...
>    \INCLUDE{type=template file="filename"}

The parser would pass the file like an HTML typed file, for example, to
be handled by the converter. To assign templates to certain converters,
we could use an additional setting to flag a template, as in

 \INCLUDE{type=html handleas=template file="filename"}

so that existing source filters would recognize if a template shall be
ignored or included. And it should already work with the current parser
;-)

I think of this as an additional feature.

                 Jochen