- From: Philip Jägenstedt <foolip@google.com>
- Date: Thu, 12 Dec 2019 14:20:09 +0100
- To: James Graham <james@hoppipolla.co.uk>
- Cc: David Burns <dburns@mozilla.com>, Luke Zielinski <lpz@google.com>, public-browser-tools-testing@w3.org
On Thu, Dec 12, 2019 at 2:11 PM James Graham <james@hoppipolla.co.uk> wrote: > > > > On 12/12/2019 13:09, Philip Jägenstedt wrote: > > On Thu, Dec 12, 2019 at 12:25 PM James Graham <james@hoppipolla.co.uk> wrote: > >> > >> On 12/12/2019 10:52, Philip Jägenstedt wrote: > >>> Would this be used only for automating PDF creation, or is there also a > >>> testing (WPT) side to it? +Luke Zielinski <mailto:lpz@google.com> > >> > >> Both are valuable; we want to make it possible to test paginated layout > >> and the working hypothesis is that the best way to do that is reftests > >> using the print rendering pipeline. > > > > Would that work by rendering the PDF to an image using another tool, > > or should this endpoint be able to print directly to an image? > > > > I suspect the render-pdf-to-image — if useful at all — is only required > for the wpt use case and is also something we can add in the wpt layer. > So I don't think we should make that part of the spec in the absence of > a signal from authors that it's functionality they require. OK, let's see what that dependency in WPT will end up looking like in a future RFC.
Received on Thursday, 12 December 2019 13:20:22 UTC