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

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

[Petrie, Glen]

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

All,

 

I have not had time until now to look at the latest version of the CPD.

 

I will on comment on the example denoted at the URL:

http://wiki.openusability.org/printing/index.php/Personal_laser_paramete
r_specifications 

 

================================================================

My first "very strong" recommendation, to all those individuals involved
with the CPD, is that they read and understand the OpenPrinting JTAPI
specification, object, attributes and values.    A great deal of
print-domain knowledge, covering embedded-printing to
production-printing; covering job-tickets to IPP; and years of the
various individuals experience, went into creating and defining the
JTAPI content.    One should think of a print dialog as the method for
setting a print job-ticket.

 

 

================================================================

Section 1:

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. 

 

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.

 

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.

 

D: I (nor I suspect most users) understand the meaning of the values for
the "fit" option; specifically, what does "to paper" or "shrink only"
actually mean.  What will they actually do?  These types of tags I lump
into a classification I call "The Buttons, Icons, Controls and Labels of
Confusion (BICLC)".   The term typically used for "fit policy", and
defined in the JTAPI specification, are Clip-to-Page and
(Scale)Fit-to-Page.  Also, there can not be a value of "none".  If the
content does not fit the media-size, something has to be done; either
clip or fit.

 

 E: Another "option" to consider for this section is an advanced button.
The key to printing a specific print-quality (actually, better stated as
a specific print-intent) is to know more about the media being printed
to.   That is, for example using paper; what is brightness, the weight,
the finish (rough, smooth, polished), color, etc.  From these facts, the
printer driver can tune its color-to-ink processing and other factors to
achieve the best output for the user print intent.  Typically, a user
can easily find this information on the cover of the media being used in
the printer.  Note, I have not seen this kind of processing done in
color-management processing software. 

 

================================================================

Section 2:

A: The label "page(s)" is better stated as "page(s) to print".

 

B: Above the current "page(s)" field there should be a button for
printing the "current page".  The current page (number) is provided to
the CPD from the application.   Or the application is requested to
provide only the "current page".

 

C: Above the current "page(s)" field there should be a button for
printing the "selection".  The application is requested to provide only
the "selected content".

 

D: Above the current "page(s)" field there should be a button for
printing the "Clipboard".  The content of the clipboard is printed.

 

E: Any combination of B:/C:/D:/page(s) should be possible.  For example,
I want to print the clipboard, the currently selected content and page 3
of the content.

 

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"

 

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.

 

H: If you allow "pages per side", there should be an option for
"presentation direction".   Again, the OpenPrinting JTAPI specification
provides the values for this option.

 

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.

 

J: The label "both sides", again, is strange.  "sides" would be better
or use the word "duplex".  I believe most people today are used to the
term duplex.

 

K: I believe "page turning" refers to "binding edge" or just "binding",
which has values of top, left, right.   Introducing new terminology to
print is just confusing.

 

L: "page turning" has no "off" state.  When "sides" is set to one, then
"page-turning" is deactivated.  When "sides" is set to two, then the
default for "page turning" has to be some real value (top, left, or
right) but not "off".

 

M: It would be nice to have a "binding type" option (again, see JTAPI
specification for values) and to overlay the binding on the print-page.
For example, a 3-hole punch would print the location of the holes on the
final printed page.  At a minimum, it needs to be in the preview.

 

N: One really nice addition would be to show the media size values
(width and height; both in inch and mm).  Not every one knows the
dimensions of all the various paper sizes.

 

================================================================

Section 3:

 

A: Sorry, but "resolution" is a numerical specification.  The correct
label should be "print quality" or just "quality".    Please look at the
JTAPI Specification.  Also note, that many debates have been done in the
printing community on how to specify quality.  The JTAPI specification
values are those agreed upon by the community.  Please do not invent new
values that have no concrete meaning and, thus, are left open to
interpretation by all entities along the print chain.   

 

B: Sorry, but "color settings" are not related to "text and photo". The
correct label should be "print content" or just "content".  You could
even call this "print intent" or just "intent".  Please look at the
JTAPI Specification.  Also note, that many debates have been done in the
printing community on how to specify content.  The JTAPI specification
values are those agreed upon by the community.  Please do not invent new
values that have no concrete meaning and, thus, are left open to
interpretation by all entities along the print chain.

 

