The larger file is because of the fix
4970557 : Browser printing of applets is at screen resolution on windows.
This is necessary to improve printing quality and was implemented for 1.5 way back in 2003.
So that is functioning as designed.
The "leak" of temp files isn't something that the 2D printing code is responsible for.
We are handed a Windows DC for a metafile that was created by the Java plugin code
Here's the essence of that code, minus some error handling :
HDC hPluginDC = CreateEnhMetaFile(hDC, NULL, NULL, NULL);
HENHMETAFILE hMF = ::CloseEnhMetaFile(hPluginDC);
::PlayEnhMetaFile(hDC, hMF, &rect);
As you can see this doesn't explicitly create a temporary file, that is
done by windows and at the end of printing DeleteEnhMetaFile() is called.
The MSDN docs state the following :
If the hemf parameter identifies an enhanced metafile stored in memory,
the DeleteEnhMetaFile function deletes the metafile.
If hemf identifies a metafile stored on a disk, the function
deletes the metafile handle but does not destroy the actual metafile.
Pointer to the file name for the enhanced metafile to be created.
If this parameter is NULL, the enhanced metafile is memory based
and its contents are lost when it is deleted by using the DeleteEnhMetaFile function.
So since plugin creates it as a MEMORY DC (see the null parameters to CreateEnhMetaFile)
and properly calls DeleteEnhMetaFile() it appears to be up to windows to clean up
this file. The docs even lead one to believe that a file isn't used in this
cases. Likely windows does in fact, and has not yet closed the file. This appears to be
a windows bug, since the implementation isn't performing as per spec.
It is likely possible to work around this by using the printer DC directly.
BTW This is seen only in IE since the firefox plugin code doesn't use a metafile.
CU provided related source code for the printing operation
The EMFFiles are in
-rw-rw-rw- 1 nobody nobody 154068 Feb 5 11:43 JRE142_10.AL7EX49K.emf
-rw-rw-rw- 1 nobody nobody 1843724 Feb 5 11:44 JRE160_05.OLOJU5K3.emf
For the new java plugin for IE, we don't create an emf file explicitly. In the OnDraw method, we received a hdcDraw inside the ATL_DRAWINFO structure from the browser. The hdcDraw is of OBJ_ENHMETADC type.
Regarding the .emf files remain in the "temp" directory after printing, this is a known issue related to printing embedded controls inside a web page as described in the following:
Adding clarification to that last comment : "old" plugin - ie the only one in all releases prior
to JDk 6 update 10, Plugin did create an EMF, but it so happens that IE *also* uses an EMF, so
-> User selects Browser: File->Print
-> IE obtains a printer DC (hdc1) to render its own content
-> For each "3rd party plugin content" on the page (eg Flash, Java), IE
creates a *disk* meta file (mf1) and passes a DC (hdc2) for it to the plugin.
-> In the case of Java Plugin, it creates a *memory* metafile (mf2), creates
a DC for that (hdc3) and asks the JRE to render the applet content into hdc3
which corresponds that metafile (mf2)
After completion Plugin plays the contents back into hdc2, then deletes
the memory metafile (mf2).
-> IE then plays back the contents of mf1 into hdc1, but *fails* to then
delete the disk metafile mf1
-> Printing is complete.
So it is something of a coincidence that two metafiles are involved, but the
one that is leaked is not created by any part of plugin, so this is purely a Microsoft
IE issue. Those of is who experienced this were all using IE 7 but without further
testing we can't say if its unique to that browser version, or if IE6 or even IE8
are similarly afflicted.
"new plugin" can't help, since although it eliminates the internal use of a metafile
that is not the source of the problem.