Sug Area can solve shift due to Page Information

[AlFerrari]

Back in March we had a thread on the topic of a shift caused by the inclusion of page information in the postscript or pdf output:

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

As far as I can tell the problem was not resolved. But some recent posts by Dov discussing the Slug Area led me to test successfully its use in solving the problem of the shift caused by the inclusion of the Page Information in the output from Indesign.

Using an arbitrarily value of .75 inch all around for the slug area and including it in the output in the Marks and Bleed section of the Print dialog produces postscript or exported pdf output which is symmetrical and includes the Page Information. This can be demonstrated with the same example of a 4.5 square page that had been used by Gigo, the original poster in March.

Al Ferrari

[AlFerrari]

Sug Area = Slug Area. It turns out that the "Check Spelling" system does not check the topic tittle.

[Cindy_Johnston@adobeforums.com]

Would it find "tittle"? : )

[AlFerrari]

Cindy,

Did you try it? I just tried it for "tittle,"and it found no spelling errors. It only finds errors if the word does not exist. A "tittle" is a very small bit. But in the original thread from March, even a small bit of shift was of great concern! <BG>

Thanks for your interest in the topic.

Al

[gig0@adobeforums.com]

Al, you know my feelings on this and I've posted another response back in the Prepress forums. I'm not about to change our multi-million dollar workflow to chase a little bug like this around. If the software can't produce consistent results when using different page size variables, then this is Adobe's problem. Plain and simple. It's not doing what it's intended to do and not consistent.

It's times like these I think that a EULA protects the developers too much and screws the end user. We've wasted time and money with this issue. Please fix it Adobe.

[Dave_Saunders@adobeforums.com]

Interesting attitude, gigO. So what are you going to do then? Let users suffer the consequences of the bug? Or take a vacation until Adobe comes out with a fix?

I think your position on the EULA doesn't take into account how inexpensive this software is. If you have spent hundreds of thousands on the software, then your attitude would be completely understandable. But you didn't. And you have a multi-million dollar workflow apparently for which Al has offered a workaround to address the problem, but you're going to dig your heels in?

I must be missing something important because I can't make any sense of your stance.

Dave

[gig0@adobeforums.com]

Dave, you are missing something.

When you're in the business that I'm in (and many others), things like this matter. Why does it matter? Because we get thousands of InDesign files in any given month and this problem destroys the fundamentals of simplifying things with a "workflow". It costs us money. If you want specifics read this thread: <http://www.prepressforums.com/ftopicp-55681.html#55681> . Also, note Brutus Maximus's post in the original thread as another example ( AlFerrari, ""Page information" shifts pages under 5 inches" #1, 14 Mar 2006 8:12 pm </cgi-bin/webx?14@@.3bbeef60/0> ) of how this issue costs money.

I don't care how 'inexpensive' the software is. Thats irrelevant. The software should behave in a consistent manner for which it is intended. I output a file and would expect consistent results. Not pages jumping around. I shouldn't have to change an expensive workflow because the application doesn't behave as it was intended. I would be more happy if ALL the files that I output from InDesign were off-center. That way we can at least compensate on our end and not worry about documents that are under 5". Thats not asking too much. I'm asking for it to be fixed.

[Peter_Truskier@adobeforums.com]

I'm asking for it to be fixed.




Whom have you asked for this? Hopefully your Adobe sales rep, since this is a user forum, and getting in a snit here likely won't do much.

I can't disagree with the point that this is a bug; it surely is. But it is also true that software has bugs. Al suggested one pretty clever way to deal with it until it gets fixed, perhaps saving you money in your expensive workflow.

[Dave_Saunders@adobeforums.com]

Indeed, I wasn't missing anything.

To each his own.

You'd probably be happier in a career that doesn't involve software.

Dave

[gig0@adobeforums.com]

Dave,

thanks for your insult.

You obviously still don't get it. You're not in the business and not a very good "consultant" if you don't see a problem like other people in the industry who have posted about this.

Oh, and I took the liberty to look up your business webpage and it looks like it was done in MSFrontpage, as opposed to GoLive. Web site development?! You're kidding right? I think you're the one that needs to find a different career. LOL

[AlFerrari]

From the threads here and the one at <http://www.prepressforums.com/ftopicp-55681.html#55681> we learn that Gig0's workflow uses the Indesign output for imposed final output through Preps, where the crop marks are useful to confirm page position and the identifier is useful when the pages have no folios. But his workflow also includes unimposed ganged proofs where the identifier is desirable but wasted space needs to be kept to a minimum. That the proofing branch of the workflow is unimposed I think tells us that it lacks the capability to crop off the extra space introduced by the enlarged bounding box generated by either work around of pushing out the crop marks or including a slug area large enough to contain the page information.

This contradiction can be surmounted with a user created identifier that will be immune from the problems of the Page Information. In a recent thread

Klaus Scharfenstein, "CS1: Slug does not move with page?" #7, 29 Aug 2006 1:56 am </cgi-bin/webx?14@@.3bc1638a/6>

it was pointed out that a text box in the slug area, just touching the page could be grounded to that page. Such a text box with the job name and a page number marker, and of a size that would keep the slug area within the standard crop mark area can be placed on master pages. This I think would satisfy the requirements of Gig0's workflow. A script could be developed that creates this text box on all master pages in the doc, adds the slug area to the doc set up, and and proceeds to postscript or pdf output with "include slug area" selected.

This might just work, but then again, I may have missed something.

Al Ferrari

[gig0@adobeforums.com]

yeah, a slug line could also be added to library, for example, and used to identify pages but you're also talking about changing the presets and now have to rely on operators to fill in the unique data to the slugline for ALL IDCS jobs... hundreds of times each month? I don't think that's even an option considering now you have to man-handle the files even more. You want as little manipulation as possible when dealing with customer files. It reduces possible errors. Thats what presets are for... at least, thats the way they're supposed to work.

