No, that's not what I meant. All I'm saying is that people will want
to migrate legacy content to DB 5 to take advantage of new features,
so I argue against questioning each and every construct of the
existing docbook-slides, and in favor of extending it, while being
very careful and constructive
Stefan Seefeld seef...@sympatico.ca wrote on Tue, 20 Jan 2009
09:51:23 -0500:
foil template=my-two-column-template
block name=left
itemizedlist/
/block
block name=right
mediaobject/
/block
block name=footer/
/foil
I see. Not bad. However, I would prefer to avoid element
justus-b...@piater.name wrote:
Stefan Seefeld seef...@sympatico.ca wrote on Tue, 20 Jan 2009
09:51:23 -0500:
foil template=my-two-column-template
block name=left
itemizedlist/
/block
block name=right
mediaobject/
/block
block name=footer/
/foil
I see. Not bad. However, I would
justus-b...@piater.name wrote:
Of course, this is a brutal departure from the XML principle of
separation of content from presentation, but as I argued in an earlier
posting, to me the advantages of (ab)using DocBook for presentations
weigh far heavier than purity of principle.
Sorry for
Jirka Kosek wrote:
justus-b...@piater.name wrote:
Of course, this is a brutal departure from the XML principle of
separation of content from presentation, but as I argued in an earlier
posting, to me the advantages of (ab)using DocBook for presentations
weigh far heavier than purity of
DavePawson wrote:
justus-b...@piater.name wrote:
Stefan Seefeld seef...@sympatico.ca wrote on Tue, 20 Jan 2009
09:51:23 -0500:
foil template=my-two-column-template
block name=left
itemizedlist/
/block
block name=right
mediaobject/
/block
block name=footer/
/foil
I see. Not bad.
Jirka Kosek wrote:
Sorry for stepping-in, but to me it seems that you might try to have a
look ODF and OOXML and see how they describe presentation slides. It
seems that your requirements are so presentational and layout driven
that it simply doesn't nicely fit into DocBook principles.
I
Stefan Seefeld wrote:
This sort of layout can in principle be achieved using DocBook tables
(CALS or HTML style), which is what I do, but it is unwieldy and
cumbersome to adjust.
It is not semantic, it is inaccessible for non-visual users
and plain bad XML IMHO.
Could you elaborate on that a
DavePawson wrote:
I was referring to the use of tables.
Oh I see. I guess Justus was suggesting a way to emulate (part of) the
desired layout capabilities by means of existing markup.
I agree that tables are a bit hackish (as they are in most cases in HTML).
Plain divs, correctly
DavePawson da...@dpawson.co.uk wrote on Wed, 21 Jan 2009 15:45:21
+:
Tables are for tabular data. Go read W3C accessibility guidelines.
Tables are not for visual layout all over the screen.
CSS does that nicely without messing with accessibility.
It's the *HTML rendering* that has to be
justus-b...@piater.name wrote:
Exactly. And my suggestion to introduce some new 'box' markup was
precisely meant to provide hooks similar to HTML divs, so somewhere
else an appropriate layout could be attached to it.
Somewhere else being an XSLT stylesheet?
That, or CSS.
This
Hi folks,
This one is embarrassing, but I've pored over the scripts for hours and I still
can't figure out how to dump the trailing period used in label numbers.
Basically, the Docbook scripts give me 1.2.3.4. Title and I need 1.2.3.4
Title.
I know. This should be simple, and likely is. I
The last period comes from the generated text templates in common/en.xml:
l:template name=section text=%n. %t/
(non-breaking space replaced by ordinary space for clarity here).
So you'll need to add a 'local.l10n.xml' parameter to your customization
layer and include a customized gentext for
I meant to respond to this item earlier.
The 'hyphenate' property does not apply to fo:inline elements, only block
level elements. That's what the XSL-FO 1.0 and 1.1 standards say, and I'm
not sure why that is. There doesn't seem to be an FO mechanism to prevent
hyphenation while allowing
Bob Stayton wrote:
The 'hyphenate' property does not apply to fo:inline elements, only
block level elements. That's what the XSL-FO 1.0 and 1.1 standards say,
and I'm not sure why that is.
Maybe because many typesetting engines are not able to control this
property on word level, but also
Thanks Bob,
When you update the manual, mentioning that the trailing period in the *toc* is
controlled independently by the autotoc.label.separator parameter might save
some folks a little groping as well.
Or, it might be obvious to people who get more sleep than I do.
Cheers,
Jeff.
Thank you, Bob and Jirka, for your notes.
Bob Stayton ha scritto:
However, your attribute-set includes the use of
keep-together.within-line=always, so it should prevent that whole
phrase from breaking across lines, which would of course prevent
hyphenation within any of its words. In my
justus-b...@piater.name wrote:
DavePawson da...@dpawson.co.uk wrote on Wed, 21 Jan 2009 15:45:21
+:
Tables are for tabular data. Go read W3C accessibility guidelines.
Tables are not for visual layout all over the screen.
CSS does that nicely without messing with accessibility.
It's the
18 matches
Mail list logo
