docbook-apps

I've just put the finishing touches on a Python module to assist
in the programmatic construction of XSL-FO files. It's built on
top of lxml:

http://www.nmt.edu/tcc/projects/fohelpers

If you find this useful or have any comments, I'd like to hear
about it. I realize XSL-FO is a dead standard, but so long as
DocBook and DITA are around, it'll be supported. Can anyone
suggest a better route from Python to PDF?

Best regards,
John Shipman (john@nmt.edu), Applications Specialist
New Mexico Tech Computer Center, Speare 146, Socorro, NM 87801
(575) 835-5735, http://www.nmt.edu/~john
``Let's go outside and commiserate with nature.'' --Dave Farber

Just curious as to why you think xsl-fo is a dead standard?

Carlos
On May 8, 2012, at 2:17 PM, John W. Shipman wrote:

> I've just put the finishing touches on a Python module to assist
> in the programmatic construction of XSL-FO files. It's built on
> top of lxml:
>
> http://www.nmt.edu/tcc/projects/fohelpers
>
> If you find this useful or have any comments, I'd like to hear
> about it. I realize XSL-FO is a dead standard, but so long as
> DocBook and DITA are around, it'll be supported. Can anyone
> suggest a better route from Python to PDF?
>
> Best regards,
> John Shipman (john@nmt.edu), Applications Specialist
> New Mexico Tech Computer Center, Speare 146, Socorro, NM 87801
> (575) 835-5735, http://www.nmt.edu/~john
> ``Let's go outside and commiserate with nature.'' --Dave Farber
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>

On Tue, 8 May 2012, Carlos Araya wrote:

+--
| Just curious as to why you think xsl-fo is a dead standard?
+--

A colleague (who does not wish to be quoted) says there's not
much action on the committee anymore. Although it is still
officially supported, it seems moribund.

I was sort of hoping that the committee was working on adding
critical features not in the current standard that modern book
designers appreciate, e.g., constraints about positioning content
on facing pages, or text floated on both sides of a figure, or a
page model not as primitive as the five-region simple-page-master
model. Apparently not.

I've heard a few people over the past few years insisting that
the replacement for XSL-FO (within W3C) is to use the "@media
print" feature of the CSS standard. If I read that correctly,
that means that in order most ordinary people to get a decent
print rendering of their web page, the following must hold:

(1) The page author has to write the CSS to define how to
render it on a fixed page size;

(2) Their browser supports the "@media print" rule and
renders it correctly.

Then the user prints it using the browser's print function.

Am I right? Is this practical? Do browsers do the right thing?
Will this eventually obviate the need for XSL-FO? What replaces
the Modular Style Sheets in my DocBook toolchain?

What about the important differences between Web and print
rendering? Will there be a table of contents? Will that and
cross-references display page numbers instead of useless,
unclickable underlining? How does that work in CSS?

One of my pet peeves is Web pages that can't be printed because
they contain program source code with lines way too wide to fit
on the page. Will CSS render such pages with the pages wrapped
and not truncated? If they do, will I be able to tell the
hard line breaks from cases where the line got wrapped?

Best regards,
John Shipman (john@nmt.edu), Applications Specialist
New Mexico Tech Computer Center, Speare 146, Socorro, NM 87801
(575) 835-5735, http://www.nmt.edu/~john
``Let's go outside and commiserate with nature.'' --Dave Farber

The people at lxml-dev will only get half the conversation but here it
goes.

XSL-FO is as complete as it needs to be, for the domain it is used in.
People who have been in the standard bodies can confirm or deny this but I
believe that FO was not meant for book publishing but to be used in
conjunction with XSL to produce short articles and reports.

In the time the standard was developed other technologies have emerged that
give you better results when creating full books. Epub 3 comes to mind. It
can incorporate multimedia and do other things like the ones you're
mentioning: TOC, content positioning (for some readers, right now it only
works on the iPad as far as I know), multimedia (audio and video) and, as
far as I know, overlays.

