CS5.5 reached end of life a long time ago. Even if there is a bug, it will not be fixed.
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?
1 person found this helpful
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.
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.
If the issue is also with my German version of CS5.5.
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.
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.
Hi~ Thank you for your help.
I created a new document in version 126.96.36.199 of InDesign CC 2017, but I have the same bug.
Below is a link to the file created in InDesign CC 2017.
This is Korean and I am using window7 (64bit) and CS5.5 is version 7.5.3.
And InDesign CC 2017 is version 188.8.131.52.
And you did not copy the text over into the new InDesign CC 2017.1 document?
You typed it in as new text?
I entered the text myself.
There is no error in indesign CS 5.5(German).
Probably the Korean version is the problem.
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:
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:
How to install 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.
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>.
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 )
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
Will you modify it and test it?
I get the same error in a document made of jsx files.
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.
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.
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.
I'll do a bug report as well…
You will not get a reply when you submit a bug report, but it will be read.
2 people found this helpful
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.
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.