================================================================

Section 4:

 

A:  I would add the following options:

    A1: For any, add orientation.  (many watermarks are placed at 45
degrees)

    A2: For text , add color (unless that will be in the "format text"
option)

    A3: For any, add "placement" label with values like "tile,
scale-to-fit, top, bottom".

 

================================================================

Section 5:

 

A:  Please change the label "which way-up" (not even good English).
The JTAPI variable is "output orientation". Please look at the JTAPI
Specification.

 

B. "output order" option is missing.  Please look at the JTAPI
Specification.

 

C: "output bin" option is missing.  Please look at the JTAPI
Specification.

 

==================

Other

A: There needs to be an option for a "cover sheet"

 

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.

 

C: I really don't think that the preview is providing sufficient
information to the user.  For example, for n-up, the preview should show
the n-up.  For a binding edge, there should be a graphical indication of
which edge.   For two-sided printing, the preview should show a turned
corner (the corner changes depending if the page being displayed is the
front or back page).  And so forth and so forth.

 

Glen

 

 


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

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

[Ira McDonald]

Hi,

I agree with every one of Glen's comments on CPD!
(mark this date on your calendars folks - smile)

In the CPD or *any* other part of Linux Printing System,
the MOST important aspect is to use printing industry
standard terms and options grouping.

All modern printing industry standards derive their
coherence from ISO Document Printing Application
(ISO 10175, early 1990s), including:

CIP4 JDF
- the basis of ALL production printing

IETF IPP
- the basis of CUPS and every modern spooler

OP JTAPI
- the coherent synthesis of JDF and IPP features

PWG Semantic Model
- comprehensive XML schema for all 18 IPP standards
  (used even in Microsoft WS-Print as a primary source)

With the publication of the First Edition of PWG IPP/2.0
(now in PWG Formal Vote until 31 July), a single reference
will cover most IETF and PWG IPP standards.

CUPS/1.4 already implements all of both IPP version 2.0
(workgroup) and version 2.1 (enterprise) conformance
requirements.

In the Second Edition of PWG IPP/2.0 later this year,
we will add IPP version 2.2 (production printing), and
coverage will extend to *every* IETF and PWG IPP
standard.

CPD designers and implementors - PLEASE pay careful
attention to the primary printing industry standards.

End users should NEVER have to waste their time
*understanding* a print dialog.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic@gmail.com
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434



