Re: [docbook] DocBook Slides 5.0 alpha1 available for testing

[Gabor Kovesdan <gabor@kovesdan.org>]

Hi Justus,

thanks a lot for your comments.

Em 21-06-2012 21:06, Justus-bulk@Piater.name escreveu:
> 
> I suggest adding 
> 
>   <xsl:template match="*[namespace-uri()]">
>     <xsl:copy-of select="."/>
>   </xsl:template>
> 
> to dbs3-upgrade.xsl to move over non-docbook content (MathML, SVG, ...,
> which the current script imports into the docbook namespace).

I haven't yet thought of how to process such content but it is a really
good idea indeed.


> There are some spacing and scaling issues with my own converted slides,
> but I'll hold it until you give the list green light for serious
> testing.

I'm aware of some existing problems, mostly in the S5 output, Slidy has
more space for the actual content and its CSS supports better
incremental lists. But my dilemma in general is that slides need a
layout-based presentation form and I don't know how to control the
allowed text amount on a per slide basis. I have no idea how to
calculate what will fit on a slide and what won't and it also depends on
the output format.

> I suspect that consistent content positioning (without using tables)
> between HTML and FO targets will require some thought.  To this end,
> will slide-specific markup be part of your project?

As long as content fits on a slide in all rendered formats, or in other
words, all slides have the same content in all formats, I don't think it
is necessary to implement strict consistency. I imagine you mean that
you want to present the content on web and provide a printable version
with the very same outlook, or do you mean something else? You can
control background images and formatting by customizing your CSS and FO
will have some kind of styling support, as well. Isn't using similar
formatting and the same logos (company, university department, etc.)
enough? Do we really need strict consistency? That may also limit
exploiting some features that are not present in other formats.


> The current schema requires <foil> <title>s to be wrapped inside <info>.
> In contrast, DB5 allows <section> <title>s either inside or outside of
> an <info> (but not both).  Having a title as the only info-type element
> inside a <foil> is such a common case that I think it should be allowed
> without <info>, just as it is in DB5 <section>s.

I wanted to avoid ambiguity even at the cost of verboseness. But now I
see that article also allows title, titleabbrev and subtitle. I think
you're right in this part so I'll allow it for DBS, as well.

> I think "incremental" and "collapsible" should be properties of lists,
> not of slides, as they are in Slidy.  I suspect you attached them to
> <foil> instead to avoid messing with the DocBook element content models.
> Actually, "collapsible" makes sense even for regular DocBook (at least
> for some output formats), not only for slides.

First I wanted to mess with DocBook elements but then I thought more
about it and I found that because of the limited space on a slide you
most probably won't include too many lists on a single slide. Maybe in
some particular cases you will include two lists with few elements only
but if you look at some slides you'll see that usually there is one long
enumeration per slide. And even if you include several lists, really
would you want to make such a strange design that you make one of them
incremental and not the rest? I think it would look strange and it is
definitely not a really common use case so I thought it would be better
to setup the incremental property on a per slide basis, which also
spares messing with DocBook elements.

Gabor