[Printing-architecture] Another Epson Question on the Common Print Dialog

[Printing-architecture] Another Epson Question on the Common Print Dialog

[Petrie, Glen]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

All,

 

Another question has been asked by Epson internal on the Common Print
Dialog.

 

The issue is on borderless printing.

 

1.	Is the follow flow correct?

 

In addition, we want to ask a question regarding the borderless printing
with Common Printing Dialog (CPD).

We are understanding the borderless printing scenario with CPD as
follows. Is it right?

 

1) Users select the "Borderless" option.

2) The "Borderless" option is reported back to the application.

3) The application "expands" the image for "Borderless" printing, and
send the expanded PDF to CPD.

4) CPD shows the preview of received PDF.

5) If users judge that it is OK, CPD sends the "expanded" PDF to CUPS.

 

2.	If the above flow is correct; then, how does the application
"expand" the image ?

a.	by how much ?
b.	if the image size does not equal media size, the how is the
scale ratio of the expanding decided?
c.	what is the method used by the application to expand the  image?
There are other methods beyond simple scaling.

 

Borderless printing, today, is done by the printer driver independent of
the application. 

 

I will forward your replies to internal Epson.

 

Glen

 


[-- Attachment #2: Type: text/html, Size: 10686 bytes --]

Re: [Printing-architecture] Another Epson Question on the Common Print Dialog

[Lars Uebernickel]

On Thu, 2010-03-25 at 09:16 -0700, Petrie, Glen wrote:
> In addition, we want to ask a question regarding the borderless
> printing with Common Printing Dialog (CPD).
> 
> We are understanding the borderless printing scenario with CPD as
> follows. Is it right?
>  
> 1) Users select the "Borderless" option.
> 
> 2) The "Borderless" option is reported back to the application.
> 
> 3) The application “expands” the image for "Borderless" printing, and
> send the expanded PDF to CPD.
> 
> 4) CPD shows the preview of received PDF.
> 
> 5) If users judge that it is OK, CPD sends the “expanded” PDF to CUPS.
> 
>  
> 
>      1. If the above flow is correct; then, how does the application
>         “expand” the image ?
>              a. by how much ?
>              b. if the image size does not equal media size, the how
>                 is the scale ratio of the expanding decided?
>              c. what is the method used by the application to expand
>                 the  image?  There are other methods beyond simple
>                 scaling.
> 
>  
> 
> Borderless printing, today, is done by the printer driver independent
> of the application. 

In general, this is correct.  However, this will only work if the
application knows about this particular driver option.  Additional
options or custom parameters might be used to let the user select scale
ratio and quality.  This would mean that all applications would have to
implement it, which is unlikely (especially if it is a vendor specific
option).

There is currently no provision to let the driver modify the preview
when an option changes.  I am open to suggestions on this if such a
feature is desired.

To be honest, I think this would be better implemented as an
application-specific option, because the application has more
information about the content and can make better decisions based on
that.

    Lars

Re: [Printing-architecture] Another Epson Question on the Common Print Dialog

[Till Kamppeter]

On 03/25/2010 05:16 PM, Petrie, Glen wrote:
> All,
>
> Another question has been asked by Epson internal on the Common Print
> Dialog.
>
> The issue is on borderless printing.
>
>    1. Is the follow flow correct?
>
> In addition, we want to ask a question regarding the borderless printing
> with Common Printing Dialog (CPD).
>
> We are understanding the borderless printing scenario with CPD as
> follows. Is it right?
>
> 1) Users select the "Borderless" option.
>
> 2) The "Borderless" option is reported back to the application.
>
> 3) The application “expands” the image for "Borderless" printing, and
> send the expanded PDF to CPD.
>
> 4) CPD shows the preview of received PDF.
>
> 5) If users judge that it is OK, CPD sends the “expanded” PDF to CUPS.
>
>    2. If the above flow is correct; then, how does the application
>       “expand” the image ?
>          1. by how much ?
>          2. if the image size does not equal media size, the how is the
>             scale ratio of the expanding decided?
>          3. what is the method used by the application to expand the
>             image? There are other methods beyond simple scaling.
>
> Borderless printing, today, is done by the printer driver independent of
> the application.
>
> I will forward your replies to internal Epson.

Not exactly, this is more the workflow of an application-supplied 
option, where the setting of the option determines how the application 
should create the document to be sent to the printer.

Borderless is usually simply a boolean option supplied by the driver. 
One does not expect that the application needs to re-render the PDF. The 
driver takes care of appropriate overspray expansion when rendering the PDF.

I general, the app can only react to option settings with re-rendering 
if the options is an option supplied by the app and not from the 
printer, driver, or printing system (CUPS).

    Till

Re: [Printing-architecture] Another Epson Question on the Common Print Dialog

[kate price]

Hi all - here is the reaction from the UI perspective-
There are a couple of major points here as far as I am concerned:

1. By borderless printing we assume you to mean printing with minimum  
margins/maximum printable area, as opposed to printing without a  
border line.

I understand that borderless printing is a special feature of some  
printers and manufacturers and as such may need a high visibility.  
However generally, for clarity and logic's sake across all printer  
clusters, we have included this into the "print on" group of controls.  
This sets media type and size, and therefore margin size according to  
the media selected.

