Export values and right-to-left radio buttons

[Joel Cherney]

I have a PDF that is an Arabic translation of an interactive form. There are a large number of yes/no radio buttons with tooltips and "Yes" and "No" export values in the source English form - a few thousand.

So I've written some JS to automate the process of replacing English tooltips with Arabic tooltips. I've already done this without a hitch in a dozen other languages.  However, when the form content is laid out right-to-left, as in Arabic, like this:

then my script to replace exportValues with localized Yeses and Nos reverses the order. Note that, when I'm selecting the Arabic Yes and No in the following GIF, that they're in logical order in the JS console, yet still get inserted in the wrong order when I run the code. 

How can I get the array in the console to insert values correctly into the radio buttons? Since exportValues are an array, I expected that I might be able to specify exportValue[0] or  exportValues[0] but it doesn't seem to work that way.

Is Acrobat just picking up the top leftmost value on the page first?

Is there any way to force Acrobat to respect the logical order of the text in the console?

Is there any way to address the values in the exportValues array one-by-one? 

[PDF Automation Station]

The export values are in the widget order - the order the fields were created.  exportValues[0] is the export value of the first widget of the field and exportValues[1] is the export value of the 2nd widget.  Write a script that loops through the exportValues array and creates a new array that pushes the replacements into the new array.  Then set the exportValues with the new array.  I'll use A and B export values in a radio button called Group1, in this example, and replace them with AA and BB, since I don't know Arabic:

var ray=this.getField("Group1").exportValues;
var ray2=[];
for(var i=0;i<ray.length;i++)
{
if(ray[i]=="A"){ray2.push("AA")}
if(ray[i]=="B"){ray2.push("BB")}
}
this.getField("Group1").exportValues=ray2;

You can expand this script to loop through all fields and test the type for radio buttons, the apply the script to each set of radio button fields.

[try67]

Just change the order in which they appear in the array. Move the Yes string to be the first in the array, and the No string to be the second one. I would actually strongly recommend to use variables for this, like so:

var yes = "نعم";
var no = "لا";
this.getField("Is this thing on?").exportValues = [yes,no];

The order in which the export values are applied is the internal order of the widgets, which is determined by their creation order. Their physical location on the page is not relevant.

[Joel Cherney]

Well! Thanks, folks, but these answers leave me with more questions. 

exportValues[0] is the export value of the first widget of the field and exportValues[1] is the export value of the 2nd widget.

I appreciate that I'm asking a "why does Javascript behave like this" question, and this Acrobat forum might not be the place to ask. But: just wrapping the statement up in the "ray" variable, and operating on ray[i] instead of this.getfield(etc) works, but this doesn't:

this.getField("Is this thing on?").exportValues[0] = ["نعم"]
this.getField("Is this thing on?").exportValues[1] = ["لا"]

I'm happy to take my "why does Javascript do this?" questions elsewhere, but beyond that, I think that there may be something wrong under the hood, here.  I don't want to have to test for the values of "Yes" and "No" because my client's source English is full of "No." and "YES" and "No:" and other items that will fail the "replace A with AA" instruction.

Just change the order in which they appear in the array. 

But... they're already in the right order! exportValues[0] should be "Yes" in English. That's why I included this GIF showing me holding down the Shift key and selecting letters one by one by hitting the right-arrow key, demonstrating that the glyphs render in the console in logical order:

If the Console is respecting logical order when I'm working in it, but visual order when actually running what's on the Console, then I figure it's not working correctly. In general, when working with RtL raw text, I expect logical order to be respected. 

But it's not, even when wrapping the RtL text up in variables. If their position is supposed to be derived from their order of creation, then why are they reversing order when I insert RtL values? 

[PDF Automation Station]

"Logical order" is subjective.  Field widget order is not.  If you loop through the array and create a new array with replacement values like I suggested, the order will be correct.  If you simply switch the order in your array you're assuming the widgets have the same order for all radio buttons, which they might not.

"I don't want to have to test for the values of "Yes" and "No" because my client's source English is full of "No." and "YES" and "No:" "

You could change the test to a regular expression that catches the different variations.

[Joel Cherney]

Thanks for your input, but absolutely not.  "Logical order" is part of the Unicode Bidirectional Algorithm.

[Joel Cherney]

