Sounds good. When we created the service we went with the A4 and Letter sizes initially. In order to work on this task, we need some input from the designer about the page sizes that we need to support. We also need to create a task to implement the change in page sizes and the ability to render the page in mobile mode. I'm not sure if we should repurpose this task and re-do T178278 with for mobile in mind, or whether we should create a new task and then work on this task. Your call.

/cc @Nirzar

In order to work on this task, we need some input from the designer about the page sizes that we need to support

I didn't quiet understand what supporting means in this context. Don't we support all dimensions and it scales accordingly?

We also need to create a task to implement the change in page sizes and the ability to render the page in mobile mode.

referring to the mobile css?

In T181513#3792803, @Nirzar wrote:

In order to work on this task, we need some input from the designer about the page sizes that we need to support

I didn't quiet understand what supporting means in this context. Don't we support all dimensions and it scales accordingly?

Right now the Chromium render service only outputs PDFs with the A4 and letter sizes. What other sizes do we want the service to output?

These are the built-in options in chromium:

Letter: 8.5in x 11in
Legal: 8.5in x 14in
Tabloid: 11in x 17in
Ledger: 17in x 11in
A0: 33.1in x 46.8in
A1: 23.4in x 33.1in
A2: 16.5in x 23.4in
A3: 11.7in x 16.5in
A4: 8.27in x 11.7in
A5: 5.83in x 8.27in

We can also specify the page size in one of these units of length:

px - pixel
in - inch
cm - centimeter
mm - millimeter

See: https://github.com/GoogleChrome/puppeteer/blob/v0.11.0/docs/api.md#pagepdfoptions

We also need to create a task to implement the change in page sizes and the ability to render the page in mobile mode.

referring to the mobile css?

Yes. The service as it stands now is really simple. It just pulls a page from RESTBase and renders it in A4/letter size. But we need to make sure that the service is capable of pulling mobile CSS and rendering pages using mobile rules.

What other sizes do we want the service to output?

for Mobile we should default to Legal or if possible record height x width of device, send it with the PDF request to server and generate the PDF with that, but then we will need max-width and max-height options which are missing from that doc afaik.

Let's go with Legal as default for Mobile

Yes. The service as it stands now is really simple. It just pulls a page from RESTBase and renders it in A4/letter size. But we need to make sure that the service is capable of pulling mobile CSS and rendering pages using mobile rules.

cool

I'm not really sure I understand this task.
Do you mean

1. performance of the code to produce PDFS
2. test the new mobile PDFs visually

or

3. do you mean can we scale to the traffic demands of mobile?

1. There should be no performance problems, as we're using the same code as desktop and @pmiazga has done a great job of stress testing that in T178278 and IMO we don't need to do anything more specifically for mobile.
2. This task should be rewritten
3. If this is needed, the first thing to do is determine the expected traffic to the service per hour/day (I'm guessing that would be a Tilman analysis task?). Then it should be a question of whether we can scale to that traffic which will involve Sam/myself talking to services. We can and should progressively roll this feature out, but that would be best done at deployment.

I think #2 can be safely ruled out.

In T181513#3953687, @Jdlrobson wrote:

I'm not really sure I understand this task.
Do you mean

1. performance of the code to produce PDFS
2. test the new mobile PDFs visually

or

3. do you mean can we scale to the traffic demands of mobile?

1. There should be no performance problems, as we're using the same code as desktop and @pmiazga has done a great job of stress testing that in T178278 and IMO we don't need to do anything more specifically for mobile.
2. This task should be rewritten
3. If this is needed, the first thing to do is determine the expected traffic to the service per hour/day (I'm guessing that would be a Tilman analysis task?). Then it should be a question of whether we can scale to that traffic which will involve Sam/myself talking to services. We can and should progressively roll this feature out, but that would be best done at deployment.

The task was originally meant for #1 , but it sounds that this won't be needed. We can adapt it to mean #3, and perhaps include a blocking relationship with the already-existing analysis task: T179915: Determine expected amount of usage of mobile print to PDF button per browser

@pmiazga @phuedx is T179915 done? I can't tell if the analysis there is WIP or completed. Can this is be unstalled? It was my understanding we are deploying now?

In T181513#4455603, @Jdlrobson wrote:

@pmiazga @phuedx is T179915 done? I can't tell if the analysis there is WIP or completed.

AIUI – looking at the analysis that @Tbayer published on the task in T179915#4266991 – the third AC has yet to be met.

Can this is be unstalled?

Given the above, no.

It was my understanding we are deploying now?

Briefly, the service should be receiving a fraction (TBD) of production traffic within two weeks as part of the last stage of performance testing.

Is this done? Does it need to be done?