6 Replies Latest reply on Sep 28, 2009 10:06 AM by Patrick Leckey

    parseInt bug in Acrobat?

    MarkWalsh Level 4

      A script I have in many PDFs uses the parseInt() function to convert a string to integer. I have just found that it doesn't work properly (at least in 8.1.2) when the data being converted starts with a '0'. Using parseInt('19') will produce the result of '19', but parseInt('09') will produce the result of '0', not '9' as expected.

       

      I switched to using parseFloat(), and that seems to work fine (in this case, the value being converted will not be fractional), but is this a known bug? Is this fixed in later versions of Acrobat?

        • 1. Re: parseInt bug in Acrobat?
          Patrick Leckey Level 3

          What you're seeing is not a bug, it's expected.  You assume parseInt will always go with a base-10 conversion - however, it looks at the string to decided what is best if no base variable is supplied.  When there is a leading zero, it assumes a binary or hex string and then will stop when it hits an invalid character.

           

          If you want to force a base-10 conversion no matter what, simply specify it:

           

          parseInt('09', 10);

          1 person found this helpful
          • 2. Re: parseInt bug in Acrobat?
            MarkWalsh Level 4

            Thanks for the explanation. I was not aware of this.

             

            Is there a reason why this works differently in other Adobe apps? Running parseInt('09') results in '9' when run through ExtendScript for the CSX suite.

            • 3. Re: parseInt bug in Acrobat?
              Patrick Leckey Level 3

              Acrobat uses a JavaScript engine that is ECMAScript compliant (ECMA-262, Edition 3), and that is how the ECMA standard has defined the parseInt function.

               

              ExtendScript is NOT JavaScript.  It is JS-based, but it is not an ECMA-compliant language as it has been extended/modified for use in the CS apps so it may differ in functionality from an ECMA-compliant language.

              • 5. Re: parseInt bug in Acrobat?
                MarkWalsh Level 4

                Thanks for clarifying that for me, and the link is very helpful. I was not aware that I had not been using parseInt properly. The code I am using may have originated in an ExtendScript script, and, having worked properly there, I had naturally assumed it would be fine here. I shall need to be more careful when repurposing code from ExtendScript into Acrobat.

                 

                For reference, is there any documentation noting where ExtendScript is not ECMAScript compliant?

                • 6. Re: parseInt bug in Acrobat?
                  Patrick Leckey Level 3

                  No, and I mis-stated myself.

                   

                  Acrobat JavaScript is JavaScript 1.7 compliant.  JavaScript is a derivative of ECMA-262, edition 3.

                   

                  ExtendScript is ECMA-262, edition 3 compliant - however, it is NOT JavaScript compliant.

                   

                  As an example, ActionScript 3 is also ECMA-262e3 compliant but it is clearly a different language than JavaScript.

                   

                  If you're looking for documentation that says ExtendScript is not JavaScript, it's in the name.  In Acrobat it is clearly refered to in all documentation as JavaScript, not ExtendScript.