This RFE describes a request for new behaviours that may resolve some
of the issues described in bug ID 4311283.
This request is that selected detectable side effects of a platform
native print dialog be used by the Java 2D printing implementation to
update its notion of the internal state of a PrinterJob.

The Java 2D printing API (the java.awt.print package) was introduced in
J2SE V1.2.
Similarly to other printing APIs it also defined the concepts of
UIs for page setup and for print job setup.
These are the PrinterJob.pageDialog() and PrinterJob.printDialog() methods
respectively.
The API made a distinction between the roles of these two dialogs.
The latter was intended to control printer selection, collation etc.
The former defined the properties of the page. This was returned to
the calling application as a PageFormat. The application could use this
in any way it wished  - it could ignore it, or it could specify it as
the PageFormat to be used for the PrinterJob by calling
PrinterJob.setPrintable(Printable, PageFormat).

The problem is that some platforms provide ways for non-standard side-effects
of these dialogs.
For example, the win32 page setup dialog can be used to invoke the
print dialog, and the print dialog can be used to invoke a printer vendor's
own UI.

None of these are dependable however, eg
- they may be selectively disabled or customised by applications
- these may change from windows release to release, and aren't even
  consistent within a release as the printer vendor's property sheet
- they aren't necessarily directly supported by platform API. ie
  in the case of the "Properties" sheet on the win32 native print dialog
  the entire contents of that sheet is defined by the particular printer
  vendor and could change driver specific properties that are completely
  inaccessible via any API (including native ones). Or they may constitute
  duplicate UI than the standard ones provided by the platform to manipulate
  settings.
  
The request here is that for the specific common case of the size and
orientation of the media that updates made by an end-user be detected where
possible and used to update the internal state of the PrinterJob in such
a way that the Java client application can make proper use of that information.

N/A

This problem is one of mapping the Java APIs to the
side effects of print vendor specific UI which may update the DEVMODE.
Only updates to public DEVMODE settings can be detected by the JRE and
there is no way to directly inform the application that something was
changed as a result of the printDialog.

The minimal implementation of this RFE will internally create a new
PageFormat object reflecting the dimensions and orientation of the new
page settings and set it as the PageFormat which will be used when printing
using a Printable object. Margin settings would have to be calculated somehow.
This could be accomplished without new APIs so that existing code could make
use of it.

This however means that clients would know of the change only when called
to print() and clients using Pageable would not benefit from this at all.
Thus it is an incomplete solution.

A more complete implementation of the RFE would provide a call-back interface
which an application could implement to be notified of a change to the
PageFormat so it could be aware of any change. For this call back to be
useful it needs to provide a discover the new PageFormat. Consideration needs
to be given as to whether there are other side-effects on which notification
would be useful or just constrain this RFE to the known problem.

This is a lot of machinery to partially satisfy this requirement and
duplicates capabilities already inherent in the enhancements to PrinterJob
which use the javax.print APIs.

  xxxxx@xxxxx   2001-11-27
This describes the same scenario as 4880226. The evaluation of that bug
(although not the original problem description) notes that the side effects
of changing the pagelayout can happen in the print dialog as well as the
page dialog. This bug report is a superset of that one adddresses concerns around
paper size, margins and orientation, when using the various dialogs, including
vendor specific ones.

Those issues have in fact been resolved in existing releases, at least
as far back as JDK 1.5.0, so I am closing this bug as not reproducible.
Posted Date : 2007-07-30 18:54:23.0

The described "minimal implementation" should be regarded as 
a bug fix and only the "more complete implementation" should 
be regarded as an RFE.

If our code has allowed the user to interact with either the 
printer dialog or the page dialog, then that code also has an 
opportunity to subsequently query the PrinterJob object for 
changes to the PrintService object and the PageFormat 
object.

With JDK 1.4.1 (using Win2K and an HP Laserjet 5Si Printer 
driver), querying the PrinterJob object for a change in the 
PrintService is successful after calling either printDialog() or 
pageDialog().  Similarly, if you retrieve a PageFormat by 
calling defaultPage() after calling either printDialog or 
pageDialog, the user's most recent selection for media (as 
implied by the Paper object associated with the PageFormat) 
is correct.  However, the orientation is only correct when a 
PageFormat is retrieved from a a call to pageDialog().  

Fixing the orientation would fix the "bug" part of this - adding 
the requirement to implement a call back mechanism as well 
sounds nice, but the extra work is likely to delay any sort of 
resolution.  

People have complained about this issue repeatedly in 
4311283 and in 4746768 as well as here.  It is not clear that 
Sun regards this problem even yet as a bug.  It would be nice 
if Sun would acknowledge that this IS a bug.