You can also view epub content on the browser (I use a Firefox extension to
view most of mine) both online and offline, iPad, Nook, Kindle and many,
many others.

The solution you propose is not mean to replace FO or Epub. If anything
it's mean to give web content a better printed output rather than the ugly
and awful printout from non-css browsers way back when.

Carlos

On Wed, May 9, 2012 at 10:51 AM, John W. Shipman <john@nmt.edu> wrote:

> On Tue, 8 May 2012, Carlos Araya wrote:
>
> +--
> | Just curious as to why you think xsl-fo is a dead standard?
> +--
>
> A colleague (who does not wish to be quoted) says there's not
> much action on the committee anymore. Although it is still
> officially supported, it seems moribund.
>
> I was sort of hoping that the committee was working on adding
> critical features not in the current standard that modern book
> designers appreciate, e.g., constraints about positioning content
> on facing pages, or text floated on both sides of a figure, or a
> page model not as primitive as the five-region simple-page-master
> model. Apparently not.
>
> I've heard a few people over the past few years insisting that
> the replacement for XSL-FO (within W3C) is to use the "@media
> print" feature of the CSS standard. If I read that correctly,
> that means that in order most ordinary people to get a decent
> print rendering of their web page, the following must hold:
>
> (1) The page author has to write the CSS to define how to
> render it on a fixed page size;
>
> (2) Their browser supports the "@media print" rule and
> renders it correctly.
>
> Then the user prints it using the browser's print function.
>
> Am I right? Is this practical? Do browsers do the right thing?
> Will this eventually obviate the need for XSL-FO? What replaces
> the Modular Style Sheets in my DocBook toolchain?
>
> What about the important differences between Web and print
> rendering? Will there be a table of contents? Will that and
> cross-references display page numbers instead of useless,
> unclickable underlining? How does that work in CSS?
>
> One of my pet peeves is Web pages that can't be printed because
> they contain program source code with lines way too wide to fit
> on the page. Will CSS render such pages with the pages wrapped
> and not truncated? If they do, will I be able to tell the
> hard line breaks from cases where the line got wrapped?
>
> Best regards,
> John Shipman (john@nmt.edu), Applications Specialist
> New Mexico Tech Computer Center, Speare 146, Socorro, NM 87801
> (575) 835-5735, http://www.nmt.edu/~john
> ``Let's go outside and commiserate with nature.'' --Dave Farber
>

On Wed, May 09, 2012 at 11:34:25AM -0700, Carlos Araya wrote:
> The people at lxml-dev will only get half the conversation but
> here it goes.
>
> XSL-FO is as complete as it needs to be, for the domain it is used
> in. People who have been in the standard bodies can confirm or
> deny this but I believe that FO was not meant for book publishing
> but to be used in conjunction with XSL to produce short articles
> and reports.

Wow, that's ... quite something.

So, basically, there's no sane, supported toolchain for producing
books from doc*book*?

I mean, the options I'm aware of that are actually usable are
XSL-FO, which apparently isn't *for* that, and dblatex, which is
certainly usable but isn't really about docbook at all, it's about
transforming docbook into something book-able.

Am I missing something? I take it, therefore, that the pro/paid
XSL-FO solutions are a bunch of hacks on top of XSL-FO?

-Robin

Robin,

On May 9, 2012, at 12:28 PM, Robin Lee Powell wrote:

> On Wed, May 09, 2012 at 11:34:25AM -0700, Carlos Araya wrote:
>> The people at lxml-dev will only get half the conversation but
>> here it goes.
>>
>> XSL-FO is as complete as it needs to be, for the domain it is used
>> in. People who have been in the standard bodies can confirm or
>> deny this but I believe that FO was not meant for book publishing
>> but to be used in conjunction with XSL to produce short articles
>> and reports.
>
> Wow, that's ... quite something.
>
> So, basically, there's no sane, supported toolchain for producing
> books from doc*book*?
>
That is incorrect.