On Thu, Jul 9, 2009 at 12:39 PM, Petrie, Glen<glen.petrie@eitc.epson.com> wrote:
> All,
>
>
>
> I have not had time until now to look at the latest version of the CPD.
>
>
>
> I will on comment on the example denoted at the URL:
>
> http://wiki.openusability.org/printing/index.php/Personal_laser_parameter_specifications
>
>
>
> ================================================================
>
> My first “very strong” recommendation, to all those individuals involved
> with the CPD, is that they read and understand the OpenPrinting JTAPI
> specification, object, attributes and values.    A great deal of
> print-domain knowledge, covering embedded-printing to production-printing;
> covering job-tickets to IPP; and years of the various individuals
> experience, went into creating and defining the JTAPI content.    One should
> think of a print dialog as the method for setting a print job-ticket.
>
>
>
>
>
> ================================================================
>
> Section 1:
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> D: I (nor I suspect most users) understand the meaning of the values for the
> “fit” option; specifically, what does “to paper” or “shrink only” actually
> mean.  What will they actually do?  These types of tags I lump into a
> classification I call “The Buttons, Icons, Controls and Labels of Confusion
> (BICLC)”.   The term typically used for “fit policy”, and defined in the
> JTAPI specification, are Clip-to-Page and (Scale)Fit-to-Page.  Also, there
> can not be a value of “none”.  If the content does not fit the media-size,
> something has to be done; either clip or fit.
>
>
>
>  E: Another “option” to consider for this section is an advanced button.
>  The key to printing a specific print-quality (actually, better stated as a
> specific print-intent) is to know more about the media being printed to.
>   That is, for example using paper; what is brightness, the weight, the
> finish (rough, smooth, polished), color, etc.  From these facts, the printer
> driver can tune its color-to-ink processing and other factors to achieve the
> best output for the user print intent.  Typically, a user can easily find
> this information on the cover of the media being used in the printer.  Note,
> I have not seen this kind of processing done in color-management processing
> software.
>
>
>
> ================================================================
>
> Section 2:
>
> A: The label “page(s)” is better stated as “page(s) to print”.
>
>
>
> B: Above the current “page(s)” field there should be a button for printing
> the “current page”.  The current page (number) is provided to the CPD from
> the application.   Or the application is requested to provide only the
> “current page”.
>
>
>
> C: Above the current “page(s)” field there should be a button for printing
> the “selection”.  The application is requested to provide only the “selected
> content”.
>
>
>
> D: Above the current “page(s)” field there should be a button for printing
> the “Clipboard”.  The content of the clipboard is printed.
>
>
>
> E: Any combination of B:/C:/D:/page(s) should be possible.  For example, I
> want to print the clipboard, the currently selected content and page 3 of
> the content.
>
>
>
> 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”
>
>
>
> 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.
>
>
>
> H: If you allow “pages per side”, there should be an option for
> “presentation direction”.   Again, the OpenPrinting JTAPI specification
> provides the values for this option.
>
>
>
> 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.
>
>
>
> J: The label “both sides”, again, is strange.  “sides” would be better or
> use the word “duplex”.  I believe most people today are used to the term
> duplex.
>
>
>
> K: I believe “page turning” refers to “binding edge” or just “binding”,
> which has values of top, left, right.   Introducing new terminology to print
> is just confusing.
>
>
>
> L: “page turning” has no “off” state.  When “sides” is set to one, then
> “page-turning” is deactivated.  When “sides” is set to two, then the default
> for “page turning” has to be some real value (top, left, or right) but not
> “off”.
>
>
>
> M: It would be nice to have a “binding type” option (again, see JTAPI
> specification for values) and to overlay the binding on the print-page.  For
> example, a 3-hole punch would print the location of the holes on the final
> printed page.  At a minimum, it needs to be in the preview.
>
>
>
> N: One really nice addition would be to show the media size values (width
> and height; both in inch and mm).  Not every one knows the dimensions of all
> the various paper sizes.
>
>
>
> ================================================================
>
> Section 3:
>
>
>
> A: Sorry, but “resolution” is a numerical specification.  The correct label
> should be “print quality” or just “quality”.    Please look at the JTAPI
> Specification.  Also note, that many debates have been done in the printing
> community on how to specify quality.  The JTAPI specification values are
> those agreed upon by the community.  Please do not invent new values that
> have no concrete meaning and, thus, are left open to interpretation by all
> entities along the print chain.
>
>
>
> B: Sorry, but “color settings” are not related to “text and photo”. The
> correct label should be “print content” or just “content”.  You could even
> call this “print intent” or just “intent”.  Please look at the JTAPI
> Specification.  Also note, that many debates have been done in the printing
> community on how to specify content.  The JTAPI specification values are
> those agreed upon by the community.  Please do not invent new values that
> have no concrete meaning and, thus, are left open to interpretation by all
> entities along the print chain.
>
>
>
> ================================================================
>
> Section 4:
>
>
>
> A:  I would add the following options:
>
>     A1: For any, add orientation.  (many watermarks are placed at 45
> degrees)
>
>     A2: For text , add color (unless that will be in the “format text”
> option)
>
>     A3: For any, add “placement” label with values like “tile, scale-to-fit,
> top, bottom”.
>
>
>
> ================================================================
>
> Section 5:
>
>
>
> A:  Please change the label “which way-up” (not even good English).   The
> JTAPI variable is “output orientation”. Please look at the JTAPI
> Specification.
>
>
>
> B. “output order” option is missing.  Please look at the JTAPI
> Specification.
>
>
>
> C: “output bin” option is missing.  Please look at the JTAPI Specification.
>
>
>
> ==================
>
> Other
>
> A: There needs to be an option for a “cover sheet”
>
>
>
> 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.
>
>
>
> C: I really don’t think that the preview is providing sufficient information
> to the user.  For example, for n-up, the preview should show the n-up.  For
> a binding edge, there should be a graphical indication of which edge.   For
> two-sided printing, the preview should show a turned corner (the corner
> changes depending if the page being displayed is the front or back page).
>  And so forth and so forth.
>
>
>
> Glen
>
>
>
>
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
>
>

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

