Re: [Printing-architecture] Coding the Common Printing Dialog an dits interface - PPD and Foomatic extensions

Re: [Printing-architecture] Coding the Common Printing Dialog an dits interface - PPD and Foomatic extensions

[Petrie, Glen]

Till,

I am finally catching up on email...I have only scanned some them so far

There are a lot of good comments and a lot of information that looks like
requirements and we should capture them.

Can I suggest that you create a wiki page to capture these requirements.  I
would suggest a table like.  Then we as a group can help keep the
requirement table up to date.



Req   Requirement                       Approved        First
No.                                     Pending         Implementation
                                        Removed         Version
----- ------------------------------  --------------  -----------------
1001  Application and Print Dialog      Approved        Prototype
      communication SHALL use DBUS 
      expect for PDF content
----- ------------------------------  --------------  -----------------
1002  Icons for options and choices     Approved        Prototype
      SHALL be UU-encoded.
----- ------------------------------  --------------  -----------------
1003  Application MAY send preview      Approved	  Version 1.0
      of a document page to the print
      dialog
----- ------------------------------  --------------  -----------------
1004  Application SHALL send preview    Pending
      of a document page in PDF         Sending preview as PDF is a burden
      format.				    to the dialog.  Since previews
                                        are scaled down version of the 
                                        actual page a icon graphical
                                        format is sufficient.



acceptable requirement keys word for the requirements should be limited to

SHALL
MUST
MAY

SHALL NOT
MUST NOT
MAY NOT

Key word like SHOULD have no meaning when discussing requirements and are
impossible for determining if the requirement is implemented; either a
required is required (SHALL) or is optional (MAY).  

Re: [Printing-architecture] Coding the Common Printing Dialog an dits interface - PPD and Foomatic extensions

[Lars Uebernickel]

Glen,

Great idea - this way, we will have a better overview than browsing 
through endless threads here on the list.

I have started a requirements page on the OpenPrinting wiki with the 
examples you've given:

   http://www.linux-foundation.org/en/OpenPrinting/Requirements

I have also collected some information on this list about the 
specification of the PPD extensions and the API of the dialog:

   http://www.linux-foundation.org/en/OpenPrinting/Specifications


Petrie, Glen wrote:
> Till,
> 
> I am finally catching up on email...I have only scanned some them so far
> 
> There are a lot of good comments and a lot of information that looks like
> requirements and we should capture them.
> 
> Can I suggest that you create a wiki page to capture these requirements.  I
> would suggest a table like.  Then we as a group can help keep the
> requirement table up to date.
> 
> 
> 
> Req   Requirement                       Approved        First
> No.                                     Pending         Implementation
>                                         Removed         Version
> ----- ------------------------------  --------------  -----------------
> 1001  Application and Print Dialog      Approved        Prototype
>       communication SHALL use DBUS 
>       expect for PDF content
> ----- ------------------------------  --------------  -----------------
> 1002  Icons for options and choices     Approved        Prototype
>       SHALL be UU-encoded.
> ----- ------------------------------  --------------  -----------------
> 1003  Application MAY send preview      Approved	  Version 1.0
>       of a document page to the print
>       dialog
> ----- ------------------------------  --------------  -----------------
> 1004  Application SHALL send preview    Pending
>       of a document page in PDF         Sending preview as PDF is a burden
>       format.				    to the dialog.  Since previews
>                                         are scaled down version of the 
>                                         actual page a icon graphical
>                                         format is sufficient.
> 
> 
> 
> acceptable requirement keys word for the requirements should be limited to
> 
> SHALL
> MUST
> MAY
> 
> SHALL NOT
> MUST NOT
> MAY NOT
> 
> Key word like SHOULD have no meaning when discussing requirements and are
> impossible for determining if the requirement is implemented; either a
> required is required (SHALL) or is optional (MAY).  
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] Coding the Common Printing Dialog an dits interface - PPD and Foomatic extensions

[Lars Uebernickel]

Lars Uebernickel wrote:
> Glen,
> 
> Great idea - this way, we will have a better overview than browsing 
> through endless threads here on the list.
> 
> I have started a requirements page on the OpenPrinting wiki with the 
> examples you've given:
> 
>    http://www.linux-foundation.org/en/OpenPrinting/Requirements
> 

I have just changed the format of the Requirements page.

Each requirement has its own section now (there was too little room in 
the table). I also suggest to put notes and remarks directly to the 
corresponding requirement (with the colon syntax known from wikipedia 
talk pages).

I have also added some requirements that I came up with while I started 
to specify the API. I will add some more later tonight (CEST).

It would be nice if lots of people could look at them from time to time 
(esp. the 'Pending' ones) and tell me what they think. Also, feel free 
to add more requirements.

I want to finish the API as soon as possible to start implementing it in 
some applications. After that, it will be very hard to change 
fundamental stuff.

Thanks,

     Lars