To be clear: I tried looping through that array, and it did sucessfully replace English terms with whatever terms I pushed into ray2. I don't love that solution, because it requires a great deal more prep work, but it doesn't insert values in the wrong places. So I have to go and find all of the values that are neither "yes" nor "no" and manually fix them all, with this solution, which may well be the most time-efficient solution. 

I still don't understand why I can't specify exportValues[0] and have to store the whole statement in a variable, but I suppose that is a question about how Javascript works, and not how the JS API for Acrobat works, so I'll take that question elsewhere. 

> "I don't want to have to test for the values of "Yes" and "No" because my client's source English is

> full of "No." and "YES" and "No:" "

You could change the test to a regular expression that catches the different variations.

That makes a fair bit of sense. Because, besides the thousands of yes/no checkboxes, there are also thousands of other radio buttons that aren't yes/no radio buttons, so I suppose that "testing the exportValues with regex" makes more sense than "grabbing a list of field IDs known to be yes/no radio buttons and inserting Arabic terms for "yes" in all exportValues[0] and Arabic "no" in all exportValues[1]."

Finally: yes, simply switching the order in the array feels like an incorrect solution - that would be working around what I believe to be a bug in the implementation of the UBA in the Acrobat Console. That's what I'm chasing, here; I think that someone on the Acrobat dev team is Doing It Wrong and I'm considering working up a bug report. 

[PDF Automation Station]

The widget order is the order the fields were created.  Their position on the page doesn't set the order.  What if you changed the location of the fields on the page?  The export values wouldn't, and shouldn't, change.

[try67]

Your code doesn't work because you can't edit an item in a property array directly. You have to edit the entire thing, and then re-apply to the property. Same with rect, and other array-properties.

And with all due respect to the logic you want to follow, it means nothing in the PDF world. The only order that matters here is the widget order, as was explained. This is not a bug, and you have to adhere to it if you want your code to work properly.

[Joel Cherney]

Your code doesn't work because you can't edit an item in a property array directly. You have to edit the entire thing, and then re-apply to the property. Same with rect, and other array-properties.

That absolutely makes sense; 1000x thanks for this explanation. 

And with all due respect to the logic you want to follow, it means nothing in the PDF world. The only order that matters here is the widget order, as was explained. This is not a bug, and you have to adhere to it if you want your code to work properly.

That's utter nonsense (the Unicode specification is not "the logic you want to follow"), but thanks for posting it, because that's helped me finally pinpoint exactly where the bug actually is. It was maybe the third or fourth repetition of "widget order" that finally struck home for me. It didn't occur to me that the tool that generated the PDF would be important. So when I made the widgets in Yes - No order in InDesign and exported to interactive PDF, I expected that the creation order of the widgets would carry through to the PDF. 

Clearly, this is not the case. In this example, I created the radio buttons in ascending numerical order, in InDesign, and at PDF export, InDesign created (recreated?) the widgets in a top-down, left-right order, the exact opposite of the apparent order of creation from the operator's standpoint. Here's the fifth checkbox showing up as the first in the array:

So! Clearly my guess was wrong: there is nothing fundamentally wrong with the console's implementation of the bidi algorithm. That's reassuring to me. honestly. But there's still a bug; if widget creation order is that important, then probably InDesign should respect widget creation order, right?

It's a bug in InDesign, of course. 

It's a bug, and I have to adhere to it if I want my code to work properly. 

Thanks for your help. 

[try67]

So my reply is both "utter nonsense", as well as being correct? Wow, don't know how I managed to pull that one off... </s>

Anyway, if it's a bug in InDesign it won't be the first one we've encountered when it comes to form fields in PDF files. You would think Adobe would get it right, having written the original specs and the industry-standard application for the format, but I guess that's too much to ask for.

Glad to hear you were able to pinpoint the issue and solve it (hopefully), though!

[Joel Cherney]

So my reply is both "utter nonsense", as well as being correct? Wow, don't know how I managed to pull that one off... </s>

I'd credit it to your top-notch posting skills. Congratulations are in order, for sure! But I'm a localization engineer; 100% of my work in in complex writing systems. There is simply no way that I can sit still for skilled JS devs telling me "Logical order? Yeah? Well, you know, that's just like, uh, your opinion, man."  Perfectly happy to tell you aaaaaall about Unicode logical order, but I don't expect it would be of much use or interest to you, if you don't work in right-to-left languages. And Acrobat was, in fact, respecting logical order, as it turns out. 