[Till Kamppeter]

Petrie, Glen wrote:
> Section 1:
> 
> 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.

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

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.

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

>  
> 
> D: I (nor I suspect most users) understand the meaning of the values for 
> the “fit” option; specifically, what does “to paper” or “shrink only” 
> actually mean.  What will they actually do?  These types of tags I lump 
> into a classification I call “The Buttons, Icons, Controls and Labels of 
> Confusion (BICLC)”.   The term typically used for “fit policy”, and 
> defined in the JTAPI specification, are Clip-to-Page and 
> (Scale)Fit-to-Page.  Also, there can not be a value of “none”.  If the 
> content does not fit the media-size, something has to be done; either 
> clip or fit.
> 

Once we should use good names, or the common standard names (as Ira 
suggests in another posting to this thread) perhaps accompanied with icons.

>  
> 
>  E: Another “option” to consider for this section is an advanced button. 
>  The key to printing a specific print-quality (actually, better stated 
> as a specific print-intent) is to know more about the media being 
> printed to.   That is, for example using paper; what is brightness, the 
> weight, the finish (rough, smooth, polished), color, etc.  From these 
> facts, the printer driver can tune its color-to-ink processing and other 
> factors to achieve the best output for the user print intent.  
> Typically, a user can easily find this information on the cover of the 
> media being used in the printer.  Note, I have not seen this kind of 
> processing done in color-management processing software.
> 
>  
> 
> ================================================================
> 
> Section 2:
> 
> A: The label “page(s)” is better stated as “page(s) to print”.
> 
>  
> 
> B: Above the current “page(s)” field there should be a button for 
> printing the “current page”.  The current page (number) is provided to 
> the CPD from the application.   Or the application is requested to 
> provide only the “current page”.
> 
>  
> 
> C: Above the current “page(s)” field there should be a button for 
> printing the “selection”.  The application is requested to provide only 
> the “selected content”.
> 
>  
> 
> D: Above the current “page(s)” field there should be a button for 
> printing the “Clipboard”.  The content of the clipboard is printed.
> 
>  
> 
> E: Any combination of B:/C:/D:/page(s) should be possible.  For example, 
> I want to print the clipboard, the currently selected content and page 3 
> of the content.
> 

Printing the clipboard and pages 1-3, and you get nicely a job 
containing data from 2 apps.

>  
> 
> 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"?

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

>  
> 
> H: If you allow “pages per side”, there should be an option for 
> “presentation direction”.   Again, the OpenPrinting JTAPI specification 
> provides the values for this option.
>

CUPS has this option. The dialog should support it.

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

>  
> 
> J: The label “both sides”, again, is strange.  “sides” would be better 
> or use the word “duplex”.  I believe most people today are used to the 
> term duplex.
> 
>  
> 
> K: I believe “page turning” refers to “binding edge” or just “binding”, 
> which has values of top, left, right.   Introducing new terminology to 
> print is just confusing.
> 
>  
> 
> L: “page turning” has no “off” state.  When “sides” is set to one, then 
> “page-turning” is deactivated.  When “sides” is set to two, then the 
> default for “page turning” has to be some real value (top, left, or 
> right) but not “off”.
> 
>  
> 
> M: It would be nice to have a “binding type” option (again, see JTAPI 
> specification for values) and to overlay the binding on the print-page. 
>  For example, a 3-hole punch would print the location of the holes on 
> the final printed page.  At a minimum, it needs to be in the preview.
> 
>  
> 
> N: One really nice addition would be to show the media size values 
> (width and height; both in inch and mm).  Not every one knows the 
> dimensions of all the various paper sizes.
> 

This would be a really good addition.

