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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

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

Subject: Re: [docbook-apps] O'Reilly blog...

On 05/02/13 04:59, Warren Young wrote:
On 2/1/2013 11:31, davep wrote:

It's an interesting article, and the issues it brings up are real.
DocBook XML is fine when it fits the shape of the hole your problem has
made in the world.  The current stylesheets have a bit of flexibility
and customizability in them to reshape that plug a bit, but it's pretty
rigid in practice.

(I'm working from the assumption that most DBX creators use the stock
stylesheets as-is, or with minimal customizations, most of which are
pasted in from third party resources.  I'm aware that you can get a lot
more flexibility out of DBX if you're willing to write some XSL{T,FO,}
yourself.  I'm just betting that most are like me, and don't.)

I would guess that most start out like you (and me), then get an itch
which XSLT scratches, i.e. we want more out of docbook, or more usually,
we want something just a little different (your chapter numbering example)

I just happened to be reading a status update from one of the authors of
_The Art of Electronics_[1], regarding the upcoming third edition.  Its
second edition is such a perfect example of the typesetter's art that
DBX wouldn't work for it as-is.  The third edition has a feature that
would prevent even a ham-handed attempt: the 'x' chapters.

This will always be the case. I quite firmly believe that between the
cheque signers and the 'can you just' bosses, many publishers want to
hark back to the days when typesetting took longer than writing the book.

(un)fortunately, cost constraints bring up options such as docbook and
other XML processes, whereby the content layout can be automated and
bring in a product for 5% of the prior cost. When this is seen the
bean counters soon stand up and are counted. The loss of 'final pixel'
layout is accepted (especially with the consistent quality of docbook output) and that then becomes the norm.

The other side of this non-equation is that publishers and dead trees
are falling out. Their readers want the other options, html, epub3 etc
where the pixel perfect is not the norm. That either adds an extra
burden on production costs or is 'forgotten', often to their detriment.

All a balancing act?

What I don't see from the O'Reilly article is where the benefit is
for them?


Dave Pawson

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