Subject: Re: [xsl] xsl 2.0? From: Peter West <lists@xxxxxxxxx> Date: Tue, 5 Nov 2013 08:27:23 +1000 |
Thanks for this Tony, and especially for the mention of the Print and Page Layout Community Group. The idea of a more modular spec is appealing if it means that a more modular implementation can be built and tested piecemeal. I haven't had a look for many years now, but the 1.0 spec was a nightmare. There were, necessarily, complex interactions buried across scattered elements of the spec; and these interactions were poorly understood by its writers. This is not to say that the spec isn't a virtuoso display of print layout expertise - it is. But the domain is so complex that problems were inevitable. I imagine there are still plenty of edge cases where mature commercial FO processors are incompatible, and the requirement for compatibility is going to be a major hurdle to surgery on the spec. Peter West "...for everyone who exalts himself will be humbled, but he who humbles himself will be exalted. On 5 Nov 2013, at 1:27 am, Tony Graham <tgraham@xxxxxxxxxx> wrote: > 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@xxxxxxxxxx > 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-forw ard+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-Graham0 1.html#d44854e105
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] xsl 2.0?, Tony Graham | Thread | Re: [xsl] xsl 2.0?, Peter Flynn |
Re: [xsl] re:[xsl] xsl 2.0?, Tony Graham | Date | Re: [xsl] xsl 2.0?, Paul Tyson |
Month |