docbook-apps

  • 1.  O'Reilly blog...

    Posted 02-01-2013 18:32
    http://techblog.safaribooksonline.com/2013/02/01/the-unxmling-of-digital-books/

    " Until we have an EPUB/sans/XHTML, it's worth considering a lightweight
    subset of the format, one that represents a convention over
    configuration approach. A "microformat" version --- EPUB: the beach
    novel edition --- could be mechanically "upsampled" into big boy EPUB
    for use in the real ecosystem. It won't solve the problem of
    heterogeneity in books (which is, after all, not actually a problem
    except to reading system developers), but it could make it easier for
    even experienced ebook authors to create publications without firing up
    an XML editor, for the majority of books that have very simple metadata
    requirements. I'll outline some ideas for that in a future post."

    Odd post by Liza Daly, I'm the VP of Engineering atSafari Books Online
    <http://safaribooksonline.com/>.

    I thought others might be interested.

    DaveP



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

    Posted 02-05-2013 05:00
    On 2/1/2013 11:31, davep wrote:
    > http://techblog.safaribooksonline.com/2013/02/01/the-unxmling-of-digital-books/

    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 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.

    You see, _The Art of Electronics_ has been so popular over so many years
    that you can write something like "AoE chapter 4" and expect many people
    to know you're talking about the op-amp chapter.

    So much has changed over the 24 years (!) that have passed since the
    second edition came out that the third edition will be a substantially
    new book. They're recommending that people who have a copy of the
    second edition keep it as a supplement to the third, because they had to
    throw out so much material to make room.

    But, rather than renumber all the chapters and thereby create confusion
    when people with different editions make reference to the book, the
    authors have come up with this creative solution. The old chapter
    number will be for the material most readers will want, with extra stuff
    moved/added in the 'x' chapter.

    I don't see in The Standard Source [2] that the DBX customization
    mechanism allows for this. No doubt you could completely replace the
    label.markup implementation, but at that point, what is DBX buying you
    over some less strict markup or page layout language?

    I don't mean to bash the current way DBX works, its creators, etc. I
    myself have many DBX-sized holes in my life, and I'm happy to plug them
    with DBX. I simply want to second the observation that not all holes in
    the world are DBX-shaped.

    Frankly, the idea that XHTML, DBX, etc. might be 100% abandoned in favor
    of infinite flexibility makes me unhappy. We had that already: e.g.
    PostScript and all the DTP apps that spoke it. Sometimes trading
    flexibility for simplicity is a good thing.


    --------
    [1] http://goo.gl/Kt2Rh
    [2] http://goo.gl/JCPA6



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

    Posted 02-05-2013 07:01
    On 5.2.2013 5:59, Warren Young wrote:

    > I don't see in The Standard Source [2] that the DBX customization
    > mechanism allows for this. No doubt you could completely replace the
    > label.markup implementation, but at that point, what is DBX buying you
    > over some less strict markup or page layout language?

    Just add label attribute to each chapter with irregular label and you
    are done.

    --
    ------------------------------------------------------------------
    Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz
    ------------------------------------------------------------------
    Professional XML consulting and training services
    DocBook customization, custom XSLT/XSL-FO document processing
    ------------------------------------------------------------------
    OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
    ------------------------------------------------------------------
    Bringing you XML Prague conference http://xmlprague.cz
    ------------------------------------------------------------------




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

    Posted 02-05-2013 07:59
    On 05/02/13 04:59, Warren Young wrote:
    > On 2/1/2013 11:31, davep wrote:
    >> http://techblog.safaribooksonline.com/2013/02/01/the-unxmling-of-digital-books/
    >>
    >
    > 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?





    regards

    --
    Dave Pawson
    XSLT XSL-FO FAQ.
    http://www.dpawson.co.uk