Page info bug strikes again!

[gig0@adobeforums.com]

First off, if you're not familiar with this issue check out these posts:

AlFerrari, ""Page information" shifts pages under 5 inches" #1, 14 Mar 2006 8:12 pm </cgi-bin/webx?14@@.3bbeef60/0>

<http://www.adobeforums.com/cgi-bin/webx?128@@.3bc18a65>

<http://www.prepressforums.com/ftopict-5495.html>

TLDR vesion:

the reason why this such a factor is because a high end/high volume prepress environment uses presets to simplify or automate a workflow to generate efficiency in order to make a profit. These presets include applying 'page info' and an 1/8th inch bleed (both of which are industry standards) along with with DEFAULT settings in the 'Marks & Bleeds' print dialog when outputting. A known bug would shift the pages when 'page info' is included in the slug line when the document is under 5 inches. When these pages are ripped, common prepress imposition software (such as Preps) would place the ripped pages in the imposition layout (based on the MEDIA SIZE, not the bounding box)incorrectly. The practical way to deal with this is to rely on operator experience to turn off page info in the preset. The problem is, the human factor is not always 100% when your dealing with hundreds of files each week and the bug only affects a small percentage of jobs. Costs of the error vary depending at what point in the process it was realized that it's wrong.
So in a nutshell, a simple variable defeats the entire automation process thats supposed to be part of the application and workflow.

Now, here's what we found today:

I had a $500/per hour press go down because of this bug. This time it isn't because the page was under 5 inches. The pages were a common 8 1/2 x 11" page size. It's because the spot varnish pages were output with separations turned on in the print menu. That was the only difference between the process color portion of the job and the spot varnish, since both were built using the same file. The extra spot color tag information in the slug line of the varnish separation file shifted the entire page up 1/64th of an inch. We ended up re-ripping and remaking all the varnish plates for a 136 page catalog. Thats 34 plates plus the time lost. Whom at Adobe should I send the bill to?



WTF? Why does such an simple setting have to be such a burden to an entire workflow? More importantly, why hasn't it been fixed? It's been around since CS 1.

[AlFerrari]

Gig0,

We really must stop meeting like this!

When these pages are ripped, common prepress imposition software (such
as Preps) would place the ripped pages in the imposition layout (based
on the MEDIA SIZE, not the bounding box)incorrectly.




I just realized something after dwelling on that statement: Adobe's page layout product produces postscript with header comments for bounding box (based on all objects contained in the output including page information) and for crop box. With those two pieces of information, any good imposition software is able to locate the page correctly. But you are taking that postscript and rasterising it first, thus obliterating the crop box information. The bounding box now corresponds to what you call the media size. Well no wonder Preps or any other imposition tool can't find the page correctly!

Even though the rasterising process may be carried out by another product also by Adobe, it seems inappropriate to blame IndDesign for the problem. After all, the pages impose correctly before rasterising. Don't get me wrong, I do agree that there is a problem, but not where you say it is.

What would solve this shift problem in those workflows that impose rasterised pages, is for the workflow vendor to ad a feature that would automatically enlarge the bounding box as needed to make it symmetrical about the crop box BEFORE ripping takes place. That would give you the trouble free workflow not needing operator interference that you are after. I think you are complaining to the wrong vendor here.

How much did you say you paid for this workflow? :-)

Al Ferrari

[gig0@adobeforums.com]

You like playing devil's advocate, don't you Al? With your circular logic, I could easily blame the customer for sending us these files in the first place. :)

The Brisque, like many other RIP's out there, is a rip once-output many workflow. What makes it so flexible is the fact that it can take these ripped pages and output to many different devices. I can output to a laser printer, high resolution plotter, drum image/plate setter, normalize into a PDF, whatever. All with the same file. Not only that, theres specialized software that gives us the ability to make changes to these ripped pages without going back to the document. It's far from being an antiquated system. What you're saying defeats the purpose of all this and many other workflows. But I have heard of people doing that method at small print shops.

The pages don't jump around in any other application we use. Not even MS Publisher! There is a fundamental design flaw in InDesign CS and CS2 that should get fixed.

