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
======================================================================
--~----------------------------------------------------------------
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
--~--