3:33 p.m.
Jan-Peter wrote
Olaf Drümmer wrote:
(I don´t now
any serious colormanagement expert, who says proofing of
RGB-data is yet possible)
what about PDF/X-3? Five Digitalproof-Forum events
have proven that the
majority of proofing systems can do this.
Olaf
Hello Olaf, hello List
The PDF/X-3 approach for proofing simulates the gamut of the
output-Intent in combination with gamut-mapping of the output-intent and
the rendering intent defined for the RGB-data.
The ISO-standard PDF/X-3 gives no definition, if the user can expect
usable results, if he uses instead of the output-intent a different profile.
The main problem are the different Lab->CMYK conversion strategies from
the profile vendores for:
- gamutmapping of saturated colors
- lightness compression
- greybalance in conjunction to the paperwhite
If we want to have a proof of RGB-data, this must be embedded in a
workflow definition, where the user can expect predictable results if
the RGB-data is converted to different output conditions.
The ICC-specs (incl. the implementation in the Adobe PDF-specs and the
ISO-standard PDF/X-3) are far away to be a reliable and robust framework
for fully automated colormanagement-workflows.
This concerns especially colors and workflows, which are touched by the
different Lab-CMYK conversion strategies:
- very saturated colors
- overal gradation (lightnes compression)
- greybalance, if RGB-data is converted to output condition with
different paperwhites
- numeric control of corporate colors and product-colors in the RGB-file
This are some points, which have to be fixed first in the ICC-specs,
then in the Adobe PDF-specs and after this in the ISO-standard PDF/X-3,
if colormanagement with RGB-data should be predictable, robust and reliable
:-) Jan-Peter
--
--
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann@colormanagement.de
--
--
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann@colormanagement.de
6:41 p.m.
New subject: Proof of RGB-Data (was CM 2006...)
Hello Jan-Peter,
I thought we discussed that point already ?!?
All you are referring to is ambiguity in the case that *different*
printing profiles are used which, as you know, is prohibited in a pdf/
x-3 workflow.
At that point all your remarks regarding different color appearence
depending on rendering intent and profiles used for the RGB to CMYK
conversion are *not* valid in a pdf/x-3 workflow where source (RGB-
profile), rendering intent and target (CMYK/output condition profile
of the PDF/X-3) file are defined.
Once all three parameters (source-profile, target-profile and
rendering intent) are defined the user (e.g. prepress house or
graphic designer) can verify the to be expected color appearance of
the choosen printing condition via softproof in Adobe Acrobat or on a
proofing system.
No color ambiguity - not here.
Best regards,
Florian
Am 06.12.2005 um 15:33 schrieb Jan-Peter Homann:
Jan-Peter wrote
Olaf Drümmer wrote:
--
Florian Suessl, Director Technology
MetaDesign AG, Leibnizstrasse 65, 10629 Berlin
+49 30 59 00 54 246, fax +49 30 59 00 54 114
fsuessl(a)metadesign.de, http://www.metadesign.de, www.metaprintcheck.de
(I don´t
now any serious colormanagement expert, who says
proofing of
RGB-data is yet possible)
what about PDF/X-3? Five Digitalproof-Forum
events have proven
that the
majority of proofing systems can do this.
Olaf
Hello Olaf, hello List
The PDF/X-3 approach for proofing simulates the gamut of the
output-Intent in combination with gamut-mapping of the output-
intent and
the rendering intent defined for the RGB-data.
The ISO-standard PDF/X-3 gives no definition, if the user can expect
usable results, if he uses instead of the output-intent a different
profile.
The main problem are the different Lab->CMYK conversion strategies
from
the profile vendores for:
- gamutmapping of saturated colors
- lightness compression
- greybalance in conjunction to the paperwhite
If we want to have a proof of RGB-data, this must be embedded in a
workflow definition, where the user can expect predictable results if
the RGB-data is converted to different output conditions.
The ICC-specs (incl. the implementation in the Adobe PDF-specs and the
ISO-standard PDF/X-3) are far away to be a reliable and robust
framework
for fully automated colormanagement-workflows.
This concerns especially colors and workflows, which are touched by
the
different Lab-CMYK conversion strategies:
- very saturated colors
- overal gradation (lightnes compression)
- greybalance, if RGB-data is converted to output condition with
different paperwhites
- numeric control of corporate colors and product-colors in the RGB-
file
This are some points, which have to be fixed first in the ICC-
specs, then in the Adobe PDF-specs and after this in the ISO-
standard PDF/X-3, if colormanagement with RGB-data should be
predictable, robust and reliable
:-) Jan-Peter
--
--
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann@colormanagement.de
--
--
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann@colormanagement.de
_______________________________________________
ECI-EN mailing list
ECI-EN(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci-en
8:33 p.m.
New subject: Proof of RGB-Data (was CM 2006...)
Hello all,
Florian Süßl wrote:
Hello Jan-Peter,
I thought we discussed that point already ?!?
yes, e.g. in July in the german list (thread "Acrobat 7 vs. Distiller 7
- Output Intents") ... with a deflating conclusion IMHO.
All you are referring to is ambiguity in the case that *different*
printing profiles are used which, as you know, is prohibited in a pdf/
x-3 workflow.
At that point all your remarks regarding different color appearence
depending on rendering intent and profiles used for the RGB to CMYK
conversion are *not* valid in a pdf/x-3 workflow where source (RGB-
profile), rendering intent and target (CMYK/output condition profile of
the PDF/X-3) file are defined.
Once all three parameters (source-profile, target-profile and rendering
intent) are defined the user (e.g. prepress house or graphic designer)
can verify the to be expected color appearance of the choosen printing
condition via softproof in Adobe Acrobat or on a proofing system.
- PDF/X-3 does not force the use of a target-profile, but an
OutputIntents, which *can* contain a DestOutputProfile.
- Distiller 7 does not allow to set the OutputConditionIdentifier and
Registry correctly (e.g. to "FOGRA27") if you want to use *any* Profiles
other than those provided by Adobe (e.g. "EuropeISOCoatedFOGRA27"). This
behavior is *hardcoded* in acrodistdll!
This means that if you are working with eci IsoCoated or any ohter
Profile based on Forga27 and want to use Distiller or Indesing to create
the X3, yo can *eiter* embed ther correct profile *or* set the
"OutputConditionIdentifier" and "Registry" fileds correctly.
There are workarouds (e.g. using MacOSX Colorsync Filters to create the
X3 or convert every PDF to X3 using Acrobat's Prefligt tools), but
IMHO Distiller's behaves more than strange and is finally useless to
create fully-fledged X3s.
No color ambiguity - not here.
IMHO this is practically not more than wishful thinking today. I would
be already happy if the "blind excange" of PDF/X-1a (or CMYK-Based X-3)
would flow smoothly in either case -- but I still hope for a better
future :-)
Best regards,
Florian
Best Regards,
Klaus
10:47 p.m.
New subject: Proof of RGB-Data (was CM 2006...)
Hello Mr. Karcher,
Please find my comments below ...
Best regards,
Florian Suessl
Am 06.12.2005 um 20:33 schrieb Klaus Karcher:
--
Florian Suessl, Director Technology
MetaDesign AG, Leibnizstrasse 65, 10629 Berlin
+49 30 59 00 54 246, fax +49 30 59 00 54 114
fsuessl(a)metadesign.de, http://www.metadesign.de, www.metaprintcheck.de
Hello all,
Florian Süßl wrote:
this is only true if the
pdf/x-3 file contains cmyk and spot color only.
in the case of non CMYK such as CIELAB and color characterized RGB
the outputIntent profile is a must and *not* an option in a PDF/X-3 file
Hello Jan-Peter,
I thought we discussed that point already ?!?
yes, e.g. in July in the german list (thread "Acrobat 7 vs.
Distiller 7 - Output Intents") ... with a deflating conclusion IMHO.
All you are referring to is ambiguity in the case
that
*different* printing profiles are used which, as you know, is
prohibited in a pdf/ x-3 workflow.
At that point all your remarks regarding different color
appearence depending on rendering intent and profiles used for
the RGB to CMYK conversion are *not* valid in a pdf/x-3 workflow
where source (RGB- profile), rendering intent and target (CMYK/
output condition profile of the PDF/X-3) file are defined.
Once all three parameters (source-profile, target-profile and
rendering intent) are defined the user (e.g. prepress house or
graphic designer) can verify the to be expected color appearance
of the choosen printing condition via softproof in Adobe Acrobat
or on a proofing system.
- PDF/X-3 does not force the use of a target-profile, but an
OutputIntents, which *can* contain a DestOutputProfile.
- Distiller 7 does not allow to set the OutputConditionIdentifier
and Registry correctly (e.g. to "FOGRA27") if you want to use *any*
Profiles other than those provided by Adobe (e.g.
"EuropeISOCoatedFOGRA27"). This behavior is *hardcoded* in
acrodistdll!
This is a bug and not intenionally - and of course bugs need to be
fixed.
However creating a valid pdf/x-3 is not rocket science: Acrobat
Professional offers the respective option via an icon in the lower
left corner of the preflight window.
This means that if you are working with eci IsoCoated or any ohter
Profile based on Forga27 and want to use Distiller or Indesing to
create the X3, yo can *eiter* embed ther correct profile *or* set
the "OutputConditionIdentifier" and "Registry" fileds correctly.
As mentioned above - bugs need to be fixed but as there is a
workaround this is no show stopper.
There are workarouds (e.g. using MacOSX Colorsync Filters to create
the X3 or convert every PDF to X3 using Acrobat's Prefligt
tools), but IMHO Distiller's behaves more than strange and is
finally useless to create fully-fledged X3s.
with regard to Jan-Peter's example I completely disagree.
Once a pdf/x-3 is created it's color appearence is identical with the
color appearance of a pdf/x-1 with the same color conversions
conducted prior to the pdf creation.
If I get your point correctly I would like to agree: As long as the
properties of (pdf-)files - regardless whether they are pdf/x-1 or
pdf/x-3 - are changed at output stage, there will be suboptimal final
printed output (colorwice causing a mismatch between proof and print).
Interventions by the CtP RIP such as ignoring the overprint settings
of the pdf (happened with overprinting black turned to cut out in a
huge print job), ignoring profiles etc. may or may not be the right
choice.
But these problems are not caused by the pdf/x standard - things like
that happened and happen with open files as well.
No color ambiguity - not here.
IMHO this is practically not more than wishful thinking today. I
would be already happy if the "blind excange" of PDF/X-1a (or CMYK-
Based X-3) would flow smoothly in either case -- but I still hope
for a better future :-) Best regards,
Florian
Best Regards,
Klaus
_______________________________________________
ECI-EN mailing list
ECI-EN(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci-en
7:30 a.m.
New subject: Re(2): Re: Proof of RGB-Data (was CM 2006...)
Hallo,
karcher(a)schrift-und-form.de wrote Tue, 6 Dec 2005 20:33:30 +0100
- PDF/X-3 does not force the use of a target-profile,
but an
OutputIntents, which *can* contain a DestOutputProfile.
in the case conversion for at least some of the content in a PDF/X-3
file is needed - because it is using a device independent color like ICC
based RGB or Lab - a destination profile MUST be included in the
OutputIntent, otherwise it is not a valid PDF/X-3 profile.
A destination profile may only be omitted, if there is only DeviceGray/
DeviceCMYK and/or spot colors being used in the PDF/X-3 file - but then
no conversion to the destination is necessary, and thus a destination
profile is not required.
Olaf Druemmer
7:38 a.m.
New subject: Re(2): Re: Proof of RGB-Data (was CM 2006...)
karcher(a)schrift-und-form.de wrote Tue, 6 Dec 2005 20:33:30 +0100
IMHO this is practically not more than wishful thinking
today. I would
be already happy if the "blind excange" of PDF/X-1a (or CMYK-Based X-3)
would flow smoothly in either case -- but I still hope for a better
future :-)
admittedly there are still a few glitches in the software that is
available today. At least using Preflight in Acrobat 7 Professional will
allow you to have a properly identified FOGRA27 printing condition
together with profile of your choice, e.g. ISO coated (or any other
profile that reflects FOGRA27).
Nevertheless if I would follow your reasoning I'd have to say: let's go
back to copydot.
For one reason or another I do not believe this would be a wise move.
Instead, after having updated hardware and software such that it __can__
deal with both PDF/X-1a and PDF/X-3 properly (and after hoping that the
industry actually buys and installs them), we may have update the
firmware in the brains of those in charge of using all this. If this
firmware doesn't get updated we will not get anywhere, but then this is
true for any new technology.
If those used to punching holes in punch cards on mainframe
computers more than twenty years ago would have insisted on keeping
punching holes, monitors would not have worked the way they had been
designed. Of course you could have said monitors just don't work.
Olaf Druemmer
2:43 p.m.
New subject: What is late binding ? (was Proof of RGB-Data...)
Hello Florian
The main point we have to discuss is a definition of "late binding"
classical definition of late binding
--------------------------------------
Reseparating a delivered PDF-file in the printing house to a colorspace
chosen by the printing house.
PDF/X-3 definition of late binding
----------------------------------
"Color-Flattening" a PDF-file which contains objects in ICCbased
colorspace to the colorspace of the outputintent defined by the CREATOR
(!!) of the PDF-file.
Many years, the PDF/X-3 evangelist praised, that PDF/X-3 gives the
creator of the PDF-file and printing house the option of late binding in
a classical definition.
Today a failure less PDF/X-3 work flow would gives the guarantee, that
the separation in the RIP is identical to the colormanagement settings
in the layout-application. From the view off the creator, it would make
no difference, if he does the "color-flattening" in the
layout-application and delivers PDF/X-1a or if he delivers PDF/X-3 and
the "color-flattening" is done in the printing-house.
The result would be always the same.
The big questions are:
------------------------
1) Are there any advantages to do the "color-flattening" at the side of
the printing-house ?
My answer: No
2) Is the workflow with exchange of ICCbased PDF/X-3 files robust and
reliable like a PDF/X-1a workflow ?
My answer: No
In my view the ISO-standard PDF/X-3 must be rewritten, that it gives the
possibility of late binding in a classical way.
Otherwise the ISO standard PDF/X-3 is useless and introduces additional
sources of failures into the data exchange between the creator of PDF/X
files and the printing house.
Classical late binding with PDF/X-1a
---------------------------
As Florian wrote, PDF/X-3 is not suitable for late binding in a
classical definition. But today, several printing houses are already
doing late binding for delivered PDF/X files.
The key technology for doing this, is delivering of pure CMYK PDF/X in a
defined colorspace (e.g. PDF/X-1a) and the usage of a tailormade
devicelink-profile for the transformation into the colorspace chosen by
the printing house.
This is the only technology, offering identical transformations both for
images and vector graphics, addressing the colormanagement for corporate
colors and product colors and which has clear clear tasks for quality
assessment of the complete colortransformation from source to destination.
RGB-workflow vs. PDF/X-1a with devicelink-profiles
---------------------------------------------------
RGB-workflows are fine for photographers and postproduction for digital
images.
If we want to build workflows for colorconversion of complete files for
printing, the combination of PDF/X-1a and devicelink-profiles is the
adequate technology.
For which tasks, PDF/X-3 should be choosen ?
--------------------------------------------
I don´t know any real world task, where PDF/X-3 has advantages in
comparison with PDF/X-1a and the optional usage of devicelink-profiles.
So ask the PDF/X-3 for their view and build your own opinion.
Florian Süßl wrote:
Hello Jan-Peter,
I thought we discussed that point already ?!?
All you are referring to is ambiguity in the case that *different*
printing profiles are used which, as you know, is prohibited in a pdf/
x-3 workflow.
At that point all your remarks regarding different color appearence
depending on rendering intent and profiles used for the RGB to CMYK
conversion are *not* valid in a pdf/x-3 workflow where source (RGB-
profile), rendering intent and target (CMYK/output condition profile of
the PDF/X-3) file are defined.
Once all three parameters (source-profile, target-profile and rendering
intent) are defined the user (e.g. prepress house or graphic designer)
can verify the to be expected color appearance of the choosen printing
condition via softproof in Adobe Acrobat or on a proofing system.
No color ambiguity - not here.
Best regards,
Florian
Am 06.12.2005 um 15:33 schrieb Jan-Peter Homann:
> Jan-Peter wrote
> This concerns especially colors and workflows,
which are touched by the
> different Lab-CMYK conversion strategies:
> - very saturated colors
> - overal gradation (lightnes compression)
> - greybalance, if RGB-data is converted to output condition with
> different paperwhites
> - numeric control of corporate colors and product-colors in the RGB- file
>
> This are some points, which have to be fixed first in the ICC- specs,
> then in the Adobe PDF-specs and after this in the ISO- standard
> PDF/X-3, if colormanagement with RGB-data should be predictable,
> robust and reliable
--
--
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann@colormanagement.de
3:30 p.m.
New subject: What is late binding ? (was Proof of RGB-Data...)
Dear Jan-Peter,
frankly said I have problems to follow your argumentation.
Starting point were problems in conjunction with PDF/X-3
- now you ask about advantages ...
I do not want to discuss your, or as you say 'the traditional'
understanding of late binding.
PDF/X-3 has a clearly defined way with zero color ambiguity - late
binding in the concept of pdf/x-3 clearly defines that the one and
only profile to use is the output intent profile.
Your discussion of problems caused by using different printing
profiles is another story - please do not mix the topics!
The problems you describe will be the same if you start with a PDF/
X-1 file and convert the CMYK values to another print profile.
This is a discussion of concepts which, from my point of view is easy
to answer: - both (early and late binding as defined by pdf/x-3) are
possible due to existing software capabilities.
It is up to the user to choose.
Best regards,
Florian
Am 07.12.2005 um 14:43 schrieb Jan-Peter Homann:
Hello Florian
The main point we have to discuss is a definition of "late binding"
classical definition of late binding
--------------------------------------
Reseparating a delivered PDF-file in the printing house to a
colorspace chosen by the printing house.
PDF/X-3 definition of late binding
----------------------------------
"Color-Flattening" a PDF-file which contains objects in ICCbased
colorspace to the colorspace of the outputintent defined by the
CREATOR (!!) of the PDF-file.
Many years, the PDF/X-3 evangelist praised, that PDF/X-3 gives the
creator of the PDF-file and printing house the option of late
binding in a classical definition.
Today a failure less PDF/X-3 work flow would gives the guarantee,
that the separation in the RIP is identical to the colormanagement
settings in the layout-application. From the view off the creator,
it would make no difference, if he does the "color-flattening" in
the layout-application and delivers PDF/X-1a or if he delivers PDF/
X-3 and the "color-flattening" is done in the printing-house.
The result would be always the same.
The big questions are:
------------------------
1) Are there any advantages to do the "color-flattening" at the
side of the printing-house ?
My answer: No
2) Is the workflow with exchange of ICCbased PDF/X-3 files robust
and reliable like a PDF/X-1a workflow ?
My answer: No
In my view the ISO-standard PDF/X-3 must be rewritten, that it
gives the possibility of late binding in a classical way.
Otherwise the ISO standard PDF/X-3 is useless and introduces
additional sources of failures into the data exchange between the
creator of PDF/X files and the printing house.
Classical late binding with PDF/X-1a
---------------------------
As Florian wrote, PDF/X-3 is not suitable for late binding in a
classical definition. But today, several printing houses are
already doing late binding for delivered PDF/X files.
The key technology for doing this, is delivering of pure CMYK PDF/X
in a defined colorspace (e.g. PDF/X-1a) and the usage of a
tailormade devicelink-profile for the transformation into the
colorspace chosen by the printing house.
This is the only technology, offering identical transformations
both for images and vector graphics, addressing the colormanagement
for corporate colors and product colors and which has clear clear
tasks for quality assessment of the complete colortransformation
from source to destination.
RGB-workflow vs. PDF/X-1a with devicelink-profiles
---------------------------------------------------
RGB-workflows are fine for photographers and postproduction for
digital images.
If we want to build workflows for colorconversion of complete files
for printing, the combination of PDF/X-1a and devicelink-profiles
is the adequate technology.
For which tasks, PDF/X-3 should be choosen ?
--------------------------------------------
I don´t know any real world task, where PDF/X-3 has advantages in
comparison with PDF/X-1a and the optional usage of devicelink-
profiles.
So ask the PDF/X-3 for their view and build your own opinion.
Florian Süßl wrote:
--
Florian Suessl, Director Technology
MetaDesign AG, Leibnizstrasse 65, 10629 Berlin
+49 30 59 00 54 246, fax +49 30 59 00 54 114
fsuessl(a)metadesign.de, http://www.metadesign.de, www.metaprintcheck.de
Hello Jan-Peter,
I thought we discussed that point already ?!?
All you are referring to is ambiguity in the case that
*different* printing profiles are used which, as you know, is
prohibited in a pdf/ x-3 workflow.
At that point all your remarks regarding different color
appearence depending on rendering intent and profiles used for
the RGB to CMYK conversion are *not* valid in a pdf/x-3 workflow
where source (RGB- profile), rendering intent and target (CMYK/
output condition profile of the PDF/X-3) file are defined.
Once all three parameters (source-profile, target-profile and
rendering intent) are defined the user (e.g. prepress house or
graphic designer) can verify the to be expected color appearance
of the choosen printing condition via softproof in Adobe Acrobat
or on a proofing system.
No color ambiguity - not here.
Best regards,
Florian
Am 06.12.2005 um 15:33 schrieb Jan-Peter Homann:
> Jan-Peter wrote
> This concerns especially colors and
workflows, which are touched
> by the
> different Lab-CMYK conversion strategies:
> - very saturated colors
> - overal gradation (lightnes compression)
> - greybalance, if RGB-data is converted to output condition with
> different paperwhites
> - numeric control of corporate colors and product-colors in the
> RGB- file
>
> This are some points, which have to be fixed first in the ICC-
> specs, then in the Adobe PDF-specs and after this in the ISO-
> standard PDF/X-3, if colormanagement with RGB-data should be
> predictable, robust and reliable
--
--
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann@colormanagement.de
_______________________________________________
ECI-EN mailing list
ECI-EN(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci-en
4:41 p.m.
New subject: What is late binding ? (was Proof of RGB-Data...)
Florian Süßl wrote:
Dear Jan-Peter,
frankly said I have problems to follow your argumentation.
Starting point were problems in conjunction with PDF/X-3
- now you ask about advantages ...
I do not want to discuss your, or as you say 'the traditional'
understanding of late binding.
PDF/X-3 has a clearly defined way with zero color ambiguity - late
binding in the concept of pdf/x-3 clearly defines that the one and only
profile to use is the output intent profile.
In my view, this should not named late binding, because the Creator of
the PDF/X-3 file has exactly to specify the colorspace, the
printing-house wants to have.
A better description would be early binding for delivering PDF-files
which contains Iccbased objects.
Early binding:
the Creator defines the colorspace before delivering
Late binding:
the printing-house can convert the delivered data to a colorspace of its
choice.
Your discussion of problems caused by using different
printing profiles
is another story - please do not mix the topics!
The problems you describe will be the same if you start with a PDF/ X-1
file and convert the CMYK values to another print profile.
The combination of PDF/X-1a and a tailormade devicelink-profile solves
exact this problem. There is only one defined sourcespace for the
delivered document and the defined destination-colorspace which the
printing-house choses.
Now the printing-house generate, optimize and test a devicelink-profile,
which makes a smooth and colorimetric correct transformation from the
delivered colorspace to the colorspace choosed by the printing-house.
This is in my view late binding, because the printing-house is able to
convert the data to a colorspace of its choice in a robust and reliable
colormamagement-workflow.
:-) Jan-Peter
--
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann@colormanagement.de
6738
days inactive
6739
days old
eci-en@lists.callassoftware.com
8 comments
4 participants
participants (4)
-
Florian Süßl -
Jan-Peter Homann -
Klaus Karcher -
Olaf Drümmer