[texworks] Wishlist for pdf previewer

Stefan Löffler st.loeffler at gmail.com
Tue Nov 1 09:42:07 CET 2011


Hi,

On 2011-11-01 01:47, Paul A Norman wrote:
> I am not sure that the complications/complexities of entering the
> world of proper colour management is worth the result, where I feel
> that all we are probably actually looking for is an indication of
> likely outcomes so that colours producing likely grey scale conflicts
> can be adjusted in editing?

<academical discussion>
The question is: how do you convert colors to gray scale? Mathematically
speaking, how do you project a 3D color space (I'm omitting CMYK here)
into a 1D color space? Mathematically, there are uncountably many ways
of doing that (don't hold me to that "number" or ask for a proof ;)).
Popular choices are to take the lightness (L in HSL/V in HSV color
space), the luma (Y in YCbCr), something related to black (the K in
CMYK), or the average of R, G, and B. Each of them gives you a single,
"grayscale" value, but no two of them are the same in general. For a
comparison, see, e.g.,
http://en.wikipedia.org/wiki/HSL_and_HSV#Disadvantages or the
"Desaturate" dialog in the GIMP (and probably other image processing
applications).

So, there is no one gray scale. Since TeXworks is inherently
document-oriented and the most probable reason for checking a document
in gray scale is the intent to print it in gray scale (as you wrote
before), one would be interested in simulating how the document would
look like when printed. But that brings us to the question how the
printer handles colors - and we're in the middle of color management...

Alternatively, one could also ask for a feature to simulate the vision
of (partially) color-blind people - e.g., to check presentations or
documents for online distribution. But again, this depends on how your
computer screen handles colors...
</academical discussion>


> As the screens are nearly all effectively RGB something as simple as
> that may help on a Qt area draw routines perhaps?
>  http://twscript.paulanorman.com/downloads/?InsertColour

Yes, that ultimately we produce images in RGB color space, that are then
displayed on screen. So that would be where any postprocessing would
have to kick in. Note, though, that how things ultimately appear on your
screen depend on that screen. At least on mine, there are numerous
settings (on the hardware side, accessible through buttons at the
bottom), ranging from presets like "warm" or "cinema" over gamma curves
to color temperatures. So the internal RGB does not render the same
everywhere, either...

> May be if deemed necessary, CMYK workflow could be detected in the
> document's  xcolor or other package settings? But if someone is
> working towards CMYK output, then they are not seeing their colours on
> screen in the pdf properly any way? Or are there
> screens/graphic-drivers out there that have that degree
> of colour management?

Yes, there are screen/drivers capable of that, AFAIK. I've looked into
color management a bit a while back, but never had the nerve or the
money to actually create/use color profiles (in particular, since
everyone in my surrounding is not using it - so what's the point in
having perfectly calibrated devices when others don't and hence images
look different on their computers, anyway ;)).

> Something is nagging the back of my mind that Qt has some sort of
> draw/paint routine /convertToGrayScale/

I haven't seen such a thing yet. At least not in QColor (where I'd
expect such a routine).

-Stefan

PS: MuPDF does colorspace conversion internally, so we could borrow
their algorithm - at least that would make things consistent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20111101/dcf501ab/attachment-0001.html>


More information about the texworks mailing list