🚀 go-pugleaf

Niels,

There are two separate issues with FM (colour) output on a Windows
platform. First and foremost is that FM relies on the Windows GDI to
create the postscript output process. Thanks to MS, the GDI only
operates in a RGB world, so all of your FM colour definitions get
translated to RGB using a mathematical (imprecise) relationship. Note:
the process of going from CMYK to RGB is non-linear, so you can almost
never get back (CMYK > RGB > CMYK) to where you started from relying
on automatic features in the various applications. 

Also, this colour shifting can be exasperated (or minimized) by a FM
setting in the maker.ini file, GetLibraryColorRGBFromCMYK
>
>      GetLibraryColorRGBFromCMYK=Printing&Screen (like 5.1) will
>      get the RGB values converted from CMYK values both for screen display and
>      printing.
>
>      GetLibraryColorRGBFromCMYK=None (like 5.5) will get the RGB values
>      from the library color description for screen and print.
>
>      GetLibraryColorRGBFromCMYK=Printing (the 5.5.6 default) will get the
>      RGB values from the color library and print the converted RGB from
>      CMYK.
>
>      GetLibraryColorRGBFromCMYK=Screen (probably will never be used) will
>      display the converted RGB and print the RGB values from the library.

This function intervenes between FM and the GDI RGB conversion.

Finally, colours defined in an EPS are simply passed through the GDI
(i.e. it completely ignores the contents of an EPS), so you can end up
with multiple representations of the same colour that you thought was
the simple 96/95/0/1.

But that's not necessarily the end of the story. If you're going to be
outputting to a local device (laser or inkjet), there may be another
round of colour conversions (again, non-linear) coming into play. Most
inkjets are optimized for RGB input and then convert these to CMYK at
the ink-spitting end.

So it's kind of like trying to run to the start on a Mobius strip,
just when you think you're back to where you should be...