Re: [NTG-context] font expansion MkXL vs. MkIV

[Hans Hagen]

On 2/17/2020 10:56 PM, Pablo Rodriguez wrote:

On 2/17/20 7:49 PM, Hans Hagen wrote:

On 2/17/2020 4:51 PM, Pablo Rodriguez wrote:

[...]
Sorry if I hadn’t expressed myself accurately before. The issue here
isn’t having exactly the same output in both MkIV and MkXL. The real
problem is that characters are misplaced in MkXL with hz enabled. I
think this might be a bug.


hm, i uploaded a maybe better variant


Many thanks for the new version, Hans.

It works much better now. Dos the improvement come from the new
LuaMetaTeX binary?


not this time. its from usage

Hans

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] font expansion MkXL vs. MkIV

[Pablo Rodriguez]

On 2/17/20 7:49 PM, Hans Hagen wrote:
> On 2/17/2020 4:51 PM, Pablo Rodriguez wrote:
>> [...]
>> Sorry if I hadn’t expressed myself accurately before. The issue here
>> isn’t having exactly the same output in both MkIV and MkXL. The real
>> problem is that characters are misplaced in MkXL with hz enabled. I
>> think this might be a bug.
>
> hm, i uploaded a maybe better variant

Many thanks for the new version, Hans.

It works much better now. Dos the improvement come from the new
LuaMetaTeX binary?

Many thanks again,

Pablo
--
http://www.ousia.tk
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] font expansion MkXL vs. MkIV

[Hans Hagen]

On 2/17/2020 4:51 PM, Pablo Rodriguez wrote:

On 2/16/20 11:00 PM, Hans Hagen wrote:

[...]
in lmtx there is more precise handling of edge cases (protrusion) that
are ignored in mkiv ... so any difference that you observe can simply be
a side effect of tex deciding otherwise (because these calculations do
influence linebreaks)

anyway, you should use 'stretch' to because otherwise expansion and
protrusion has not enough options to do better (the linebreak third pass
that is)

\setupalign[hanging, stretch, hz]


Many thanks for your reply, Hans.

