Re: ICC in PDF / iQueue
Re: ICC in PDF / iQueue
- Subject: Re: ICC in PDF / iQueue
- From: Henrik Holmegaard <email@hidden>
- Date: Thu, 9 Aug 2001 05:54:24 +0200
Any word on whether Xpress5 is going the device route? Full PDF support ect.,?
Fred Ebrahimi toured Scandinavia for the XML warm-up a while ago.
There was a scandal over here on his previous trip. The Scandianvian
countries are only offered dongle versions which cost about twice
what US customers pay without dongles, and forget rebate if you
happen to have +100 licences. Fred's word that time round was that if
we didn't like it, we could look up the contact details for
Scandinavian versions in the Timbuktu phone book. Then he flew out on
the first plane. This time round he was laying on the charm. though.
The emphasis was on the XML technologies and repurposing for the web,
and on Quark's business model that lets customers turn to Quark for
database warehousing, implementation and so forth. Very smart, very
smooth. PDF was said to be too static a technology for database
publishing. In a sense I would agree except that PDF is already
object-based and could be married to XML architectures.
The sideshow was a promise that QuarkXPress would generate PDF 1.3
without the use of Distiller. IMO this is a sine qua non because
Distiller is a kludge. It's only a PS RIP and as such strips out ICC
color space specifications when it generates PDF 1.3. Then it tags
ICC profiles when the PDF 1.3 is generated. The only sensible way for
this to work is never to use Distiller in the first place, and export
PDF 1.3 directly the way InDesign does.
If Adobe gets InDesign 2.0 up to speed and fixes the ICC
implementation so intents aren't used symmetrically (Lab to CMYK =
CMYK to Lab), then the superior type handling in InDesign will make
life hard for QuarkXPress that relies on ATM to function at all.