Skip to toolbar

Community & Business Groups

Print and Page Layout Community Group

The Print & 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 and CSS discussed here, but you will also find other stylesheet languages, and all are equally welcome.

pplcg

Group's public email, repo and wiki activity over time

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.

No Reports Yet Published

Learn more about publishing.

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

This group does not have a Chair and thus cannot publish new reports. Learn how to choose a Chair.

XSLTExtensions 0.1.0

The code for the XSLT Extensions has finally completely moved from Mercurial to GitHub at https://github.com/pplcg/XSLTExtensions. Along the way, I added an Ant build file to make it easier (IMO) to run the Saxon extension cross-platform. (I haven’t been able to test either the DotNet or Xalan versions of the extension.) The Saxon extension now works with FOP 2.0+ as well as with Antenna House Formatter.

The Java and DotNet distributions (and the Ant build file) are now released in one zip file.

Getting an area tree within your XSLT transform

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?

balisage-poster-top

Continue reading

Free to join, all welcome, at every level of expertise

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.

Survey results

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:

member-xsl-fo

whereas non-members by a large margin favoured making XSL-FO the primary focus:

non-member-xsl-fo

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:

member-develop

whereas non-members favoured XSL-FO specifications and tutorials over the other alternatives:

non-member-develop

For what sort of specification, if any, the CG should develop, members favoured a simpler stylesheet language or specs adding to XSL 1.1:

member-spec

whereas non-members favoured developing XSL-FO 2.0 or a simpler stylesheet language over other alternatives:

non-member-spec

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.

What’s next for the Print and Page Layout Community Group?

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.

http://printandpagelayout.polldaddy.com/s/what-s-next-for-ppl-cg

If the embedded survey doesn’t work or is too wide for your screen, the survey is also available at http://printandpagelayout.polldaddy.com/s/what-s-next-for-ppl-cg.

Discussing what to do next

The initial proposal to revise our group description [1] generated quite a bit of discussion [2] that is still going on in related threads [3].

Along the way, we’ve had discussion of:

  • Layout/styling technologies that people have used [4]
  • Readability or otherwise of EPUB standards [5]
  • S100D IETP [20]
  • Advantages of learning German [21]
  • Silos versus outreach [22]
  • Crystal goblets and window types [6]

And threads that were started but not taken up included:

  • Listing people/companies with software that matches our definition [7]
  • Making a common glossary [8]
  • Whether “0” valid for all XSL-FO lengths [9]
  • Commenting on other people’s specs [10]

The first two suggestions for revising the group description were for keeping the focus on XSL-FO [11] and dropping the XSL-FO mentions [12], respectively.

We also heard about:

  • Needs of developers and that “Our major end user community here is not professional publishing experts.” [13]
  • “any additional participation in the PPL group will be representative of the professional publishing expert community.” [14]
  • “I know quite a few people in the Digital Publishing Interest Group who would be happy to join the conversation over here” [15]
  • “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.” [16]
  • “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.” [17]
  • “Programmatic approaches to creating PDF and Postscript are nothing new to me, nor to many programmers tasked with publishing.” [18]
  • “While it might not be hard to create a PDF file, creating a PDF file that is suitable for today’s publishing needs is.” [19]
  • “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.” [24]
  • “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?” [25]
  • “CSS syntax is being cleaned up, but I think some of the simplicity is deceptive, because it doesn’t do as much as FO.” [26]
  • “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.” [27]
  • “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.” [28]
  • “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.” [28]
  • “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 :)” [29]

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.

See http://lists.w3.org/Archives/Public/public-ppl/2014Jan/0067.html for the rest of the references.  There seems to be a size limit on posts, and putting in all the references results in a ‘Bad Request’ error when saving this post.