>  
> 
> ================================================================
> 
> Section 3:
> 
>  
> 
> A: Sorry, but “resolution” is a numerical specification.  The correct 
> label should be “print quality” or just “quality”.    Please look at the 
> JTAPI Specification.  Also note, that many debates have been done in the 
> printing community on how to specify quality.  The JTAPI specification 
> values are those agreed upon by the community.  Please do not invent new 
> values that have no concrete meaning and, thus, are left open to 
> interpretation by all entities along the print chain.   
> 
>  
> 
> B: Sorry, but “color settings” are not related to “text and photo”. The 
> correct label should be “print content” or just “content”.  You could 
> even call this “print intent” or just “intent”.  Please look at the 
> JTAPI Specification.  Also note, that many debates have been done in the 
> printing community on how to specify content.  The JTAPI specification 
> values are those agreed upon by the community.  Please do not invent new 
> values that have no concrete meaning and, thus, are left open to 
> interpretation by all entities along the print chain.
> 
>  
> 
> ================================================================
> 
> Section 4:
> 
>  
> 
> A:  I would add the following options:
> 
>     A1: For any, add orientation.  (many watermarks are placed at 45 
> degrees)
> 
>     A2: For text , add color (unless that will be in the “format text” 
> option)
> 
>     A3: For any, add “placement” label with values like “tile, 
> scale-to-fit, top, bottom”.
> 
>  
> 
> ================================================================
> 
> Section 5:
> 
>  
> 
> A:  Please change the label “which way-up” (not even good English). 
>   The JTAPI variable is “output orientation”. Please look at the JTAPI 
> Specification.
> 
>  
> 
> B. “output order” option is missing.  Please look at the JTAPI 
> Specification.
> 
>  
> 
> C: “output bin” option is missing.  Please look at the JTAPI Specification.
> 
>  
> 
> ==================
> 
> Other
> 
> A: There needs to be an option for a “cover sheet”
>
>  
> 
> 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.


>  
> 
> C: I really don’t think that the preview is providing sufficient 
> information to the user.  For example, for n-up, the preview should show 
> the n-up.  For a binding edge, there should be a graphical indication of 
> which edge.   For two-sided printing, the preview should show a turned 
> corner (the corner changes depending if the page being displayed is the 
> front or back page).  And so forth and so forth.

I think so, too. Peter also suggest to show duplex and binding by 
animating the preview appropriately when turning pages.

    Till

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

[Petrie, Glen]

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

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

[Hal V. Engel]

On Thursday 09 July 2009 09:39:14 am Petrie, Glen wrote:
>  E: Another "option" to consider for this section is an advanced button.
> The key to printing a specific print-quality (actually, better stated as
> a specific print-intent) is to know more about the media being printed
> to.   That is, for example using paper; what is brightness, the weight,
> the finish (rough, smooth, polished), color, etc.  From these facts, the
> printer driver can tune its color-to-ink processing and other factors to
> achieve the best output for the user print intent.  Typically, a user
> can easily find this information on the cover of the media being used in
> the printer.  Note, I have not seen this kind of processing done in
> color-management processing software.

You are incorrect.  This is exactly what should happen in a proper color 
managed work flow and this is exactly what color management is for.  Proper 
profiles are media (as well as device and device settings) specific.  They are 
created by measuring the media white point (you called this color) and 
brightness (these are actually the same thing) as well as the resulting 
absolute (meaning CIE XYZ or CIE L*a*b*) colors/tones of various amounts and 
combinations of inks/colorants on that media (we usually measure 1,000 to 
3,000 color patches when creating a printer profile).  

The correct use of a printer ICC profile should optimize how the 
inks/colorants are put down on the paper to match the paper white point to the 
grays/blacks created by the inks/colorants (I have assumed relative 
colorimentric intent) as well as to optimize the gamut/dynamic range of the 
resulting prints without over inking.

I am not sure if I have ever seen a paper package that had the media white 
point listed at least not in a form that would have colorimetric meaning.  
Although these may exist I have NEVER seen a printer driver that had the 
ability to accept this data (paper white point) as user input other than by 
using an ICC profile.  I just looked at the box and the product sheet from the 
box of the Ilford paper that I use and it did NOT list the paper white point 
or brightness of the paper.  If it did I would expect to find something like:

White point: XYZ: 84.550000 88.240000 74.960000, D50 Lab: 95.261904 -0.999796 
-1.888369

(The above is the measured white point of a sample of Ilford Galerie Smooth 
Gloss paper - note the first Lab value is also the "brightness" - actually 
Luminosity - of the paper).

Isn't the media type setting what is used to denote the general 
characteristics of the media such as finish and weight.... 

Hal 

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

[Till Kamppeter]

Petrie, Glen wrote:
>>> 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.
>

In OpenOffice.org Writer, Scribus, ... you produce a document where each 
page has its well-determined size (set with "Format" -> "Page"). Most 
documents have the same size for all pages, but some can have pages of 
different sizes. For example a book can contain a fold-out page with a 
map. So the app sends the document in PDF format to the CPD. The PDF 
contains the paghe size information for each page. If we want to get all 
pages out in the sizes chosen when creating the document, the dialog 
should not impose any page size to the job. Then we would use the choice 
"Document's Media Size" in the PageSize option of the dialog. Then the 
printer will automatically pull A4 for most of the pages and A3 for the 
fold-outs. If our printer has only A4 paper, you would choose the page 
size "A4" in the dialog and "fit to page". This makes the fold-outs 
being shrinked to fit into A4 pages (and rotated by 90 degrees for the 
best fit).

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

This is the problem: A photo does not have a well-determined absolute 
size. So a size comes into the picture only if the user wants to print 
the photo. Therefore I think here is best to set the size in the 
printing dialog. Additional parameters could also get set in the 
application-specific options.

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

Here we would have layouted pages again (like the documents of 
OpenOffice.org Writer), so the PageSize option should have "Document's 
Media Size" added and selected by default.

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

Yes, let us leave out "Poster" for now and let it really be a project 
for GSoC 2010.

    Till

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

[Petrie, Glen]

I am not going to argue with you; you simply missed the point.

> -----Original Message-----
> From: printing-architecture-bounces@lists.linux-foundation.org
> [mailto:printing-architecture-bounces@lists.linux-foundation.org] On
> Behalf Of Hal V. Engel
> Sent: Friday, July 10, 2009 4:01 PM
> To: printing-architecture@lists.linux-foundation.org
> Subject: Re: [Printing-architecture] Questions, Concern, Disscusion on
CPD
> 
> On Thursday 09 July 2009 09:39:14 am Petrie, Glen wrote:
> >  E: Another "option" to consider for this section is an advanced
button.
> > The key to printing a specific print-quality (actually, better
stated as
> > a specific print-intent) is to know more about the media being
printed
> > to.   That is, for example using paper; what is brightness, the
weight,
> > the finish (rough, smooth, polished), color, etc.  From these facts,
the
> > printer driver can tune its color-to-ink processing and other
factors to
> > achieve the best output for the user print intent.  Typically, a
user
> > can easily find this information on the cover of the media being
used in
> > the printer.  Note, I have not seen this kind of processing done in
> > color-management processing software.
> 
> You are incorrect.  This is exactly what should happen in a proper
color
> managed work flow and this is exactly what color management is for.
> Proper
> profiles are media (as well as device and device settings) specific.
They
> are
> created by measuring the media white point (you called this color) and
> brightness (these are actually the same thing) as well as the
resulting
> absolute (meaning CIE XYZ or CIE L*a*b*) colors/tones of various
amounts
> and
> combinations of inks/colorants on that media (we usually measure 1,000
to
> 3,000 color patches when creating a printer profile).
> 
> The correct use of a printer ICC profile should optimize how the
> inks/colorants are put down on the paper to match the paper white
point to
> the
> grays/blacks created by the inks/colorants (I have assumed relative
> colorimentric intent) as well as to optimize the gamut/dynamic range
of
> the
> resulting prints without over inking.
> 
> I am not sure if I have ever seen a paper package that had the media
white
> point listed at least not in a form that would have colorimetric
meaning.
> Although these may exist I have NEVER seen a printer driver that had
the
> ability to accept this data (paper white point) as user input other
than
> by
> using an ICC profile.  I just looked at the box and the product sheet
from
> the
> box of the Ilford paper that I use and it did NOT list the paper white
> point
> or brightness of the paper.  If it did I would expect to find
something
> like:
> 
> White point: XYZ: 84.550000 88.240000 74.960000, D50 Lab: 95.261904 -
> 0.999796
> -1.888369
> 
> (The above is the measured white point of a sample of Ilford Galerie
> Smooth
> Gloss paper - note the first Lab value is also the "brightness" -
actually
> Luminosity - of the paper).
> 
> Isn't the media type setting what is used to denote the general
> characteristics of the media such as finish and weight....
> 
> Hal
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
>
https://lists.linux-foundation.org/mailman/listinfo/printing-architectur
e

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

