xsl-list
[Top] [All Lists]

Re: [xsl] Prince XML vs Docbook

2018-01-19 10:41:32
That would be much appreciated Eliot.

regards

On 19 January 2018 at 15:27, Eliot Kimber ekimber(_at_)contrext(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
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


On 1/18/18, 12:14 PM, "Eliot Kimber ekimber(_at_)contrext(_dot_)com" 
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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



    On 1/18/18, 11:39 AM, "B Tommie Usdin 
btusdin(_at_)mulberrytech(_dot_)com" 
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:

        Hi Eliot --

        > On Jan 18, 2018, at 10:54 AM, Eliot Kimber 
ekimber(_at_)contrext(_dot_)com 
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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 “perceived” 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).

        — Tommie

        ======================================================================
        B. Tommie Usdin                        
mailto:btusdin(_at_)mulberrytech(_dot_)com
        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
        ======================================================================










-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--

<Prev in Thread] Current Thread [Next in Thread>