From: Till Kamppeter <till.kamppeter@gmail.com>
To: Osamu MIHARA <osamu.mihara@fujixerox.co.jp>
Cc: printing-architecture@lists.linux-foundation.org,
printing-japan@lists.linux-foundation.org
Subject: Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan June Meeting Minutes
Date: Wed, 25 Jun 2008 23:39:40 +0200 [thread overview]
Message-ID: <4862BB1C.60500@gmail.com> (raw)
In-Reply-To: <485F6319.8060101@fujixerox.co.jp>
Thank you for the review of the specs. I have improved the specs and
given my comments below.
Osamu MIHARA wrote:
> (4) CPD Specification Review
> ----------------------------
[...]
> ==== PPD Extensions ====
> - Quick Presets
> The definition should be in formal matter such as BNF.
>
I think BNF is somewhat overkill for the mostly one-line expressions in
the PPD file. I have now added man-page-like syntax schemes with
descriptions of the elements.
> Need more explanation for each items, in special a) in Quick Presets
> (no one can understand relationship of a) and b)).
>
I have added an introduction telling what the quick preset buttons are.
To simplify, I have dropped a) now. If a driver developer wants to
control exactly one option with the quick preset buttons, he lets each
button only set that one option to a value appropriate to the button.
> Need detail explanation for Lecacy case
>
I have improved these explanations now.
> - Option Tagging
> Is it a MUST item? What happens for a PPD without tagging?
>
It is not a MUST. A legacy fallback based on the option groups as
proposed by the Adobe specs is provided. But using tags is highly
recommended.
> - Icons for options and chises
> Icons should be switched based on language settings.
>
As it is intended for now the icons should play more or less the role of
icons in the menus and toolbars of desktop applications. These are
pictograms without any text to be used with any language, so icon sets
for different languages are not needed.
Please tell me what you would like to put into icons and logos and why
you want to have the language-dependent?
Till
next prev parent reply other threads:[~2008-06-25 21:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <001b01c8d263$64a884a0$9e72150a@nsl.ad.nec.co.jp>
[not found] ` <485B44C5.4000509@gmail.com>
[not found] ` <485B5347.3090408@fujixerox.co.jp>
2008-06-20 9:00 ` [Printing-architecture] [Printing-japan] OpenPrinting Japan June Meeting Minutes Osamu MIHARA
2008-06-23 8:47 ` Osamu MIHARA
2008-06-23 9:38 ` Lars Uebernickel
2008-06-23 21:50 ` Till Kamppeter
2008-06-23 21:50 ` Till Kamppeter
2008-06-25 21:39 ` Till Kamppeter [this message]
2008-06-25 23:53 ` Olaf Meeuwissen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4862BB1C.60500@gmail.com \
--to=till.kamppeter@gmail.com \
--cc=osamu.mihara@fujixerox.co.jp \
--cc=printing-architecture@lists.linux-foundation.org \
--cc=printing-japan@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.