[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] JDK-7107175 - Paper tray handling
From:       Patrick Reinhart <patrick () reini ! net>
Date:       2013-11-25 21:27:49
Message-ID: 7385180E-1888-4A4A-8633-76F20ECD7CC2 () reini ! net
[Download RAW message or body]


Am 25.11.2013 um 18:16 schrieb Phil Race <philip.race@oracle.com>:

> On 11/25/2013 6:48 AM, Patrick Reinhart wrote:
> > If I understand this correct, that means it should be possible to just define a \
> > MediaTray without a MediaSizeName then right? But in my environment the default \
> > MediaSizeName is set to Letter even though the current PrintService would define \
> > A4 as the default.
> > > 
> > > I see a line in RasterPrinterJob.java which might cause that to happen if you \
> > > specify a tray and no paper but that seems like its a bug. It should always be \
> > > the default for the current printer unless I'm forgetting something we had to \
> > > do for backwards compatibility. 
> > Do you mean this lines starting at 562:
> 
> Yes. That's what I saw from a very quick (< 1 min) look at the sources.
> > 
> > Media media = (Media)attSet.get(Media.class);
> > if (media == null) {
> > media =
> > (Media)service.getDefaultAttributeValue(Media.class);
> > }
> > if (!(media instanceof MediaSizeName)) {
> > media = MediaSizeName.NA_LETTER;
> > }
> > 
> > This would replace a set MediaTray from the attribute set with the \
> > MediaSizeName.NA_LETTER right? 
> 
> Yes, looks like a bug to me.
> 
> > A would sugest to change the lines to something like this:
> > 
> > Media media = (Media)attSet.get(Media.class);
> > if (media == null) {
> > media =
> > (Media)service.getDefaultAttributeValue(Media.class);
> > if (media == null) {
> > media = MediaSizeName.NA_LETTER;
> > }
> > }
> > 
> > This would fall back to letter in case of a non default definition of a media \
> > size name and no such is defined within the request attributes...
> 
> Not sure. Need to look at the wider context. The code here seems to be expecting \
> MediaSizeName. I'd need to look deeper and I don't have time.

I will take a closer look into that and do some more investigations. As I saw already \
that it seems that the MediaSizeName is mainly needed to setup to correct paper size. \
I thank you anyway for your help so far.

> > > > If I compare the basic behavior in comparison to the Windows implementation. \
> > > > The are some differences in setting the default MediaSize and MediaSizeName. \
> > > > Those will be not initialized in the Windows world and taken from the current \
> > > > PrintService in case it's not set via PrintRequestAttributeSet. 
> > > > 
> > > > > I can see no way around this other than defining an new attribute class \
> > > > > that doesn't subclass Media and duplicates MediaTray .. but then you'd also \
> > > > > need to say what happens if someone specifies two different trays, one by \
> > > > > each means. 
> > > > I do not completely understand what you mean. Do you mean the use case if one \
> > > > specifies A4,Tray2 but Tray2 contains Letter?
> > > 
> > > I meant that if we provided a new class "MediaSource" you could specify \
> > > MediaSource.TRAY1 whilst still specifying for "Media" an instance of the \
> > > subclass MediaTray that corresponded to TRAY2. That's an API solution that \
> > > doesn't seem likely any time soon.
> > I always thought that the MediaTray does specify the source already as it says in \
> > the JavaDoc:
> 
> It does specify the source, but as I've already twice tried to make clear, with \
> present API you cannot simultaneously specify the size which is what I thought you \
> were raising as the main issue.

I do not want to specify both size and input tray. I may have made myself not clear \
enough in that point. I do not see how there can be found out, what media size is set \
on e certain MediaTray to construct the correct paper size on line 575.

> I am guessing that IPP took the view that if you specify the tray that implied a \
> paper size, and if you could specify both, you could over-constrain the \
> requirements, eg requesting a paper size from a tray that didn't support that paper \
> size.

I see, but this would not be needed if the specified tray within the attribute set \
would be taken correctly and there is some way to get the media size configured for \
that tray.

Cheers

Patrick


[prev in list] [next in list] [prev in thread] [next in thread]