Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI

Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI

[Petrie, Glen]

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

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

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

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

[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
> 
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
>
https://lists.linux-foundation.org/mailman/listinfo/printing-architectur
e

Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI

[Till Kamppeter]

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

Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI

[Petrie, Glen]

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

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

[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.
> 
> "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()
> 

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

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

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

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

[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")

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

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

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

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


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

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

> 
> Thanks a lot for your feedback and suggestions! The API is not
formally
> released yet, so making changes to it is still possible.
> 
>    Lars
> 
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
>
https://lists.linux-foundation.org/mailman/listinfo/printing-architectur
e

Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI

[Lars Uebernickel]

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

[Printing-architecture] Some Comments/ Feedback on CPDAPI

[Petrie, Glen]

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

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

 

org.openprinting.PrintDialog.Manager.*****

 

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


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

Re: [Printing-architecture] Some Comments/ Feedback on CPDAPI

[Lars Uebernickel]

> 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