Skip to main content
Participant
January 31, 2019
Question

Acrobat Javascript roundtrip to external editor replacing non-English characters

  • January 31, 2019
  • 4 replies
  • 839 views

I'm building an interactive PDF with JS in a project which requires language localization, so there's a bunch of strings in the JS with non-english characters.

Acrobat seems to support this nicely until you get an external JS editor involved, in which case Acrobat corrupts the code, replacing the non-english characters with garbage (see the proof of concept example below).

Why use the external editor at all? For small projects, you can paste your code from your preferred editor into Acrobat's bare bones internal JS editor, but once your code exceeds a certain character limit, Acrobat requires you to use an external editor exclusively. I haven't had any problems with this configuration when the code and strings made up of english characters.

If anybody has any ideas on how I might fix this, I'd be very appreciative.

Code maintained entirely within Acrobat:

/*---------- Begin PDF Document Script ----------*/

function Open()

{}

/*---------- Begin VARIABLE declaration ----------*/

// Field to variable connections

var dtlanguage = this.getField("dtlanguage");

var gVis = {

gVisSetLanguage : function () {

if (event.target.name == 'English') {

    dtlanguage.value = 'Hello there.';

    dtlanguage.textFont = "BentonSans-Light";

}

else if (event.target.name == 'Spanish') {

    dtlanguage.value = '¡Holå!';

    dtlanguage.textFont = "BentonSans-Light";

}

else if (event.target.name == 'Japanese') {

    dtlanguage.value = '資かけっ入迫';

    dtlanguage.textFont = "HiraKakuPro-W3";

}

}

}

Code saved through Acrobat's internal editor, then opened through an external editor:

/*---------- Begin PDF Document Script ----------*/

function Open()

{}

/*---------- Begin VARIABLE declaration ----------*/

// Field to variable connections

var dtlanguage = this.getField("dtlanguage");

var gVis = {

gVisSetLanguage : function () {

if (event.target.name == 'English') {

    dtlanguage.value = 'Hello there.';

    dtlanguage.textFont = "BentonSans-Light";

}

else if (event.target.name == 'Spanish') {

    dtlanguage.value = '�Hol�!'; // <--------- HERE

    dtlanguage.textFont = "BentonSans-Light";

}

else if (event.target.name == 'Japanese') {

    dtlanguage.value = '......'; // <-------- HERE

    dtlanguage.textFont = "HiraKakuPro-W3";

}

}

}

This topic has been closed for replies.

4 replies

Legend
January 31, 2019

It takes two to mojibake. It’s not a fault in one app but a disconnect between two apps.

So, what encoding does Acrobat export in? Preserve it.

Participant
February 1, 2019

That might be true, that it takes two to mojibake, but (to stretch the metaphor) it looks to me like both dancers are cutting a rug within Acrobat. Acrobat seems to be 'baking' the JS at the point that the external JS editor is launched before it passes it to the external editor, and I suspect again when it's ingested back into the pdf file.

Happily, I found a workaround: Foxit PhantomPDF.​ The PC version allows you to edit the Javascript (without launching an external editor). I can paste my JS right in, save the file, and then open it in Acrobat and it's all good–no mojibaking. I'm not sure what else this software does, but it seems to be pretty robust.   

Legend
January 31, 2019

Then you are using the wrong encoding to open the file. If you aren’t offered a choice, your editor may be unsuitable. You can’t escape encoding issues when using other character sets outside Latin1; we try but always our luck runs out in the end.

Participant
January 31, 2019

Alright, so it definitely looks like Acrobat is mojibaking the js coming in from the external editor.

Does anyone know if there's a way to configure Acrobat to accept UTF-8? My character set falls outside of Latin1.

Also, Acrobat accepts the UTF-8 JS as long as it's dropped in via the internal JS editor. The mojibaking is only occurring when importing the JS from the external editor.

try67
Community Expert
Community Expert
January 31, 2019

Do NOT edit the code using the Edit All JavaScripts command! It can seriously mess up your file.

If you want to edit a doc-level script do so via Document JavaScripts. For all other scripts go to where they are located (field, bookmark, link, etc.) and edit them there.

What external editor are you using?

Participant
January 31, 2019

Thanks for the reply.

I'm using the Document JavaScripts function, so that's not the issue.

Regarding the using scripts where they're located, my actual project is just too complex. (The code in my post is just to illustrate the issue.) I have almost 3,000 lines of code supporting 100+ of objects in the document. So it's definitely not practical and probably not even possible to bake them in at the object level.

I'm using Atom as my external editor. But I've also tried configuring the external editor to be Brackets, and I get the same results. 

try67
Community Expert
Community Expert
January 31, 2019

Move all the code to doc-level script(s) and edit it from there. If you don't you might end up with a file that's corrupt and can't be fixed, and will need to re-do all of your work. You've been warned.

Legend
January 31, 2019

Looks like a typical mess of mojibake. Make sure you use the right settings for encoding when you save from your external editor. No I don't know what you need to choose, so experiment !

Participant
January 31, 2019

That sounds like it's on the right track, but the problem occurs even when I do not save the JS in the external editor.

In other words, if I open a PDF with the in-tact JS, then configure Acrobat to use an external editor, and then launch the JS editor (which launches the external editor), I can see the JS looks wrong in the external editor, so I quit that without saving. Now the js is corrupt in Acrobat.