When printing plugins in Windows, the device context handed to the plugin is translated to reflect its position on the page. For example, a widget taking up a region starting at (8, 54) on the screen is printed using a context whose world transform has been translated by (8, 54). This is not correct when a header is being used. In printing tests I can see that the translated context is the same as the on-screen representation, yet the rest of the page contents are further down the page due to the header spacing. This causes the plugin to paint over the top of some of the text region.
Created attachment 45447 [details] Screen shot of PDF generated by printing a sample page with a single embedded plugin. Notice how the region drawn by the plugin overlaps the heading region (labeled 'Sample Heading'). The region on-screen is properly offset by the amount of the header.
Created attachment 45941 [details] Patch to update CTM with scale and position when drawing a plugin The attached patch modifies the CTM to account for desired page position, so that margins and header are accounted for when drawing the plugin.
style-queue ran check-webkit-style on attachment 45941 [details] without any errors.
Comment on attachment 45941 [details] Patch to update CTM with scale and position when drawing a plugin > Index: WebCore/ChangeLog > =================================================================== > --- WebCore/ChangeLog (revision 52752) > +++ WebCore/ChangeLog (working copy) > @@ -1,3 +1,16 @@ > +2010-01-05 Brent Fulgham <bfulgham@webkit.org> > + > + Reviewed by NOBODY (OOPS!). > + > + Scale device context world transform passed to plugins to account > + for print surface DPI. > + http://bugs.webkit.org/show_bug.cgi?id=33022. This mentions a different bug #. Is there a similar change that needs to be made for windowless plug-ins? Is there any way to add a test this? Perhaps a manual test? r=me
Landed in http://trac.webkit.org/changeset/52955.
A final test of this functionality will need to address Bug 33022, since plugins currently do not print under Safari. I can show this works under WinCairo, but WinLauncher does not have CG-based printing support.