25
Replies
Hi Johan,
I see the issue with the exported PDF as well.
Bug confirmed.
What I did:
Opened your "thai test export.pdf" in Acrobat Pro on my Windows 10 machine.
Copied the text to the clipboard, turned to your InDesign document where I activated the font Adobe Thai Regular from Adobe fonts and pasted the text in a text frame that was formatted with Adobe Thai Regular.
Did the same with "thai test print.pdf" in Acrobat Pro on my Windows 10 machine.
No issues with "thai test print.pdf", three different results, all wrong, with "thai test export.pdf":
Voted and commented at InDesign UserVoice.
Regards,
Uwe Laubender
( ACP )
Also tried the following workflow with InDesign 2021 on Windows 10:
Print to PostScript > distill to PDF
Copy text from PDF
Straight away that did not work.
One error A couple of errors in the result sneaked in. See screenshot below.
What worked without flaw:
Switched to the Edit PDF workspace in Acrobat Pro DC and copied from that.
Regards,
Uwe Laubender
( ACP )
EDITED: Added a different screenshot with the error marked.
We (the DTP department in a translation agency) also got issues with Thai encoding in PDFs exported from InDesign 2021 (v16).
Just like thread starter Johan we can't use "Print to Adobe PDF" as a workaround because we are working on interactive documents which contain form fields and buttons.
Laubender mentioned that the bug would not exist in INDD2019, but our export to PDF from INDD2019 (v14.0.3) still shows issues, even if not the complete mess we get from the higher versions.
So, here we go, in this post everything refers to INDD2021:
Text encoding is fine in the INDD, compare screenshot 1.
I can properly copy text to my clipboard and place it in a TXT editor. If in the first line one of three Unicode characters gets displayed separately from the rest of the abugida, this seems ok and only got to to with how the editor decides about text placement in this line. In the last line the same three characters ('THAI CHARACTER SO SUA' + vowel mark + tone mark; U+0E2A + U+0E37 + U+0E48) combine well to properly form the Thai abugida in question.
Similar case further to the right, and the rest of the text is completely unconspicuous as far as I can tell.
screenshot 1)
But in the PDF we exported from that very INDD that is no more the case. On the surface it looks fine, but again copying over to a clean text format reveals quite a mess, see screenshot 2.
We now got multiplying tone and vowel marks all over the place (compare the purple boxes), plus empty squares and black diamond question marks which indicate invalid or replacement characters and also some extra empty spaces thrown in between. No good at all.
For a more detailed look, here I chose the first complex (and at once showing a broken encoding) abugida to place on the last line (in the red boxes). First it properly displays the three parts it is supposed to contain: 'THAI CHARACTER RO RUA' + vowel mark + tone mark (U+0E23 + U+0E37 + U+0E48), but then it is followed by unwanted stuff like the characters U+DBC0 and U+DEE0), then adding the same tone mark another time (U+0E48).
Same story with the character we already copied in the first screenshot (orange boxes). After the three correct Unicode characters which already form the abugida (U+0E2A + U+0E37 + U+0E48), we also receive the same unwanted trio (U+DBC0 + U+DEE0 + U+0E48) as above.
screenshot 2)
Our linguists need to be able to properly work with the text in the PDFs, that is to copy the text in its proper encoding over to comment boxes and other tools. We also want to deliver properly working PDFs to our client. Obviously with these PDFs we can't do that.
I will vote in the uservoice post provided by Johan and soon add some more details regarding the issues we see in Thai-PDFs exported from INDD2019 .
Hello Johan and Laubender, thank you for the quick replies.
About using different fonts: for Thai, we are working with „Sarabun“, „Neue Frutiger Thai“ and „Noto Sans Thai“.
In the INDD unsurprisingly the text encoding is always clean, only after exporting to PDF the problems develop and then indeed differently for different fonts. But so far no font seems to work without fail. If you could recommend a looped style Thai font, which produces reliable results (at least in INDD2019), it would be very welcome.
But now more details from our file:
1) First I converted it to INDD2019, font is still „Sarabun“, export method is still „interactive PDF“.
(I also exported this as a „print PDF“ but the results in both PDF and TXT file were identical to the „interactive PDF“ export, showing the same issues at the same position, so that setting doesn’t seem to be a factor.)
Here we still got 3 issues in 2 categories
case 1: line 2 (orange box)
PDF export messes with the sequence of the Unicode characters (THAI CHARACTER SARA UEE now appears over the wrong abugida) and adds a space:
INDD: \u0e2a\u0e37\u0e48\u0e2d\u0e2a\u0e32
PDF: \u0e2a\u0e48\u0e2d\u0e37 \u0e2a\u0e32
also case 1: line 4
INDD: \u0e40\u0e1e\u0e37\u0e48\u0e2d\u0e1b
PDF: \u0e40\u0e1e\u0e48\u0e2d\u0e37 \u0e1b
case 2: line 4 (red box)
PDF export adds invalid characters U+DBC0 + U+DEF8
INDD: \u0e23\u0e17\u0e33\u0e07
PDF: \u0e23\u0e17\udbc0\udef8\u0e33\u0e07
2) After switching the font to „Neue Frutiger Thai“ and converting to INDD2019 we are down to only one issue, exactly the same case 2 (line 4, red box) from above.
3) But with „Noto Sans Thai“ (INDD2019) again quite a few problems are cropping up in the PDF:
case 1b: line 2 (purple box)
Variant of case 1, now two characters move to the wrong position, then a space gets added
INDD: \u0e40\u0e0a\u0e35\u0e48\u0e22\u0e27
PDF: \u0e40\u0e0a\u0e22\u0e35\u0e48 \u0e27
also case1b: line 4
INDD: \u0e07\u0e1c\u0e39\u0e49\u0e2d\u0e37\u0e48\u0e19
PDF: \u0e07\u0e1c\u0e2d\u0e39\u0e49 \u0e37\u0e48\u0e19
case 3, line 2 (blue box)
PDF export messes with the sequence of Unicode characters, two diacritics move to the wrong abugida, but no space is added.
INDD: \u0e30\u0e1c\u0e1d\u0e39\u0e36\u0e49\u0e01
PDF: \u0e30\u0e1c\u0e39\u0e49\u0e1d\u0e36\u0e01
case 2 (line 4, red box) seems to be wrong all the time, no matter which font is being applied
Also many thanks to Laubender for the idea to assemble the final PDF from two exports, that might indeed work, event though not out of the box.
Here we need to replace step [1] with a „Print to“ -> Adobe PDF, because „Export as“-> Print PDF still gives us the same encoding issues.
... and then the placement of elements is a little off compared to the „Export as“->Interactive PDF. But this looks fixable.
And it is probably a matter of luck that the button texts (from the „Interactive PDF“) stay in proper encoding, they are usually short which should help, at least in my current test project they did.
Still, Adobe should make some effort to fix these issues. When exporting to PDF preservation of the proper encoding should not depend on workarounds.
AdChoices
