InDesign export PDF text color issue.

[Angus Lam]

Dear All,

I have a question for export PDF text color issue as below. Is there a way to solve?

When text uses "non-breaking spaces" and "line breaks" and appears on the same line, the text fill color is replaced with the stroke color when exporting to PDF.

InDesign:

Stroke:

Overprint Stroke:

PDF:

Thanks!!

Angus

[Laubender]

Hi Angus,

could you post a sample InDesign document where you see this?

Just tested with InDesign 2022 version 17.3.0 and the exported PDF is alright.

Used PDF (Print) with the PDF/X-4 export preset.

Viewing application was Adobe Acrobat Pro.

Thanks,
Uwe Laubender
( Adobe Community Professional )

[Angus Lam]

Hi Uwe Laubender,

I've attached a test file and tested in InDesign 2022 (17.3) and exported to PDF/X-4 and still have issues.

Hope to find a solution. Thank you very much!!

Angus

[rob day]

Hi @Angus Lam , I can see the problem—I’m not sure if it something peculiar to your file or a bug, but AcrobatPro’s Object Inspector shows the fill of the first line’s Xs as 100% cyan, so it’s not an overprint issue. I tried exporting an IDML, changing the font, and removing the stroke’s Overprint, none of which worked.

If I copy one of the Xs from the 2nd line, select the last X in the first line, and paste (leaving the soft return), that fixes the problem in the PDF.

Can’t say I ever seen something like this. I’m testing in CC2021 on OSX.

[Laubender]

Hi Angus,

thank you for your test document! With that I can see the issue as well.

And as soon as I remove the line break special character the problem is gone.

There are no nested styles applied in your original text.

Also no GREP styles.

If I change the color of the stroke, I still see the problem.

If I remove overprinting or if I change the font, I still can see the problem.

Did a side by side comparison.

One sample that is working ( the top one ) , one sample that is showing the issue ( the bottom one ) :

From Acrobat Pro:

Viewing in Output Preview where I put off the Magenta channel:

The difference between both text frames in InDesign:

The top one is using the Adobe Paragraph Composer, the bottom one where we see the issue, is using the World Ready Paragraph Composer. So we can conclude the surprising faulty result is because of a bug in the World Ready Paragraph Composer.

I attached my test document and also the exported PDF/X-4.

All tests done on my German InDesign 17.3.0 on Windows 10.

Note, that I turned off overprint for the text stroke in both text frames.

Also changed the font to Myriad Pro Bold.

Regards,
Uwe Laubender
( Adobe Community Professional )

[rob day]

Hi Uwe, Thanks for testing. I was able to fix the problem and keep the soft return and World Ready Paragraph Composer by copying and pasting one of the characters from line 2, and pasting it over the last character in line 1. Are you seeing the same?

[rob day]

Also, I tried replacing the Nonbreaking Space after the 100 and that was a fix. Angus was the text by any chance placed or pasted from MS Word or some other app?:

[rob day]

And as soon as I remove the line break special character the problem is gone.

Uwe were you referring to the nonbreaking space after 100, or the soft return at the end of line 1?

[Laubender]

@rob day asked: "Uwe were you referring to the nonbreaking space after 100, or the soft return at the end of line 1?"

Hi Rob,

I removed the soft return.

That also resolved the issue!

Regards,
Uwe Laubender
( Adobe Community Professional )

[rob day]

It seems like the nonbreaking space after the 100 might the real culprit, replacing it with a regular space is a fix and allows the soft return and world composer. I get lots of nonbreaking spaces with text provided from MS Word, so I’m wondering if the "corruption" came from pasted or placed text?

[rob day]

Attatched is a regular space version and exported PDF/X-4

[Laubender]

Hi Rob,

I cannot reproduce your solution with copying a character from the second line to the first line. Not if I try this with the text at the bottom. Maybe I did something wrong?

The result is still the same: every character after the special character "Non-breaking space" is filled with the color of the stroke when I export to PDF:

Only when I switch over to the Adobe Paragraph Composer the issue is gone.

Attached all the 220805-3-4 files.

Also see in my sample 220805-3-7 where I typed some text:

Original test files for 220805-3-7 also attached.

Thanks,
Uwe Laubender
( Adobe Community Professional )

[Angus Lam]

Dear Uwe, Rob,

Thanks for your test and reply!!

First let me explain my work and why I use stroke color to process these text.
My job is to design some variable data Templates for different kinds of printing through InDesign.

For the data, Adobe World-Ready Composer is usually used due to the need to deal with data in different languages.

"non-breaking spaces" and "line breaks" are also often used to control the distribution of data.

The cause of this problem is to provide a template for the Print Shop for production. Since there will be a Backgroud color, in order to avoid color leakage, it is necessary to add an Overprint stroke color to the Text and set it as a center stroke.

I tried setting different Composer, but I don't know if I set something wrong, still have problems, please advise. Thanks!!

Attached test file for check!!

InDesign CC 2022 (17.3) - English (North America)

[Laubender]

Hi Angus,

did some more tests with other special characters as well.

Here a list of special characters that lead to the bug, don't know if other characters will also have this effect:

NO-BREAK-SPACE U+00A0
NARROW NO-BREAK SPACE U+202F
EM QUAD U+2001
EN SPACE U+2002
EM SPACE U+2003
THREE-PER-EM SPACE U+2004
FOUR-PER-EM SPACE U+2005
SIX-PER-EM SPACE U+2006
FIGURE SPACE U+2007
PUNCTUATION SPACE U+2008
THIN SPACE U+2009
HAIR SPACE U+200A
ZERO WIDTH NON-JOINER U+200C
ZERO WIDTH JOINER U+200D
MEDIUM MATH SPACE U+205F
INVISIBLE SEPARATOR U+2063
TAB U+0009
RIGHT INDENT TAB U+0008
INDENT TO HERE U+0007
END NESTED STYLE HERE U+0003

( ??? ) EN QUAD U+2000

With this I am not sure, because the applied font style does not have the glyph implemented.

I cannot see the bug if the Adobe Paragraph Composer is applied through a paragraph style.

The bug can be seen with both World Ready Composers only. Not with both Japanese ones, not with both ordinary ones.

My tests were done with InDesign 2022 version 17.3.0 on Windows 10.

Note: The bug occured the first time with InDesign 2020, so I can see it with InDesign 2020, 2021 and 2022.

Also with the latest prerelease version of InDesign 2022.

Also tested all versions from InDesign CS6 version 8.1 to InDesign 2019  where I cannot see the bug.

Regards,
Uwe Laubender
( Adobe Community Professional )

[Angus Lam]

Dear Uwe,

I'm testing on macOS Monterey Version 12.5 (CC2020 and CC2022).

I tested Adobe Paragraph Composer and Adobe Single-line Composer (non-World-Ready), but still have problem, I don't know if I set something wrong.

In addition, I have further tested other white spaces, and only have problems with Nonbreaking Space, Nonbreaking Space (Ficed Width) and Flush Space.

Thanks!!

Angus

[Laubender]

Hi Angus,

well, it seems I spoke too soon as I stated that I cannot see the issue with the Adobe Paragraph Composer or with the Adobe Single Line Composer. I was wrong!

Therefore I attached my findings for that list of special characters I gave above.

Did an InDesign document with two layers. The top one contains the placed PDF page of the underlying InDesign page showing an issue or not.

Below example page 1 where I am showing only one combination of special character plus forced line break with all six available composers in InDesign. The placed PDF is obscuring the characters on the page leaving the invisible characters visible so you can see what's between the rendered glyphs that are not white spaces. Also toggle the visibility of layer "Exported PFX4":

On with special characters and the world ready composers:

After page 6 surprisingly also the Adobe Paragraph Composer and the Adobe Single Line Composer showing the issue:

Download the packaged document from my Dropbox account:

https://www.dropbox.com/s/udy1aqb0slp50op/220807-3-0-NoIssues-vs-Issues-2022.zip?dl=1

Regards,
Uwe Laubender
( Adobe Community Professional )

[Laubender · Accepted solution]

Hi @Angus Lam ,

I hope, that you will notice my posts here; since Friday I only sporadically get mail notifications of posts in threads I am participating.

Well, there is bad news and good news.

The bad news: also the Japanese composers are affected.

Download my new packaged test document from my Dropbox account:

https://www.dropbox.com/s/o19jbi1widate5s/220807-4-0-NoIssues-vs-Issues-2022.zip?dl=1

The "good news", I found a way to avoid the bug.

A workaround and not a real fix!

Simply exchange all line break characters with a blank character that is formatted with 1000% width and with a huge value of tracking. Did this in a document that is also packaged and that you can download from my Dropbox account:

https://www.dropbox.com/s/nzfo1mo1ao45lzh/220807-5-0-NoIssues-vs-Issues-2022-FIXED.zip?dl=1

That bug should be reported at InDesign UserVoice:

https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs

Regards,
Uwe Laubender
( Adobe Community Professional )

[Brad @ Roaring Mouse]

I've done a couple of additional tests and I have narrowed it down to the fact the stroke is aligned to center. If the stroke is aligned to outside the issue doesn't happen.

But yes, this is a bug.

By nature, strokes are always centered on a path. The way InDesign usually handles strokes is that it puts them BEHIND the fill objects, but at double the stroke width (.4 pt instead of .2 pt), so when the fill is rendered on top, it gives the appearance of a .2 pt stroke on the outside of the fill obeject. This is easier code to write as the PDF will render the stroke part first, then render the fill on top of it which knocks out below. (btw: Overprinting such a stroke only affects the objects behind it).

However when the stroke is centered (overprint or not). it needs to be moved to the front, but for reasosn I can't fathom, the PDF code is more complicated. It renders it character by character starting with a fill, then the stroke, then the next fill, then the next stroke, etc. This works fine up to the non-breaking space, then it gets confused, causing the incorrect fill issue. So, yes, a bug.

If the non-breaking space is switched to a regular space (or a thin space or whatever), and they sssign it as No Break instead to keep them together, it works as expected.

if you open my sample in Illustrator, you can see how the objects are ordered in the PDF.

[Angus Lam]

Hi Uwe, Brad and All,

Thanks for your help with the test.

This should be a bug, there may be different results in different OS and language versions, I will try to summarize and report to InDesign UserVoice. Thank!!

Angus

[Laubender]

Hi Angus,

something new; had the time to test another case:

One of the white space characters listed in my other post plus hyphenation in the same line will cause the bug!

I see a solution for all this. Just use a GREP Style on the applied paragraph styles that assigns a character style to all white spaces that does NOT use strokes on all white spaces. GREP pattern:

\s+

See details here:

Regards,
Uwe Laubender
( Adobe Community Professional )