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