Skip to content

GitLab

Last edited by julien
Page history

Agenda and outcomes

Agenda and outcomes

may 8, 2018

Agenda for the may 23rd

  • Previewer —aka modular changes—
  • update on testing
  • update on issues and blockers that need to be removed
  • set up the next demo/meet
  • PrePostPrint workshop

Outcomes

  • Automated tests for paged-media specifications is now available using Jets. @fchasen will provide example of a test so we can add those to the issues we're raising. (simply put, using pupeteer, we render a pdf of what would be on screen, convert to an image format and testing pixel per pixel if things changed on the page).

  • From now on, issue templace should include the html file with style in the header, under a style tag (or inline), and, if possible, a pdf of the file rendered with prince or pdf reactor, so it can be tested using Jets.

  • The library will be as modular as possible to build workflows, based on the schema that julie made:

scheme

CORE will handle the required files and functions for the paged.js to work : chunker + polisher;

INFERFACE will provide tools to preview the output on screen (the list of features is yet to define, but the basics would be: show/hide margin-boxes, zoom in/out, go to page, etc.) The goal is to provide as much tools as you'd get in a pdf reader;

PLUG-IN will be set of the file needed per css features supported by the paged media team.

  • From this scheme: a configurable workflow should be able to let the user add new javascript scripts plug-in (hooks), in the order he decides. So, for instance, you could use a hyphenization library, a dropcap one, and some javascript to render visually random titles and choose exactly when each will be used. The flow of even should be configurable.

  • We need an ordered list of supported / will support / won't support features. This will look as a checkbox list to begin with. The best would be to have, per feature, a link to the gitlab issue with the discussion about how we did it, and, if possible, a link to the Mozilla developper network, as it's more user friendly than the W3C specs.

  • Next step: we're cleaning the minimal features we need: page-breaks, widows and orphans, etc. and we set up a first demo with early invites and see, from there, what is the best way to enlarge the community.