Is your code to create XML on the fly inside InDesign? How does that table (without any data inside!) then appear? Perhaps it's a bug that you could actually specify it in earlier versions and that has been fixed ...

To put it in a nutshell, the following 1-line script throws an error if the target in ESTK is InDesign 2019, but not if it's ESTK, or InDesign 2018.

x = <myxml>{String.fromCharCode(22)}</myxml>

To me it seems very strange the the Javascript interpreter should be affected by the target-app dropdown in ESTK, especially considering that this 1-liner doesn't actually touch the target application in any way.

Thanks. Interesting that you were even able to wrap this in try-catch. Were you running the script in InDesign? When I tried to run it in ESTK with ID2019 as target, even try-catch didn't help. (Actually, maybe I didn't check my debug options, but I think I did tell it not to break.)

Thanks. Interesting that you were even able to wrap this in try-catch. Were you running the script in InDesign? When I tried to run it in ESTK with ID2019 as target, even try-catch didn't help. (Actually, maybe I didn't check my debug options, but I think I did tell it not to break.)

Hi Ariel,

I did my tests with the ESTK CS6 3.8.0.12 and also with ESTK CC 4.0.0.1 with target InDesign CC 2019 14.0.1.209 on Windows 10 Pro. Trevor's code with try-catch worked like it should. Had exactly the same results as Trevor is showing in reply 4. Maybe it will turn out differently, try-catch not working, on OS X ?

Very interesting about InCopy which my understanding was that it's basically InDesign core with a different set of plugins and UI.

Hi Ariel

Martinho's method I think is the way to go, XML literals E4X had not been supported in mainstream JS environments for years and I can't see it holding out for long in AdobeLand. Using methods like appendChild is going to make porting to the new environments a lot more simple as those methods are much more similar to what is going to be available.

You can see what the engineers come up with but it just a matter of time before it breaks again forever even if they do fix it.

To me it seems very strange the the Javascript interpreter should be affected by the target-app dropdown in ESTK, especially considering that this 1-liner doesn't actually touch the target application in any way.

What allows me to make this assumption is that typical XML tokens and error strings appear in ExtendScript's core library (ScCore.dll) and most of them are clearly connected to Expat parameters.

2. Expat is “an XML 1.0 parser”, as stated in its documentation and confirmed in its source code. For example, the header asciitab.h has the folowing lines

which indicates that almost all control codes from 0x00 to 0x1F are considered NONXML—and then should be reported as invalid by the tokenizer.

As already observed by my colleagues, the only control codes allowed in XML 1.0 are U+0009, U+000A, U+000D. Hence, the code 0x16 (decimal 22) which TaW has inserted in its XML stream should have failed from the very beginning, in any target app.

3. However, Expat has, or had, various bugs that made it more or less permissive regarding the XML spec. Many updates and fixes are reported in the changelog from release 1.95.0 (Sept. 2000) to 2.2.6 (Aug. 2018.) I do not understand those technical details, but sentences like “Fixed UTF-8 decoding bug that caused legal UTF-8 to be rejected”, “Check that a UTF-16 encoding in an XML declaration has the right endianness”, or “Mass-fix compilation for XML_UNICODE_WCHAR_T”, etc. sound very much in connection with our topic.

Also, depending on how Expat is configured when compiling the lib, I suppose that the client can get the tool in various flavors. Cf. the section “Configuring Expat Using the Pre-Processor” in the documentation.

4. Now, let's go back to the original question: how is it possible that ID CC 2019 differs from ID CC 2018 regarding XML parsing at the ExtendScript level? My guess is that they may not use the same Expat version (in ScCore.dll.) The following screenshots strongly support that view: