[Printing-architecture] Outline of OpenPrinting Architecture Team Next Steps

[Printing-architecture] Outline of OpenPrinting Architecture Team Next Steps

[Petrie, Glen]

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

From the Steering Committee / Architecture Meeting of November 3, 2008,
Till Kamppeter suggested the following items for next steps for the
Architecture Team to address.  By far, the Common Print Dialog was
highest on the list.  The order for the remaining activities is what I
remember but someone who at the meeting please provide correction where
needed.

 

I volunteered to provide more content to each below as a start to
defining each of the activities below.  These are my understanding and
they will be corrected, enhanced and modified by those who are more
directly involved with each. 

 

=====

    o Finish of the Common Printing Dialog

The CPD currently consist of three major components; namely, the GUI
Dialog, the API and PPD extensions.

The CPD GUI Dialog:

Background:

The format/layout of the CPD Dialog is being developed by the
OpenUsability Group.  

Activity: (by the OpenPrinting Architecture Team)

1. Provide coherence of the GUI with the API and the PPD extensions
along with coherence with existing printing conventions.

2. Validate scalability of the GUI from embedded to production printing
environment.

3. If not currently available; provide a prototype for each environment.

 

The CPD API:

Background:

The API was began as GSoC and continues by the student.

Activity: (by the OpenPrinting Architecture Team)

1. Review of the existing API

2. Provide suggestion/recommendation of additions, modification,
enhancements of the API

3. Create a formal OpenPrinting Document/Specification of the API

4. If not currently available; provide a prototype.

 

The CPD PPD extensions:

Background:

The API was began as GSoC and continues by the student.

Activity: (by the OpenPrinting Architecture Team)

1. Align the basic printing options/attributes/values with the existing
JTAPI specification. 

2. Create a formal OpenPrinting Document/Specification for the CPD PPD
extensions.

3. Create several - 10+ example PPD files illustrating ALL of the CPD
PPD extensions.

4. If not currently available; provide a prototype using the CPD
enhanced PPD file(s).

 

    o Creation of a key to sign downloadable printer driver packages

I believe that Till Kamppeter should address this.  Till, how can the
Architecture Team help?

 

    o Study Out of Box User Experience

Printing for Linux has grown a lot over the last several years but is
still considered to being done/setup by "some one in the know".

Background:

This activity is an evaluation or a ???? of the User experience of
literally taking a printer out-of-the-box and what it take to create
their first print page.

Activity: (by the OpenPrinting Architecture Team)

I am not quite sure what the Architecture Team can do to help this
activity directly.  Actually, a central entity or the printer vendors
need to conduct these tests.  The Architecture Team could define what
testing environment and needs to done, and, more importantly, what
feedback information is needed by the testing entity so that the Linux
printing experience can be improved/fixed.

 

    o Investigate Requirements for next LSB

The LSB adds content by defacto usage; that is, instead of creating a
specification, followed by an implementation; the LSB requires that
content have defacto usage in LSB OS distro's. 

Background:

To date printing content have been added in an adhoc approach with no
focused direction or goal.

Activity: (by the OpenPrinting Architecture Team)

1. Identify printing content (without regards to time of inclusion in
the LSB) that should be prompted by OpenPrinting.

2. Prioritize ordering and induction of printing content in the LSB.

3. Develop a time line for induction of printing content in the LSB.

4. Outline plans (how/what/time-line) to incorporate printing content
into individual OS distro's.

5. Document defacto usage to the LSB team so that the specific printing
content becomes part of the LSB

    o Embedding of printing metadata/job ticket in PDF for PDF printing

PDF document format is (becoming) the document exchange format of choice
today. The format contains detailed data that allows it be displayed by
any display entity independent of OS.  PDF already supports JDF job
tickets.......................

 

Till you elaborate on what you want to do here.  Do you want to put the
CPD "print-intent" content in a PDF file?

 

    o Color Management on the OS/Printing System level

This is complex issues to be performed by knowledgeable personnel.

Background:

I am assuming a generic background here; much the same as was the
situation with PPD files. Thus, the issues is managing ICC profiles or
the equivalent.

Activity: (by the OpenPrinting Architecture Team)