2. To this end, when we state that changes in margin size should be  
reflected in the preview, it of course follows that borderless  
printing should be shown in the preview too. We are working from the  
basis that printable area and orientation are two obvious parameters  
that the app must know to transform.

Apologies if this was not clearly enough stated in the spec. This has  
been rectified.

Kate
m+mi works

On 25 Mar 2010, at 21:15, Till Kamppeter wrote:

> On 03/25/2010 05:16 PM, Petrie, Glen wrote:
>> All,
>>
>> Another question has been asked by Epson internal on the Common Print
>> Dialog.
>>
>> The issue is on borderless printing.
>>
>>   1. Is the follow flow correct?
>>
>> In addition, we want to ask a question regarding the borderless  
>> printing
>> with Common Printing Dialog (CPD).
>>
>> We are understanding the borderless printing scenario with CPD as
>> follows. Is it right?
>>
>> 1) Users select the "Borderless" option.
>>
>> 2) The "Borderless" option is reported back to the application.
>>
>> 3) The application “expands” the image for "Borderless" printing, and
>> send the expanded PDF to CPD.
>>
>> 4) CPD shows the preview of received PDF.
>>
>> 5) If users judge that it is OK, CPD sends the “expanded” PDF to  
>> CUPS.
>>
>>   2. If the above flow is correct; then, how does the application
>>      “expand” the image ?
>>         1. by how much ?
>>         2. if the image size does not equal media size, the how is  
>> the
>>            scale ratio of the expanding decided?
>>         3. what is the method used by the application to expand the
>>            image? There are other methods beyond simple scaling.
>>
>> Borderless printing, today, is done by the printer driver  
>> independent of
>> the application.
>>
>> I will forward your replies to internal Epson.
>
> Not exactly, this is more the workflow of an application-supplied
> option, where the setting of the option determines how the application
> should create the document to be sent to the printer.
>
> Borderless is usually simply a boolean option supplied by the driver.
> One does not expect that the application needs to re-render the PDF.  
> The
> driver takes care of appropriate overspray expansion when rendering  
> the PDF.
>
> I general, the app can only react to option settings with re-rendering
> if the options is an option supplied by the app and not from the
> printer, driver, or printing system (CUPS).
>
>    Till
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] Another Epson Question on the Common Print Dialog

[Petrie, Glen]

All,

<..snip..>

>>............ We are working from the basis that printable area and
orientation are two obvious parameters that the app must know to
transform.

This clarification states, "the app must know to transform"; thus, the
application will, by this clarification, perform the transformation.
Epson is specifically interested in understanding about the "how does
the app perform the transform" and 

> >>   2. ..... how does the application "expand" the image ?
> >>         1. by how much ?
> >>         2. if the image size does not equal media size, the how is
> >>            the scale ratio of the expanding decided?
> >>         3. what is the method used by the application to expand the
> >>            image? There are other methods beyond simple scaling.
 
All of these item can change from print-vendor to print-vendor and
printer-to-printer; so it important the printer vendor to understand
more of the details.

Thanks, glen


=============================
> 
> On 25 Mar 2010, at 21:15, Till Kamppeter wrote:
> 
> > On 03/25/2010 05:16 PM, Petrie, Glen wrote:
> >> All,
> >>
> >> Another question has been asked by Epson internal on the Common
Print
> >> Dialog.
> >>
> >> The issue is on borderless printing.
> >>
> >>   1. Is the follow flow correct?
> >>
> >> In addition, we want to ask a question regarding the borderless
> >> printing
> >> with Common Printing Dialog (CPD).
> >>
> >> We are understanding the borderless printing scenario with CPD as
> >> follows. Is it right?
> >>
> >> 1) Users select the "Borderless" option.
> >>
> >> 2) The "Borderless" option is reported back to the application.
> >>
> >> 3) The application "expands" the image for "Borderless" printing,
and
> >> send the expanded PDF to CPD.
> >>
> >> 4) CPD shows the preview of received PDF.
> >>
> >> 5) If users judge that it is OK, CPD sends the "expanded" PDF to
> >> CUPS.
> >>
> >>   2. If the above flow is correct; then, how does the application
> >>      "expand" the image ?
> >>         1. by how much ?
> >>         2. if the image size does not equal media size, the how is
> >> the
> >>            scale ratio of the expanding decided?
> >>         3. what is the method used by the application to expand the
> >>            image? There are other methods beyond simple scaling.
> >>
> >> Borderless printing, today, is done by the printer driver
> >> independent of
> >> the application.
> >>
> >> I will forward your replies to internal Epson.
> >
> > Not exactly, this is more the workflow of an application-supplied
> > option, where the setting of the option determines how the
application
> > should create the document to be sent to the printer.
> >
> > Borderless is usually simply a boolean option supplied by the
driver.
> > One does not expect that the application needs to re-render the PDF.
> > The
> > driver takes care of appropriate overspray expansion when rendering
> > the PDF.
> >
> > I general, the app can only react to option settings with
re-rendering
> > if the options is an option supplied by the app and not from the
> > printer, driver, or printing system (CUPS).
> >
> >    Till
> > _______________________________________________
> > Printing-architecture mailing list
> > Printing-architecture@lists.linux-foundation.org
> > https://lists.linux-foundation.org/mailman/listinfo/printing-
> architecture

