During the exporting INDD into IDML, the error occurs.

[혜란이72662040]

[InDesign CS5.5 version:7.5.3 ]
During the exporting INDD into IDML, the error below occurs.
Certain Paragraph Return (\r) is changed into 'PARAGRAPH SEPARATOR'(U+2029) and the first sentence’s paragraph style is changed into the paragraph style of the second sentence which makes two sentences into one.
Every time this bug occurs, we have to open the INDD file and change “U+2029” into another character such as “space” and export it again.
Finally we found out that this error occurs when 8000th character is “Paragraph Return (\r)”.
When 8000th character is “\r”, it is changed into “U+2029” automatically during exporting it to IDML. (it seems that it occurs every 8000th character: 8000th, 16000th …)

Now, we made a sample (test) files for your check.
test.indd : we put 9000 characters with two paragraph styles
test.idml (exported from text.indd):
8000th paragraph return (right after the last character “h”) had been changed into “U+2029” and its paragraph style had also been changed from “Description” to “Heading2” which is the next paragraph’s style.
FYI, A table with text is counted as one character only. (Text inside the table is not considered as a character in this case)

Please help us with this bug and let us know if there’s any solution for it.
Thank you for your support.

Sample files

http://ec2-54-64-80-132.ap-northeast-1.compute.amazonaws.com/indesign/test.zip

[BobLevine]

CS5.5 reached end of life a long time ago. Even if there is a bug, it will not be fixed.

[Srishti Bali]

Hi 혜란이,

I have checked the files and they are working fine on CS6 version. If you have original DVDs and serial key you may try to reinstall InDesign or if possible try to check files on some other system which has same version.

And also could you please share a screenshot of error?

Regards

Srishti

[혜란이72662040]

Hi Srishti.

Thank you for your answers.

I get the same error in the version of CS6 and CC2017.

Screenshot showing the error.

test.indd

test.idml

Thank you.

[Laubender]

Hi,

I opened your test document from CS5.5 in CS6 v 8.1.0 on OS X 10.10.5 and can confirm the error with IDML export.

Then I did a new document in CS6 with a new text frame and new contents: 8020 characters where the 8000th one is a \r.
I did not copy/paste your text. I cannot see a problem with IDML.

FWIW:
One cannot escape the problem if one uses the text from InDesign CS5.5.

Opened the CS5.5 doc in CS6:
Copy/pasted formatted text from the converted CS5.5 doc to new CS6 doc => IDML was wrong

Copy/pasted unformatted text from the converted CS5.5 doc to new CS6 doc => IDML was wrong

What I did not test:
If the issue is also with my German version of CS5.5.

Regards,
Uwe

[Laubender]

Laubender  wrote

… What I did not test:

If the issue is also with my German version of CS5.5.

Regards,
Uwe

Now I tested with a new document and new text with my German InDesign CS5.5.
The 8000th character, that was a end of paragraph sign did not convert to “U+2029” after exporting to IDML.

혜란이72662040 ,

what is your locale version of InDesign on what OS?
( I noticed that you are working with Japanese color management settings )

So I suspect a bug with a localized version or a version on Windows.

Regards,
Uwe

[혜란이72662040]

Hi~ Thank you for your help.

I created a new document in version 12.1.0.56 of InDesign CC 2017, but I have the same bug.

Below is a link to the file created in InDesign CC 2017.

http://ec2-54-64-80-132.ap-northeast-1.compute.amazonaws.com/indesign/test2.zip

This is Korean and I am using window7 (64bit) and CS5.5 is version 7.5.3.

And InDesign CC 2017 is version 12.1.0.56.

Thank you.

[Laubender]

And you did not copy the text over into the new InDesign CC 2017.1 document?
You typed it in as new text?

Regards,
Uwe

[혜란이72662040]

I entered the text myself.

There is no error in indesign CS 5.5(German).

Probably the Korean version is the problem.

[Laubender]

I still can see no reason why the Korean version should do this…
Maybe there are some other factors that I cannot see in your test files.
Like special formatting.

What baffles me most:
The problem does not go away if I copy the text from your test file and paste in without formatting to the first insertion point of a new document with a new text frame. InDesign detects no overrides. No formatting "remnants" perhaps from your Korean version. It's a mystery…

Maybe you can do another test with a script I wrote for testing your special case:

It will:

1. Add a new document.
2. Add a new text frame.

2. Add text to the story of the frame where the 8000th character is a end-of-paragraph-sign.

Install and test the script with InDesign CS5.5 and also with CC 2017.1.

You can download it from my Dropbox account:

Dropbox - Add-New-Doc-Add-8000-characters.jsx

How to install scripts:

How to Install InDesign & InCopy Scripts

Then flow the text manually in new pages.

If I do this with my German CS5.5 I will see no problem exporting to IDML.

Regards,
Uwe

[Laubender]

Also added to my Dropbox a sample result of the script run in my German CS5.5 version together with an exported IDML file:

Dropbox - Add-New-Doc-Add-8000-characters-CS5.5.zip