[Hal V. Engel]

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

On Monday 13 July 2009 06:25:45 am Petrie, Glen wrote:
> I am not going to argue with you; you simply missed the point.

I don't think I missed the point.  Perhaps I didn't communicate my points 
effectively and if so I apologize.  Let me try again.  

In a round about way Glen asked how media characteristics and color management 
were related and if color management was (or could be) used to tailor how 
colorants were applied to the media based on media characteristics.  

Referring how "color-to-ink processing" could/should be tailored to a specific 
media Glen wrote: 

"Note, I have not seen this kind of processing done in color-management 
processing software." 

I pointed out that this is in fact exactly what color management of printers 
does and is designed to do.  And that using profiles and color management was 
very specific about tailoring the colorant output to the media characteristics 
(including the specific device and the device settings) since it did this 
based on detailed media/device/device settings specific measurements.  How 
could it possibly be more tailored then that?

Looking at the CUPS PPD extension documentation about the cupsICCProfile 
keyword CUPS uses various bits of information including the media type and 
resolution to select which output profile to use for a particular print job.  
Unfortunately CUPS restricts this to three values that are used for this 
selection process which is probably too restrictive to be as flexible as we 
would like in actual practice.  But the current CUPS design, with in these 
limits, does exactly the thing that Glen has "not seen done in color-
management processing software" by selecting different profiles, which means 
different "color-to-ink processing", based on printer queue, color model, 
media type and resolution settings.  To be clear my point is that using the 
existing CUPS design users can set up color management in CUPS (once color 
management aware *toraster filters are available) to do exactly the type of 
processing Glen was talking about.  CUPS, in fact, does this on OS/X systems 
using the OS/X proprietary color management aware *toraster filters and has 
for a long time so we know it can work. 

I also tried to point out some incorrect assumptions and terminology.  I did 
this to try to clarify the subject since fuzzy terminology and incorrect 
assumptions make for bad design.   I did not intend to be confrontational and 
if I appeared to be let me apologize.    

The incorrect assumptions and fuzzy terminology include:

1. Users could "easily find" paper "brightness" and "color" (media white 
point?) "information on the cover of the media".  This is at best true in only 
a limited number of cases and then only for "brightness" information.   I have 
never seen a paper package or product sheet with  "color" information of any 
kind. 

In fairness to Genn, unlike most paper manufacturers, Epson papers do have 
published ISO brightness specifications so I think the disagreement here is 
over how common this is and how useful this information is.

2. There is an apparent assumption that this information is colorimetricaly 
meaningful.  Some papers come with a stated brightness number but I have 
measured some of these papers with a spectrophotometer and the stated 
"brightness" does not appear to correspond to the measured colorimentric 
values.  The stated "brightness" is usually significantly higher than the 
measured L* value probably because of FWA enhancers. I found a research paper 
about this on-line and these "brightness" values are in fact not colorimentric 
and in it's Conclusion section it stated:

"Brightness is not a parameter related to color of substrate; actually it is 
not even connected to its appearance. It is a number related to the color of 
substrate viewed under a blue stained glass. Brightness is related to 
reflectance values in a narrow region of the total visible spectra around 460 
nm. Due to this limitation, values of brightness cannot be connected or 
correlated to (white) appearance of pulp or manufactured paper, not even in 
those cases where no FWAs are applied."*  

* See www.axiphos.com/BrightnessReview.pdf

So these "brightness" numbers are in fact a measurement of the blue spectrum 
(457 nm +- 44nm) reflectivity of the paper plus blue region florescence caused 
by UV interaction with the FWA.

3. The assumption that the "brightness" and "color" information for these 
media is of some use to the driver.  

Even if colorimentricly meaningful white point and brightness information was 
available on the media box or product specification sheet how would this be 
used in a non-color managed work flow?   

Would there be a place for users to enter this information so the driver would 
know about it?  

Are there any existing drivers that make use of this information on any 
platform?  

How would the driver use this information since it does not have access to 
characterization data about how it's colorants interact with the media unless 
there is an ICC profile available?   IE. unless detailed measurements had been 
done.

If there is an ICC profile the media white point and "brightness" information 
is already part of the profile and there is no reason for users to get this 
information from the box even if this were available. 

