418915 - Plugin print rendering window's coordinates clipping and unit conversion issues

Status: RESOLVED FIXED

(Core :: Printing: Output, defect, P1)

Description

[danielle.pham]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022005 Minefield/3.0b4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022005 Minefield/3.0b4pre

Despite fixes to bugzillas 408623 and 415285, Java plugin still facing Plugin printing issues with latest build of FF3.0b4pre (tested on Windows XP).

Summary:
- With 408623: The plugin drawing area's coordinates for printing are supposedly correctly converted from app units to device units. However, we were unable to test this fix because of the over printing problem in 415285.

- With 415285: FF fixes the over printing problem by creating a new windows for plugin to render print contents on. This window is backed by a cairo paginated layer where everything else except plugin is drawn on.

After the 2 fixes above, the issues we're facing now is with the new plugin print rendering window's coordinates clipping and unit conversion.
Attached are 2 MDI files to view with MS Doc Image Viewer and 2 htmls where these MDI are produced. ArcTest1.html is basically the same as ArcTest2.html, except that it has a bunch of lines added at the top to push the drawing area of ArcTest applet further down the page.

The coordinates {x,y,width,height} that plugin received from NPEmbedPrint.window are:

+ For ArcTest1.html:
  - If print to MDI file:  {183, 150, 800, 800}
  - If print to real printer (Xerox 432):  {367, 300, 800, 800} <-- applet is printable on actual 8x11 paper here.

+ For ArcTest2.html:
  - If print to MDI file:  {183, 437, 800, 800}
  - If print to real printer:  {367, 945, 800, 800} <-- applet is off the 8x11 paper here

1) The "origin" (x,y) coordinates of this window are calculated very off with reference to the rest of the contents on the paginated back layer.
Look at ArcTest2.mdi and see how (x,y) is placed low (y) and more centered (x) on the page, when it supposes to show right below the title on the page and left adjusted.
Further, the "y" values for ArcTest1 and ArcTest2 seem odd/reversed, because y's value becomes bigger as the applet moved further up the page. 

2) Even after 408623 fix, the conversion to device units doesn't seem to work right.
Comparing the coordinates received when printing to MDI vs. real printer, while width and height remained constant, x & y changed dramatically between the 2 devices. Aren't all 4 coordinates undergone the same AppUnitsToDevPixels() conversion with 408623 fix? If so, it seems this conversion do not work properly to account for various devices.

2) The unclipped area of the plugin rendering window is physically located very low with respect to the back layer. That is, if the applet is displayed further up the page, the unclipped/print-renderable area becomes shortened. Please compare ArcTest1.mdi with ArcTest2.mdi. In ArcTest2.html, the applet is displayed higher and so the rendering window's height is shortened.

I've tried continuously to get FF3 printing to work for Java Plugin, but faced one problem after another with each round of FF3 printing code change.
As of this point, besides fixing the above issues, I'd like to ask if you could ensure backward compatibility.

Since the new generation of Java Plugin is still under development, I simply ask if you could make Flash plugin printing to work with FF3. Because as of current, you cannot print any Flash contents whether to real printer or to MDI.
Try the following page:
http://smiley.smileycentral.com/download/index.jhtml?partner=ZNxmk762&spu=true&nsrc=az2&click_hash=11HbFFc

If you need access to latest Java Plugin binary, please contact me. Thanks.

Reproducible: Always

Steps to Reproduce:
1. Try with Flash: print the following page http://smiley.smileycentral.com/download/index.jhtml?partner=ZNxmk762&spu=true&nsrc=az2&click_hash=11HbFFc to either a real printer or an MDI.
2. See the attached MDI images of Java Plugin prints.
Actual Results:  
Applet print location is off and the "off" amount is depended on print device.
Applet print area is clipped wrongly.

Expected Results:  
Print result should looks like how contents looks on the browser.

Comment 1

[danielle.pham]

Attachment: ArcTest1.mdi - ArcTest1.hml print onto MDI

Comment 2

[danielle.pham]

Attachment: ArcTest2.mdi - ArcTest2.hml print onto MDI

Comment 3

[danielle.pham]

Attachment: ArcTest1.html

Comment 4

[danielle.pham]

Attachment: ArcTest2.html

Comment 5

[Johnny Stenback (:jst)]