There most definitely is a sane, supported toolchain for producing books from DocBook.
Nearly our entire catalog at XML Press is produced from DocBook Version 5 using the open source DocBook stylesheets.

The standard stylesheets will generate a respectable book with TOC, index, front matter, back matter, chapters, appendices, prefaces, colophons, etc.

We have customizations, but they are for presentation details (fonts, page size, etc.), not for the basic functionality needed to create a book.

I can't say whether FO was "intended" for book publishing, but in our experience it is adequate for our needs, and with a few extensions provided by RenderX (and also by Antenna House), it is fully up to the job.

Best Regards,
Richard Hamilton
-------
XML Press
XML for Technical Communicators
http://xmlpress.net
hamilton@xmlpress.net

Robin:

When I expressed my opinion of FO being as complete as it needed to be perhaps I should have clarified a few things.

Is Docbook a viable way to publish book-based content. Yes, it is

Is it as complete as it need to be for me to consider it a full-fledged book publishing tool. No, and here are the reasons why I think this is the case.

You cannot do absolute positioning of content on a page
Typography is weak (at least with the open source tools available)

If anyone can point me to resources that address those two areas, I'll be more than happy to be proved wrong.

Carlos

On May 9, 2012, at 12:28 PM, Robin Lee Powell wrote:

> On Wed, May 09, 2012 at 11:34:25AM -0700, Carlos Araya wrote:
>> The people at lxml-dev will only get half the conversation but
>> here it goes.
>>
>> XSL-FO is as complete as it needs to be, for the domain it is used
>> in. People who have been in the standard bodies can confirm or
>> deny this but I believe that FO was not meant for book publishing
>> but to be used in conjunction with XSL to produce short articles
>> and reports.
>
> Wow, that's ... quite something.
>
> So, basically, there's no sane, supported toolchain for producing
> books from doc*book*?
>
> I mean, the options I'm aware of that are actually usable are
> XSL-FO, which apparently isn't *for* that, and dblatex, which is
> certainly usable but isn't really about docbook at all, it's about
> transforming docbook into something book-able.
>
> Am I missing something? I take it, therefore, that the pro/paid
> XSL-FO solutions are a bunch of hacks on top of XSL-FO?
>
> -Robin

On 10 May 2012, at 01:22, Carlos Araya wrote:

> Robin:
>
> When I expressed my opinion of FO being as complete as it needed to be perhaps I should have clarified a few things.
>
> Is Docbook a viable way to publish book-based content. Yes, it is
>
> Is it as complete as it need to be for me to consider it a full-fledged book publishing tool. No, and here are the reasons why I think this is the case.
>
> You cannot do absolute positioning of content on a page

You are absolutely right about this but for large classes of books this is irrelevant. We've found that most b&w text can be done up and including academic monographs with tables and charts (although chart positioning is not perfect)

> Typography is weak (at least with the open source tools available)

FOP has poor typography and FO itself isn't really up to the standard of a page layout tool but for many purposes it's good enough. Once you start talking real money (such as the Antenna House tools) the situation gets a lot better.

It definitely isn't a technology for spread based layouts thought.

We've done proofs of concept on FO based publishing with two large UK publishers and are looking at a third. The second client is looking at how to use the tools in a production environment at the moment.

The biggest problem is the lack of support for signatures and that is in the 2.0 wishlist. One of the big issues we've seen with our clients is that publishers see the W3C as irrelevant to them. This means that publishing industry representation on the FO committee is poor.

