|
|
# Agenda and outcomes
|
|
|
|
|
|
## may 8, 2018
|
|
|
|
|
|
### Agenda for the may 23rd
|
|
|
|
|
|
- update on testing
|
|
|
- update on issues and blockers that need to be remove
|
|
|
- set up the next demo/meet
|
|
|
|
|
|
### 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](https://gitlab.pagedmedia.org/tools/pagedjs/uploads/e3c8acdd3b82e6c368f115466fd9c3e6/20180509_schema-tool.png)
|
|
|
|
|
|
**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.
|
|
|
|
|
|
|
|
|
|
|
|
|