W3C home > Mailing lists > Public > public-css-print@w3.org > January to March 2020

BFO Position Paper

From: Mike Bremford <mike@bfo.com>
Date: Sat, 8 Feb 2020 19:39:13 +0000
Message-ID: <CABvfMXXH75kRu=gt1b6RsMWHuN1Q28F2R+omAyCUUeb-Mv=utg@mail.gmail.com>
To: public-css-print@w3.org
BFO are based in London and have been developing PDF software in Java for
20 years. We released our first product for converting XML+CSS to PDF in
2001, but CSS hasn't been our main focus for some time.

We're hoping to change that with the release of a new product later this
year. It will operate in the same market segment as Prince, Antenna House
Formatter and PDFReactor from RealObjects, amongst others.

When we first entered this market, CSS2.1 hadn't been published and "Best
Viewed in Netscape" was still common on the web. The very few products
using CSS for print output were not overly concerned with compatibility.

18 years later and the primary goal for our upcoming release is
compatibility with the specifications. We're testing against the
web-platform-tests <https://github.com/web-platform-tests/wpt> (WPT)
constantly, as part of our development cycle - although some tests require
a browser, many can be run in an environment where PDF, rather than a
screen, is the target. There are about 29,000 testcases in the WPT, and we
run a subset of just over 18,000.

The conclusion we've drawn from this process is that the print side of CSS
needs some serious attention. From reading the other position statements,
that appears to be the general consensus.

On this presumption, I'm going to jump right in with my take on why this is
and what we can do about it, as I'm not able to make it to Prague.

   1. The CSS working group is very active, and it can be hard to identify
   issues of particular interest to print users amongst the noise.
   2. As well as defining new functionality, there are many loose ends that
   need to be tied up in the CSS specifications specific to print: css-gcpm,
   css-page being the most obvious. This is not a reflection on the editors in
   any way; there's less feedback from users, and presumably fewer people
   testing.
   3. There is a desperate shortage of test-cases for these specifications.
   Every single css-gcpm test to date has been contributed by Dave Cramer, and
   all are at least 6 years old.
   4. There is a lack of involvement from both print vendors and users in
   the CSSWG. Again, this is not a criticism - people are busy, and there are
   many ways to be useful. But there is only one way to get the specifications
   out of draft stage, and that is to get involved in this process. This means
   filing or providing feedback on issues, creating tests and verifying
   behaviour.

To put some numbers on these statements, as I write this:

   - There are 8 issues
   <https://github.com/w3c/csswg-drafts/issues?utf8=✓&q=is%3Aissue+is%3Aopen+label%3Acss-gcpm-3>
   filed against css-gcpm, of which four are mine and one is Jirka's. One is
   closed.
   - There are 14 issues
   <https://github.com/w3c/csswg-drafts/issues?utf8=✓&q=is%3Aissue+is%3Aopen+label%3Acss-page-3+>
   against css-page of which two are mine. Two are closed. About half of them
   are "housework" issues and not substantial problems.
   - There are 3891 issues against the other specs, of which 2247 are
   closed.
   - And of those 29,000 CSS test-cases, css-gcpm has 20
   <https://github.com/web-platform-tests/wpt/tree/master/css/css-gcpm>
and css-page
   just 18
   <https://github.com/web-platform-tests/wpt/tree/master/css/css-page>.

So what can we do about this? Well first, this mailing list is a really
good start - thanks to whoever set it up.

1. I'd like to propose a "print"  label for issues filed against the CSSWG
issue list. This would make it easier for those with a print focus to
find issues they're interested in. This is a quick and easy one - if
there's general agreement I can try and get this set up, and tag as many as
I can find that apply. (should it be "paged"? Something else?)

2. We've started rolling our in-house tests into a form that makes them
suitable for inclusion in the WPT tests, and plan on contributing a lot
more over the next few months (Dave, you will be seeing some pull requests
coming your way). When we get further down our track we'll publish our
results, and get them integrated with the results at tests.csswg.org. It
would be great to see other vendors do the same. Many of the issues we've
found with the specifications have come from creating tests in this way.

3. Where issues are filed, we'll test against our software and respond with
our results. We have been testing our own software and Prince,
which explicitly has an evaluation license for this purpose. I'd be happy
to test with Antenna House and RealObjects products too, but I'm not clear
their license would allow this given we're developing a product in the same
space. So it would be great to see others submitting test results too.
Without a consensus from the main print vendors on what is "correct"
behaviour, or at least current behaviour, we're not going to move forward.

4. There are some "low hanging fruit" we might look at - for example,
Prince, Antenna House, RealObjects and ourselves all have a "text-replace"
property, which appear to function identically but all use different
prefixes. I'm aware this was dropped from a previous version of css-text -
but with three shipping implementations, if it's being used and is
considered effective, then should we consider suggesting its return to the
spec? I don't know. But if interoperability is the goal, this sort of thing
is an easy place to start. Attempting to define large areas of new
functionality like page floats without multiple vendor buy in isn't going
to work, so testing the collaboration process on smaller features like this
one might not be a bad idea.


Finally, there is one other point I need to make. If the specifications are
to move out of draft, they will require a lot more tests, and multiple
implementations to pass those tests. That will likely mean changes to some
existing implementations, upsetting any existing users who depend on the
old way of doing things. No doubt this can be managed, but it won't be
pain-free. I think a willingness to do this anyway, by both developers and
their users really needs to be the first step.

It's a shame I can't be in Prague to discuss all this, but if there's audio
recording I hope to listen afterwards, and perhaps meet some of you F2F at
some point in the future.


Cheers... Mike
--
-----------------------------------------------------
Mike Bremford - CTO                   mike@bfo.com
Big Faceless Organization             http://bfo.com
Received on Saturday, 8 February 2020 19:40:03 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 8 February 2020 19:40:03 UTC