1. If Color Management content extends beyond ICC profile; the Color
Management content needs to be defined.

2. Using the same approach as was used for PPD, a directory location and
structure would be defined for the Color Management content.

 

 


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

Re: [Printing-architecture] Outline of OpenPrinting Architecture Team Next Steps

[Till Kamppeter]

Petrie, Glen wrote:
>  
> 
> The CPD PPD extensions:
> 
> Background:
> 
> The API was began as GSoC and continues by the student.

The PPD extensions were not done by a GSoC student. I have created them.

> 
> Activity: (by the OpenPrinting Architecture Team)
> 
> 1. Align the basic printing options/attributes/values with the existing 
> JTAPI specification.
> 

Appropriate part will be added to the PPD extensions.

> 2. Create a formal OpenPrinting Document/Specification for the CPD PPD 
> extensions.
> 
> 3. Create several – 10+ example PPD files illustrating ALL of the CPD 
> PPD extensions.
> 

Good idea.

> 4. If not currently available; provide a prototype using the CPD 
> enhanced PPD file(s).
> 
>  
> 
>     o Creation of a key to sign downloadable printer driver packages
> 
> I believe that Till Kamppeter should address this.  Till, how can the 
> Architecture Team help?
>

I have renamed all downloadable driver packages on the server now so 
that they do not conflict with files in distros, now these drivers can 
coexist with the same driver provided by a distro package.

I have posted this to the discussion on the lsb-discuss and webdevel 
lists and reminded the participants that we have to finish the key issue.

>  
> 
>     o Study Out of Box User Experience
> 
> Printing for Linux has grown a lot over the last several years but is 
> still considered to being done/setup by “some one in the know”.
> 
> Background:
> 
> This activity is an evaluation or a ???? of the User experience of 
> literally taking a printer out-of-the-box and what it take to create 
> their first print page.
> 

Yes, we want to find out whether the user can really easily set up a 
printer and print on it from all standard applications.

> Activity: (by the OpenPrinting Architecture Team)
> 
> I am not quite sure what the Architecture Team can do to help this 
> activity directly.  Actually, a central entity or the printer vendors 
> need to conduct these tests.  The Architecture Team could define what 
> testing environment and needs to done, and, more importantly, what 
> feedback information is needed by the testing entity so that the Linux 
> printing experience can be improved/fixed.
> 

There must be tests on the printers, here we nned to work together with 
printer vendors.

There must be also tests on apps, whether they show the correct printing 
dialog, show all print queues, all options, whether they obey page size 
(and other default settings) of the user and of the system, whether they 
output correct and clean PostScript and whether (most important) they 
are switchi9ng from PostScript to PDF as output data format. If this is 
not the case we should report bugs, like these ones:

https://bugzilla.mozilla.org/show_bug.cgi?id=459748
https://bugzilla.mozilla.org/show_bug.cgi?id=462872

>     o Embedding of printing metadata/job ticket in PDF for PDF printing
> 
> PDF document format is (becoming) the document exchange format of choice 
> today. The format contains detailed data that allows it be displayed by 
> any display entity independent of OS.  PDF already supports JDF job 
> tickets…………………..
> 
>  
> 
> Till you elaborate on what you want to do here.  Do you want to put the 
> CPD “print-intent” content in a PDF file?
>

I thought about the embedding of JDF job tickets so that printing also 
works through channels where option settings and other metadata cannot 
be transmitted with things like IPP attributes, for example also SMB or 
so. For this we would need to implement JTAPI.

>  
> 
>     o Color Management on the OS/Printing System level
> 
> This is complex issues to be performed by knowledgeable personnel.
> 
> Background:
> 
> I am assuming a generic background here; much the same as was the 
> situation with PPD files. Thus, the issues is managing ICC profiles or 
> the equivalent.
> 
> Activity: (by the OpenPrinting Architecture Team)
> 
> 1. If Color Management content extends beyond ICC profile; the Color 
> Management content needs to be defined.
> 
> 2. Using the same approach as was used for PPD, a directory location and 
> structure would be defined for the Color Management content.
> 

Yes, we need a fixed place for the CM content.

For the workflow we need to discuss with the CM experts.

    Till