[webkit-dev] Plugin Printing Behavior

[Marc-Antoine Ruel]

On Fri, Dec 18, 2009 at 1:51 AM, Brent Fulgham <bfulgham at gmail.com> wrote:

> I've recently written an in-house NPAPI plugin for use with WebKit in an
> application I'm working on.  One of the primary functions of this tool is to
> generate printed output, so naturally I was dismayed to discover that my
> plugin's NPP_Print implementation was not getting called during WebKit page
> print operations.  So, the bulk of the page prints fine, leaving a big blank
> rectangle where the plugin should be.
>
> I attempted to test printing of production quality plugins (Adobe Acrobat
> Reader, Flash, SWF, and Quicktime) on Windows using Safari, Chrome, and
> Firefox as well as Safari on the Mac.  Adobe's PDF plugin does not produce
> printed output on Windows in Safari or Google Chrome, but does seem to work
> on the Mac.  Firefox seems to work on Windows as well.  I'm not that
> surprised that the video plugins produce no print output, but did not have
> any other installed plugin examples to choose from.
>
> Before I exert too much effort trying to reduce this to a reasonable test
> case, I was wondering if this was a known issue.  I didn't see much in
> Bugzilla, though I must admit to not spending more than a few minutes
> running queries.  The closest I could find was a bug from 2007 related to
> display of PDFs in Safari, which isn't quite the same as my problem.
>
> If anyone else is aware of this issue, please let me know.  Otherwise I'm
> going to see if I can track down the issue.
>
> Thanks,
>
> -Brent
>

I spent a significant effort on getting plugin printing working on Google
Chrome in early 2008 for the windows port. Please forgive me if there is
factual errors on the following. At the time, Safari wasn't printing plugins
either.

First, a small recall about how Firefox and IE print:
If we compare Firefox3.0 to IE7 on Windows, Firefox is getting better plugin
printouts than IE. Why? Because it's doing vectorial based drawing, like
flash charts, are rendered "vectorially" in NPP_Print. In IE, surprisingly,
a bitmap screen shot is taken instead. Firefox is handing out the printer
device context handle(HDC) directly to the plugin for it to render so the
GDI calls are done in at the right resolution.

Let me explain the Google Chrome and Windows-specific situation:
In our case, the plugin runs in a separate process so it doesn't have access
to the actual HDC. So there is two remaining ways:
- Take a display snapshot, ala IE7, with NPP_HandleEvent + WM_PAINT into a
EMF metafile HDC.
- Create a EMF metafile HDC for it to print into and hand it to NPP_Print.

The main issue is that I wasn't able to get consistent results with an EMF
metafile. If I take Flash as an example, it has some expectation when
querying the device context that the EMF buffer doesn't fulfill. The EMF HDC
doesn't have margins or anything like that. I tried faking them with
clipping rect but that didn't work; this created drawing elements going out
of the plugin rect, like a line going all over the page, or shifted
rendering in one or two axis by roughly a paper margin.

I don't recall why I ditched the display snapshot implementation, I recall
having the implementation done but recall some issues with it. Since Safari
wasn't printing plugins either, which means the webkit code paths weren't
exercised, I decided to go the safer route by disabling it altogether.

Hope this sheds some light on the challenges.

M-A

PS (not to you specifically): patches are welcome :)
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/plugin/webplugin_delegate_stub.cc?revision=34596&view=markup
still
has a OnPrint implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091218/c6b23632/attachment.html>