OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi Gabor,

Gabor Kovesdan <gabor@kovesdan.org> wrote on Sat, 23 Jun 2012 08:21:14
+0200:

> 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 think this is beyond the scope of DB-Slides.  It is up to the user to
decide what to put on a slide.  In HTML, the content can be scaled to
fit using JavaScript (at least optionally), or the presenter can scroll
(which often makes sense too).  In FO, making a slide a page-sequence
will automatically split the content across slides (but perhaps there is
a way to auto-scale-to-fit the content as well).

>> 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?
>
> I imagine you mean that you want to present the content on web and
> provide a printable version with the very same outlook

No, I don't need strict consistency. But it would be nice to be able to
use any suitable output formats for presentations (HTML, PDF, ...).  It
is easy (but cumbersome and abusive) to achieve almost any page layout
using tables in a target-agnostic way.  But if we want to layout HTML
using CSS (float style, etc.), then we need DB Slides markup that is
translated into CSS classes for HTML and into, say, tables for FO
output.  We have already discussed such markup on this list.

>> I think "incremental" and "collapsible" should be properties of lists,
> ...
> 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.

Yes, I basically agree.  (<rant>Besides, I almost never use incremental
bullet points.  They obscure context and rob the listener of the ability
to anticipate where the speaker is headed.  Most speakers using them end
up microstepping through the bullet points, further damaging the thread
of the presentation.  Slides should support the speech, not vice
versa.</rant>)

Justus


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]