nic
>
> If anyone can point me to resources that address those two areas, I'll be more than happy to be proved wrong.
>
> Carlos
>
> On May 9, 2012, at 12:28 PM, Robin Lee Powell wrote:
>
>> On Wed, May 09, 2012 at 11:34:25AM -0700, Carlos Araya wrote:
>>> The people at lxml-dev will only get half the conversation but
>>> here it goes.
>>>
>>> XSL-FO is as complete as it needs to be, for the domain it is used
>>> in. People who have been in the standard bodies can confirm or
>>> deny this but I believe that FO was not meant for book publishing
>>> but to be used in conjunction with XSL to produce short articles
>>> and reports.
>>
>> Wow, that's ... quite something.
>>
>> So, basically, there's no sane, supported toolchain for producing
>> books from doc*book*?
>>
>> I mean, the options I'm aware of that are actually usable are
>> XSL-FO, which apparently isn't *for* that, and dblatex, which is
>> certainly usable but isn't really about docbook at all, it's about
>> transforming docbook into something book-able.
>>
>> Am I missing something? I take it, therefore, that the pro/paid
>> XSL-FO solutions are a bunch of hacks on top of XSL-FO?
>>
>> -Robin
>

--
Corbas Consulting / @CorbasLtd
Digital Publishing Consultancy and Training
http://www.corbas.co.uk, +44 (0)7718 906817/+44 (0)1273 930765

On Thu, May 10, 2012 6:32 am, Nic Gibson wrote:
> On 10 May 2012, at 01:22, Carlos Araya wrote:
>
>> Robin:
>>
>> When I expressed my opinion of FO being as complete as it needed to be
>> perhaps I should have clarified a few things.
>>
>> Is Docbook a viable way to publish book-based content. Yes, it is
>>
>> Is it as complete as it need to be for me to consider it a full-fledged
>> book publishing tool. No, and here are the reasons why I think this is
>> the case.
>>
>> You cannot do absolute positioning of content on a page
>
> You are absolutely right about this but for large classes of books this is
> irrelevant. We've found that most b&w text can be done up and including
> academic monographs with tables and charts (although chart positioning is
> not perfect)

Are we talking about Docbook or FO here? XSL 1.0 has absolutely
positioned block containers, and XSL 1.1 added the ability to flow content
into multiple regions on the page.

>> Typography is weak (at least with the open source tools available)
>
> FOP has poor typography and FO itself isn't really up to the standard of a
> page layout tool but for many purposes it's good enough. Once you start
> talking real money (such as the Antenna House tools) the situation gets a
> lot better.

The absence of properties for kerning, etc., ties in with XSL-FO not
specifying the line layout algorithm, which I would attribute partly to
XSL 1.0 being meant to be used with multiple formatters, including being
retrofitted onto pre-existing formatting engines (as it was), and partly
to a philosophy that formatters should be able to implement the spec and
still compete on features, so if you want better-looking paragraphs, you'd
find the formatter that could do it.

