The ability to undo changes, the maintenance of as detailed a "history" as possible within software, is an integral element in today's User Friendly applications.
While this is a useful and often absolutely essential part of any software environment's design, when it comes to software which has to maintain a high level of control in order to perform a precise operation, the way the software maintains this hidden back end can cause some problems.
Case in point: PDF files created by Microsoft PowerPoint.
From a printing standpoint, printers would much rather have files created using software built for creating files which will ultimately be printed. Color management, font embedding, precise relationships between elements, and the rendering of transparency are only a few of the issues which these industry-standard applications are tailored to address. Digital printing is a complex process with almost endless variables, a fact which can be belied to the novice or casual user by the ease with which a person can hit "Print" on their computer and receive a decent looking printout from their office printer.
Like it or not, PowerPoint is the go-to software used to create posters for novices and students and people who have no access to, nor general need of, something like the Adobe Creative suite--although it would be wise for printers to convince clients who continually submit files from PowerPoint to upgrade to a professional solution, because it will produce files which will make both client and printer happier in the long run.
One thing we have noticed in our shop is that the PowerPoint history buffer is persistent; this is a good thing for their software and for their users, as it means that elements of the file are preserved well. But it's a bad thing during preflight conversion, particularly during the font embedding phase.
When I tell you the history buffer is persistent, what I mean is that sometimes elements the user believed were deleted are still present, and are rendered during preflight. This causes hidden elements to appear on the page--elements the user didn't even know were there. This presents a definite conflict for the printer, in that the preflight introduces elements the client did not approve, and it causes a bump in the workflow, which wastes time. If the error isn't caught during preflight, it can result in the necessity to reprint.
The lesson here is that the preflighting should be done with the client present, or at the very least the preflight should occur and then the final, preflighted file should be delivered, electronically or physically, to the customer for final approval. Sometimes in a lower volume shop, though, with fewer staff and a more constant workload, that's not always going to be easy to accomplish. It's worth it though.
In PowerPoint, what we believe happens (we're not Microsoft engineers, by the way) involves a user deleting an element, particularly a text element. There are two ways to do this: one can either delete the text inside a text box, or delete the text box itself. The problem we see at the font embedding stage relates to the text within the box being deleted but the box itself still residing on the page.
If the box itself gets deleted, we don't have an issue.
When the box doesn't get deleted but the content inside does, PowerPoint tries to maintain the states of that box, i.e., before and after deletion so that an "undo" can return the content if desired. Because the box element the text resides in is invisible, the element gets hidden, visually at least. When Acrobat Pro preflights it, PowerPoint doesn't/can't tell Acrobat that that element is a history state, not an actual printable object, so Acrobat renders it as a visible element.
This phenomenon looks like the following examples (blurred to protect any possible proprietary information of the client). The document appears correct before embedding fonts, like so:
After embedding fonts, the hidden (history buffer) content appears as a normal element. In this case, it would have been "Diagram B."
You can see in the above example that a little bit of text, and an additional "B," have appeared in the lower half of the document. Voilà! The History Buffer has won. Or, rather, Acrobat and PowerPoint got together on this one, and decided that no information may be discarded without the express operation of the user.
Well, a lot of times we just send the file back to the customer. However, if we're dealing with a novice, we will often walk the client through the process of deleting the element from within Adobe Acrobat. If we have access to the original PowerPoint file, we will open it, show them that the element in question does, in fact, exist, and then delete it and resave.
In most cases where the client sees this, they just say "Get rid of it." In that case we will go in to Acrobat and select and delete the offending element, resave, re-preflight, and rerun. Unfortunately, if the preflight and proofing were not done in the presence of the customer, if we printed in error we can't recapture that lost time and material cost, so it is always a good idea to preflight in the presence of the client.
Hope this helps point a finger at a question which bugged us for quite some time. It always recurs at our shop, and we've grown patient in dealing with it, but if you're encountering it for the first time, hope this provides a good starting point.
We'll deal with transparency at a later date, when we've figured out a decent preflight which catches 95% of the errors we deal with.
Thanks!
While this is a useful and often absolutely essential part of any software environment's design, when it comes to software which has to maintain a high level of control in order to perform a precise operation, the way the software maintains this hidden back end can cause some problems.
Case in point: PDF files created by Microsoft PowerPoint.
From a printing standpoint, printers would much rather have files created using software built for creating files which will ultimately be printed. Color management, font embedding, precise relationships between elements, and the rendering of transparency are only a few of the issues which these industry-standard applications are tailored to address. Digital printing is a complex process with almost endless variables, a fact which can be belied to the novice or casual user by the ease with which a person can hit "Print" on their computer and receive a decent looking printout from their office printer.
Like it or not, PowerPoint is the go-to software used to create posters for novices and students and people who have no access to, nor general need of, something like the Adobe Creative suite--although it would be wise for printers to convince clients who continually submit files from PowerPoint to upgrade to a professional solution, because it will produce files which will make both client and printer happier in the long run.
PowerPoint, and the history buffer issue.
One thing we have noticed in our shop is that the PowerPoint history buffer is persistent; this is a good thing for their software and for their users, as it means that elements of the file are preserved well. But it's a bad thing during preflight conversion, particularly during the font embedding phase.
When I tell you the history buffer is persistent, what I mean is that sometimes elements the user believed were deleted are still present, and are rendered during preflight. This causes hidden elements to appear on the page--elements the user didn't even know were there. This presents a definite conflict for the printer, in that the preflight introduces elements the client did not approve, and it causes a bump in the workflow, which wastes time. If the error isn't caught during preflight, it can result in the necessity to reprint.
The lesson here is that the preflighting should be done with the client present, or at the very least the preflight should occur and then the final, preflighted file should be delivered, electronically or physically, to the customer for final approval. Sometimes in a lower volume shop, though, with fewer staff and a more constant workload, that's not always going to be easy to accomplish. It's worth it though.
In PowerPoint, what we believe happens (we're not Microsoft engineers, by the way) involves a user deleting an element, particularly a text element. There are two ways to do this: one can either delete the text inside a text box, or delete the text box itself. The problem we see at the font embedding stage relates to the text within the box being deleted but the box itself still residing on the page.
If the box itself gets deleted, we don't have an issue.
When the box doesn't get deleted but the content inside does, PowerPoint tries to maintain the states of that box, i.e., before and after deletion so that an "undo" can return the content if desired. Because the box element the text resides in is invisible, the element gets hidden, visually at least. When Acrobat Pro preflights it, PowerPoint doesn't/can't tell Acrobat that that element is a history state, not an actual printable object, so Acrobat renders it as a visible element.
This phenomenon looks like the following examples (blurred to protect any possible proprietary information of the client). The document appears correct before embedding fonts, like so:
You can see in the above example that a little bit of text, and an additional "B," have appeared in the lower half of the document. Voilà! The History Buffer has won. Or, rather, Acrobat and PowerPoint got together on this one, and decided that no information may be discarded without the express operation of the user.
What's the solution?
Well, a lot of times we just send the file back to the customer. However, if we're dealing with a novice, we will often walk the client through the process of deleting the element from within Adobe Acrobat. If we have access to the original PowerPoint file, we will open it, show them that the element in question does, in fact, exist, and then delete it and resave.
In most cases where the client sees this, they just say "Get rid of it." In that case we will go in to Acrobat and select and delete the offending element, resave, re-preflight, and rerun. Unfortunately, if the preflight and proofing were not done in the presence of the customer, if we printed in error we can't recapture that lost time and material cost, so it is always a good idea to preflight in the presence of the client.
Hope this helps point a finger at a question which bugged us for quite some time. It always recurs at our shop, and we've grown patient in dealing with it, but if you're encountering it for the first time, hope this provides a good starting point.
We'll deal with transparency at a later date, when we've figured out a decent preflight which catches 95% of the errors we deal with.
Thanks!
