Looks like a bug to me. I'm going to ping Dov Isaacs to see what he has to say.
Thank you, Peter. I have had some commercial printers look into it, and that is what they thought also. It gave them the chills because their entire workflows are built around PDFs...
I just sent Dov an email. He's the Principal Scientist for Adobe PDF Workflow, or something like that, at Adobe, so he's the man to get involved.
Thanks, John. That's it.
I can't figure out why this vertical shifting happens now, but horizontal shifting happened moreso in the past. Perhaps tracking, kerning, or wordspacing and letterspacing values had something to do with it, but it could be the same issue at the core. I can't reproduce those dramatic horizontal shifts now, only the vertical as you have done. Hopefully solving one will solve both!
For what it's worth, so far I've only been able to reproduce it with the 9/12 type spec, so it appears not to be a general problem.
In doing a lot of testing, it looks like a ratio issue, somehow. 9 / 9 and 9 / 18, for example, won't reproduce it. But if you try 7 / 10, or 8 / 11.5, for example, it will. Almost all of my real projects use type sizes and leading sizes that create the issue, whatever the ratio and bug may be.
And, unfortunately, since I can't reproduce the horizontal version of this issue, I can't test it to see if similar parameters apply.
Just tried using Auto leading with 9 pt type, with the auto amount set to 133.333333333333% to get 9/12, and that shows the creep as well.
Hm, creating a PostScript file and distill that to PDF will help a lot.
It's not perfect, but the shift will be minimal…
I can reproduce the vertical text offset issue. But, it appears only in the display of Indesign. If I create a PDF of the layered text, open into Illustrator, both text blocks (ID + PDF) are in the exact position, where as the Indesign display shows about a 1pt vertical offset.
@Jeffrey – I do not think it's just a display issue of InDesign!
I've tested this with a 3-column text frame using 9/12 pt Minion Pro Regular.
1. I created an exported PDF with fonts included
2. Placed that PDF as accurate as possible above the page x/y = [0,0]
3. Printed to PostScript with transparency reduction forcing all fonts to outline
4. Distilled to PDF
5. Opened the resulting PDF in Acrobat Pro.
The original live text on the InDesign page is in Magenta, the stacked PDF (placed above) with font included is in Black (overprinting). The shift is ocurring not only as visible in InDesign, but also in the exported PDF where transparency reduction was forcing all text to outline:
The outlined glyphs you can see here are from the last line of the third column* shown in a 3492% view from Acrobat Pro. (*One text frame with three columns.)
And: The alignment of original and exported PDF is perfect, if you are using 9/12.1pt instead of 9/12pt.
(as others testing this already mentioned)
Tested with inDesign CS5.5 on Mac OSX 10.6.8.
Unfortunately, the major issue here (for me) is that jobs printed with commercial printers are affected, because almost all printers use PDF workflow. So printed projects are literally coming out wrong. I noticed the issue recently on a proof where the baseline jumped by many points because I had down-sized a smallcaps word to a point smaller than the surrounding body text (approximate reproduction below). So once the type size went smaller, the problem re-set from that point on. Luckily I caught it, and we converted the type to outlines before printing, as we could not find another solution.
I have asked some printers in the past about using .ps files that have been distilled (I tried this too and found that it improved the problem), but all of the printers I have asked said that this isn't compatible with their workflow.
As for the fractional leading changes affecting the issue, yes, I noticed this as well. Obviously, it isn't a great solution to have to only be able to use certain leadings, especially if you have baseline grids involved and are trying to align multiple type sizes across various leadings all sharing a common denominator (as I do in book work frequently).
Based on what people here have posted, it seems like a widespread and systemic bug, and one that has serious implications for those of us doing print work with vendors using PDF workflow. I really hope a solution can be found.
@Michael – I just tested the following:
Instead of using 9/12 pt, I did format the text with 9/11.9 pt with a document baseline grid setting of 12 pt distance, so that the effective leading will become exactly 12 pt, if "Align To Baseline" is true for all paragraphs.
Result: No problems with the exported PDF. PDF lines of text will exactly match the live text on the page.
Test done in InDesign CS5.5 on Mac OSX 10.6.8.
So there is some hope…
Alas, I just tried it with those specs, however, and still have the issue... I've tried it on both CC and CS3 on an old machine.
I hope someone can really identify what is causing this though, as the parameters and complications (and implications) are really broad...
@Michael – sorry, now, after double checking, I have to admit, that I had a "special" ingredients in my InDesign document: A layer with a rectangle on top spanning the whole page.
The rectangle's fill color was "[Paper]", the transparency of the fill was set to zero percent. And since working with a PDF Export Preset for Acrobat 4 (PDF v1.3) some transparency reduction took place during output. However no text to outline conversion, the text is still editable in the PDF. Just the "usual" default [High Resolution] transparency reduction preset I'm always using creating PDF/X-1a… *
So I conclude, that transaprency reduction will effect the alignment of the lines of text: The alignment will be perfect. And that without creating outlines.
I will continue to investigate the issue.
(After setting the top layer with the transparent rectangle to invisible, no transparency reduction would take place and I see your issue again!)
* The whole setup with the extra layer on top was necessary to force all text to outlines in a previous experiment with transparency reduction.
So I think we have a working solution for PDF/X-1a or simply a PDF with version Acrobat 4 (PDF-v1.3).
The trick is to force transparency reduction to the text frame. One can do it without converting text to outline.
Just put a rectangle with a fill of 100% [Paper] set to transparency 0% on top of it. Downside is, that the exported PDF will get a white background.
Currently for PDF/X-4 I see no chance to work around the issue, if:
1. Point size is 9 pt *
2.1. A baseline grid of 12 pt * is used and the paragraph styles are set to align to it
or 2.2. If the pointsize is extactly 9 pt * and the leading is exactly 12 pt *
* I did not check all other creteria you mentioned in your 7th post: the ratio assumption between pointsize and leading, maybe the formula is something like that: Text Line Distance = n * (Pointsize + Pointsize / 3 ) => creep.
I packed all documents to a zip archive that you can download from my Dropbox account:
150127-1-TextShift-CS5.5.zip contains the following files:
"150127-1-TextShift-CS5.5.indd" contains several layers (from top to bottom):
Text2Path (currently invisible)
PDF-Layer-Text2Path-VISIBLE-when-exported (currently invisible)
PDF-Layer-Text2Path-NOT-VISIBLE-when-exported (currently invisible)
The mentioned white rectangle is placed on master spread A on layer "Text2Path".
Live text in a text frame is on "Layer1" (visible).
Layer "PDF-Layer-Text2Path-VISIBLE-when-exported" contains the placed PDF "Layer-Text2Path-VISIBLE-PDF-X1a.pdf", layer color is green, because here we can see no issues.
Layer "PDF-Layer-Text2Path-NOT-VISIBLE-when-exported" contains the placed PDF "Layer-Text2Path-NOT-VISIBLE-PDF-X1a.pdf"; layer color is red and showing the issues.
Both PDFs are exported with the same PDF Export Preset.
Thanks very much for this. I appreciate all the effort and thoughtfulness! You've really dug into this and gotten some interesting information in the process...
Unfortunately, I think have to continue the search for a broad solution. My ultimate issue is not so much with PDFs that I make, but with commercial printers, who pretty much all use PDF workflow. Different printers have different PDF export settings based on their prepress / RIP / etc. For example, I am working on a large book with a printer who uses X-4 only in their workflow. So I have to hope someone from Adobe can solve this problem at the root level, as workarounds may not work all the time and on all projects for people doing print design.
What a frustrating problem.
Many thanks again for taking so much time in looking into it.
Talk to the printers about the problems. They might accept a PDF/X-1a …
Fixing a problem like that could take a while. Months, maybe years, I think, because the problem seems to be burried deep inside the code for the PDF Export functionality.
Thanks, Uwe. I agree — the problem seems deep in the PDF export code. Ugh...
Yes, with this printer, I have chatted to them about it and they were horrified! Unfortunately, they use X-4 for very specific reasons based on how their presses are set up. I'm trying to come up with a temporary fix with them while a more holistic solution is developed, in the longer-term.
Do you have any suggestions on how I can get this issue under the nose of the right people at Adobe?
@Michael – let's see, if Peter Spier is successful in talking to Dov Isaacs from Adobe (answer #1).
Did you download my files and see what's going on?
Also: Making an "optical" preflight would help.
But this would mean placing PDFs (the old PDF/X-4 ones with transparency) for every page on every page on top, until we find:
1. The right formula of the ratio for pointsize and leading (or better distance)
2. Other circumstances that forces the issue
(Baseline grid set to 12 pt, type set to 9 pt, type forced to baseline grid is just one!)
In the meanwhile we could go back to PDF/X-1a covering the page with a transparent element on top.
@Michael – I found some old threads in the hilfdirselbst.ch forum (German language) from 2010:
Eg. the one that is mentioning the pointsize of 9. Unfortunately the provided test material seems not to be downloadable after 4 years.
The suggested solution then: Simply print to PostScript, distill to PDF.
After doing some tests yesterday, I come to the conclusion, that this is not the complete solution.
Simply printing to PostScript (tiny shifts are still visible) or using PDF/X-1a in export is not sufficient!
You also need transparency reduction. And that means, transparency (on top?) of the affected text frame.
I wonder, if Yves Apel, one of the participants in that thread on hilfdirselbst.ch, filed a bug report back then (June 2010). Have to ask him…
Oh, and Jörg Aigner also detected the problem in September 2010 (also on hilfdirselbst.ch):
I think, he was using a 14-column text frame.
I sent Dov both a personal email and a forum message, but so far no response.
Perhaps that's because it is already a known bug (as evidenced by posts on hilfdirselbst.ch forum (German language) from 2010), but he usually does respond to things like this to at least give us a current state analysis.
I guess the point is that it doesn't work with PDF/X-4, and at the risk of my comment being beside-the-point, the problem doesn't show if you export as High Quality Print, and does happen if you export the same file to PDF/X-4. It couldn't just be one of the different settings between these two output specs, could it? It's something more complicated, right?
In InDesign I am seeing the exact same halos around the text, where the text appears to shift when the PDF is placed in InDesign.
However, I don't see the shift when I export to PDF.
It's only viewing in InDesign that I see this.
Or have I picked up on this wrongly?
If I understand your question correctly, Eugene, I'm still getting the problem. I followed the instructions at the top of this thread (11x17, 3 columns, 9 on 12 type, export as PDF/X-4, change the color in InDesign, place the PDF) and I noticed the shift:
I exported that file (live type and placed PDF) to another PDF and got the same shift:
Is that what you meant? Although now that I look at it, the amount of shift seems to be different.
When I overlay the PDF on top of the indesign file - I see the shift in InDesign.
Then I export that to a PDF (when the file is overlayed, the problem is not there in the pdf)
I'll try this again and follow the instructions again.
But I'm only seeing the shift in InDesign.
I took a slightly different tack to test this ID display error theory.
I printed both the .indd (with type changed to 100% cyan for contrast) and the PDF with Black type on the same printer, then overlaid the prints on my light table equivalent (a window), and I don't see any shift that I wouldn't attribute to minor misalignment of the sheets. Certainly nothing like what I see overlaying the PDF on the page in ID.
michaeld, can you try the same test on a file you think is printing incorrectly?
I can deffinitely see this shift in the PDF. Just tried a 14-column text frame with 9/12pt text.
Aligned a rectangle filled with Black to one of the text's baselines.
The black rectangle didn't move in the PDF. The text did.
Thanks, Peter. I will give it a shot and see.
However, since my particular issue has to do with commercial printers who use PDF as part of their workflow, I have found this problem both on physical hard proofs they have sent me, PDF proofs they have sent, and, unfortunately, on finished, offset products where the issue was not caught during proofing. This has happened across multiple printers with different PDF export settings. So the issue definitely makes its way through the entire workflow, at least in the cases I have seen.
Uwe, was that in ID, or in print?
Hi Peter — I tested with a larger point size and more columns, to make the issue easier to see in print, and it reproduces there as well for me. The type at top left aligns exactly from the one print to the other, and by the time it gets to the bottom right corner, it's shifted dramatically, as it appears on-screen, unfortunately.
The first screen is from InDesign with the placed PDF on top of live text.
The second one is the PDF itself.
The rectangle is not anchored to the text. Just a "marker" for the position of two baselines. I positioned the rectangle at 4000% view to the best precision I was able to in InDesign. Then did the export, then colored my live text plus the rectangle in red, then placed the exported PDF on top of it.
@Peter – you could download my zip file and print the provided PDF. I do not think the text will shift down by printing it to align with the top or the bottom of the rectangle. At least I would be very surprised if this would happen…
@ michaeld, that's a pity.
@ Uwe, if I have some time over the weekend I might do that, but I think your screen shot from Acrobat is pretty convincing (we were sort of cross posting -- I hadn't seen the screen caps yet), especially in light of michaeld's print test. I have a lot of snow I need to start moving right now.
Thanks again, Uwe and Peter!
Uwe, I downloaded your zip file. Then did my Illustrator test. In Illustrator, the ID text is layered precisely over the PDF text, no vertical or horizontal offset, just a display glitch in Indesign.