* [Printing-architecture] Coding the Common Printing Dialog and its interface - PPD and Foomatic extensions
@ 2008-04-25 17:19 Till Kamppeter
2008-05-01 16:21 ` Lars Uebernickel
0 siblings, 1 reply; 5+ messages in thread
From: Till Kamppeter @ 2008-04-25 17:19 UTC (permalink / raw)
To: Alexander Wauck, Lars Uebernickel
Cc: printing-architecture, Peter Sikking, Jonathan Riddell
Hi,
here is my suggestion for part 1 of the specs, the extensions for PPDs:
1. Custom options/Advanced data types
-------------------------------------
We use the CUPS extensions for custom options, so that not only boolean
and enumerated choice options are posible but also more advanced datatypes:
- integer numbers
- real numbers - interpreted linearly or exponentially, for example for
color and brightness adjustments
- lengths in points - for example for margin widths
- strings - for example for user names and fax numbers
- passwords - numerical or alphanumerical
See section "Custom Options" on
http://www.cups.org/documentation.php/spec-ppd.html
2. Multi-language PPDs
----------------------
We use also the CUPS extensions for multi-language PPDs. This way a
print queue can be set up on a server and the users on the clients can
use different desktop languages and the printer options appear in their
languages.
See section "Globalized PPD Support" on
http://www.cups.org/documentation.php/spec-ppd.html
3. "Quick Presets" button support
---------------------------------
There are two possibilities to describe such buttons in the PPD file
(and we should support both for maximum flexibility):
a) One option in the PPD has to be selected to represent the quick
preset buttons in the default view of the OpenUsability printing dialog.
This option will not appear under the tags then, even if it is tagged
in the PPD. It must be an enumerated choice option where each choice
will make up one button. We will select it by using the following
keyword ONCE in the PPD file:
*OPQuickPresetsOption: PrintoutMode
In this example "PrintoutMode" is the option selected to make up the
buttons.
In Foomatic we could add the tag
<QuickPresets />
to one option XML file to select the appropriate option.
b) With special keywords we define each button and which options it
should set:
*OPQuickPresetsButton Document/Office Document: "Resolution=600dpi
MediaType=Plain"
*OPQuickPresetsButton Photo/Photo: "Resolution=1200dpi MediaType=Glossy"
...
Translations for the button texts are done as with option choices:
*de.OPQuickPresetsButton Document/Bürodokument: ""
*de.OPQuickPresetsButton Photo/Foto: ""
...
In Foomatic we could create an option with a new "quickpresets" option type.
The buttons have a little bit different meaning with a) and b).
In case a) always one button is selected, as each option of the PPD must
have a value. If the driver or the PPD is designed so that this option
sets several of the other options, there must either a quick preset
button for manual setting of the other options or each of the other
options must have an "Automatic", or "None" setting where the setting
from the quick preset buttons is used and its usual settings (this
latter case is the case for the "PrintoutMode" option in Foomatic PPDs.
Case a) makes the quick presets available in all dialogs, not only in
the OpenUsability one. The quick presets simply appear as an extra option.
In case b) clicking a button sets all options in the button's list to
the given values. After having clicked one can change the options
individually. Here no button would be shown as selected, or on each
option change (independent whether by button or individually) one checks
the option settings against the button's lists and shows each button
whose options are set as in its list pressed down. In case b) there will
be no option appearing in non-OpenUsability dialogs to represent the
quick preset buttons.
For legacy PPDs without special keywords for quick preset buttons we use
the "PrintoutMode" option, as this one does exactly this task in
Foomatic PPDs.
A second fallback could be to set standard options for the printout quality:
Button Settings
------------------------------------------------------------------
Draft Resolution=<Lowest Choice> Economode=On
Normal Resolution=<Second highest value> Economode=Off
High Quality Resolution=<Highest Value> Economode=Off
4. Option Tagging
-----------------
In the OpenUsability printing dialogs options are categorized by tags.
In contrary to groups an option can have more than one tag. The option
will be shown if any of the tags is selected. For example the Duplex
option can have a "Paper Handling" and "Resource Saving" tag. If either
of these is selected, the option will be shown.
In PPD options must be tagged to make this working. Let us define tags
and translations for their human-readable texts like this:
*OPOptionTag ResourceSaving/Resource Saving: ""
*de.OPOptionTag ResourceSaving/Resourcen sparen: ""
Let each option have this keyword to assign it with one or more tags:
*OPTagList Duplex: "ResourceSaving PaperHandling
Finishing"
*End
In Foomatic add a construction like this to each option XML file (into
the "<arg_execution>...</arg_execution>" section):
<tags>
<tag id="PaperHandling">
<en>Paper Handling</en>
<de>Papierhandhabung</de>
</tag>
<tag id="ResourceSaving">
<en>Resource Saving</en>
<de>Resourcen sparen</de>
</tag>
</tags>
5. Icons for options and choices
--------------------------------
Let us also give the possibility to add an icon to every human-readable
text item in the dialog: option names, choice names, tag names. ...
To not need to invent too many new keywords, let us simply add
"translations" with the language code "OPIcon" for option choices and
let them have the base-64-UU-encoded icon, either a PNG image or SVG
drawing as its code:
*OPIcon.InputSlot Auto: "begin-base64 644 InputSlot-Auto.png
iVBORw0KGgoAAAANSUhEUgAAAOAAAAC6CAMAAACA5rFCAAADAFBMVEX/////
/8z/zP//zMz/zGb/zDP/zAD/mWb/mTP/mQD/Zmb/MzPM///M/8zM/zPMzP/M
zMzMzJnMzGbMzDPMzADMmf/MmczMmZnMmWbMmTPMmQDMZjPMZgCZzP+ZzMyZ
...
4SfnV38C83lfZ0FU5/N58n1aZI2z2fxfwOTVfkPrH2h/Luv33J7bc3tuz+25
Pbfn9tye25+5/T9t163O+/ghTQAAAABJRU5ErkJggg==
===="
*End
For main keywords lets use
*OPIcon InputSlot: "begin-base64 644 InputSlot.png
iVBORw0KGgoAAAANSUhEUgAAAOAAAAC6CAMAAACA5rFCAAADAFBMVEX/////
..."
*End
And this is for the option tags:
*OPIcon.OPOptionTag ResourceSaving: "begin-base64 644 ResourceSaving.svg
..."
*End
For a manufacturer-specific picture (logo or so) let us use '*OPIcon
Manufacturer: "..."' and for a model-specific picture (image of the
printer or so) let us use '*OPIcon ModelName: "..."'.
What do you think about these specs for PPD extensions? Should we go
this way? Or is there something missing? Breaking Adobe specs? If all is
OK, we should start coding the dialog and the dialog interface based on
these extensions.
Till
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Printing-architecture] Coding the Common Printing Dialog and its interface - PPD and Foomatic extensions
2008-04-25 17:19 [Printing-architecture] Coding the Common Printing Dialog and its interface - PPD and Foomatic extensions Till Kamppeter
@ 2008-05-01 16:21 ` Lars Uebernickel
2008-05-01 17:44 ` Till Kamppeter
0 siblings, 1 reply; 5+ messages in thread
From: Lars Uebernickel @ 2008-05-01 16:21 UTC (permalink / raw)
To: printing-architecture
Till Kamppeter wrote:
> Hi,
>
> here is my suggestion for part 1 of the specs, the extensions for PPDs:
>
>
> 1. Custom options/Advanced data types
> -------------------------------------
>
> We use the CUPS extensions for custom options, so that not only boolean
> and enumerated choice options are posible but also more advanced datatypes:
>
> - integer numbers
> - real numbers - interpreted linearly or exponentially, for example for
> color and brightness adjustments
> - lengths in points - for example for margin widths
> - strings - for example for user names and fax numbers
> - passwords - numerical or alphanumerical
>
> See section "Custom Options" on
> http://www.cups.org/documentation.php/spec-ppd.html
Are there any other datatypes that might be needed often? The more
precise an option is defined in the PPD, the better a gui can show
it to the user (and prevent false entries).
For example, Ricoh's "UserCode" option, which is basically an
eight-digit number, but should be displayed as a string rather than a
slider or spinbox. This is similar to the 'passcode' option, only in
clear text. If it is exposed as a string, the dialog can not warn a user
if he enters non-digit characters.
If there is a need for additional types like this, we should try to get
them into CUPS as soon as possible, otherwise all kinds of workarounds
might get into the PPDs.
> --- snip ---
>
> 3. "Quick Presets" button support
> ---------------------------------
>
> There are two possibilities to describe such buttons in the PPD file
> (and we should support both for maximum flexibility):
>
> a) One option in the PPD has to be selected to represent the quick
> preset buttons in the default view of the OpenUsability printing dialog.
> This option will not appear under the tags then, even if it is tagged
> in the PPD. It must be an enumerated choice option where each choice
> will make up one button. We will select it by using the following
> keyword ONCE in the PPD file:
>
> *OPQuickPresetsOption: PrintoutMode
>
> In this example "PrintoutMode" is the option selected to make up the
> buttons.
>
> In Foomatic we could add the tag
>
> <QuickPresets />
>
> to one option XML file to select the appropriate option.
>
> b) With special keywords we define each button and which options it
> should set:
>
> *OPQuickPresetsButton Document/Office Document: "Resolution=600dpi
> MediaType=Plain"
> *OPQuickPresetsButton Photo/Photo: "Resolution=1200dpi MediaType=Glossy"
> ...
I think "*OPQuickPreset" suffices. It might not be implemented as
buttons in all cases.
> --- snip ---
>
> 5. Icons for options and choices
> --------------------------------
>
> Let us also give the possibility to add an icon to every human-readable
> text item in the dialog: option names, choice names, tag names. ...
>
> To not need to invent too many new keywords, let us simply add
> "translations" with the language code "OPIcon" for option choices and
> let them have the base-64-UU-encoded icon, either a PNG image or SVG
> drawing as its code:
>
> *OPIcon.InputSlot Auto: "begin-base64 644 InputSlot-Auto.png
> iVBORw0KGgoAAAANSUhEUgAAAOAAAAC6CAMAAACA5rFCAAADAFBMVEX/////
> /8z/zP//zMz/zGb/zDP/zAD/mWb/mTP/mQD/Zmb/MzPM///M/8zM/zPMzP/M
> zMzMzJnMzGbMzDPMzADMmf/MmczMmZnMmWbMmTPMmQDMZjPMZgCZzP+ZzMyZ
> ...
> 4SfnV38C83lfZ0FU5/N58n1aZI2z2fxfwOTVfkPrH2h/Luv33J7bc3tuz+25
> Pbfn9tye25+5/T9t163O+/ghTQAAAABJRU5ErkJggg==
> ===="
> *End
>
> For main keywords lets use
>
> *OPIcon InputSlot: "begin-base64 644 InputSlot.png
> iVBORw0KGgoAAAANSUhEUgAAAOAAAAC6CAMAAACA5rFCAAADAFBMVEX/////
> ..."
> *End
Will those icons only be defined in the PPD files? This could mean that
the options and tags have different icons for different printers
(especially if they are from different vendors), which might be
confusing. Wouldn't it make sense to have a set of standard icons for
the most common options (such as PaperSize), and only use custom icons
for options which are specific to a printer/vendor?
> For a manufacturer-specific picture (logo or so) let us use '*OPIcon
> Manufacturer: "..."' and for a model-specific picture (image of the
> printer or so) let us use '*OPIcon ModelName: "..."'.
Where will the logo appear in the dialog? If we reserve space for it
somewhere in the dialog, we should probably publish some some size
restrictions for it (or at least an aspect ratio).
Lars
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Printing-architecture] Coding the Common Printing Dialog and its interface - PPD and Foomatic extensions
2008-05-01 16:21 ` Lars Uebernickel
@ 2008-05-01 17:44 ` Till Kamppeter
[not found] ` <8B8709E6C8B8784583FA9C7C013CB4515366F2@etd1.etd.ussj.ricoh.com>
0 siblings, 1 reply; 5+ messages in thread
From: Till Kamppeter @ 2008-05-01 17:44 UTC (permalink / raw)
To: Lars Uebernickel; +Cc: printing-architecture
Lars Uebernickel wrote:
> Till Kamppeter wrote:
>> Hi,
>>
>> here is my suggestion for part 1 of the specs, the extensions for PPDs:
>>
>>
>> 1. Custom options/Advanced data types
>> -------------------------------------
>>
>> We use the CUPS extensions for custom options, so that not only boolean
>> and enumerated choice options are posible but also more advanced datatypes:
>>
>> - integer numbers
>> - real numbers - interpreted linearly or exponentially, for example for
>> color and brightness adjustments
>> - lengths in points - for example for margin widths
>> - strings - for example for user names and fax numbers
>> - passwords - numerical or alphanumerical
>>
>> See section "Custom Options" on
>> http://www.cups.org/documentation.php/spec-ppd.html
>
> Are there any other datatypes that might be needed often? The more
> precise an option is defined in the PPD, the better a gui can show
> it to the user (and prevent false entries).
>
> For example, Ricoh's "UserCode" option, which is basically an
> eight-digit number, but should be displayed as a string rather than a
> slider or spinbox. This is similar to the 'passcode' option, only in
> clear text. If it is exposed as a string, the dialog can not warn a user
> if he enters non-digit characters.
>
> If there is a need for additional types like this, we should try to get
> them into CUPS as soon as possible, otherwise all kinds of workarounds
> might get into the PPDs.
>
CUPS 1.4 seems to be shortly before beta and so shortly before feature
freeze. I do not kno whether we will get still something new in, but you
should try. Make a feature request for a new custom option, like for
example "code" which allows a string of digits in a given length range,
but with visible input of the code.
>
> > --- snip ---
> >
>> 3. "Quick Presets" button support
>> ---------------------------------
>>
>> There are two possibilities to describe such buttons in the PPD file
>> (and we should support both for maximum flexibility):
>>
>> a) One option in the PPD has to be selected to represent the quick
>> preset buttons in the default view of the OpenUsability printing dialog.
>> This option will not appear under the tags then, even if it is tagged
>> in the PPD. It must be an enumerated choice option where each choice
>> will make up one button. We will select it by using the following
>> keyword ONCE in the PPD file:
>>
>> *OPQuickPresetsOption: PrintoutMode
>>
>> In this example "PrintoutMode" is the option selected to make up the
>> buttons.
>>
>> In Foomatic we could add the tag
>>
>> <QuickPresets />
>>
>> to one option XML file to select the appropriate option.
>>
>> b) With special keywords we define each button and which options it
>> should set:
>>
>> *OPQuickPresetsButton Document/Office Document: "Resolution=600dpi
>> MediaType=Plain"
>> *OPQuickPresetsButton Photo/Photo: "Resolution=1200dpi MediaType=Glossy"
>> ...
>
> I think "*OPQuickPreset" suffices. It might not be implemented as
> buttons in all cases.
>
You mean simply to replace the keyword *OPQuickPresetsButton by
*OPQuickPreset here? I think this is a good idea. It is also shorter.
>
>> --- snip ---
> >
>> 5. Icons for options and choices
>> --------------------------------
>>
>> Let us also give the possibility to add an icon to every human-readable
>> text item in the dialog: option names, choice names, tag names. ...
>>
>> To not need to invent too many new keywords, let us simply add
>> "translations" with the language code "OPIcon" for option choices and
>> let them have the base-64-UU-encoded icon, either a PNG image or SVG
>> drawing as its code:
>>
>> *OPIcon.InputSlot Auto: "begin-base64 644 InputSlot-Auto.png
>> iVBORw0KGgoAAAANSUhEUgAAAOAAAAC6CAMAAACA5rFCAAADAFBMVEX/////
>> /8z/zP//zMz/zGb/zDP/zAD/mWb/mTP/mQD/Zmb/MzPM///M/8zM/zPMzP/M
>> zMzMzJnMzGbMzDPMzADMmf/MmczMmZnMmWbMmTPMmQDMZjPMZgCZzP+ZzMyZ
>> ...
>> 4SfnV38C83lfZ0FU5/N58n1aZI2z2fxfwOTVfkPrH2h/Luv33J7bc3tuz+25
>> Pbfn9tye25+5/T9t163O+/ghTQAAAABJRU5ErkJggg==
>> ===="
>> *End
>>
>> For main keywords lets use
>>
>> *OPIcon InputSlot: "begin-base64 644 InputSlot.png
>> iVBORw0KGgoAAAANSUhEUgAAAOAAAAC6CAMAAACA5rFCAAADAFBMVEX/////
>> ..."
>> *End
>
> Will those icons only be defined in the PPD files? This could mean that
> the options and tags have different icons for different printers
> (especially if they are from different vendors), which might be
> confusing. Wouldn't it make sense to have a set of standard icons for
> the most common options (such as PaperSize), and only use custom icons
> for options which are specific to a printer/vendor?
>
We can do it as follows:
We let the dialog provide standard icons, and they are used as long as
the appropriate option or choice in the PPD does not bring its own icon.
If neither the dialog nor the PPD has an icon, the option or choice
stays without icon.
In the specs we should give a list of the icons we provide and also info
about the desired size for icons provided by the PPD. The dialog should
scale icons which are of unsuitable size though.
>
>> For a manufacturer-specific picture (logo or so) let us use '*OPIcon
>> Manufacturer: "..."' and for a model-specific picture (image of the
>> printer or so) let us use '*OPIcon ModelName: "..."'.
>
> Where will the logo appear in the dialog? If we reserve space for it
> somewhere in the dialog, we should probably publish some some size
> restrictions for it (or at least an aspect ratio).
>
Yes, we should give an aspect ratio, perhaps even more than one scheme
(horizontal top banner, left side banner, ...).
Till
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Printing-architecture] Coding the Common Printing Dialog and its interface - PPD and Foomatic extensions
[not found] ` <8B8709E6C8B8784583FA9C7C013CB4515366F2@etd1.etd.ussj.ricoh.com>
@ 2008-05-01 18:17 ` Till Kamppeter
[not found] ` <8B8709E6C8B8784583FA9C7C013CB45142BBE6@etd1.etd.ussj.ricoh.com>
0 siblings, 1 reply; 5+ messages in thread
From: Till Kamppeter @ 2008-05-01 18:17 UTC (permalink / raw)
To: George Liu; +Cc: printing-architecture
Yes, this is the better way to do it, let's suggest that.
Till
George Liu wrote:
> CUPS custom PPD options (string) lacks AllowedChars, compared with
> foomatic-rip extension.
> Instead of adding a new type "Code", I'd like to suggest adding
> AllowedChars into CUPS custom PPD options.
>
> Ideally, CUPS custom PPD option will be used to generate GUI front end,
> and foomatic-rip will be used as backend script to consume the option.
> It's important that CUPS option and foomatic-rip extension comes in
> sync.
>
> George
>
>
> -----Original Message-----
> From: printing-architecture-bounces@lists.linux-foundation.org
> [mailto:printing-architecture-bounces@lists.linux-foundation.org] On
> Behalf Of Till Kamppeter
> Sent: Thursday, May 01, 2008 10:45 AM
> To: Lars Uebernickel
> Cc: printing-architecture@lists.linux-foundation.org
> Subject: Re: [Printing-architecture] Coding the Common Printing Dialog
> and its interface - PPD and Foomatic extensions
>
> Lars Uebernickel wrote:
>> Till Kamppeter wrote:
>>> Hi,
>>>
>>> here is my suggestion for part 1 of the specs, the extensions for
> PPDs:
>>>
>>> 1. Custom options/Advanced data types
>>> -------------------------------------
>>>
>>> We use the CUPS extensions for custom options, so that not only
> boolean
>>> and enumerated choice options are posible but also more advanced
> datatypes:
>>> - integer numbers
>>> - real numbers - interpreted linearly or exponentially, for example
> for
>>> color and brightness adjustments
>>> - lengths in points - for example for margin widths
>>> - strings - for example for user names and fax numbers
>>> - passwords - numerical or alphanumerical
>>>
>>> See section "Custom Options" on
>>> http://www.cups.org/documentation.php/spec-ppd.html
>> Are there any other datatypes that might be needed often? The more
>> precise an option is defined in the PPD, the better a gui can show
>> it to the user (and prevent false entries).
>>
>> For example, Ricoh's "UserCode" option, which is basically an
>> eight-digit number, but should be displayed as a string rather than a
>> slider or spinbox. This is similar to the 'passcode' option, only in
>> clear text. If it is exposed as a string, the dialog can not warn a
> user
>> if he enters non-digit characters.
>>
>> If there is a need for additional types like this, we should try to
> get
>> them into CUPS as soon as possible, otherwise all kinds of workarounds
>
>> might get into the PPDs.
>>
>
> CUPS 1.4 seems to be shortly before beta and so shortly before feature
> freeze. I do not kno whether we will get still something new in, but you
>
> should try. Make a feature request for a new custom option, like for
> example "code" which allows a string of digits in a given length range,
> but with visible input of the code.
>
>> > --- snip ---
>> >
>>> 3. "Quick Presets" button support
>>> ---------------------------------
>>>
>>> There are two possibilities to describe such buttons in the PPD file
>>> (and we should support both for maximum flexibility):
>>>
>>> a) One option in the PPD has to be selected to represent the quick
>>> preset buttons in the default view of the OpenUsability printing
> dialog.
>>> This option will not appear under the tags then, even if it is
> tagged
>>> in the PPD. It must be an enumerated choice option where each choice
>>> will make up one button. We will select it by using the following
>>> keyword ONCE in the PPD file:
>>>
>>> *OPQuickPresetsOption: PrintoutMode
>>>
>>> In this example "PrintoutMode" is the option selected to make up the
>>> buttons.
>>>
>>> In Foomatic we could add the tag
>>>
>>> <QuickPresets />
>>>
>>> to one option XML file to select the appropriate option.
>>>
>>> b) With special keywords we define each button and which options it
>>> should set:
>>>
>>> *OPQuickPresetsButton Document/Office Document: "Resolution=600dpi
>>> MediaType=Plain"
>>> *OPQuickPresetsButton Photo/Photo: "Resolution=1200dpi
> MediaType=Glossy"
>>> ...
>> I think "*OPQuickPreset" suffices. It might not be implemented as
>> buttons in all cases.
>>
>
> You mean simply to replace the keyword *OPQuickPresetsButton by
> *OPQuickPreset here? I think this is a good idea. It is also shorter.
>
>>> --- snip ---
>> >
>>> 5. Icons for options and choices
>>> --------------------------------
>>>
>>> Let us also give the possibility to add an icon to every
> human-readable
>>> text item in the dialog: option names, choice names, tag names. ...
>>>
>>> To not need to invent too many new keywords, let us simply add
>>> "translations" with the language code "OPIcon" for option choices and
>
>>> let them have the base-64-UU-encoded icon, either a PNG image or SVG
>>> drawing as its code:
>>>
>>> *OPIcon.InputSlot Auto: "begin-base64 644 InputSlot-Auto.png
>>> iVBORw0KGgoAAAANSUhEUgAAAOAAAAC6CAMAAACA5rFCAAADAFBMVEX/////
>>> /8z/zP//zMz/zGb/zDP/zAD/mWb/mTP/mQD/Zmb/MzPM///M/8zM/zPMzP/M
>>> zMzMzJnMzGbMzDPMzADMmf/MmczMmZnMmWbMmTPMmQDMZjPMZgCZzP+ZzMyZ
>>> ...
>>> 4SfnV38C83lfZ0FU5/N58n1aZI2z2fxfwOTVfkPrH2h/Luv33J7bc3tuz+25
>>> Pbfn9tye25+5/T9t163O+/ghTQAAAABJRU5ErkJggg==
>>> ===="
>>> *End
>>>
>>> For main keywords lets use
>>>
>>> *OPIcon InputSlot: "begin-base64 644 InputSlot.png
>>> iVBORw0KGgoAAAANSUhEUgAAAOAAAAC6CAMAAACA5rFCAAADAFBMVEX/////
>>> ..."
>>> *End
>> Will those icons only be defined in the PPD files? This could mean
> that
>> the options and tags have different icons for different printers
>> (especially if they are from different vendors), which might be
>> confusing. Wouldn't it make sense to have a set of standard icons for
>> the most common options (such as PaperSize), and only use custom icons
>
>> for options which are specific to a printer/vendor?
>>
>
> We can do it as follows:
>
> We let the dialog provide standard icons, and they are used as long as
> the appropriate option or choice in the PPD does not bring its own icon.
>
> If neither the dialog nor the PPD has an icon, the option or choice
> stays without icon.
>
> In the specs we should give a list of the icons we provide and also info
>
> about the desired size for icons provided by the PPD. The dialog should
> scale icons which are of unsuitable size though.
>
>>> For a manufacturer-specific picture (logo or so) let us use '*OPIcon
>>> Manufacturer: "..."' and for a model-specific picture (image of the
>>> printer or so) let us use '*OPIcon ModelName: "..."'.
>> Where will the logo appear in the dialog? If we reserve space for it
>> somewhere in the dialog, we should probably publish some some size
>> restrictions for it (or at least an aspect ratio).
>>
>
> Yes, we should give an aspect ratio, perhaps even more than one scheme
> (horizontal top banner, left side banner, ...).
>
> Till
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architectur
> e
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Printing-architecture] Coding the Common Printing Dialog and its interface - PPD and Foomatic extensions
[not found] ` <8B8709E6C8B8784583FA9C7C013CB45142BBE6@etd1.etd.ussj.ricoh.com>
@ 2008-05-02 21:21 ` Till Kamppeter
0 siblings, 0 replies; 5+ messages in thread
From: Till Kamppeter @ 2008-05-02 21:21 UTC (permalink / raw)
To: George Liu; +Cc: printing-architecture
George Liu wrote:
> I have posted my suggestion to CUPS feature request 1729
> http://cups.org/str.php?L1729+P0+S-2+C0+I0+E0+M10+Q
>
Please open a new feature request for that, STR 1729 is only about the
access to the custom options via the web interface, not about the design
of the options themselves.
> If my PPD has JobType=Normal/LockedPrint and LockedPrintPassword is
> using CUPS custom PPD option.
> Will the following constraints work?
>
> *UIConstraints: JobType=Normal LockedPrintPassword=Custom
>
Here you should better ask Mike Sweet on the cups-general mailing list.
Or you try it out.
Till
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-05-02 21:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-04-25 17:19 [Printing-architecture] Coding the Common Printing Dialog and its interface - PPD and Foomatic extensions Till Kamppeter
2008-05-01 16:21 ` Lars Uebernickel
2008-05-01 17:44 ` Till Kamppeter
[not found] ` <8B8709E6C8B8784583FA9C7C013CB4515366F2@etd1.etd.ussj.ricoh.com>
2008-05-01 18:17 ` Till Kamppeter
[not found] ` <8B8709E6C8B8784583FA9C7C013CB45142BBE6@etd1.etd.ussj.ricoh.com>
2008-05-02 21:21 ` Till Kamppeter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.