[AlFerrari]

Gig0,

I think I understand your concern, but maybe not. But that's why my suggestion includes the idea of a script. I agree that without some type of automation, it places a heavy burden on the operator, introduces possible error, and slows the process down.

and now have to rely on operators to fill in the unique data to the slug
line for ALL IDCS jobs... hundreds of times each month?




Well, not exactly. I am assuming that a script could pick up say the first 15, or 20, characters of the file name (remember that this identifier has to work for narrow pages). Then you just need to add the job number to the beginning of the file name BEFORE opening the file (can be done by order entry staff, or CSRs). After that, the script generates the slug line. Are you familiar with scripts in InDesign? A script is written only once by a scripting expert, and then used over and over by an operator much like a preset.

Regards,

Al Ferrari

[Dave_Saunders@adobeforums.com]

gigO,

I do understand your problem.

I do understand that ultimately it is Adobe' issue to fix.

It would be ironic (but acceptable in my eyes) if their fix consisted of a note in the documentation that warned that if you didn't make the slug area large enough you might have the problem you're experiencing.

The issue is what to do in the meantime. What to do while Adobe is working on the fix. To declare that you will do nothing because it is not your fault makes your position somewhat farcical.

But I'll step away from this topic because I'm clearly not making much of a positive contribution. If you want to wait for Adobe to fix the problem, then go to it.

Dave

[AlFerrari]

Dave,

If you left us now, it would be at a time when your scripting skills could be brought to bear on this interesting problem that has affected Brutus and Marco, besides Gig0, plus unknown others:

Marco A SantaMaria, ""Page information" shifts pages under 5 inches" #8, 16 Mar 2006 5:07 pm </cgi-bin/webx?14@@.3bbeef60/7>

Gig0's #11 response encourages me to think that my #10 post has identified how the problem impacts his particular case. In #12 I sketch how a script could provide an automated solution that could be used by others, but I lack the skill to make it bear fruit. A collectively derived solution would be a credit to the forum. With that end in mind I have avoided the acrimony to concentrate on the problem.

Al Ferrari

[Dave_Saunders@adobeforums.com]

Al,

Indeed, such a script could be written. But it would require that gigO change his workflow, something he has decreed he is not prepared to do.

Meanwhile, I'm having trouble paying this month's mortgage, so I'm not about to ante up a freebie script in this acrimonious environment.

Dave

[AlFerrari]

Dave,

I understand your cahsflow problem, and wish i could send you a check, but I am having the same problem trying to pay my rent. You at least are building equity with each payment.

But the script I am thinking of would hardly require a change in workflow:

1. Add job # at the beginning of file name.
2. Open file.
3. Run script.
4. Continue with existing workflow.
5. Collect payment for completed job, and make mortgage payment.

Can't get any easier.

Thanks for the response.

Next scripter up to the plate.

Regards,

Al

[gig0@adobeforums.com]

The script could be written by me. I used to be a code monkey and understand programming structure, even though my knowledge of javascript is minimal, but am willing to do it. Thats no problem.

My reservation is this; it doesn't make sense to make global procedural changes for something that affects maybe less than 2 percent of the workload. The operators would need to treat IDCS files in a different manner than all the other applications. If one page in the file needs to be re-output because of customer changes (which is quite common in publishing) we would have to hope the operator saved the file before outputting because a modified date and page# is needed in that slug as well. This information is critical and indicates changes have been made and the correct updated files will be married into Preps. See how it throws in new variables and affects everything else? It's like if you go to the dentist to fix a tooth ache and he extracts all your teeth so you'll never have that problem again. Yes it fixes the issue but in a roundabout way.

As long as this topic keeps popping up (which it has), I'm content. It's proving to be a thorn in the application. And Dave, yes there are developers that view these posts and I'm confident someday it will be patched or fixed in new versions. Not because people complain about it, but programmatically it's a flaw and not consistent with IDCS output intent.

[AlFerrari]

Gig0,

Glad to learn that you have coding skills; more power to you. But your reservations don't sound convincing.

1. All applications have similar, but different output dialogs, so your operators already deal with a variety of procedures to create output. I hardly think that only 2% of your files are indesign. Instead, that is more likely the proportion that gets affected by the Page Information bug. Perhaps you don't realize that my script idea, if implemented, would apply to ALL indesign files. Your operators would simply get used to a one time change, much as they'll have to when the next version of the software alters the print dialog. So scratch that reservation.

2. The pitfalls risked in re working the output of a file due to customer changes, would be no more severe as a result of my script idea than they are in your current workflow, because it is to be used for output of all or part of indesign files. So scratch that reservation also.

3. The dentist analogy is a wee bit (a tittle) far fetched.

Since you are volunteering to write the script, I think you found merit in my ideas, but you are just afraid of change.

My work is done here now. Going forward, it's your baby. But if this discussion leads to an improvement in your expensive workflow, do let me know where I can send an invoice; I am late with the rent again.

Good night, and good luck.

Al Ferrari

[gig0@adobeforums.com]

I hardly think that only 2% of your files are indesign. Instead, that is more likely the proportion that gets affected by the Page Information bug.

Exactly. About 2% of the IDCS files we get would be affected by the bug.

With the use of the script, it relys soley on the file modification time/date stamp itself in order to update, unlike how 'page info' is dynamically updated when outputting. Herein lies the human factor risk to the other 98% of the workload; if the operator neglects to save the file before output, the page information will be the same as the previous proof and we couldn't make a quick visual inspection to see that the files been updated. You'd be compounding a risk in order to eliminate a 2% bug.