On Sun, November 3, 2013 4:41 pm, G. Ken Holman wrote:
At 2013-11-02 16:23 +0900, Toshihiko Makita wrote:
3. I beleive that XSL-FO is most suitable techinology for formatting
XML documents.
Agreed. My customers are getting real-world problems solved with XSL-FO
1.1.
It's one of those things where the answer if different for different
people. I've had more approaches for XSL-FO work in the last 18 months
than in any similar period previously, so, yes, it's working for many
people, including people new to XSL-FO, yet the volume of messages on
www-xsl-fo is at the lowest that it's ever been [1], so it's hard to see
that the number of developers is growing, so other people are looking
elsewhere to solve their real-world problems.
Again, whether it solves enough real-world problems depends on which world
you live in. IIRC, Peter Flynn will happily describe XSL-FO as being only
good for office documents (meaning, for Peter, that it's not as good as
TeX), and it didn't take long for people at the Print and Page Layout
Community Group to come up with some unsatisfied requirements of their own
[2], yet Bert Bos in his "Can you typeset a book with CSS?" [3]
presentation at the "eBooks & i18n" workshop in Tokyo shows a mathematical
formula in a running header that is simple in XSL-FO (with MathML support
in the XSL-FO formatter) but impossible in CSS as it stands, and Dave
Cramer in his "The Exotic World of Trade Publishing" [4] presentation
shows the lengths he has to go to to get a running title, a dingbat, and
the page number as the running header, which, again, is simple in XSL-FO.
The problem for XSL-FO is that it looks like the CSS users will get their
problems solved in a standard and interoperable way sooner than the XSL-FO
users will theirs.
I think the few things that are needed and are found (or not) in some
vendor extensions would be good fodder for an XSL-FO 1.2 rather than
an XSL-FO 2.0 (e.g. line numbering, repeating sets of page master
references, more page-position testing options, etc.).
It hardly matters whether the next step is XSL-FO 1.2 or XSL-FO 2.0 when
there's no Working Group to bless it and no commitment from vendors to
join a Working Group or to implement any common scheme, since you need
interoperable implementations to get a spec to Rec.
In the absence of a Working Group, the next best place to work on a spec
is a W3C Community Group [5]. The Print and Page Layout Community Group
[6], to my mind at least, isn't solely about XSL-FO (or even solely about
XML) but it does have permission to host and modify its own version of the
XSL-FO 2.0 spec [7]. There is a long outstanding action item to put the
source up on the CG's Mercurial repository, but so far no-one's tapped me
on the shoulder to follow up on why it hasn't been done yet.
The Print and Page Layout CG has also considered making a version of the
spec that's more modular [9] so that improvements aren't all-or-nothing.
I also think the features of XSL-FO 1.x are going to continue to
satisfy high-volume or highly-repetitive print requirements for a
very long time.
It can satisfy many requirements for high-volume or highly-repetitive
print, but Klaas Bals of Inventive Designers was the editor of the 2.0
requirements document [8], and Inventive Designers's customers produce
documents in jaw-dropping quantities, so I think that it's fair to say
that XSL-FO 1.1 doesn't satisfy all requirements for high-volume or
highly-repetitive print.
Of course I'm not trying to devalue the work those working on XSL-FO
2.x are creating to meet client requirements of theirs that demand
Thank you (on behalf of many people), but at this point it's "who worked",
and once the requirements document was agreed upon and published, it was a
matter of working to meet the published requirements, not looking to
satisfy any clients. Who, for example, would you count as Liam's clients?
the changes needed ... I'm just not seeing anything major that has to
change for me to do my job.
Which is a good thing, though I think we agree that other people have
other requirements.
Of course, part of the problem for XSL-FO is that there's unlikely to be
anybody who desperately wants everything that's in the XSL-FO 2.0
requirements document, but various needs for various parts of it hasn't
translated into a strong push from many users for vendors to implement it.
Does CSS techinology become the complete alternative of the XSL-FO?
I don't think so, but then again, I haven't been following CSS very
closely since XSL-FO 1.1 has been meeting my client's expectations.
I do follow it, and CSS for pagination is in a strange place right now
since the two pagination-related specs are having a holiday [10] in a
stranger place [11]. Discussion often centers around what can be done by
the two main implementations, but given the way CSS can specify things in
successive 'levels', the CSS folks can -- once they have the details
specced and interoperable -- codify that as 'level 1' then move on to
bigger and better things as 'level 2'.
As other people have said in this thread, it's not so much a question of
whether CSS can become the complete alternative to XSL-FO but whether CSS
can become a good enough alternative to XSL-FO for enough people. E.g., I
have some stuff that I do with deciding if a table should be column-wide,
page-wide, or rotated based on its formatted size [12] that I can't see
CSS doing in a hurry because it requires multiple passes through the
formatter (though with the future addition of JavaScript inside a CSS
pagination engine, I'm no longer so sure), but there's a lot of stuff
today for which CSS is good enough and there's likely to be more in the
future.
I don't see XSL-FO and CSS as either/or, us/them, saints/sinners, or any
other dichotomy. I'm happy to help both advance so I can produce better
output, but at this point XSL-FO doesn't have enough people working on it
for it to be able to advance.
Regards,
Tony Graham tgraham(_at_)mentea(_dot_)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
Chair, Print and Page Layout Community Group @ W3C
[1]
http://markmail.org/search/?q=www-xsl-fo#query:www-xsl-fo%20order%3Adate-forward+page:1+state:facets
[2] http://www.w3.org/community/ppl/wiki/CustomerRequirements
[3] http://www.w3.org/Talks/2013/0604-CSS-Tokyo/, slide 10
[4]
http://www.w3.org/2012/12/global-publisher/slides/Day2/P1-w3c-paris-hachette.pdf,
pages 38 and 39
[5] http://www.w3.org/community/
[6] http://www.w3.org/community/ppl/
[7] http://lists.w3.org/Archives/Public/public-ppl/2013Feb/0046.html
[8] http://www.w3.org/TR/xslfo20-req/
[9] http://lists.w3.org/Archives/Public/public-ppl/2013Mar/0000.html
[10] http://lists.w3.org/Archives/Public/www-style/2013Oct/0460.html
[11] http://blog.whatwg.org/css-books-css-figures
[12]
http://www.balisage.net/Proceedings/vol10/html/Graham01/BalisageVol10-Graham01.html#d44854e105
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--