From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93DEA.8EA61811" Date: Mon, 3 Nov 2008 11:32:58 -0800 Message-ID: From: "Petrie, Glen" Subject: [Printing-architecture] Some Comments/ Feedback on CPDAPI List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Open Printing This is a multi-part message in MIME format. ------_=_NextPart_001_01C93DEA.8EA61811 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have finally had some time to review the API for the =20 org.openprinting.PrintDialog.Manager.***** =20 1. I am concerned how job/option/attributes of CPDAPI align to JTAPI. 2. Long term I would expect that API will grow/improve. The "Show" method seems to be a little to generic a method name and I could really imagine a lot of additional "Show" methods. Therefore, I would suggest changing this method to "ShowDialog". In fact, there can be a desire to "ShowDialog" with a specific set of options/attributes being displayed with specific option/attribute values. So I would propose a new command "ShowThisDialog" where the argument define the initial display state. 3. The "SetNumberOfPages" was not initially clear to me of the intent. I would suggest "SetPagesToPrint" with an string argument such that printed pages could be more complex. I.e. SetPagesToPrint('s', '1-3,5,7,9,10-21") If the arguments is NULL or Negative it would print all pages. 4. For "AddOption": It is not clear that all vendor/application additions can be called "options". For pre-defined CPD options/attributes (if there are any) how can you "AddValueToOption". 5. For "AddOption" and for "AddPreset": I would like to see and strongly prompt that an initial set of options/attributes be those defined by JTAPI. Letting vendors/applications/developers set common option/attribute names will result in various names for the same option/attribute. This will cause confusion to the end user - the last thing Linux needs to do. 6. I can see two major reasons for "SetOptionValue". The first is when the dialog is started to set the default values. The second reason, is the user setting of one option/attribute changes one or more other options/attributes (coupled options/attributes). I would like to see an additional attribute added to the command that can be used to highlight a "SetOptionValue". So the "SetOptionValue('s' name, 'v' value, ' b' highlight, out 'b' success); 7. Many windowing system will provide a signal when a option/attribute (actually is gui field/region/object) is selected or deselected or moved-from. So a signal called "OptionSelection('i' selection); where selection takes on the values of "SELECTED", "DESELECTED", "MOVED_FROM". One could argue about the "MOVED_FROM". ------_=_NextPart_001_01C93DEA.8EA61811 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have finally had some time to review the API for = the

 

org.openprinting.PrintDialog.Manager.*****<= /span>

 

  1. I am concerned how job/option/attributes of CPDAPI align to = JTAPI.
  2. Long term I would = expect that API will grow/improve.  The “Show” method seems to = be a little to generic a method name and I could really imagine a lot of additional “Show” methods.  Therefore, I would = suggest changing this method to “ShowDialog”.  In fact, = there can be a desire to “ShowDialog” with a specific set of options/attributes being displayed with specific option/attribute values.  So I would propose a new command = “ShowThisDialog” where the argument define the initial display = state.
  3. The = “SetNumberOfPages” was not initially clear to me of the intent.  I would suggest = “SetPagesToPrint” with an string argument such that printed pages could be more complex.  I.e. SetPagesToPrint(‘s’, = ‘1-3,5,7,9,10-21”)  If the arguments is NULL or Negative it would print all = pages.
  4. For = “AddOption”: It is not clear that all vendor/application additions can be called = “options”.  For pre-defined CPD options/attributes (if there are any) how can = you “AddValueToOption”.
  5. For =  “AddOption” and for “AddPreset”: I would like to see and strongly = prompt that an initial set of options/attributes be those defined by JTAPI.   Letting vendors/applications/developers set = common option/attribute names will result in various names for the same option/attribute.   This will cause confusion to the end = user – the last thing Linux needs to do.
  6. I can see two major = reasons for “SetOptionValue”.  The first is when the dialog is started to set the default values.  The second reason, is the = user setting of one option/attribute changes one or more other = options/attributes (coupled options/attributes).   I would like to see an = additional attribute added to the command that can be used to highlight a = “SetOptionValue”.  So the “SetOptionValue(‘s’ name, ‘v’ = value, ‘ b’ highlight, out ‘b’ = success);
  7. Many windowing system = will provide a signal when a option/attribute (actually is gui field/region/object) is selected or deselected or moved-from.  = So a signal called “OptionSelection(‘i’ selection); = where selection takes on the values of “SELECTED”, = “DESELECTED”, “MOVED_FROM”.  One could argue about the = “MOVED_FROM”.
------_=_NextPart_001_01C93DEA.8EA61811-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Uebernickel In-Reply-To: References: Content-Type: text/plain; charset="utf-8" Date: Tue, 04 Nov 2008 12:12:45 +0100 Message-Id: <1225797165.9360.45.camel@chimera> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: printing-architecture@lists.linux-foundation.org > 1. I am concerned how job/option/attributes of CPDAPI align to JTAPI. I am not intimately familiar with the JTAPI. Where is the difference between "options" and "attributes"? There is no notion of a "job" in the CPDAPI, as one dialog only ever creates one job (at the most) during its lifetime. Printing options map directly to options in the PPD files. > 2. Long term I would expect that API will grow/improve. The “Show” > method seems to be a little to generic a method name and I could > really imagine a lot of additional “Show” methods. Therefore, I would > suggest changing this method to “ShowDialog”. In fact, there can be a > desire to “ShowDialog” with a specific set of options/attributes being > displayed with specific option/attribute values. So I would propose a > new command “ShowThisDialog” where the argument define the initial > display state. "Show" is a method of a PrintDialog instance. Hence, code using the API will look somewhat like this (depending on the language, of course): dialog.Show() I don't think it is necessary to change that to dialog.ShowDialog() An application is free to set as arbitrarily many options before/ after showing the dialog with PrintDialog.SetOptionValue. I don't think we need a ShowThis method which does exactly the same thing plus showing the dialog. > 3. The “SetNumberOfPages” was not initially clear to me of the intent. > I would suggest “SetPagesToPrint” with an string argument such that > printed pages could be more complex. I.e. SetPagesToPrint(‘s’, > ‘1-3,5,7,9,10-21”) If the arguments is NULL or Negative it would > print all pages. This method is not for setting the pages which are to be printed. It is used for letting the dialog know how many pages the final document will have. This is useful for setting the widgets in the preview area to sensible values, i.e. disabling the "next" button when the user arrives at the last page. It can also be used to give the user a warning when specifying pages which are out of range. I admit the naming is a bit ambiguous and the documentation might lack a bit in that area... > 4. For “AddOption”: It is not clear that all vendor/application > additions can be called “options”. For pre-defined CPD > options/attributes (if there are any) how can you “AddValueToOption”. Option is the terminology in PPD files, which I simply carried over into this API. Vendor options will not be added using this API, as they are specified in the PPD file. Only applications will use it. What do you mean with "AddValueToOption"? There is a method called "SetOptionValue", which sets an option to a specific value. For example, "PageSize" to "A4". > 5. For “AddOption” and for “AddPreset”: I would like to see and > strongly prompt that an initial set of options/attributes be those > defined by JTAPI. Letting vendors/applications/developers set common > option/attribute names will result in various names for the same > option/attribute. This will cause confusion to the end user – the > last thing Linux needs to do. This comes from the usability designer of the dialog, Peter Sikking. He has good reasons for this, which he outlines in the specs for the dialog: http://wiki.openusability.org/printing/index.php/Specification > 6. I can see two major reasons for “SetOptionValue”. The first is > when the dialog is started to set the default values. The second > reason, is the user setting of one option/attribute changes one or > more other options/attributes (coupled options/attributes). I would > like to see an additional attribute added to the command that can be > used to highlight a “SetOptionValue”. So the “SetOptionValue(‘s’ > name, ‘v’ value, ‘ b’ highlight, out ‘b’ success); What effect would "highlighting" an option have? So that the user can see when an option changes? This is a very good idea, but I don't think this should be part of the API. The dialog show always do this by default. > 7. Many windowing system will provide a signal when a option/attribute > (actually is gui field/region/object) is selected or deselected or > moved-from. So a signal called “OptionSelection(‘i’ selection); where > selection takes on the values of “SELECTED”, “DESELECTED”, > “MOVED_FROM”. One could argue about the “MOVED_FROM”. This could be added, but I do not see any benefits for the application to have such information. What exactly do you have in mind? Thanks a lot for your feedback and suggestions! The API is not formally released yet, so making changes to it is still possible. Lars From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Nov 2008 07:20:21 -0800 Message-ID: From: "Petrie, Glen" Subject: Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lars Uebernickel , printing-architecture@lists.linux-foundation.org My comment are noted by [gwp] > -----Original Message----- > From: printing-architecture-bounces@lists.linux-foundation.org > [mailto:printing-architecture-bounces@lists.linux-foundation.org] On > Behalf Of Lars Uebernickel > Sent: Tuesday, November 04, 2008 3:13 AM > To: printing-architecture@lists.linux-foundation.org > Subject: Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI >=20 >=20 > > 1. I am concerned how job/option/attributes of CPDAPI align to JTAPI. >=20 > I am not intimately familiar with the JTAPI. Where is the difference > between "options" and "attributes"? >=20 [gwp] The important thing about JTAPI is not that it is a job API but that it has defined a common set of terms for standard and commonly used printing terms/actions/attributes/options/values. It is great to have a CPD format, layout, etc.; but it just as important (from the User point-of-view, not the applications point-of-view) that the CPD use common terminology between printer vendor or better stated between PPD's. The CPD is currently not specifically concerned with "what the options/attributes/etc" are "labeled" or called; it gets the information from the PPD file. Thus, this discussion needs to be moved to the details about the PPD extension for the CPD. > There is no notion of a "job" in the CPDAPI, as one dialog only ever > creates one job (at the most) during its lifetime. Printing options map > directly to options in the PPD files. >=20 >=20 [gwp] There may be a 'job' concept. How do the CPD option settings get the printer driver? Yes, it could be piped set of option:value key word pairs. But please note, that not all print solution provide instant printing. Many have spoolers which must maintain a "print job" and not the rendered printed pages. I use the term "print job" loosely; as we don't want create yet-another job ticket format, I prefer to call it the "print intent". Also, CUPS will not be only receiver of the CPD "print intent". There are a lot of qualified receivers of the "print intent" content from the CPD. Also note; I see the CPD being used over the range of embedded devices to production printing. (I will discussion in another email.) Please do not expect the application or the caller of the CPD to create "print intent" content. This is a common function which is best done by the CPD. If each application has to do this then the number of errors and bad "print intent" content will grow with each application. > > 2. Long term I would expect that API will grow/improve. The "Show" > > method seems to be a little to generic a method name and I could > > really imagine a lot of additional "Show" methods. Therefore, I would > > suggest changing this method to "ShowDialog". In fact, there can be a > > desire to "ShowDialog" with a specific set of options/attributes being > > displayed with specific option/attribute values. So I would propose a > > new command "ShowThisDialog" where the argument define the initial > > display state. >=20 > "Show" is a method of a PrintDialog instance. Hence, code using the API > will look somewhat like this (depending on the language, of course): >=20 > dialog.Show() >=20 > I don't think it is necessary to change that to >=20 > dialog.ShowDialog() >=20 [gwp] Ok. > An application is free to set as arbitrarily many options before/ after > showing the dialog with PrintDialog.SetOptionValue. I don't think we > need a ShowThis method which does exactly the same thing plus showing > the dialog. >=20 >=20 [gwp] I guess I was not too clear. What I meant was something similar to what other OS print dialogs do. Once the user has set options, he/she would like those same options to be set the next time they print or the CPD is shown. It is too much burden for the application to remember the details. So I suggested a ShowThis API. But there would also have to be a GetShow or GetThis. This either returns opaque pointer or reference to the current CPD configuration. The ShowThis sends the opaque pointer/reference to the CPD and the exact same dialog is displays with the pervious options set. (Opaque content can either be saved in memory, a file or ???) > > 3. The "SetNumberOfPages" was not initially clear to me of the intent. > > I would suggest "SetPagesToPrint" with an string argument such that > > printed pages could be more complex. I.e. SetPagesToPrint('s', > > '1-3,5,7,9,10-21") If the arguments is NULL or Negative it would > > print all pages. >=20 > This method is not for setting the pages which are to be printed. It is > used for letting the dialog know how many pages the final document will > have. This is useful for setting the widgets in the preview area to > sensible values, i.e. disabling the "next" button when the user arrives > at the last page. It can also be used to give the user a warning when > specifying pages which are out of range. >=20 > I admit the naming is a bit ambiguous and the documentation might lack a > bit in that area... >=20 [gwp] The concept of "Set" does not apply here as an API. It is actually an attribute of the logical document and represents the number-of-pages based on the current printing options. If the user changes the paper size, the margins or any page format option then the NumberOf(Logical)Pages changes. Note that reformatting may not only change the number of logical pages but the size of document. [gwp] My proposal would be change SetDocumentName to SetDocument; remove SetNumberOfPages and SetDocumentSize. Pages and Size are added to SetDocument; [gwp] SetDocument('s' name, 'u' octetSize, 'u' logicalPageCount) [gwp] I might even add the "url" to the SetDocument in the event of off-line, pull-printing and/or spool printing. [gwp] Note a 'byte' does not have to be 8-bits. To ensure interoperability I suggest 'byte' size information be called octetSize. This indicates the size if 8-bit units. >=20 > > 4. For "AddOption": It is not clear that all vendor/application > > additions can be called "options". For pre-defined CPD > > options/attributes (if there are any) how can you "AddValueToOption". >=20 > Option is the terminology in PPD files, which I simply carried over into > this API. Vendor options will not be added using this API, as they are > specified in the PPD file. Only applications will use it. >=20 > What do you mean with "AddValueToOption"? There is a method called > "SetOptionValue", which sets an option to a specific value. For example, > "PageSize" to "A4". [gwp] Suppose the PPD has a PageSize of A4, then the printer could print 4"x6" but the value was not included in the PPD. Then the application wants to add a value to "Media Size" option of 4"x6". =20 [gwp] example: AddValueToOption(MEDIA_SIZE, "4 x 6 Photo Card") >=20 > > 5. For "AddOption" and for "AddPreset": I would like to see and > > strongly prompt that an initial set of options/attributes be those > > defined by JTAPI. Letting vendors/applications/developers set common > > option/attribute names will result in various names for the same > > option/attribute. This will cause confusion to the end user - the > > last thing Linux needs to do. >=20 > This comes from the usability designer of the dialog, Peter Sikking. He > has good reasons for this, which he outlines in the specs for the > dialog: >=20 > http://wiki.openusability.org/printing/index.php/Specification >=20 [gwp] I thought all options and preset labels where defined within the PPD file. Assuming this is true; then, the proposal to use JTAPI options/attributes/values is still a good idea, supported by the OpenPrinting Architecture/SteeringCommittee and reinforces the concept of "common". Otherwise I don't correctly understand your reply; could you please explain further.=20 >=20 > > 6. I can see two major reasons for "SetOptionValue". The first is > > when the dialog is started to set the default values. The second > > reason, is the user setting of one option/attribute changes one or > > more other options/attributes (coupled options/attributes). I would > > like to see an additional attribute added to the command that can be > > used to highlight a "SetOptionValue". So the "SetOptionValue('s' > > name, 'v' value, ' b' highlight, out 'b' success); >=20 > What effect would "highlighting" an option have? So that the user can > see when an option changes? This is a very good idea, but I don't think > this should be part of the API. The dialog show always do this by > default. >=20 [gwp] The CPD may/should do this. What I meant was; if the User changes one option; then, any affected/coupled option(s) should be highlighted to draw attention to the user that something was changed (automatically) based on the setting of options he/she just changed. >=20 > > 7. Many windowing system will provide a signal when a option/attribute > > (actually is gui field/region/object) is selected or deselected or > > moved-from. So a signal called "OptionSelection('i' selection); where > > selection takes on the values of "SELECTED", "DESELECTED", > > "MOVED_FROM". One could argue about the "MOVED_FROM". >=20 > This could be added, but I do not see any benefits for the application > to have such information. What exactly do you have in mind? >=20 [gwp] At this point I am still working on some ideas. But this type of signaling has been useful in other gui's. If you can just put the hooks in or have these addition in your architecture, we can determine the value of them as application begin to use CPD. >=20 > Thanks a lot for your feedback and suggestions! The API is not formally > released yet, so making changes to it is still possible. >=20 > Lars >=20 >=20 > _______________________________________________ > Printing-architecture mailing list > Printing-architecture@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/printing-architectur e From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Uebernickel In-Reply-To: References: Content-Type: text/plain Date: Tue, 04 Nov 2008 18:46:20 +0100 Message-Id: <1225820780.9360.81.camel@chimera> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: printing-architecture@lists.linux-foundation.org > [gwp] The important thing about JTAPI is not that it is a job API but > that it has defined a common set of terms for standard and commonly used > printing terms/actions/attributes/options/values. It is great to have a > CPD format, layout, etc.; but it just as important (from the User > point-of-view, not the applications point-of-view) that the CPD use > common terminology between printer vendor or better stated between > PPD's. The CPD is currently not specifically concerned with "what the > options/attributes/etc" are "labeled" or called; it gets the information > from the PPD file. Thus, this discussion needs to be moved to the > details about the PPD extension for the CPD. Ok. > [gwp] There may be a 'job' concept. How do the CPD option settings get > the printer driver? Yes, it could be piped set of option:value key word > pairs. But please note, that not all print solution provide instant > printing. Many have spoolers which must maintain a "print job" and not > the rendered printed pages. I use the term "print job" loosely; as we > don't want create yet-another job ticket format, I prefer to call it the > "print intent". Also, CUPS will not be only receiver of the CPD "print > intent". There are a lot of qualified receivers of the "print intent" > content from the CPD. Also note; I see the CPD being used over the > range of embedded devices to production printing. (I will discussion in > another email.) Please do not expect the application or the caller of > the CPD to create "print intent" content. This is a common function > which is best done by the CPD. If each application has to do this then > the number of errors and bad "print intent" content will grow with each > application. The CPD will talk to CUPS, the application doesn't have anything to do with it. The only thing that the application will use is the CPD API. > > An application is free to set as arbitrarily many options before/after > > showing the dialog with PrintDialog.SetOptionValue. I don't think we > > need a ShowThis method which does exactly the same thing plus showing > > the dialog. > > > > > > [gwp] I guess I was not too clear. What I meant was something similar > to what other OS print dialogs do. Once the user has set options, he/she > would like those same options to be set the next time they print or the > CPD is shown. It is too much burden for the application to remember the > details. So I suggested a ShowThis API. But there would also have to be > a GetShow or GetThis. This either returns opaque pointer or reference > to the current CPD configuration. The ShowThis sends the opaque > pointer/reference to the CPD and the exact same dialog is displays with > the pervious options set. (Opaque content can either be saved in > memory, a file or ???) Oh, then I misunderstood you. This is already planned: It will be possible for the user to save a configuration as a preset, so that all these options can be easily set with one click for subsequent documents. This is handled transparently by the dialog, the application will not have to deal with it. AFAIK, Peter has also specified a mechanism to save those presets to a file (to share with somebody else or use on another computer). > [gwp] The concept of "Set" does not apply here as an API. It is > actually an attribute of the logical document and represents the > number-of-pages based on the current printing options. If the user > changes the paper size, the margins or any page format option then the > NumberOf(Logical)Pages changes. Note that reformatting may not only > change the number of logical pages but the size of document. > > [gwp] My proposal would be change SetDocumentName to SetDocument; remove > SetNumberOfPages and SetDocumentSize. Pages and Size are added to > SetDocument; > > [gwp] SetDocument('s' name, 'u' octetSize, 'u' logicalPageCount) > > [gwp] I might even add the "url" to the SetDocument in the event of > off-line, pull-printing and/or spool printing. > > [gwp] Note a 'byte' does not have to be 8-bits. To ensure > interoperability I suggest 'byte' size information be called octetSize. > This indicates the size if 8-bit units. This is a very good idea. I will ensure that merging those functions will not clash with any other specifications (especially the preview). If not, I'll change it to your suggestion. Thanks! > [gwp] Suppose the PPD has a PageSize of A4, then the printer could print > 4"x6" but the value was not included in the PPD. Then the application > wants to add a value to "Media Size" option of 4"x6". > > [gwp] example: AddValueToOption(MEDIA_SIZE, "4 x 6 Photo Card") This would be a custom setting for the page size (can be specified in the PPD file with the CUPS custom option extension). I think this is the way options should be extended, as given values will be validated by the CPD (e.g. maximum paper size, etc.). If an application can add arbitrary values to options, the printer driver would not know how to handle them. > [gwp] I thought all options and preset labels where defined within the > PPD file. Assuming this is true; then, the proposal to use JTAPI > options/attributes/values is still a good idea, supported by the > OpenPrinting Architecture/SteeringCommittee and reinforces the concept > of "common". Otherwise I don't correctly understand your reply; could > you please explain further. They are specified in the PPD file. This is by design, as Peter wants as much flexibility as possible for individual printers. He does have specific option/tag names in mind for different types/uses of printers (they are/ will be specified by him). I don't know whether those are the same as the ones from the JTAPI. Nevertheless, the CPDAPI should not know about specific option types, but rather be able to handle any options. The options in a PPD file can (and probably should) be named in a specific scheme, be it Peter's or the one from JTAPI. > [gwp] The CPD may/should do this. What I meant was; if the User changes > one option; then, any affected/coupled option(s) should be highlighted > to draw attention to the user that something was changed (automatically) > based on the setting of options he/she just changed. Ok, that makes sense. > [gwp] At this point I am still working on some ideas. But this type of > signaling has been useful in other gui's. If you can just put the hooks > in or have these addition in your architecture, we can determine the > value of them as application begin to use CPD. To be honest, I would rather not include features for which we don't have any use case yet. Note that an application can already subscribe to the "OptionChanged" signal, which is emitted whenever the value of an option changes. Lars From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Nov 2008 10:20:45 -0800 Message-ID: From: "Petrie, Glen" Subject: Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lars Uebernickel , printing-architecture@lists.linux-foundation.org > -----Original Message----- > From: printing-architecture-bounces@lists.linux-foundation.org > [mailto:printing-architecture-bounces@lists.linux-foundation.org] On > Behalf Of Lars Uebernickel > Sent: Tuesday, November 04, 2008 9:46 AM > To: printing-architecture@lists.linux-foundation.org > Subject: Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI >=20 > > [gwp] The important thing about JTAPI is not that it is a job API but > > that it has defined a common set of terms for standard and commonly used > > printing terms/actions/attributes/options/values. It is great to have a > > CPD format, layout, etc.; but it just as important (from the User > > point-of-view, not the applications point-of-view) that the CPD use > > common terminology between printer vendor or better stated between > > PPD's. The CPD is currently not specifically concerned with "what the > > options/attributes/etc" are "labeled" or called; it gets the information > > from the PPD file. Thus, this discussion needs to be moved to the > > details about the PPD extension for the CPD. >=20 > Ok. >=20 >=20 > > [gwp] There may be a 'job' concept. How do the CPD option settings get > > the printer driver? Yes, it could be piped set of option:value key word > > pairs. But please note, that not all print solution provide instant > > printing. Many have spoolers which must maintain a "print job" and not > > the rendered printed pages. I use the term "print job" loosely; as we > > don't want create yet-another job ticket format, I prefer to call it the > > "print intent". Also, CUPS will not be only receiver of the CPD "print > > intent". There are a lot of qualified receivers of the "print intent" > > content from the CPD. Also note; I see the CPD being used over the > > range of embedded devices to production printing. (I will discussion in > > another email.) Please do not expect the application or the caller of > > the CPD to create "print intent" content. This is a common function > > which is best done by the CPD. If each application has to do this then > > the number of errors and bad "print intent" content will grow with each > > application. >=20 > The CPD will talk to CUPS, the application doesn't have anything to do > with it. The only thing that the application will use is the CPD API. >=20 [gwp] I am not expecting the caller application to receive the print-intent to be spooled; but it could. I hope that CPD will be able to talk to other spoolers or """print""" controller/service software other than CUPS. If you think of CPD as a printing-client then there has to be a way for CPD to send print-intent content to any CPD qualified print controller/service. [gwp] If the goal is that CPD will only talk with CUPS, I have misunderstood the intent of this activity. I would think that the CUPS team should define, design and provide the implementation of CPD.=20 >=20 > > > An application is free to set as arbitrarily many options before/after > > > showing the dialog with PrintDialog.SetOptionValue. I don't think we > > > need a ShowThis method which does exactly the same thing plus showing > > > the dialog. > > > > > > > > > > [gwp] I guess I was not too clear. What I meant was something similar > > to what other OS print dialogs do. Once the user has set options, he/she > > would like those same options to be set the next time they print or the > > CPD is shown. It is too much burden for the application to remember the > > details. So I suggested a ShowThis API. But there would also have to be > > a GetShow or GetThis. This either returns opaque pointer or reference > > to the current CPD configuration. The ShowThis sends the opaque > > pointer/reference to the CPD and the exact same dialog is displays with > > the pervious options set. (Opaque content can either be saved in > > memory, a file or ???) >=20 > Oh, then I misunderstood you. >=20 > This is already planned: It will be possible for the user to save a > configuration as a preset, so that all these options can be easily set > with one click for subsequent documents. This is handled transparently > by the dialog, the application will not have to deal with it. >=20 > AFAIK, Peter has also specified a mechanism to save those presets to a > file (to share with somebody else or use on another computer). >=20 >=20 > > [gwp] The concept of "Set" does not apply here as an API. It is > > actually an attribute of the logical document and represents the > > number-of-pages based on the current printing options. If the user > > changes the paper size, the margins or any page format option then the > > NumberOf(Logical)Pages changes. Note that reformatting may not only > > change the number of logical pages but the size of document. > > > > [gwp] My proposal would be change SetDocumentName to SetDocument; remove > > SetNumberOfPages and SetDocumentSize. Pages and Size are added to > > SetDocument; > > > > [gwp] SetDocument('s' name, 'u' octetSize, 'u' logicalPageCount) > > > > [gwp] I might even add the "url" to the SetDocument in the event of > > off-line, pull-printing and/or spool printing. > > > > [gwp] Note a 'byte' does not have to be 8-bits. To ensure > > interoperability I suggest 'byte' size information be called octetSize. > > This indicates the size if 8-bit units. >=20 > This is a very good idea. I will ensure that merging those functions > will not clash with any other specifications (especially the preview). > If not, I'll change it to your suggestion. >=20 > Thanks! >=20 >=20 > > [gwp] Suppose the PPD has a PageSize of A4, then the printer could print > > 4"x6" but the value was not included in the PPD. Then the application > > wants to add a value to "Media Size" option of 4"x6". > > > > [gwp] example: AddValueToOption(MEDIA_SIZE, "4 x 6 Photo Card") >=20 > This would be a custom setting for the page size (can be specified in > the PPD file with the CUPS custom option extension). I think this is the > way options should be extended, as given values will be validated by the > CPD (e.g. maximum paper size, etc.). If an application can add arbitrary > values to options, the printer driver would not know how to handle them. >=20 >=20 [gwp] I am still not communicating correctly. The CPD has reads the PPD CPD extension content. But the application wants to add new/more values to an option beyond the values that were specified in PPD. So the new/more values would never have been in the PPD. > > [gwp] I thought all options and preset labels where defined within the > > PPD file. Assuming this is true; then, the proposal to use JTAPI > > options/attributes/values is still a good idea, supported by the > > OpenPrinting Architecture/SteeringCommittee and reinforces the concept > > of "common". Otherwise I don't correctly understand your reply; could > > you please explain further. >=20 > They are specified in the PPD file. This is by design, as Peter wants as > much flexibility as possible for individual printers. He does have > specific option/tag names in mind for different types/uses of printers > (they are/ will be specified by him). I don't know whether those are the > same as the ones from the JTAPI. [gwp] Since the PPD CPD extensions are being done by the OpenPrinting Architecture team; they have very strongly recommended that CPD options/tags/values be based on JTAPI. All members of the Architecture Team have real life experience with this situation and JTAPI was based on domain experts with years of printing/print-job experience. >=20 > Nevertheless, the CPDAPI should not know about specific option types, > but rather be able to handle any options. The options in a PPD file can > (and probably should) be named in a specific scheme, be it Peter's or > the one from JTAPI. >=20 >=20 > > [gwp] The CPD may/should do this. What I meant was; if the User changes > > one option; then, any affected/coupled option(s) should be highlighted > > to draw attention to the user that something was changed (automatically) > > based on the setting of options he/she just changed. >=20 > Ok, that makes sense. >=20 >=20 > > [gwp] At this point I am still working on some ideas. But this type of > > signaling has been useful in other gui's. If you can just put the hooks > > in or have these addition in your architecture, we can determine the > > value of them as application begin to use CPD. >=20 > To be honest, I would rather not include features for which we don't > have any use case yet. Note that an application can already subscribe > to the "OptionChanged" signal, which is emitted whenever the value of an > option changes. >=20 >=20 [gwp] I am asking to add the feature at this time; however, I am requesting that the architecture and design allow for extension of the type I suggested above. I have seen many, many, many "closed architecture" that find it difficult to added extension if it not considered in the original architecture/design phase of the project. > Lars >=20 >=20 > _______________________________________________ > Printing-architecture mailing list > Printing-architecture@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/printing-architectur e From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <491330CF.9080901@gmail.com> Date: Thu, 06 Nov 2008 19:00:47 +0100 From: Till Kamppeter MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Petrie, Glen" Cc: printing-architecture@lists.linux-foundation.org Petrie, Glen wrote: > [gwp] I am not expecting the caller application to receive the > print-intent to be spooled; but it could. I hope that CPD will be able > to talk to other spoolers or """print""" controller/service software > other than CUPS. If you think of CPD as a printing-client then there > has to be a way for CPD to send print-intent content to any CPD > qualified print controller/service. > The specs are not tied to CUPS, only the implementations of the GSoC students are made for CUPS. > [gwp] If the goal is that CPD will only talk with CUPS, I have > misunderstood the intent of this activity. I would think that the CUPS > team should define, design and provide the implementation of CPD. > As the implementation are GUI programs based on the desktop's toolkits we have decided to get them part of the desktops. So GNOME users will see the GNOME implementation and KDE users the KDE implementation. > > [gwp] I am still not communicating correctly. The CPD has reads the PPD > CPD extension content. But the application wants to add new/more values > to an option beyond the values that were specified in PPD. So the > new/more values would never have been in the PPD. > The app is supposed to add its own options. If it adds choices to existing PPD options there must be some conditions fulfilled that the driver could really cope with that: 1. The options need standardized names, so that it works with as many drivers/printers as possible, like names defined by the PPD specs from Adobe or by JTAPI. 2. The options must support custom values (custom paper size, numerical or string options) and the app adds only some more pre-defined choices which are in the range of the custom value. 3. If the option where the app wants to add choices does not exist, the adding of choices should get silently ignored. > [gwp] Since the PPD CPD extensions are being done by the OpenPrinting > Architecture team; they have very strongly recommended that CPD > options/tags/values be based on JTAPI. All members of the Architecture > Team have real life experience with this situation and JTAPI was based > on domain experts with years of printing/print-job experience. > Yes, I will add a paragraph to the PPD extensions that options and choices provided by the JTAPI should be named appropriately in the PPDs. Till