oh, nm, I was looking at the old mocks. ignore me.
@bmansurov - do we have a way of estimating page numbers?
Fri, Sep 22
@Niedzielski - while technically stalled, I'm marking this as open so we can get an estimate over the following week (as stalled task do not currently appear on the board by default).
Moving to needs analysis. @phuedx - this is issue should disappear with the new endpoint, right?
Marking as stalled until completion of T176463: [Spike] Investigate libraries for post-processing without non-JS dependencies
marking as stalled until completion of T176463: [Spike] Investigate libraries for post-processing without non-JS dependencies
Moving out of sprint and marking as stalled until the completion of T176463: [Spike] Investigate libraries for post-processing without non-JS dependencies
@Tbayer - are the enwiki and dewiki results saved in a different table from the stage0 results? If so, we may be able to delete the most recent test now and relaunch once T175918: EventLogging subscriber module in ready state but not sending tracked events is complete.
Next steps on headless Chromium:
- test rendering with single-article PDFs
- redesign workflow for book download to account for longer download times T176466: Update books workflow to account for longer render times
- investigate ways of combining headless Chromium and post-processing, look into whether we can post-process with node.js T176463: [Spike] Investigate libraries for post-processing without non-JS dependencies
- once OCG is retired and the above tasks completed, create a task investigating hardware requirements
@bmansurov - is something like this possible? If so, the will the browser notify the user when download is complete?
closing this for now. Next steps for post-processing and headless chrome to be tracked in T176463: [Spike] Investigate libraries for post-processing without non-JS dependencies
Thu, Sep 21
Moving into sprint so we can start recording data asap. We can then proceed with T169732: Deploy new desktop print styles on all projects in two weeks (Oct 9)
Cool, so yeah, this would be for all projects (including the ones that don't redirect to Special:ElectronPDF currently.
@bmansurov - not I'm a bit confused. Selecting "Download as PDF" on enwiki right now redirects to the selection screen which currently is Special:ElectronPDF:
@bmansurov - no, that was our initial plan, but we would want the workflow from this task on all projects.
Wed, Sep 20
@Tbayer - do we still want to do 10%?
Headless Chromium is able to render books with thousands of pages. It just takes a long time. We'll need machines with good CPU power if we want to speed up the render time. We'll have to work with a designer to change the UI (for example, by limiting the number of articles one can add to a book) and redo the back-end to render PDFs as queued jobs and notify the user via an email or an echo notification when their PDF is ready.
@Nirzar - is this a blocker for deploying the new styles?
Tue, Sep 19
Stalled due to pausing the books feature, as electron will not be our final renderer. Let's get back to this once we select a renderer.
It seems that splitting this will depend on our eventual choice of renderer. If we decide to go with headless chromium and do post-processing separately, we should pull out the styles for page numbers and toc into a separate task