Hi All,
What changes would we like to see in a refactoring of printing support? At
a minimum, we need to...
A) Move printing support into a separate module.
B) Provide a proxy layer to support chrome IPC.
C) Add printing support to test_shell.
We might also want to...
D) Simplify the printing notifications. If you look in print_job.cc,
print_job_manager.cc and print_view_manager.cc you'll notice that the code
ignores about 80% of the notifications that we send. Perhaps we can
eliminate some of these.
E) Use this as an opportunity to implement asynchronous printing. The
current synchronous printing works approximately as follows (but with lots
of additional notifications that I'm not mentioning):
(i) The tab process requests print settings from the browser process.
(ii) The browser process asks the user for print settings and sends the
settings to the tab process.
(iii) The tab process reformats the render window in print view and renders
each page, sending the print data back to the browser process.
(iv) The browser process writes the print data to the printer context.
It would be nice if all printing logic could be handled by a single,
separate thread and/or process that hosts its own in-memory renderer. The
required change is roughly described in this comment from
print_view_manager.cc:
void PrintViewManager::RenderOnePrintedPage(PrintedDocument* document,
int page_number) {
// Currently a no-op. Rationale: printing is now completely synchronous
and is
// handled by PrintAllPages. The reason is that PrintPreview is not used
// anymore and to make sure to not corrupt the screen, the whole
generation is
// done synchronously. To make this work completely asynchronously, a
// duplicate copy of RenderView must be made to have an "innert" web page.
// Once this object is created, we'll have all the leasure to do whatever
we
// want.
}
If we move to asynchronous printing then we only need IPC notifications for
delivering print progress (begin document, begin page, end page, end
document, error conditions) and providing the capability to cancel the print
job. So, asynchronous printing might work like this:
i) The tab process tells the browser process to print a URL.
ii) The browser process asks the user for settings and then starts a new
asynchronous print process.
iii) The print process creates its own in-memory renderer, loads the URL
(from cache or other in-memory representation, if possible) and sends out
notifications to the browser process while it's printing.
There are some additional details that we would need to work out, like how
to handle pages with submitted post data. Perhaps we can "clone" the
existing tab process renderer data in some way that doesn't require us to
re-load the request.
F) Add a dialog box that shows printing progress and gives the user the
option to cancel the print job. This could be a modeless dialog created and
handled by the asynchronous print process.
G) Add Print Preview support. This could be a modal dialog created and
handled by the asynchronous print process.
What else should be consider? Any and all ideas are welcome :-).
Regards,
Marshall
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