Developing software requires time and/or money (to fund the time). Open
source software depends on people having the itch to solve that particular
problem, not having more important claims on the time it would take to do
it, and putting in the time to write the software. Commercial software
companies use money to motivate the itch and the spending of time by their
developers, and they use your money when they sell you the result as their
motivation. To dismiss the open source implementations for not delivering
better typography while being prepared to pay real money for commercial
software ignores the possibility of pay real money to improve the open
source implementations. If there was, say, a kickstarter.com project to
improve the typography of FOP (which I am *not* setting myself up to do),
would anyone here even make a pledge? (I'll get off my soapbox now.)

> It definitely isn't a technology for spread based layouts thought.

There is a fo:spread-page-master in a previous "Design Notes" [1] but that
has yet to be merged into the full Working Draft document.

> We've done proofs of concept on FO based publishing with two large UK
> publishers and are looking at a third. The second client is looking at how
> to use the tools in a production environment at the moment.
>
> The biggest problem is the lack of support for signatures and that is in

Antenna House has extended its allowed values of the "force-page-count"
property [2] so, e.g., a page sequence can be padded with blank pages to
force a defined page count.

More to the point, with XSL-FO, it's never been clear whether things like
signatures are part of its remit or something for a job control language
to handle. For example, XSl-FO has only ever had a hazy notion of where
the binding edge lies. But if you want to discuss things like that
further, the best place at present would be the W3C Print and Page Layout
Community Group [3], which anyone can join for free (and I happen to be
the current Chair).

> the 2.0 wishlist. One of the big issues we've seen with our clients is
> that publishers see the W3C as irrelevant to them. This means that
> publishing industry representation on the FO committee is poor.

More input from the publishing industry, even on the Community Group,
would be welcome.

Regards,


Tony Graham tgraham@mentea.net
Consultant http://www.mentea.net
Mentea 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
XML, XSL-FO and XSLT consulting, training and programming

[1] http://www.w3.org/TR/2010/WD-xslfo20-20101216/#sec2_2_17
[2] http://www.antennahouse.com/xslfo/extension.htm#force-page-count
[3] http://www.w3.org/community/ppl/

On 9.5.2012 19:51, John W. Shipman wrote:

> A colleague (who does not wish to be quoted) says there's not
> much action on the committee anymore. Although it is still
> officially supported, it seems moribund.

Well, this is more or less very close reality of W3C working group
responsible for XSL-FO. But this is mainly because XSL-FO 1.1 is good
enough to solve majority of batch formatting problems, there are dozen
implementations of XSL-FO 1.0/1.1 and they don't face high presure from
customers for adding new features.

So while there is a list of requirements for new exiciting and powerfull
XSL-FO 2.0 features, interest between users and implementers is not high
enough. If you care, please let this known to W3C and to vendor of your
XSL-FO engine.

http://www.w3.org/community/ppl/

> I was sort of hoping that the committee was working on adding
> critical features not in the current standard that modern book
> designers appreciate, e.g., constraints about positioning content
> on facing pages, or text floated on both sides of a figure, or a
> page model not as primitive as the five-region simple-page-master
> model. Apparently not.

Committee is not virtual, there are real people inside. If you think
that more should and could be done, please join WG and push work forward.

> I've heard a few people over the past few years insisting that
> the replacement for XSL-FO (within W3C) is to use the "@media
> print" feature of the CSS standard. If I read that correctly,
> that means that in order most ordinary people to get a decent
> print rendering of their web page, the following must hold:
>
> (1) The page author has to write the CSS to define how to
> render it on a fixed page size;
>
> (2) Their browser supports the "@media print" rule and
> renders it correctly.
>
> Then the user prints it using the browser's print function.
>
> Am I right? Is this practical? Do browsers do the right thing?
> Will this eventually obviate the need for XSL-FO? What replaces
> the Modular Style Sheets in my DocBook toolchain?

Definitively no. CSS Print features are still far beyond what XSL-FO can
done today.

> What about the important differences between Web and print
> rendering? Will there be a table of contents? Will that and
> cross-references display page numbers instead of useless,
> unclickable underlining? How does that work in CSS?

In general, when using CSS almost everything like ToC must be
precomputed. There are CSS Modules that can do proper cross-referencing
with page numbers etc. Such things are supported by standalone CSS
rendering engines like PrinceXML or Antenna House CSS Formatter.

> One of my pet peeves is Web pages that can't be printed because
> they contain program source code with lines way too wide to fit
> on the page. Will CSS render such pages with the pages wrapped
> and not truncated?

white-space: pre-wrap;

> If they do, will I be able to tell the
> hard line breaks from cases where the line got wrapped?

In theory this could be added to CSS, but I don't think it is supported now.

Jirka

--
------------------------------------------------------------------
Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz
------------------------------------------------------------------
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

On 8.5.2012 23:17, John W. Shipman wrote:

> If you find this useful or have any comments, I'd like to hear
> about it. I realize XSL-FO is a dead standard,

Why do you think that XSL-FO is a dead standard?

Jirka

--
------------------------------------------------------------------
Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz
------------------------------------------------------------------
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------