RE: BFO Position Paper

The following is some additional background information to help you better understand Antenna House’s position and experience when it comes to CSS paged media output. 

 

Antenna House has over 14 years of experience developing software conforming, as much as possible, to the CSS Recommendations and drafts.  Antenna House’s focus has always been print.  We were among the first implementers of XSL-FO, and have continued development of our formatting engine for over 20 years.  

 

Back in 2006 at the International Workshop on the future of the Extensible Stylesheet Language (XSL-FO) Version 2.0 in Heidelberg, Germany, Antenna House gave a presentation about our desire for greater compatibility between CSS, and especially the CSS 3 drafts, and XSL-FO.  There were zero votes in favor.  We strongly believed that there would be a requirement for paged media output for CSS and that there were numerous benefits to our proposed approach.  Despite the lack of enthusiasm from the XSL-FO Workshop, we went ahead and implemented AH CSS Formatter that closely follows the functionality of our XSL Formatter.  We released the first version of CSS Formatter in 2009, with a large percentage of the same functionality as our XSL Formatter.   Since 2009 we have continued to enhance the functionality of CSS Formatter to the point where it is almost on a par with our XSL Formatter.  At the same time, we have continued to enrich the formatting capabilities of our engine (we have one formatting engine that can format either FO or CSS).

 

Many of the features we implemented through extensions ultimately became part of the FO Recommendation.  We see a similar scenario with CSS, where the implementation of features for producing more than just simple pages is first accomplished by extensions, which then, hopefully, in the future, become part of the standard.   On the Antenna House website, we have a table for XSL/CSS Properties (https://www.antennahouse.com/product/ahf66/ahf-focss6.html) and descriptions of the Extensions (https://www.antennahouse.com/product/ahf66/ahf-ext.html) we have developed to meet the demands for producing paged-media output.  These documents might be useful.

 

Through experience, we have learned that representing paged information in print format invokes all the complexities of a printed (PDF) documents; landscape and portrait, multilingual writing directions and script support, accessibility,  tables that span hundreds of pages with headers and footers along with continuation headers and footers, page heading and footings, tables of content, back of the book indexes, etc.   

 

Regards,

 

Michael Miller
Antenna House

 

 

 

 

 

 

From: Mike Bremford <mike@bfo.com> 
Sent: Monday, February 10, 2020 6:44 AM
To: Florian Rivoal <florian@rivoal.net>
Cc: public-css-print@w3.org
Subject: Re: BFO Position Paper

 

> I support this, but we need to be sure about what we want. "paged" and "print" overlap a lot. Just to take one example, questions about CMYK are "print" but they're not "paged". Since this filter is meant to be of use to people who want to look at only a subset of the activity of the WG, let's not cast it too wide.

 

Precisely. I am ever so slightly leaning towards "print" - if it applies to "paged" it must apply to "print", but not the other way around - colors, of course, but also things like PDF bookmarks (already in GCPM), standardising an approach to creating PDF tags for accessible content, PDF layers and so on. If we went with "paged" those might be missed. But I could be persuaded either way.

 

Cheers... Mike

--


-----------------------------------------------------
Mike Bremford - CTO                   mike@bfo.com <mailto:mike@bfo.com> 
Big Faceless Organization             http://bfo.com

 

 

On Mon, 10 Feb 2020 at 09:16, Florian Rivoal <florian@rivoal.net <mailto:florian@rivoal.net> > wrote:

Hi,

 

I won't be in Prague either, but I'd like to make a few comments about this suggested list of action items from Mike.





On Feb 9, 2020, at 4:39, Mike Bremford <mike@bfo.com <mailto:mike@bfo.com> > wrote:

 

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?)

 

I support this, but we need to be sure about what we want. "paged" and "print" overlap a lot. Just to take one example, questions about CMYK are "print" but they're not "paged". Since this filter is meant to be of use to people who want to look at only a subset of the activity of the WG, let's not cast it too wide.

 

Relatedly, there's also quite a few topics which tend to be of interest to this crowd, which are neither really "print" not "paged", but rather around the more general topic of high quality typography. I suspect this is too broad to try and cover with this kind of filter, and that it would dilute the value of a "paged" filter, but this is worth thinking about.





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 <http://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.

 

I strongly support this (especially when combined with the next point). From a spec writer's point of view, it's very useful to be able to tell what implementations are actually doing. Testing manually from browsers is easy, and getting automated results for them from wpt is even easier. For print formatters, less so. But that can often make a difference to how we resolve on specifications. See https://github.com/w3c/csswg-drafts/issues/4036 for an example where knowing what the print formatters do changed the decision the CSSWG made.





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.

 

Yes, a clear testing license would encourage using print formatters when judging the maturity of specifications. See the previous point for why.





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.

 

Yes. Not all things that are acceptable to print formatters will be OK in browsers, due to different performance requirements. But given valid use cases, if some solution is not acceptable to browsers, we should be looking for a different solution that is, so that we can have the same thing across the board. And proposing to standardise things print formatters have is a good way to find out if it is acceptable to browsers or not.

 

—Florian