I’m afraid that "stretch" doesn’t make any difference with TeX Gyre
Heros (https://pdf.ousia.tk/stretch-mkxl-hz.pdf) and it only corrected
one problematic case with Source Serif Pro
(https://pdf.ousia.tk/stretch-ssp-mkxl-hz.pdf).

Sorry if I hadn’t expressed myself accurately before. The issue here
isn’t having exactly the same output in both MkIV and MkXL. The real
problem is that characters are misplaced in MkXL with hz enabled. I
think this might be a bug.

hm, i uploaded a maybe better variant

Hans


-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Any plans for an active color management?

[Hans Hagen]

On 2/17/2020 6:52 PM, Floris van Manen wrote:



On 17-02-2020 16:10, juh wrote:

At least, digital images are always RGB.

In my special case we started with a RGB corporate design as we are an
online cooperative. Print comes later.


The thing is that in print the CMYK will result in a fixed well defined
object: a physical  print on paper. That is then the reference.
The complete chain of getting the information into print is well defined.

Compare that to the world of digital monitor viewing.
None is well defined, every monitor and platform has its own unknown
settings. How would you translate those into a printed document?

So my point was that it might be more convenient to first create the
publication for print, then let individual pdf browsers do their trick
in their own environment rendering the CMYK into RGB or whatever...

indeed, start with cmyk when doing print

and given differences in displays one can then just be more tolerant in 
how it shows up on screen, as it's unpredictable anyway


Hans



-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Lucida small caps

[Henning Hraban Ramm]

> style={\sca},
> 
> What is the correct substitute for that?

Do your titles wear garb?
(SCA = Society for Creative Anachronism)

;D

HR
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Any plans for an active color management?

[Henning Hraban Ramm]

> Am 2020-02-17 um 17:57 schrieb Jan U. Hasecke :
> 
> I contacted three print shops and they demand three different color
> profiles, one of them prints on "100 % recycling paper" with an uncoated
> profile. The other two use ISO Coated v2 300% and Coated Fogra 39.

Oh my, the sick state of my industry…
But ISO Coated and Coated FOGRA are quite similar.

> Being online shops I think they will complain if not the right profile
> is provided. But anyway.

They probably won’t recognize if you use any or no profile...

> 1. All my images should be profiled. I think I can do this in Gimp.

✔︎

>> For type and logos I still rely on (device dependend) CMYK colors and
>> my experience how they’ll come out in Euroscale printing. 
> Device depended means what?

Not profiled.

I.e. the actual resulting color depends on the device, if it’s only defined as 
RGB or CMYK values, those don’t define a location in L*a*b color space without 
a profile.

> I did this to convert our RGB corporate colors to device depended CMYK:
> 
> transicc -i sRGB.icc -o Fogra/Iso-whatever.icc

Never used lcms, sorry. Always wanted to try...

> But what shall I do with the logo? It is a RGB SVG.

AFAIK SVG uses sRGB per definitionem.
But I don’t know what happens on conversion.

I just checked:
You can set an output intent color profile in Inkscape’s document settings, and 
the reference ends up in the SVG (with an absolute path).
If I define colors in CMYK, they get safed only as (HTML-style) RGB colors, but 
if I re-open the file, CMYK color values are still the same. Don’t know how 
Inkscape does it.
The exported PDF (using cairo) is not profiled (DeviceRGB color space).

(Around 2004 there was a discussion about CMYK or profile based colors in SVG. 
I used the preliminary standard for color definitions in SVGs that were meant 
for exchange between a Flash based online ad designer and our EPS based 
newspaper workflow. I was in the position to force the programmers of that 
horrible Flash app to export something adhering to open standards…  
But then the SVG-color stuff got delayed and finally declined. I think there 
are profile based colors possible now, but Inkscape as one of the main SVG 
players doesn’t support them…)

> Do I understand you correctly that the best would be to ask someone with
> Indesign to convert it to CMYK with the above cited profile chain?

Mmm, no. Acrobat Pro can do proper profile conversions of graphics. Don’t know 
another tool.

> Or shall I tell the designer: These are the values I need as CMYK, just
> do it.

Exactly ;) Unfortunately they can’t really do that with Inkscape.

>> Colors that you define in TeX or Metapost are a different problem. I
>> *think* they should use the output intent as their profile. But I
>> don’t know if the intent option of \setupcolors and/or \setupbackend
>> really works this way. (My only means to check was Acrobat Pro 9, and
>> that won’t run on a current macOS any more.)
> 
> I do it like this:
> 
> \startmode[fogra39]
> \definecolor  [hs-logoblau]   [c=1.000, m=0.735, y=0.279, k=0.160]
> \definecolor  [hs-dunkelblau] [c=0.844, m=0.544, y=0.070, k=0.000]
> \definecolor  [hs-hellblau]   [c=0.468, m=0.220, y=0.086, k=0.002]
> \definecolor  [hs-orange] [c=0.127, m=0.832, y=1.000, k=0.042]
> 
> \setupcolors[cmyk=yes,rgb=no,]

Try to set the same intent profile in \setupcolors. (It’s older than 
\setupbackend, and I actually don’t know what it does.)

> \setupbackend[
>   format=PDF/X-3:2003,
>   intent={Coated FOGRA39 (ISO 12647-2:2004)},
>   ]
> \stopmode

BTW: ConTeXt enforces some properties of the PDF/X standards, e.g. you don’t 
get transparencies with PDF/X-3. While InDesign would fake such effects 
(generating bitmaps), you just get plain colors with ConTeXt. That took me by 
surprise. *This* you can avoid with PDF/X-4, but I don’t know if that might 
cause different problems (e.g. printshop workflows that can’t handle it).

> I like your thought that all profiles are more or less the same.

No, that’s a misunderstanding. The several ISO/FOGRA Coated profiles *are* very 
close, as well as their Uncoated counterparts, but these groups are distinct.
If you let print on recyling/offset/copy paper, you need an Uncoated profile; 
if they use coated/silk/image… paper, you need an Coated profile. There are 
also different sets of spot colors for coated/uncoated paper.

> That would mean that my designer could convert our SVG logo and our SVG icons
> to Device-profiled CMYK-PDF and I am good.

Not device profiled, but device dependend, that means unprofiled. I’d expect 
unprofiled colors to use the default color space, and that would probably the 
right thing.

> Thanks for your help.

You’re welcome.

Best, Hraban


___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : 

Re: [NTG-context] Any plans for an active color management?

[Floris van Manen]

On 17-02-2020 16:10, juh wrote:
> At least, digital images are always RGB.
> 
> In my special case we started with a RGB corporate design as we are an
> online cooperative. Print comes later.

The thing is that in print the CMYK will result in a fixed well defined
object: a physical  print on paper. That is then the reference.
The complete chain of getting the information into print is well defined.

Compare that to the world of digital monitor viewing.
None is well defined, every monitor and platform has its own unknown
settings. How would you translate those into a printed document?

So my point was that it might be more convenient to first create the
publication for print, then let individual pdf browsers do their trick
in their own environment rendering the CMYK into RGB or whatever...

Unless it is fun to do both of course...

.F


pEpkey.asc
Description: application/pgp-keys
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

[NTG-context] Customizing \cite alternatives

[Philipp A.]

Hi List,

I want the comma gone from “et al.” citations, and modify the cite
alternatives:

   - [authoryear]: (Surname, et al., 2018) → (Surname et al., 2018)
   - [authoryears]: Surname, et al. (2018) → Surname et al. (2018)

Also I’d like to configure how many names are the maximum before all except
the first are replaced by “et al.”
i.e. \setupcitething[maxauthors=3]: (One, Two, Three, & Four, 2018) → (One
et al., 2018)

How can I do this? I didn’t find anything in the publications manual:
http://pragma-ade.nl/general/manuals/mkiv-publications.pdf

Best, Philipp
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Any plans for an active color management?

[Jan U. Hasecke]

Hi Henning Hraban,

I contacted three print shops and they demand three different color
profiles, one of them prints on "100 % recycling paper" with an uncoated
profile. The other two use ISO Coated v2 300% and Coated Fogra 39.

Being online shops I think they will complain if not the right profile
is provided. But anyway.

I will summarize:

Am 17.02.20 um 16:35 schrieb Henning Hraban Ramm:

> That means you should keep your photos in (profiled) RGB. Probably
> best use sRGB to stay device independend, because that’s default for
> monitors, even if printshops like Adobe RGB or one of the profiles
> that shrink the RGB color space to printable colors.

1. All my images should be profiled. I think I can do this in Gimp.

> For type and logos I still rely on (device dependend) CMYK colors and
> my experience how they’ll come out in Euroscale printing. 

Device depended means what?

I did this to convert our RGB corporate colors to device depended CMYK:

transicc -i sRGB.icc -o Fogra/Iso-whatever.icc

But what shall I do with the logo? It is a RGB SVG.

Do I understand you correctly that the best would be to ask someone with
Indesign to convert it to CMYK with the above cited profile chain?

Or shall I tell the designer: These are the values I need as CMYK, just
do it.

> Colors that you define in TeX or Metapost are a different problem. I
> *think* they should use the output intent as their profile. But I
> don’t know if the intent option of \setupcolors and/or \setupbackend
> really works this way. (My only means to check was Acrobat Pro 9, and
> that won’t run on a current macOS any more.)

I do it like this:

\startmode[fogra39]
\definecolor  [hs-logoblau]   [c=1.000, m=0.735, y=0.279, k=0.160]
\definecolor  [hs-dunkelblau] [c=0.844, m=0.544, y=0.070, k=0.000]
\definecolor  [hs-hellblau]   [c=0.468, m=0.220, y=0.086, k=0.002]
\definecolor  [hs-orange] [c=0.127, m=0.832, y=1.000, k=0.042]

\setupcolors[cmyk=yes,rgb=no,]

\setupbackend[
   format=PDF/X-3:2003,
   intent={Coated FOGRA39 (ISO 12647-2:2004)},
   ]
\stopmode


I like your thought that all profiles are more or less the same. That
would mean that my designer could convert our SVG logo and our SVG icons
to Device-profiled CMYK-PDF and I am good.
 Thanks for your help.
juh
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Lucida small caps

[Hans Hagen]

On 2/17/2020 4:48 PM, Mikael P. Sundqvist wrote:


style={\sca},

\tf\smallcaps

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] font expansion MkXL vs. MkIV

