All of lore.kernel.org
 help / color / mirror / Atom feed
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] [Translation] 10/23 minutues
Date: Wed, 29 Oct 2008 10:58:34 +0100	[thread overview]
Message-ID: <490833CA.8020902@gmail.com> (raw)
In-Reply-To: <490558B7.6030606@fujixerox.co.jp>

Osamu MIHARA wrote:
> o PDF printing discussion at Cairo summit
>    - They have discussed how to embed meta data, including job control,
>      into PDF.  Direction: add new API to embed meta data, which should
>      not be PDF specific.
>

The job control data set should be something like a JDF job ticket at 
best, or at least a string of key=value option settings. For the former 
we should implement the JTAPI ASAP.

On the Cairo Summit was only discussed about adding a function to insert 
arbitrary meta data into a PDF file generated by Cairo. How the job data 
looks like we have to determine.

The current PDF workflow requires the option settings to be submitted 
separately from the job data, for CUPS as IPP attributes. On some 
network printing protocols, like SMB or LPD this is not possible.

> o The theme next year
>    -ideas:
>      Print Job Control for PDF workflow.

See above, we should implement JTAPI for that.

>      Driver automatic search and install

This is mostly done. What is needed is;

  - A secure package signing concept, so that the distributions include
    the key for authenticating our binary packages. This we should do
    ASAP. We need to settle an agreement with at least SUSE, Red Hat, and
    Ubuntu.

>      Study Out of Box User Experience

Here we must see whether all our concepts really work as intended, but 
also see whether applications do printing the right way (using CUPS 
APIs, CPD, present PPD options, produce correct PostScript/PDF, ...)

>      Investigate Requirement for next LSB

Due to lack of manpower none of our LSB 4.0 proposals was taken into 
LSB. So simply go back to zero and re-propose them for 4.1. This time we 
need to find someone to implement test suites and to write specs 
(printer manufacturer?).

>      Color Management
> 

Windows and Mac support it on OS level AFAIK, Linux should support it, 
too. See recent discussion on OpenICC mailing list.

    Till


      reply	other threads:[~2008-10-29  9:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20081024.140846.71105530.sho@bbr.jp>
2008-10-27  5:59 ` [Printing-architecture] [Translation] [Printing-japan] 10/23 minutues Osamu MIHARA
2008-10-29  9:58   ` Till Kamppeter [this message]

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=490833CA.8020902@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.