- From: Mike Bremford <mike@bfo.com>
- Date: Sat, 8 Feb 2020 19:39:13 +0000
- To: public-css-print@w3.org
- Message-ID: <CABvfMXXH75kRu=gt1b6RsMWHuN1Q28F2R+omAyCUUeb-Mv=utg@mail.gmail.com>
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