4. Use of the term "color" when Glen probably should have used a term like 
"media white point" or "white point".  For color people the term color is not 
very useful or even meaningful but white point has a very specific meaning.  
Using the term color is like calling something a printer.  It tells us that 
the device is a printer but it does not tell us anything specific about the 
device where as calling something an Epson R2400 tells us a lot about the 
device.

The problem Glen was describing in item E: is exactly the problem that color 
management was designed to solve.  Why not use a tool set that is designed to 
solve that problem rather than reinventing the wheel if the existing tool set 
is not badly broken?  Admittedly there are currently issues with how this is 
handled by CUPS on non-OS/X systems because of the lack of open source CM 
aware *toraster filters.  But this issue is being worked on and will 
eventually be resolved.  

Hal

>
> > -----Original Message-----
> > From: printing-architecture-bounces@lists.linux-foundation.org
> > [mailto:printing-architecture-bounces@lists.linux-foundation.org] On
> > Behalf Of Hal V. Engel
> > Sent: Friday, July 10, 2009 4:01 PM
> > To: printing-architecture@lists.linux-foundation.org
> > Subject: Re: [Printing-architecture] Questions, Concern, Disscusion on
>
> CPD
>
> > On Thursday 09 July 2009 09:39:14 am Petrie, Glen wrote:
> > >  E: Another "option" to consider for this section is an advanced
>
> button.
>
> > > The key to printing a specific print-quality (actually, better
>
> stated as
>
> > > a specific print-intent) is to know more about the media being
>
> printed
>
> > > to.   That is, for example using paper; what is brightness, the
>
> weight,
>
> > > the finish (rough, smooth, polished), color, etc.  From these facts,
>
> the
>
> > > printer driver can tune its color-to-ink processing and other
>
> factors to
>
> > > achieve the best output for the user print intent.  Typically, a
>
> user
>
> > > can easily find this information on the cover of the media being
>
> used in
>
> > > the printer.  Note, I have not seen this kind of processing done in
> > > color-management processing software.
> >
> > You are incorrect.  This is exactly what should happen in a proper
>
> color
>
> > managed work flow and this is exactly what color management is for.
> > Proper
> > profiles are media (as well as device and device settings) specific.
>
> They
>
> > are
> > created by measuring the media white point (you called this color) and
> > brightness (these are actually the same thing) as well as the
>
> resulting
>
> > absolute (meaning CIE XYZ or CIE L*a*b*) colors/tones of various
>
> amounts
>
> > and
> > combinations of inks/colorants on that media (we usually measure 1,000
>
> to
>
> > 3,000 color patches when creating a printer profile).
> >
> > The correct use of a printer ICC profile should optimize how the
> > inks/colorants are put down on the paper to match the paper white
>
> point to
>
> > the
> > grays/blacks created by the inks/colorants (I have assumed relative
> > colorimentric intent) as well as to optimize the gamut/dynamic range
>
> of
>
> > the
> > resulting prints without over inking.
> >
> > I am not sure if I have ever seen a paper package that had the media
>
> white
>
> > point listed at least not in a form that would have colorimetric
>
> meaning.
>
> > Although these may exist I have NEVER seen a printer driver that had
>
> the
>
> > ability to accept this data (paper white point) as user input other
>
> than
>
> > by
> > using an ICC profile.  I just looked at the box and the product sheet
>
> from
>
> > the
> > box of the Ilford paper that I use and it did NOT list the paper white
> > point
> > or brightness of the paper.  If it did I would expect to find
>
> something
>
> > like:
> >
> > White point: XYZ: 84.550000 88.240000 74.960000, D50 Lab: 95.261904 -
> > 0.999796
> > -1.888369
> >
> > (The above is the measured white point of a sample of Ilford Galerie
> > Smooth
> > Gloss paper - note the first Lab value is also the "brightness" -
>
> actually
>
> > Luminosity - of the paper).
> >
> > Isn't the media type setting what is used to denote the general
> > characteristics of the media such as finish and weight....
> >
> > Hal
> > _______________________________________________
> > Printing-architecture mailing list
> > Printing-architecture@lists.linux-foundation.org
>
> https://lists.linux-foundation.org/mailman/listinfo/printing-architectur
> e


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