From a recent discussion with Kenneth Russell (cc:d) at Sun this is a critical plugin printing bug that's not specific to Java. Plussing and marking P1 to make sure this one doesn't fall through the cracks, we should at the very least have mutual agreement about what's right and wrong here with plugin vendors. According to my understanding of this issue, this is a backwards compatibility problem that bites all plugins.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think we can just use PrintWindow and handle this entirely on our side, except we might have to just bail on Win2K (very small number of users). A PrintWindow + gfxWindowsNativeDrawing combo should be fairly straightforward.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Although I guess we should use the existing interfaces to print to the DC gfxWindowsNativeDrawing gives us, to get best possible output.

Comment 8

[Johnny Stenback (:jst)]

Reassigning to Vlad, as roc says he knows how to fix this.

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Eh?  If roc knows how to fix it, he should probably do it, though there's been a few things in that category lately :)  I don't understand why we have to do anything special here -- roc, the issue is that the coordinates that are being passed in are wrong, not that the plugin is failing to print.  We're already using gfxWindowsNativeDrawing, no?

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I meant to say that I thought "we" knew how to fix this. Although actually I think I was wrong and we don't.

Could this be a regression from bug 374141?

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Note that I've printed lots of Flash without any problems (e.g. to verify that the previous bugfixes of the overprinted plugins were fixed); I'll verify that and check these testcases when I get back to mountain view next week.

Comment 12

[danielle.pham]

Vladimir,
Flash printing experiences similar coordinate problem as Java Plugin. Flash content will be printed but depended on its location referencing to the rest of the page.
If the returned coordinates reside on the clipped area, you won't be able to see Flash content on the printed media at all.

For example:
1) http://www.jibjab.com/:  The only Flash component on this page is the "JIB-JAB Sendables" mv at the lower left corner of the page. Print this page to MDI and you will see Flash isn't there. Also notice how garbled the rest of the images on the page are printed.

2) Click on a Flash mv on http://www.jibjab.com/, say, the "Irish Step", then print. This time you'll see it printed but the image is shrunken.

3) As mentioned, try http://smiley.smileycentral.com/download/index.jhtml?partner=ZNxmk762&spu=true&nsrc=az2&click_hash=21H0ZJM.
The running smileys on the right half of the page do not show up when printing.

This result is on XP with FF3b4pre dated Feb/27/08.

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: fix win32 coordinates

I hate this plugin code -so much-, words cannot describe.

The problem here is that gfxWindowsNativeDrawing is too smart, and was already arranging things so that the native drawing could just happen at the right spot, and instead we were overcompensating by pulling out the translation origin and telling the plugin to render way over there.  So it was rendering outside the (set earlier) clip rectangle, and nothing was showing up.

This should also remove the double-Print call on non-windowless plugins on win32.

Comment 14

[Kenneth Russell]

Thanks for the prompt fix. Please update the bug when the patch has landed so we can verify the fix -- or if it's convenient to use your "try" server we can test with that as well.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 307397 [details] [diff] [review]
fix win32 coordinates

--- a/gfx/cairo/cairo/src/cairo-meta-surface.c	Tue Mar 04 17:09:36 2008 -0800
+++ b/gfx/cairo/cairo/src/cairo-meta-surface.c	Tue Mar 04 21:27:10 2008 -0800

This is not part of this patch, right?

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Kenneth, you might find it useful to keep around your own debug build of Firefox. It's not hard to do and it would let you test fixes immediately. Probably also give you much easier debugging for plugin work.

Comment 17

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #15)
> This is not part of this patch, right?

Er, nope.  Won't be checked in.

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Checked in; will be in tomorrow's nightly.  Let me know if everything's working ok?

Comment 19

[danielle.pham]

I have verified that Firefox b5pre Mar/7 fixes printing issues with OJI plugin and new Java Plugin on Windows.

But please allow me the time to verify on Solaris/Linux as well.

Btw. I still see the calling twice to NPP_Print() on Windows though. And interesting enough, with this fix, a different HDC is sent with each NPP_Print() call.
It's not as urgent to get this double print calling fix, but let's keep https://bugzilla.mozilla.org/show_bug.cgi?id=418937 until it's resolved.

Thanks for your hard works.

Comment 20

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Plugin printing isn't working on Gtk2 at the moment; it probably won't be fixed in time for Gecko 1.9/Firefox 3 release.  The API that's in use there (sending back a chunk of EPS) isn't easy to integrate into our current cross-platform rendering architecture, unfortunately.

Comment 21

[danielle.pham]

Is there a bug filed for plugin printing on gtk2 yet?

Comment 22

[arno renevier]

(In reply to comment #21)
> Is there a bug filed for plugin printing on gtk2 yet?

I've filled bug 464708