Is it possible to fix --kiosk-printing missing pages using PDF printing?

[Jon Pfeffer]

I've read that the --kiosk-printing command line switch is not officially supported.

This feature has two deficiencies:

    1) It shows a brief flash of the print preview window before hiding it (https://bugs.chromium.org/p/chromium/issues/detail?id=169004)

    2) It frequently prints blank pages at the end of print job (https://bugs.chromium.org/p/chromium/issues/detail?id=631326)

#1 is cosmetic (users don't want to see this especially if they print frequently), but #2 leads to feature discrepancies and is a huge problem.

The printing of blank pages is made worse if

    a) The print job contains many pages

    b) The rendering is complex (e.g. contains lots of figures/graphics)

No one  seems to "own" this feature. The author (the...@chromium.org) could probably provide the most insight on how to fix it.

I've been trying to fix this, and still don't have a solution. 

Its easy to eliminate #1 above by simply not opening the print preview window and performing basic printing.

However, if the print preview window is not used, then the printed content will be missing the file headers and footers for each printed page.

I've noticed through debugging when stepping though method:

void PrintPreviewHandler::HandlePrint(const base::ListValue* args) file print_preview_handler.cc

if you use PrintToPdf() the resulting output file always contains all the pages correctly rendered with headers and footers.

if (print_to_pdf) {

    ...

    PrintToPdf();

}

Is there a way to send the the content inside of method PrintToPdf directly to the default printer instead of a file? It does contain no blank pages.

Regards,

Jon

[Sean]

For #1: If you want to be able to skip showing print preview, you'll probably have to extract the relevant logic from print_preview_handler so it can be used outside the webui packages.

As to #2: What platform is this for?  Not all platforms support basic printing.

[Jon Pfeffer]

Thank you for your reply.

#2 is the extremely important part I'm focusing upon for the windows platform. 

The flash (#1) although it is not ideal, it still is functional for most customers (unless for some reason they batch many print requests in a row).

So far, I'm at a dead end for using the correct PrintToPdf content and sending it to the print spooler instead of a file. 

I'm looking now at the "Printing_Worker" Thread, specifically PrintJobWorker::OnNewPage().

If the print_preview_handler starts the print job quickly (via PrintPreviewHandler::HandlePrint(const base::ListValue* args)), then print_job_worker (via PrintJobWorker::OnNewPage()) is already working with a document that has the missing pages on the end.

In that method, int page_count = document_->page_count(); is correct, but

 

Scoped_refptr<PrintedPage> page = document_->GetPage(page_number_.ToInt()) 

and 

 

 // The page is there, print it.

    SpoolPage(page.get());

spools the blank pages at the end.

I'm hoping if we can delay this being called, that also would correct the problem:

PrintJobWorker::OnDocumentChanged(PrintedDocument* new_document)

{

   ...

   document_ = new_document;

}

I can see why this bug has been out in the field so long. Conceptually, it sounds easy, just a timing bug. However, in practice, finding the place where to delay the print process until the rendering is complete has been very hard.

Regards,

Jon 

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Sean]

Yes.  Unfortunately the printing code has to do a lot of thread hopping and can be quite difficult to trace.

Would you mind summarizing your findings again?  Are you saying that OnDocumentChanged is called too early or too late?  Also, are you saying that we're rendering extra pages or that pages that don't exist are being spooled?

If it's an issue with spooling, I can take a closer look at the printing code.  If it's rendering, we'll need samples and can get some help.

On Sunday, December 4, 2016 at 9:07:10 AM UTC-8, Jon Pfeffer wrote: