[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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 ===================================================================== =
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|