Regards,
Uwe

[Laubender]

I also looked into the code of an exported IDMS ( InDesign snippet ) file where I can see the issue:
7999 characters before the end-of-paragraph-sign.

And compared it to a file that is not showing the issue:
7998 characters before the end-of-paragraph-sign.

The difference in export is a missing <Br/> tag after the closing </Content> tag of the paragraph before the next that starts with some formatting instructions before a new opening <Content> tag begins.

Because of the missing <Br/> InDesign's import filter for IDMS and IDML is merging the two paragraphs into one.
I assume that special character U-2028 is injected because two </Content> … <Content> tags follow each other without a <Br/> after the closing </Content>.

Regards,
Uwe

[Laubender]

And because between the two </Content> … <Content> formatting instructions for paragraphs are done:

</CharacterStyleRange>
</ParagraphStyleRange>
<ParagraphStyleRange AppliedParagraphStyle="ParagraphStyle/Heading2">
    <CharacterStyleRange AppliedCharacterStyle="CharacterStyle/MMI_NoBold">

( I hope, that the forum editor will not spoil the XML formatted as code )

Regards,
Uwe

[혜란이72662040]

Add-New-Doc-Add-8000-characters.jsx

I think I need to add a text from the above file.

line 33 : textFrame.parentStory.characters[-1].contents = "\r";

textFrame.parentStory.characters[-1].contents = "8\r";

Modified jsx file

http://ec2-54-64-80-132.ap-northeast-1.compute.amazonaws.com/indesign/jsx.zip

Will you modify it and test it?

I get the same error in a document made of jsx files.

error file

http://ec2-54-64-80-132.ap-northeast-1.compute.amazonaws.com/indesign/test3.zip

If an error does not occur in the document created by the above script file

I think the design of a window OS is a problem.

Thank you very much for your help.

[Laubender]

Yep.

Thank you for correcting me!

I updated the script in my Dropbox account.

The end-of-paragraph-sign must be character 8001 in the story.
Not character 8000 as I initially thought.

So now I really can recreate the problem with my German CS5.5 InDesign.

And also with: CS6 v 8.1.0 and CC v 9.3.0 on OS X 10.6.8.
I'm sure that the issue can be seen in newer versions of InDesign as well.

Thanks,
Uwe

[Laubender]

Do a bug report on this:

Feature Request/Bug Report Form

Also refer to this thread here.

This is a rather strange issue…

Thanks,
Uwe

[혜란이72662040]

The bug report has already been submitted.

I haven't received a reply from Adobe yet.

Anyway, thank you for confirming that all designs are a problem.

[Laubender]

I'll do a bug report as well…

Regards,
Uwe

[Steve Werner]

You will not get a reply when you submit a bug report, but it will be read.

[Laubender]

Hi 혜란이72662040 ,

did some new tests and based on the results I think I have new evidence that we have to expand the rule when the bug hits.

Inserted tables can influence the bug.

It seems that the number of rows are counting as characters.

A table with 2 rows will shift the bug by: -1

A table with 5 rows will shift the bug by: -4

It seems a bit weird, but my tests are showing this.

Here an example where a character \r is character 7995 in the story. I selected the first paragraph inclusively its \r character. The story has one table before that with 5 rows. 7995 + 5 is our magic number 8000. Therefore the bug should hit on that \r after an IDML roundtrip.

Before the IDML roundtrip:

And indeed, after the IDML roundtrip the bug hit:

Also tested with one column and some text in the table. That did not matter. The number of rows adds up to the character count in the story.

FWIW: What I did not test, if it's important if the rows contain cells of type text.
Perhaps it would make a difference in InDesign CC 2015 and above if a row contains graphic cells only?
Would such a row count? Further tests will tale…

Now I speculate, that other special characters could also influence the point in the story where the bug hits.
But I have no evidence for this right now.

Regards,
Uwe

[혜란이72662040]

Hi~ Laubender​

Because the table rows were mostly single lines in my work, I did not know this bug.

When you test the table by adding the rows in the way that you gave it, the same error occurs in the 2015 version.

We hope to fix bugs in Adobe and we are looking for solutions before that.

Is it possible to have a script or grep that can find the 8000th character, including the table row, like the image you uploaded to the sample?

I can find the 8000th character except the table, but it can not be retrieved if it contains a table between characters.

Thank you for finding the bug and studying it together.

Your answer has helped me a lot.

[Fourteen]

I know this is an old thread but I wanted to mention that this bug still exists in CC2018.

[Laubender]

Confirmed.

Best,
Uwe

[glenbal]

Has anyone found a solution or workaround for this issue?

The bug as described is also happening when working with inCopy.

Regards,

Glen

[Laubender]

Hi Glen,

still there is no fix for this bug.

I see no workaround other than to open the original InDesign document where you can tell what formatting should be applied.

You can hunt for the special character, but you must consult the original document for the applied formatting to correct it in case, after the damage is done.

Regards,
Uwe