[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Prince XML vs Docbook

Subject: Re: Prince XML vs Docbook
From: "Eliot Kimber ekimber@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 19 Jan 2018 15:27:18 -0000
Re:  Prince XML vs Docbook
I was thinking about the how-to knowledge issue and the need to write
something last night and I realized that as part of the work I'm doing now I
will need to capture the basic how-to of CSS pagination in any case so I might
as well do in a publicly-available form.

Cheers,

E.
--
Eliot Kimber
http://contrext.com


o;?On 1/18/18, 12:14 PM, "Eliot Kimber ekimber@xxxxxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

    I would disagree with your assessment that CSS pagination is not easier
than FO *if* there was appropriate how-to guidance available.

    Having gone through the pain of learning how to do it I think I can say
with confidence that *if* there was good guidance then it wouldn't be that
hard.

    It would also help to have a less-like facility that could be easily used
with XSLT (e.g., either an XSLT implementation of templated CSS or a Java
library so that you can use it with the infrastructure you already need to run
Saxon). I haven't found such a tool yet, although I haven't looked that hard.

    Granted, working out the details of how to translate your source into
appropriate pages is inherently challenging. Desktop publishing tools obscure
the difficulty behind nice user interfaces. That aspect of the problem is more
or a less a constant. But I think CSS's way of capturing the design details as
implementation artifacts is much more accessible to designers than XSL-FO page
masters and page sequence masters. With some appropriate templating of page
rules it could be pretty easy to define and maintain.

    Another practical issue, and one that should not be underestimated, is the
need to synthesize elements in source content to enable generation of running
headers and footers (more generally, any edge region content).

    Because of the way CSS works you can't have an element that both
contributes its structured content to an edge region and is shown in the main
flow. In addition, you may likely need to transform or adjust the content to
satisfy edge requirement requirements anyway, something you can't do with CSS
alone in all cases (e.g., something more than a simple case transform).

    But even here the separation of implementation concerns between transform
and layout helps.

    In an XSL-FO transform the generation and styling of edge region content
is usually tightly bound into the larger FO generation (and thus styling)
code, making it harder to find and adjust just as a matter of style.

    The XSLT+CSS approach separates the details of what *content* goes in the
running heads and the styling details (where it appears on the page and how
it's formatted in that context).

    Note also that for CSS pagination to work well the input really needs to
be HTML, not arbitrary XML. While CSS can, in theory, be applied to arbitrary
XML, in practice it doesn't really work, for a number of reasons, not least of
which is CSS's lack of support for namespace-aware selection.

    So the pipeline for arbitrary XML to pages via CSS needs to be:

    XML -> xform to HTML -> xform to HTML optimized for CSS -> CSS pagination
engine -> Pages

    However, pretty much all XML doctypes used for publications already have a
to-HTML transform that should be relatively easy to adapt to the needs of CSS
optimization (e.g., generating things like tables of contents, elements for
edge regions, etc.).

    Leigh White's DITA for Print book serves as an excellent example of a
comprehensive how-to guide to doing complex pagination with non-obvious
technology from sophisticated XML source. If we had a comparable book for CSS
pagination I think most people tasked with applying CSS for pagination would
be able to be productive with a minimum of pain.

    The challenge of course is finding someone to write such a book (and keep
it up to date as the technology evolves)....

    Cheers,

    E.
    --
    Eliot Kimber
    http://contrext.com



    o;?On 1/18/18, 11:39 AM, "B Tommie Usdin btusdin@xxxxxxxxxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

        Hi Eliot --

        > On Jan 18, 2018, at 10:54 AM, Eliot Kimber ekimber@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
        >
        > However, CSS is so much easier to work with and is so much more
accepted that the cost in functionality and spec fuzziness is far outweighed
by the ability to use less-specialized personnel to do the styling work.


        Actually, I see it a bit differently. CSS is bperceivedb to be
easier to work with, and people who CLAIM CSS expertise are far easier to find
and hire. However, CSS for print is no easier to work with than FO, and most
people hired for their CSS expertise find that they need to learn a lot in
order to make even reasonable quality pages using CSS.

        I have been recommending that many users adopt the CSS to print
approach not because it is better (it is not), or because it is easier (it is
not), or because you need less specialize skills to do it (you do not), but
because it is more palatable in the marketplace because it is easier to evolve
the skilled personnel needed from people with a related skill (CSS for soft
display).

        b Tommie

        ======================================================================
        B. Tommie Usdin
mailto:btusdin@xxxxxxxxxxxxxxxx
        Mulberry Technologies, Inc.                http://www.mulberrytech.com
        17 West Jefferson Street                           Phone: 301/315-9631
        Suite 207                                    Direct Line: 301/315-9634
        Rockville, MD  20850                                 Fax: 301/315-8285
        ---------------------------------------------------------------------
-
        Mulberry Technologies: A Consultancy Specializing in XML and SGML
        =====================================================================
=

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.