[AlFerrari]

You like playing devil's advocate, don't you Al?You like playing devil's
advocate, don't you Al?




If you would carefully re read all my post on these threads, you would notice that I am actually trying to help solve your problem.

theres specialized software that gives us the ability to make changes
to these ripped pages without going back to the document.




Then why not use that software to introduce the step suggested in my post? Make that software re center the trim area in the rasterised area. Do it for all jobs so that there is no special handling neede for the "problem" jobs.

Have you discussed this problem with the Brisque vendor? What is their response?

With continuing interest,

Al Ferrari

[gig0@adobeforums.com]

It's not a Creo/Kodak/Agfa/Rampage/Nexus/etc. problem! It's not a rip issue! No other application in our software library offsets pages because of a tagline under certain conditions. Many others have posted about same problems. How can I be any more clear? Here, I'll repost this:

The Brisque, like many other RIP's out there, is a rip once-output many workflow. What makes it so flexible is the fact that it can take these ripped pages and output to many different devices. I can output to a laser printer, high resolution plotter, drum image/plate setter, normalize into a PDF, whatever. All with the same file. Not only that, theres specialized software that gives us the ability to make changes to these ripped pages without going back to the document. It's far from being an antiquated system. What you're saying defeats the purpose of all this and many other workflows.

It's faster just to turn off page info and re-output the fixed pages rather than fix them in PressTouch or Remake.

[Peter_Truskier@adobeforums.com]

It's not a Creo/Kodak/Agfa/Rampage/Nexus/etc. problem! It's not a rip
issue! No other application in our software library offsets pages because
of a tagline under certain conditions. Many others have posted about same
problems. How can I be any more clear?




You have, indeed, made yourself clear - over and over and over. The problem is not lack of clarity, but rather your apparent insistence that the problem be solved by the developer of the component whose "fault" it is. You won't have anything to do with suggested workarounds, apparently because to do so wouldn't be a "fair" allocation of blame.

Let's agree this is pretty clearly a bug in InDesign. What have you done about it? I assume that a company like yours has Adobe sales and technical reps assigned to its account. Have you discussed this with them? Has a bug report been filed?

[Gerald_Singelmann@adobeforums.com]

Let's agree this is pretty clearly a bug in InDesign




I wonder: where is the specification that states that a job should not use the existing means (like trimbox information) but instead rely on the net-page being centered instead of all printed items being centered?
Isn't that what trim-boxes where introduced for? To make sure the imposition software does not need to assume where the net-page is but *knows* it?
As I said: just wondering.

[AlFerrari]

It's faster just to turn off page info and re-output the fixed pages rather
than fix them in PressTouch or Remake.




So this expensive powerful workflow software is such a pain to use that you find it easier to redo the output from the application and re rip, than to use its powerful features to make the adjustment. Well maybe you bought the wrong one.

You have not commented on my assertion in #1, that these "problem" ps files would impose correctly if brought directly into Preps. So the problem is at the Brisque. You must have been personally involved in that purchase decision to be so reluctant to find fault with it.

Sorry, but I don't know how else I can help you.

Al Ferrari

[AlFerrari]

The pages don't jump around in any other application we use.




Recent versions of Quark allow for asymmetrical bleeds. The ps output from files using that feature would presumably also jump around in your workflow. Is that a also a bug in Quark???

Or would you blame the customer for sending you these files in the first place?

Al Ferrari

[gig0@adobeforums.com]

Al, you're thinking too deep into this.

Asymmetrical bleed doesn't offset the positioning of the document or marks. It has no bearing. Also, you obviously haven't worked with PressTouch or Remake. If you did, you would see how demanding these applications are on system resources and not really optimized for speed. It's not intended to be used all the time.

Al, I really don't think you have much experience as an end user. You almost sound as if you work for Adobe or something lol

[gig0@adobeforums.com]

Have you discussed this with them? Has a bug report been filed?




in progress. Thanks Peter.

[AlFerrari]

Thank you for the insult. I am out of here.

Al Ferrari