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
Big Faceless Organization             http://bfo.com


On Mon, 10 Feb 2020 at 09:16, Florian Rivoal <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> 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. 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
>