Re: Profile compression
Re: Profile compression
- Subject: Re: Profile compression
- From: Tom Beckenham <email@hidden>
- Date: Sun, 5 Mar 2006 09:41:09 +1100
Hi Graeme,
URL substitution wouldn't work for all situations, but its great for
an *exchange* as is the intention of PDF/X. If you're intended to
keep the file around for archive or reuse then you would want to
embed the profile.
Having been in advertising transmission for some time, URL
referencing of profiles will be brilliant for sending print ads. In
just about all cases (around 99%), a display ad is only ever used
once. It can be sent to hundreds of publications in possibly multiple
issues, but then that's it. The PDF is almost never used again by the
advertiser. The layout document maybe kept, but the same layout is
almost always reworked or redone completely for the next ad in the
campaign.
If you can imagine a PDF file going to say 300 destinations all an
embedded profile, then you can imagine the problem. Usually a file
going to 300 destinations is B/W so the profile maybe quite small,
but there are cases happening now where this is happening with colour.
In the case of our software, we have grouping mechanisms in our
software to minimise the actual number of files sent by the
advertiser. The files are grouped by "unioning" publication
mechanical specifications but currently a file can only be grouped
with destinations that have specified the same profile. We have built-
in automated colour conversion to automate the process of preparing
one ad to multiple destinations but this has to be done before the
file gets sent. There is the option to send PDF/X-3 if the publisher
accepts it, *but* you can only set one profile as the output intent,
so the advertiser still has to send multiple files. So as more and
more destinations are creating custom profiles, the advertiser is
having to send more and more files each with an embedded profile.
In most cases, both ends would have the Quickcut software, so there
could be a possibility of stripping out the profile, then inserting
it again at the other end. If both ends have the full Quickcut suite,
then they will both have a mirrored copy of the profiles from the
database. However, this situation is rapidly changing. We now have
the ability to send into other systems such as AdSend in the US. This
will probably happen more and more as we move into other markets and
as we move beyond advertising.
So this is why we *love* standards. If we came up with our own
partial exchange mechanism, then not only would we have to develop
our own way to communicate with other systems, but we would also have
to build the trust of the customer as well to accept the new
mechanism. Customers are starting to have a huge problem with being
locked into a proprietary systems. This is why having a standard like
PDF/X is great, because its not vendor controlled, and we know other
people will adopt it - including our competitors. In general its much
easier to get people to adopt an open standard than it would be to
introduce a proprietary feature or a new set of checks.
So yes, I'd like to see the ICC come up with something along the
lines of the "bodiless profile" that Chris mentioned, or better yet,
come up with a way of organising the profile data so that it
compresses better. I think I'll take Chris's suggestion and "Ask
Phil" on the ICC web site ;)
Tom Beckenham
Development Manager, Graphics Group - ADG
Adstream Holdings (Quickcut Ltd)
www.quickcut.com.au
BTW: Just in case anyone brings up our involvement in standards. Yes,
we have been a little slow to jump on the band wagon, mainly because
of resource and also location, but we're fully on it now! We're now
members of CIP4, AdsML, Ghent PDF Workgroup, PPA, IDEA Alliance, and
we are now looking to help the industry in Australia form a PDF/X
technical committee.
On 05/03/2006, at 12:22 AM, Graeme Gill wrote:
Tom Beckenham wrote:
Firstly, I can't believe I missed the URL Profile Specification in
the PDF/X-5 spec! I'd actually read through the two specs but
somehow missed it. I have actually been working on getting an
Australian PDF/X technical committee together, so we can give
input into future specs. Big oops on missing that one!
I can't say I'm a big fan of the idea of URLs substituting for
profiles
in document files. To me this looks like a way of making files more
fragile,
for not a lot of benefit. URL's seem to have a bad habit of "rotting".
Over the years, there have been no end of niggling problems
with fonts, when they are included only by reference. Fonts missing or
mismatching seems to be one of the issues that the latest standards
have tried to address, by going the opposite direction - making sure
that files are fully self contained.
Of course, for a closed application that depends on network
access, there may well be good reason to download various resources
on demand.
I think there's still more that could be done by the ICC in
defining a profile format that can be efficiently used by remote
users. There are a couple of things I can think of that could
extend this idea further. What about being able to reference the
tags/tables as separate URL referencable files? This way a CMM
could download only the pieces of a profile it needs. Instead of
the tag table including offsets, it could include URLs. That way
when doing a perceptual conversion for example, you'd only
download the perceptual table you need.
Why complicate the ICC standard with such a narrow solution ? Why not
instead, simply implement or use a remote file system, with local
caching ? The application could just read the parts of the ICC profile
it needs remotely, without needing any application code changes.
Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40quickcut.com.au
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden