All of lore.kernel.org
 help / color / mirror / Atom feed
From: Solomon Peachy <pizza@shaftnet.org>
To: Michael Sweet <msweet@msweet.org>
Cc: "printing-architecture@lists.linux-foundation.org"
	<printing-architecture@lists.linux-foundation.org>,
	Jay Berkenbilt <ejb@ql.org>, Vikrant Malik <vikrant@iitk.ac.in>,
	Till Kamppeter <till.kamppeter@gmail.com>
Subject: Re: [Printing-architecture] Make use of extended color spaces on IPP printers
Date: Sat, 8 May 2021 22:24:42 -0400	[thread overview]
Message-ID: <YJdH6p4ePqKSATLL@shaftnet.org> (raw)
In-Reply-To: <E783C6F3-AF3B-41C3-9432-88E23AF907D7@msweet.org>

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

On Sat, May 08, 2021 at 09:24:27PM -0400, Michael Sweet wrote:
> >    its native/preferred colorspace.  (It's called various things in 
> >    UIs, such as "disable color correction" or "host-managed color")
> > 2) The job *must* support embedding an arbitrary ICC profile
> 
> Not the Job.  The *Document*.

Thanks for the correction -- I'm not as familiar with the IPP 
terminology as I should be.

> > handful of colorspaces via ColorSpaceEnum; eg DeviceRGB, sRGB, and 
> > AdobeRGB.  This is a weakness vs JPEG or PDF (which allows arbitrary 
> > profiles.  Can we rely on that ColorSpace field being set correctly?
> 
> First, yes.  We've been doing so for years, even with Ghostscript 
> (which typically converts everything to sRGB).

Excellent.  But I'm thinking more of folks trying to print something 
from a random app on their their iOS or Android devices.  Having a rich 
standard doesn't help when the client implementations are all 
differently brain-dead. :)

> Second, it isn't a weakness to support well-known RGB color spaces 
> along with a device RGB color space. 

I'm sorry, that's not what I was trying to say.

The "weakness" is that the PWG raster format doesn't have a way to 
self-describe what "Device RGB" means, unlike more standalone image 
formats (eg jpeg, png, tiff) that have a standard method to embed ICC 
profiles.

Now if PWG raster data can only exist (or be submitted) within a 
"Document" that explicitly supports embedding an ICC profile, that's 
another matter, but that goes back to my worry about brain-damaged 
clients that don't do the right thing.

(And trying to accomodate those brainead clients possibly breaking stuff 
 that does properly adhere to the spec..)

> Printers that only support PWG/Apple raster really don't offer much in 
> the way of color management. 

True.

(But PWG raster is mandatory, lossless, and a lot less complicated to 
 implment than PDF or the TIFF abombination..)

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-05-09  2:24 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27 17:46 [Printing-architecture] Human-readable strings for standard IPP options/choices/attributes/propertirs Till Kamppeter
2021-04-27 18:02 ` Michael Sweet
2021-04-27 18:10   ` Till Kamppeter
2021-04-28  8:17   ` Till Kamppeter
2021-04-28 11:43     ` Michael Sweet
2021-05-07 18:52       ` [Printing-architecture] Make use of extended color spaces on IPP printers Till Kamppeter
2021-05-07 19:53         ` Michael Sweet
2021-05-07 22:11           ` Till Kamppeter
2021-05-08  0:04             ` Michael Sweet
2021-05-08 23:52             ` Solomon Peachy
2021-05-09  1:24               ` Michael Sweet
2021-05-09  2:24                 ` Solomon Peachy [this message]
2021-05-09  2:54                   ` Michael Sweet
2021-05-09  8:20                     ` Till Kamppeter
2021-05-09 13:41                       ` Michael Sweet
2021-05-09 14:03                         ` Solomon Peachy
2021-05-09 20:32                           ` Michael Sweet
2021-05-09 19:26                         ` Till Kamppeter
2021-05-09 20:34                           ` Michael Sweet
2021-05-09 20:43                             ` Till Kamppeter
2021-05-09 21:03                               ` Michael Sweet
2021-05-08 22:45           ` Till Kamppeter
2021-05-09  1:38             ` Solomon Peachy
2021-05-09  9:20               ` Till Kamppeter
2021-05-09 13:49                 ` Michael Sweet
2021-05-09 20:14                   ` Till Kamppeter
2021-05-09 20:55                     ` Michael Sweet
2021-05-09 21:31                       ` Till Kamppeter
2021-05-10  1:08                         ` Michael Sweet
2021-05-27 18:04                   ` Till Kamppeter
2021-05-27 19:04                     ` Solomon Peachy
2021-05-28 12:59                     ` Michael Sweet
2021-05-29 19:19                       ` Till Kamppeter
2021-05-29 22:32                         ` Michael Sweet
2021-05-30 19:56                           ` Till Kamppeter
2021-05-30 20:53                             ` Michael Sweet
2021-05-30 21:50                               ` Till Kamppeter
2021-05-31  3:12                                 ` Michael Sweet
     [not found]                                   ` <d5082b23-8eb7-be84-db5c-42bdde3ba5ac@canonical.com>
2021-05-31 13:24                                     ` Michael Sweet
2021-05-31 15:03                                       ` Till Kamppeter
2021-05-31 18:13                                         ` Michael Sweet
2021-05-31 19:38                                           ` Till Kamppeter
2021-06-01  0:54                                             ` Michael Sweet
2021-05-25 17:43         ` Till Kamppeter

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=YJdH6p4ePqKSATLL@shaftnet.org \
    --to=pizza@shaftnet.org \
    --cc=ejb@ql.org \
    --cc=msweet@msweet.org \
    --cc=printing-architecture@lists.linux-foundation.org \
    --cc=till.kamppeter@gmail.com \
    --cc=vikrant@iitk.ac.in \
    /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.