• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Remote proofing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Remote proofing


  • Subject: Re: Remote proofing
  • From: Henrik Holmegaard <email@hidden>
  • Date: Sat, 13 Mar 2004 06:13:13 +0100

On torsdag, mar 11, 2004, at 21:45 Europe/Copenhagen, bruce fraser wrote:

Current implementations know nothing of image content, just of the spaces in which they reside,

First, 3rd generation font file formats are all multi-script. Adobe Myriad Pro supports Western European / Central European, Cyrillic and Greek which gives me a Script Working Space.

I can enter any Unicode co-ordinate I please in InDesign 3 using Unicode Hex Input, but if my Script Working Space does not support it, the co-ordinate does not exist to all intents and purposes.

I can enter any CIEL*a*b* D50 2 degree standard observer co-ordinate I please in InDesign 3, but if my CMYK Working Space does not support it, the co-ordinate does not exist to all intents and purposes (: the argument in the cookbooks).

Let's have a discussion about first principles and look at how positions have been since 1998, and what messages are being communicated.

There are two basic positions, (1) MyPhotoshop / MyInkjet / OS RGB pipeline and (2) EveryAdobeApp / PageGeometry / Passthrough PostScript or DirectPDF / ProofCMYK / PrintCMYK.

Position_1 was reasonable in the timeframe where Photoshop had to work with QuarkXPress which uses TechNote 5044 host-based separation and trapping.

Position_1 is not reasonable when Photoshop has to work with InDesign in a distributed virtual color network based on passthrough PS and direct PDF.

The argument advanced in the quote is irrelevant, because it has _always_ been the image designer's job to deliver images that will render well.

Danish scanner and camera makers have the same tale of photographers shooting shadows and saturations no printing condition.

(And the omission of explanations of tonal mapping in books about Photoshop is why LinoColor was criticized because photographers called for eyepopping black.)

If the photographer hopes to have her RGB image rendered, it is her job to bring the image into a press-oriented RGB working space such as ECI-RGB.

What RGB space she uses as her own archive is her business, but if she wants to bring her RGB content into production, then she has to do an RGB to RGB conversion.

This discussion reminds me of a position taken by Western feminists vis a vis commonsense body language in a place like Zanzibar or Basra.

(Essentially these people insist that they have a right to Scandinavian and Californian body language in a different cultural context.)

Device independence does _not_ mean devoid of context. It means flexibility _within_ a context.

Creative design is only possible by knowing the limitations of the technology in order to transcend the limitations of the technology.

And context is partly about the intended class of printing condition and partly about the intended printing pipeline.

The U.S. approach to MyApp / MyInkjet / MyOS RGB Pipeline is a significant reason that workflows are broken, because it creates the illusion that professional design is divorced from a professional understanding of PostScript imaging, whether in the font dimension, the color management dimension or the mechanical separations dimension.

Thanks,
Henrik
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.


References: 
 >Re: Remote proofing (From: bruce fraser <email@hidden>)

  • Prev by Date: Re: Color Genius
  • Next by Date: Re: Remote proofing
  • Previous by thread: Re: Remote proofing
  • Next by thread: Re: Remote proofing
  • Index(es):
    • Date
    • Thread