It was your insistence that widget order creation was the only thing that influenced the index of the radio buttons that led me to go and make some new radio buttons, by hand, in Acrobat, fully expecting them to behave incorrectly. When they behaved correctly, it only took me about 1.5 seconds of slackjawed bewilderment and a swift palm-to-forehead gesture to figure out why they weren't still in the order in which I created them. 

Haven't yet nailed down a solution, though. Revealing this InDesign export problem caused me to do some QA that I ordinarily wouldn't have until much later in the project. Doing so revealed all kinds of showstoppers. InDesign is creating all fields in a top-down, left-right order. So the tab order is 100% left-to-right. Accordingly I have to figure out how to force right-to-left field creation order from InDesign (unlikely) or manually reorder many thousands of form fields in five right-to-left languages by dragging them around in the Fields pane (no thanks) or figure out how to automate the process of reordering form fields. 

[PDF Automation Station]

You could loop through all the fields and flip the export values of all radio buttons with 2 widgets:

for(var i = 0; i < this.numFields; i++)
{
var fName = this.getNthFieldName(i);
var oFld=this.getField(fName);
if(oFld.type=="radiobutton" && oFld.exportValues.length==2)
{
var aray=oFld.exportValues.reverse();
oFld.exportValues=aray;
}
}

Or, knowing the export values are reversed for you, set them to the Arabic "Yes" and "No" in the order that matches your form.

[Joel Cherney]

1000x thanks for this as well! I can't quite use it as-is; too many of my radio buttons are laid out vertically, so they're actually being created in the correct order to match my export-value script as-is. However, I think I can easily rework the conditional that finds radiobuttons to be more selective than just finding "all the radiobuttons with two options" and only look for the, um, approx. 527 yes/no radio buttons that need their values swapped. 

[try67]

You might be surprised to hear it, but I also started as a Localization Engineer, which is what introduced me to the world of PDF files, and my native-tongue is an RTL language (Hebrew), so I'm very familiar with BiDi issues, unfortunately.

And yes, setting the tab order correctly for an RTL form is a huge pain...

[Joel Cherney]

... yes, I am surprised. Flabbergasted, in fact. It's not like "logical order" is a phrase trying to say "an order which is logical." It's technical terminology, straight out of the Unicode specification. Maybe if you grow up computing in a RTL language, you don't need to pore over the Unicode spec obsessively in order to keep yourself from accidentally ruining the Hebrew layout in Pagemaker? You committed the alt-codes for pop directional formatting & LTR/RTL markers/overrides to memory at an age when kids in the Anglosphere are still working up to solid food? 

Anyhow, I think it's worth pointing out for folks who find this thread in the future that, if you export interactive PDF with "Use structure for tab order" checked, and then switch to manual tab order once the PDF pops up in  Acrobat, the default tab order is almost perfectly RTL.

Thanks again for your help & your patience. 

[try67]

> You committed the alt-codes for pop directional formatting & LTR/RTL markers/overrides to memory at an age when kids in the Anglosphere are still working up to solid food? 

LOL, something like that... You don't know how much better it is now, compared to the early days of computing. Just trying to have a single document with both RTL and LTR encodings used to be a nightmare.

[PDF Automation Station]

Just a question.  Why does it matter what the export values are from the end user perspective, as long as the one selected lines up with the text of the form?

[try67]

I don't know if that's the reason for what the OP is trying to do, but unfortunately Adobe recently changed the UI in a non-reversible way that exposes the export values to the user in a tooltip when they hover over the fields, so they are no longer a hidden value and have to be taken into account when designing the form in terms of UI, not just functionality. This is a very unfortunate change that has already caused a lot of issues and confusion.

[PDF Automation Station]

Wow, I never noticed that - probably because I rarely use radio buttons.  If prefer mutually exclusive checkboxes.  It could be helpful but the designer should have control.  

[try67]

I think it's also the case with check-boxes... Is it not?

[PDF Automation Station]

It sure is. 😞

[Joel Cherney]

. indeed. Export values are included in the tooltip only when you've named them with the same field name to make mutually exclusive checkboxes.

If you create a standard single checkbox, its default export value is "yes" but it doesn't get shown in the tooltip. 

[try67]

Ah, so it only happens when there's a group? That's good to know... Still, shame about this undocumented (and non-reversible) change to the way the application works. It only recently started doing that, you know.