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