[OpenJDK 2D-Dev] JDK-7107175 - Paper tray handling

[Phil Race]

On 11/21/2013 2:52 PM, Patrick Reinhart wrote:
> Hi Phil,
>
> Am 21.11.2013 um 23:08 schrieb Phil Race <philip.race at oracle.com>:
>
>>> What would be the correct solution for this problem?
>> Which problem ?
>>
>> 7107175  sounds like a bug in the parameters we pass to lpr
>>
>> The other problem you mention is largely if not entirely because IPP lumped
>> trays along with papers as being "Media".
>>
>> See http://tools.ietf.org/html/rfc2566#section-4.2.11
>>
>>    If a Printer object supports a medium name as a value of this
>>    attribute, such a medium name implicitly selects an input-tray that
>>    contains the specified medium.  If a Printer object supports a medium
>>    size as a value of this attribute, such a medium size implicitly
>>    selects a medium name that in turn implicitly selects an input-tray
>>    that contains the medium with the specified size.  If a Printer
>>    object supports an input-tray as the value of this attribute, such an
>>    input-tray implicitly selects the medium that is in that input-tray
>>    at the time the job prints.
>>
> 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.


>
> 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.

-phil.

> Patrick
>
>
>> That's an API solution that doesn't seem likely any time soon.
>>
>> Plus, providing a way to specify both simultaneously at an API level wouldn't
>> be enough to resolve 7107175  .
>>
>> -phil.
>>
>> On 11/21/2013 1:34 PM, Patrick Reinhart wrote:
>>> Hi everybody,
>>>
>>> I would like to look into this defect as one of our customer has reported the same problem. I also have seen that there is no way to specify a media size name and a output tray neither thru the PrintRequestAttributeSet nor the DocAttributeSet even-though it's possible to do so within the print dialog.
>>>
>>> As in the in the defect described, media size and tray can be specified for a CUPS printer. Unfortunately the Attribute type for MediaTray and MediaSizeName can not be mixed...
>>>
>>> What would be the correct solution for this problem?
>>>
>>> Cheers Patrick