[Pablo Rodriguez]

On 2/16/20 11:00 PM, Hans Hagen wrote:
> [...]
> in lmtx there is more precise handling of edge cases (protrusion) that
> are ignored in mkiv ... so any difference that you observe can simply be
> a side effect of tex deciding otherwise (because these calculations do
> influence linebreaks)
>
> anyway, you should use 'stretch' to because otherwise expansion and
> protrusion has not enough options to do better (the linebreak third pass
> that is)
>
> \setupalign[hanging, stretch, hz]

Many thanks for your reply, Hans.

I’m afraid that "stretch" doesn’t make any difference with TeX Gyre
Heros (https://pdf.ousia.tk/stretch-mkxl-hz.pdf) and it only corrected
one problematic case with Source Serif Pro
(https://pdf.ousia.tk/stretch-ssp-mkxl-hz.pdf).

Sorry if I hadn’t expressed myself accurately before. The issue here
isn’t having exactly the same output in both MkIV and MkXL. The real
problem is that characters are misplaced in MkXL with hz enabled. I
think this might be a bug.

Many thanks for your help,

Pablo
--
http://www.ousia.tk
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Lucida small caps

[Mikael P. Sundqvist]

On Sun, Feb 16, 2020 at 11:34 AM Hans Hagen  wrote:

> On 2/15/2020 10:02 PM, Mikael P. Sundqvist wrote:
> > On Sat, Feb 15, 2020 at 9:50 PM Hans Hagen  > > wrote:
> >
> > On 2/15/2020 4:34 PM, Mikael P. Sundqvist wrote:
> >  > Hi,
> >  >
> >  > One can easily enable small caps when using lucida, see the old
> mail
> >  > https://mailman.ntg.nl/pipermail/ntg-context/2018/090997.html .
> >  >
> >  > Could this be added to the type script file?
> >
> > best use \smallcaps or somethign equivalent
>
> > Ah, so it was the \sc that was the problem. Thanks!
> \sc is more somthing mkii ... when type1 fonts (in an 8 bit universum)
> smallcaps and oldstyle and such meant using a different font
>
> nowadays one can turn them on/off as features and when you need them a
> lot you can even define an extra bodyfont variant from them and switch
> to that one when needed
>
> now, when smallcaps and oldstyle etc became features instead of font
> properties that didn't mean it always became easier because when
> opentype came around there was no 'recipe' or possibility to define what
> is default; for instance some fonts default to oldstyle in the sense
> that these shapes are in the default slots and you need to turn them off
> instead; also one needs to keep in mind that some features are language
> / script dependent and fonts differ in what they do default
>
> summary: see smallcaps as features but always look at what the font
> assumes and does by default; be prepared for inconsistencies (after all
> this is why we want/need control over what context does with a font)
>
> Hans
>
> -
>Hans Hagen | PRAGMA ADE
>Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
> tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
> -
>

That is good to know, thank you. While replacing all \sc with \smallcaps in
a document I work on, I realized that in a \setuphead I had

style={\sca},

What is the correct substitute for that?

/Mikael
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Any plans for an active color management?

[Henning Hraban Ramm]

Hi juh,

it doesn’t make sense to use device profiles of any printshop, since all the 
printshops in most of Europe are supposed to standardize on Euroscale CMYK (ISO 
Coated FOGRA##) while in the USA they use SWOP CMYK and in Japan their own 
standard. So you can stay with the same profiles as long as you stay on the 
continent.

The main difference in CMYK profiles is in relation to the general kind of 
paper: coated or uncoated or maybe newspaper / web offset.
(Web offset = Rollenoffset, no relation to the www / Coated = gestrichen, 
Bilderdruck / Uncoated = ungestrichen, Werkdruck/Naturpapier)

The difference between FOGRA27 and 39 is marginal, AFAIK. Use the latter.

If you use properly profiled RGB images, the printshop’s workflow software 
should convert them properly and consistently.

Conversion of CMYK colors (e.g. Euroscale to SWOP) is a serious problem, 
though. AFAIK the separation method (UCR/GCR) is not part of any standard.
Often I want some device dependent CMYK tone (like deep black: 30/0/0/100); if 
you convert that via L*a*b (even back to the same profile) you might get a 4c 
tone that’s harder to print and might look less clean, even if the measurable 
hue is the same.

That means you should keep your photos in (profiled) RGB. Probably best use 
sRGB to stay device independend, because that’s default for monitors, even if 
printshops like Adobe RGB or one of the profiles that shrink the RGB color 
space to printable colors.

For type and logos I still rely on (device dependend) CMYK colors and my 
experience how they’ll come out in Euroscale printing.
For an international project that should print the same e.g. in the US, in 
Europe and in Japan, I’d use differently defined graphics or Pantone spot 
colors. (I guess Pantone is the one spot color system that will work 
world-wide, even if HKS is still usual in Germany and Toyo in Japan.)
It could also work to use spot colors and have the printshop convert them to 
“their” CMYK profile.

Colors that you define in TeX or Metapost are a different problem. I *think* 
they should use the output intent as their profile. But I don’t know if the 
intent option of \setupcolors and/or \setupbackend really works this way. (My 
only means to check was Acrobat Pro 9, and that won’t run on a current macOS 
any more.)

Hope that helps a bit and doesn’t confuse you more…

Color management *is* hard.

Best, Hraban

> Am 2020-02-17 um 15:03 schrieb Jan U. Hasecke :
> 
> Hi all,
> 
> I would like to come back to a discussion from 2018 on this list.
> 
> After printing some flyers for my cooperative I come to the conclusion
> that color management *is* very difficult.
> 
> In my eyes, the only way of getting good results seems to be the
> following process.
> 
> My starting point are RGB colors as we are doing online first.
> 
> So if I create a poster or a flyer I have to do this:
> 
> 1. Decide which print shop will print the material.
> 
> 2. Download and install the color profile for this print shop in ConTeXt.
> 
> 3. Specify CMYK values by using transicc with the given profile
> 
> 4. Define named corporate colors with these CMYK values for typography,
> colored background in ConTeXt.
> 
> 5. Convert all RGB images to CMYK using the given color profile
> especially if they contain corporate colors.
> 
> Now if we decide to use another print shop, the whole process has to
> start again. The result is that I end up with color settings for x
> different print shops and cmyk images for x different print shops.
> 
> Are there any plans to automate these steps into ConTeXt? That would
> enable us to work in RGB the whole time. Only when creating a print pdf
> we would specify a color profile and ConTeXt would do the rest by
> converting all rgb values to cmyk values due to the given color profile.
> 
> As this seems very complex I fear that there are no plans to do this.
> 
> What alternatives I have?
> =
> 
> What if deliberately define my own cmyk values once and for all?
> 
> Can I work with the same cymk values no matter what profile is used by
> the print shop?
> 
> TIA
> juh
> ___
> If your question is of interest to others as well, please add an entry to the 
> Wiki!
> 
> maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
> archive  : https://bitbucket.org/phg/context-mirror/commits/
> wiki : http://contextgarden.net
> ___

___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : 

Re: [NTG-context] Any plans for an active color management?

[juh]

Floris van Manen writes:

> On 17-02-2020 15:39, Hans Hagen wrote:
>> On 2/17/2020 3:03 PM, Jan U. Hasecke wrote:
>> 
>>> Are there any plans to automate these steps into ConTeXt? That would
>>> enable us to work in RGB the whole time. Only when creating a print pdf
>>> we would specify a color profile and ConTeXt would do the rest by
>>> converting all rgb values to cmyk values due to the given color profile.
>> 
>> that would mean plugging some color transfer function into the rgb ->
>> cmyk conversion that is already there (but i never had to deal with
>> color transfer functions)
>> 
>>> As this seems very complex I fear that there are no plans to do this.
>> not unless i know exactly what to do (or am forced to use it myself)
>> 
>> can't you use spotcolors? these are kind of standardized (say pantone)
>
> As in print the default is CMYK, why not start there.
> The online might be RGB but all pdf viewers know how to deal with the
> convertion from CMYK to RGB by themselves.

At least, digital images are always RGB.

In my special case we started with a RGB corporate design as we are an
online cooperative. Print comes later.

(Strange I can't see the answer of Hans.)

Mit freundlichen Grüßen
Jan Ulrich Hasecke

-- 
Soziale Plastik. Die Kunst der Allmende
Essay zum 30. Todestag von Joseph Beuys
http://www.amazon.de/dp/1523458763/
Taschenbuch, 130 Seiten, EUR 9,90
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Any plans for an active color management?

[Floris van Manen]

On 17-02-2020 15:39, Hans Hagen wrote:
> On 2/17/2020 3:03 PM, Jan U. Hasecke wrote:
> 
>> Are there any plans to automate these steps into ConTeXt? That would
>> enable us to work in RGB the whole time. Only when creating a print pdf
>> we would specify a color profile and ConTeXt would do the rest by
>> converting all rgb values to cmyk values due to the given color profile.
> 
> that would mean plugging some color transfer function into the rgb ->
> cmyk conversion that is already there (but i never had to deal with
> color transfer functions)
> 
>> As this seems very complex I fear that there are no plans to do this.
> not unless i know exactly what to do (or am forced to use it myself)
> 
> can't you use spotcolors? these are kind of standardized (say pantone)

As in print the default is CMYK, why not start there.
The online might be RGB but all pdf viewers know how to deal with the
convertion from CMYK to RGB by themselves.

.F




pEpkey.asc
Description: application/pgp-keys
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Any plans for an active color management?

[Hans Hagen]

On 2/17/2020 3:03 PM, Jan U. Hasecke wrote:


Are there any plans to automate these steps into ConTeXt? That would
enable us to work in RGB the whole time. Only when creating a print pdf
we would specify a color profile and ConTeXt would do the rest by
converting all rgb values to cmyk values due to the given color profile.


that would mean plugging some color transfer function into the rgb -> 
cmyk conversion that is already there (but i never had to deal with 
color transfer functions)



As this seems very complex I fear that there are no plans to do this.

not unless i know exactly what to do (or am forced to use it myself)

can't you use spotcolors? these are kind of standardized (say pantone)

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

[NTG-context] Any plans for an active color management?

[Jan U. Hasecke]

Hi all,

I would like to come back to a discussion from 2018 on this list.

After printing some flyers for my cooperative I come to the conclusion
that color management *is* very difficult.

In my eyes, the only way of getting good results seems to be the
following process.

My starting point are RGB colors as we are doing online first.

So if I create a poster or a flyer I have to do this:

1. Decide which print shop will print the material.

2. Download and install the color profile for this print shop in ConTeXt.

3. Specify CMYK values by using transicc with the given profile

4. Define named corporate colors with these CMYK values for typography,
colored background in ConTeXt.

5. Convert all RGB images to CMYK using the given color profile
especially if they contain corporate colors.

Now if we decide to use another print shop, the whole process has to
start again. The result is that I end up with color settings for x
different print shops and cmyk images for x different print shops.

Are there any plans to automate these steps into ConTeXt? That would
enable us to work in RGB the whole time. Only when creating a print pdf
we would specify a color profile and ConTeXt would do the rest by
converting all rgb values to cmyk values due to the given color profile.

As this seems very complex I fear that there are no plans to do this.

What alternatives I have?
=

What if deliberately define my own cmyk values once and for all?

Can I work with the same cymk values no matter what profile is used by
the print shop?

TIA
juh
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] upload

[mf]

if you fetch from the web site you need to use /latest as we no longer 
have lpha, beta current ... maybe somthing got messed up in the git 
sync, i don't know



The git mirror is in sync again.
Thanks to anybody working on it.

Best wishes,
Massi
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___