[Printing-architecture] Questions, Concern, Disscusion on CPD

Petrie, Glen glen.petrie at eitc.epson.com
Fri Jul 10 15:26:09 PDT 2009



<...snip...>

> >
> > A: Media Type (shown in Section 5) needs to be in this section since
> > media-type and media-size (not paper-size) are connected.  For
example,
> > I want to print on a CD; it is not paper and the size is defined by
> > media-type.
> >
> 
> You're right, should be "Media Size", "Media Type", ... But I do not
> really know whether this can be fioxed in the CPD. The UI strings of
the
> options usually come from the PPD file and not from the printing
dialog.
> But to make the interface more "common" one could think about certain
> standard options and choices where the PPD's wording gets overridden
and
> the CPD provides the wording, with the big bunch of translations which
> you are used to in KDE and GNOME.
> 

[gwp] I hope a solution can be achieved; I will need more time to think
about it.  But, from the User's point-of-view (the one that matters), it
will be awkward to see what is thought of very related parameters in two
different sections.


> >
> >
> > B: The "paper size" has no "default setting"; the application sends
the
> > CPD the size of the media.  Setting the media-size is initially done
in
> > the application in the "Page Setup".  The CPD is not doing setup
> > functions.  The user may override the media-size; even the
orientation
> > received from the application in the CPD; in which case the "fit
policy"
> > would be invoked.
> >
> 
> Probably we should add a choice "Document's Media Size" to the "Media
> Size" (machine-readable name "PageSize") option. This choice should be
> selected by default and then each page is sent with the size set by
the
> application and a printer containing all needed paper sizes switches
the
> trays automatically to have each page printed on the correct paper
size.
> If one of the concrete mediua sizes (like "A4") is chosen, the pages
are
>   all converted to print on the requested size, where the user can
> select with another option whether to scale or to crop.
> 

[gwp] I do not quite understand what you stated.  Are we agreed the
application will send the media-size information to the CPD; if not,
that has to be the first item to address.  If the application sends the
"PageSize" to the CPD; then, the CPD changes the media-size choice to
the size sent by the application.  Now, if the user wants a different
size, the use the fit-option to tell how to fit it.

> If the document of an application does not have a well-defined paper
> size, like the images in a photo viewer or the text files in a plain
> text editor, the "Media Size" option should not have the "Document's
> Media Size" choice and the current CUPS default setting for the page
> size should be selected as default. The image or text gets fit into
that
> page size by application-provided options, for example fit into page,
> fixed size, n photos per sheet, poster of NxM inches, going over
several
> sheets to stick together.
> 

[gwp] I would like to encourage a single architecture/ design/
implementation approach.  That is, even the photo-application can send a
media-size to the CPD.  Now the new question is where does the photo-app
get the media-size info; they pick on based on location (A4 or Letter);
from CUPS; from the User-Print-Profile concept I copied you privately
on.

[gwp] I have noted that most photo-apps that provide n photo per sheet
will request the user the media-size so that the photo-size can do the
layout correctly.  

[gwp] Can we avoid "poster" in the first version of the CPD?  Use Alex's
suggestion and find an application to do the function right now.
Example, spread-sheet app split on cells; photo-app may not care,
drawing-app do not want to split on a "line" or "split a thick";
text-app have less options.  So if you just "cut up the large page into
smaller print pages", the output could be unacceptable.  A very good
GSoC project for next year.

> >
> > C: The word "borders" I believe refers to "margins".  It is not the
> > function of the CPD to set the margins.  The ability to set margin
to a
> > specific value or "borderless" is done within the application in the
> > "Page Setup".  The "Page Setup" within the application would have
> > retrieved the currently selected printer's capabilities to know the
> > printer's min/max margin and if the printer supports "borderless"
> printing.
> >
> 
> This depends again on the application. "Layouting" apps like
> OpenOffice.org Writer or Scribus should do the media size and margins
in
> the page setup ("Format"-> "Page" or so). Photo viewers, plain text
> editors or browsers  better do this in the printing dialog.
> 

[gwp] Again, I would like to encourage a single architecture/ design/
implementation approach.  Even if that means the application just sends
some media-size.  The user can over-ride in the dialog and now there is
a consistent use / implementation model.

<... snip ...>

> >
> >
> > ================================================================
> >
> > Section 2:
> >

<... snip ...>

> >
> > F: The label "pages per side" will be confused with "sides per
page".
> >   A more generally accept terms are "Print Layout
> >  or "Page Layout" or just "Layout" and the options are 1 page, 2,
pages,
> > 4 pages, etc.  Default is "1 page"
> >
> 
> What about "Pages per sheet side"?

[gwp] Ok???, I do not think most user will understand n-up, so we need
something.

> >
> > G: For the values of "pages per side", the typical values are 1, 2,
3,
> > 4, 6, 8, 9. Beyond 9, it is really hard to read the output. Printing
25
> > pages per side seem silly.  If the intent is to print "thumbnails"
then
> > that should be a value.
> >
> 
> N-up is implemented by the pstops and pdftopdf CUPS filters, we can
only
> offer the choices here which the filters can do. And there I think the
> max was 16.
> 

[gwp] ok.


<... snip ...>

> >
> > I: I never heard of the option called "poster" in a print dialog and
if
> > I understand it correctly, it is how to print a large content-page
on
> > many printed-pages.  This is not an option for the CPD.  Again, this
a
> > setup option and should be controlled by the application.   This is
not
> > a simple process (I know from experience).   For example, does each
page
> > have a set amount of content overlay for piecing the pages together
or
> > are alignment-marks used.  For non-borderless media, are cut-line
> > printed.   So forth, and so forth.
> >
> 
> This one would be useful, but we would need to add this functionality
to
> the pdftopdf CUPS filter.
> 

[gwp] Again, can we avoid "poster" in the first version of the CPD?  


<... snip ...>

> >
> >
> > ================================================================
> >
> > Section 3:
> >
> >
> >


<... snip ...>

> >
> >
> >
> > ================================================================
> >
> > Section 4:
> >

<... snip ...>

> >
> >
> >
> > ================================================================
> >
> > Section 5:
> >

<... snip ...>

> >
> >
> >
> > ==================
> >
> > Other
> >


<... snip ...>

> >
> >
> > B: A new issue arising in the print world is that of security.  For
> > example, one the simplest security features for networked printers
is
> > "print only when at printer".  The user must enter a code to start
the
> > print process.  This needs to be set in the CPD.   I know this out
of
> > scope right now but since we are in the design/conception phase of
this
> > project; security needs to be addressed.
> >
> 
> The PPDs contain these options. With the custom-option-aware CPD, this
> functionality will get accessible.
> 
> 

[gwp] great.

<... snip ...>



More information about the Printing-architecture mailing list