The Print and Page Layout Community Group is open to all aspects of page
layout theory and practice. We can and will cover everything from the
Crystal Goblet through to specifications and on to the nitty-gritty of
writing stylesheets. You will find XSL-FO discussed here, but you will
also find other stylesheet languages, and all are equally welcome.
Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
The Print and Page Layout Community Group is developing a series of open-source extensions for XSLT processors so you can run any number of iterations of your XSL-FO processor from within your XSLT transformation, which allows you to make decisions based on formatted sizes of areas.
The extensions are currently available for Java and DotNet and use either the Apache FOP XSL formatter or Antenna House AHF formatter to produce the area trees. Contributions supporting more XSLT–XSL-FO combinations would, of course, be welcome.
A single Java jar file covers four combinations of XSLT processor and XSL-FO formatter:
Saxon 9.5 and FOP
Saxon 9.5 and Antenna House
Xalan and FOP
Xalan and Antenna House
The DotNet version supports:
DotNet 4.0 and FOP
DotNet 4.0 and Antenna House
The graphic below is from a poster done for the Balisage 2014 conference. It shows four ways that the XSLT extensions can be used. Can you see what they are?
There is no cost to joining a W3C Community Group, and the Print and Page Layout Community Group welcomes everybody, at all levels of expertise, who wants to join.
There was a comparatively high number of survey responses from people not in the Print and Page Layout Community Group who, nonetheless, think that the Community Group should primarily be about XSL-FO and think that we should develop standards around XSL-FO. I was talking last weekend about people wanting something but not being in the group to do it to another attendee at XML Prague, who was of the opinion that some people might think they’re not expert enough to be part of this Community Group.
There’s many factors that say that isn’t so:
You don’t need to be active all the time – joining registers your interest, and we don’t mind if you lurk until such time as you have something to say
Knowing the specs isn’t the only skill – we have a wide ranging set of goals, and none of adding content to the wiki, trying out software, or voicing your opinion about what needs to be done require any advanced expertise
There’s no pre-commitment – Working Groups have a charter setting out how many hours or days per week participants are expected to spend, but Community Groups don’t have that; Business Groups are pay-to-play, so you might expect some level of commitment there, but it’s free to join a Community Group
The W3C itself doesn’t care – there’s officially no demands on a Community Group to produce anything – and, with the W3C Team account favoriting a tweet saying ‘OH: “I think a w3c community group is basically an online petition”’, there’s unofficially within some parts of the W3C an expectation that a Community Group won’t produce anything – so there’s no pressure on you yet everything we do produce is a win
Given all that, why are we happy to welcome new members? There’s no pecking order or bragging rights accruing to Community Groups based on membership numbers. The win for the CG is both that it’s easier to turn an inactive member into an active member than turn a non-member into an active member and that it helps everyone if we have a wider range of voices in the conversation. The win for you is that you get to take part in the conversation and influence the direction of the Community Group rather than projecting from the outside that the CG will or should do something: we still might not go the way that you want, but it’s more likely that we will if you take part and work towards the goal that you want.
Thank you to all who took part in the survey for what the Print & Page Layout CG should do next. It produced 64 usable responses, with very different responses from members compared to non-members.
There were more responses than expected, which was very good, but in absolute terms the number of responses was comparatively small so there has to be some uncertainty in any analysis of the results, but I’ll do it anyway…
For the extent to which the Print & Page Layout CG should discuss XSL-FO, the members favoured making it a secondary objective or something that just happened over making it the primary focus:
whereas non-members by a large margin favoured making XSL-FO the primary focus:
For what the CG should develop, members were essentially divided equally over developing: function libraries; tutorials on any of XSL-FO, other stylesheet languages, or non language-specific page layout principles; XSL-FO specifications; and other specifications:
whereas non-members favoured XSL-FO specifications and tutorials over the other alternatives:
For what sort of specification, if any, the CG should develop, members favoured a simpler stylesheet language or specs adding to XSL 1.1:
whereas non-members favoured developing XSL-FO 2.0 or a simpler stylesheet language over other alternatives:
Before working out what to put in the survey, the Print & Page Layout CG took a long, hard look at the state of XSL-FO and other technologies and at its own capabilities. That, I think, lead us to be more pluralist and less adamant that those who did the survey without the discussion. The CG welcomes new members at any time, so the comparatively many people outside the CG who want development of XSL-FO 2.0 or of a simpler stylesheet language are welcome to join the CG to work on them (as possibly one of many outputs from the CG) or to organise their own group as they see fit.
The Print and Page Layout Community Group now seeks your input on its focus and what it should do next. The survey embedded below (which is based on recent discussions) has been extended to 24 January 2014. And, of course, you are welcome to join the group at any time.
The initial proposal to revise our group description  generated quite a bit of discussion  that is still going on in related threads .
Along the way, we’ve had discussion of:
Layout/styling technologies that people have used 
Readability or otherwise of EPUB standards 
S100D IETP 
Advantages of learning German 
Silos versus outreach 
Crystal goblets and window types 
And threads that were started but not taken up included:
Listing people/companies with software that matches our definition 
Making a common glossary 
Whether “0” valid for all XSL-FO lengths 
Commenting on other people’s specs 
The first two suggestions for revising the group description were for keeping the focus on XSL-FO  and dropping the XSL-FO mentions , respectively.
We also heard about:
Needs of developers and that “Our major end user community here is not professional publishing experts.” 
“any additional participation in the PPL group will be representative of the professional publishing expert community.” 
“I know quite a few people in the Digital Publishing Interest Group who would be happy to join the conversation over here” 
“I manually modified the FO file to get the results they wanted. That was a rather painful process – and it would have been impossible, if they had to do it by themselves, as none of them seems to be willing to invest time in learning XSL-FO.” 
“I want ‘decent’ (easy to read) print. I generally use docbook stylesheets or tweak my own generic. Key point. No layout requirements which might be seen as verging on paranoia and harking back to manual typesetting.” 
“Programmatic approaches to creating PDF and Postscript are nothing new to me, nor to many programmers tasked with publishing.” 
“While it might not be hard to create a PDF file, creating a PDF file that is suitable for today’s publishing needs is.” 
“The difficulty I have with saying that we will produce XSL-FO 2.0 or even a 1.2 is that we have no reasonable expectation that it will be implemented.” 
“it’s closer to the whole shooting match that needs a review, putting it perhaps too strongly, it simply doesn’t match with what CSS offers, a dumb syntax that (nearly) does what FO does?” 
“CSS syntax is being cleaned up, but I think some of the simplicity is deceptive, because it doesn’t do as much as FO.” 
“CSS has shown a longevity and a capability to grow that I certainly didn’t expect back in 1994-1998, even though I designed it to be extensible. On the other hand, the increased size already means that it isn’t easy for people to learn CSS anymore and we should ask ourselves if it isn’t better to leave CSS alone and create a new style sheet standard that, from the start, is meant to be good enough for complex publications.” 
“XSL-FO is not suffering low rates of adoption because it’s more difficult to use than other technologies, it’s suffering because it hasn’t been sold that well.” 
“Dave Cramer’s ‘Requirements for Latin Text Layout and Pagination’ is to cover ‘requirements for pagination and layout of books in latin languages’, and the XSL-FO spec and various CSS modules are about how to instantiate pagination and layout, but there is a middle ground for material about how to do a good job at pagination and layout.” 
“So I do think there’s a lot of mileage to be had in FO tutorials and examples – when Tony mentioned SWIG I thought at first he was referring to the success of the semantic web interest group in doing that sort of outreach :)” 
So if you’re still reading this (even if you’ve skipped past the quotes to get to here), you’ll know that we’ve had good, robust discussion. We’ve also had a few instances of people looking at the same information and coming to opposite conclusions, but isn’t life ever thus?
The next step is a survey based on the ideas put forward so we can quantify and prioritise what people both inside and outside the CG see us as doing.
It’s good to see renewed activity in the CG after a period of silence. It’s less than halfway through the month, but already this been the third most active month on the mailing list since we began. Long may it continue!