Re: [Printing-architecture] Another Epson Question on the Common Print Dialog

[peter sikking]

Glen wrote:

>>> ............ We are working from the basis that printable area and
> orientation are two obvious parameters that the app must know to
> transform.
>
> This clarification states, "the app must know to transform"; thus, the
> application will, by this clarification, perform the transformation.
> Epson is specifically interested in understanding about the "how does
> the app perform the transform" and

first of all, let's define transformation: this is the act of
"putting it on paper."

how any application gets its data on paper is exactly their
expert domain. for instance: a web browser reflows the web
page content to the printable area of the page, according to
the css of the page.

there are a thousands of applications where we have no idea how
they get it on paper. a DNA database? I have no idea what
would be an appropriate representation on printed media, but
the people who write the app do.

OK, so the app needs at least the printable area (page size - margins)
to do its job. in more advanced cases (eg. centre on page), it will
have to know the page size _and_ the margins.

now, if either of these things happen in the cpd,

- media size change (eg. A4 <-> letter)
- portrait <-> landscape change
- margin change
- borderless printing (hey, nothing but a margin change, really)

the app gets notified of the new printable area, or
new page size + margins, and does the transformation again.

>>>>  2. ..... how does the application "expand" the image ?
>>>>        1. by how much ?
>>>>        2. if the image size does not equal media size, the how is
>>>>           the scale ratio of the expanding decided?
>>>>        3. what is the method used by the application to expand the
>>>>           image? There are other methods beyond simple scaling.
>
> All of these item can change from print-vendor to print-vendor and
> printer-to-printer; so it important the printer vendor to understand
> more of the details.


printer vendors are in complete control of the default paper sizes,
and their margins in the cpd via the ppd. and borderless printing
ain't nothing but a special margin.

so putting it together we can see the chain now:

- the printer (vendor) provides the paper size + borderless margins;
- users choose this paper size + borderless;
- the app transforms its data to the resulting printable area.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture

Re: [Printing-architecture] Another Epson Question on the CommonPrint Dialog

[Petrie, Glen]

Thank you for your reply.  I have forwarded to the interested parties
within Epson.

Glen


> -----Original Message-----
> From: printing-architecture-bounces@lists.linux-foundation.org
> [mailto:printing-architecture-bounces@lists.linux-foundation.org] On
> Behalf Of peter sikking
> Sent: Tuesday, March 30, 2010 2:53 AM
> To: Open Printing
> Subject: Re: [Printing-architecture] Another Epson Question on the
> CommonPrint Dialog
> 
> Glen wrote:
> 
> >>> ............ We are working from the basis that printable area and
> > orientation are two obvious parameters that the app must know to
> > transform.
> >
> > This clarification states, "the app must know to transform"; thus,
the
> > application will, by this clarification, perform the transformation.
> > Epson is specifically interested in understanding about the "how
does
> > the app perform the transform" and
> 
> first of all, let's define transformation: this is the act of
> "putting it on paper."
> 
> how any application gets its data on paper is exactly their
> expert domain. for instance: a web browser reflows the web
> page content to the printable area of the page, according to
> the css of the page.
> 
> there are a thousands of applications where we have no idea how
> they get it on paper. a DNA database? I have no idea what
> would be an appropriate representation on printed media, but
> the people who write the app do.
> 
> OK, so the app needs at least the printable area (page size - margins)
> to do its job. in more advanced cases (eg. centre on page), it will
> have to know the page size _and_ the margins.
> 
> now, if either of these things happen in the cpd,
> 
> - media size change (eg. A4 <-> letter)
> - portrait <-> landscape change
> - margin change
> - borderless printing (hey, nothing but a margin change, really)
> 
> the app gets notified of the new printable area, or
> new page size + margins, and does the transformation again.
> 
> >>>>  2. ..... how does the application "expand" the image ?
> >>>>        1. by how much ?
> >>>>        2. if the image size does not equal media size, the how is
> >>>>           the scale ratio of the expanding decided?
> >>>>        3. what is the method used by the application to expand
the
> >>>>           image? There are other methods beyond simple scaling.
> >
> > All of these item can change from print-vendor to print-vendor and
> > printer-to-printer; so it important the printer vendor to understand
> > more of the details.
> 
> 
> printer vendors are in complete control of the default paper sizes,
> and their margins in the cpd via the ppd. and borderless printing
> ain't nothing but a special margin.
> 
> so putting it together we can see the chain now:
> 
> - the printer (vendor) provides the paper size + borderless margins;
> - users choose this paper size + borderless;
> - the app transforms its data to the resulting printable area.
> 
>      --ps
> 
>          founder + principal interaction architect
>              man + machine interface works
> 
>          http://mmiworks.net/blog : on interaction architecture
> 
> 
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
>
https://lists.linux-foundation.org/mailman/listinfo/printing-architectur
e