[ANN] IdExtenso: InDesign JSX Framework

Report · Apr 23, 2017

Hi colleagues,

I'm open-sourcing IdExtenso—a (new) ExtendScript framework for InDesign scripters—and I'd be happy to get feedback, issue reports, requests, etc.

The core structure may seem a bit esoteric but the key idea is really simple: delivering rich and efficient modules thru an easy-to-use API embedded a single object ($$). You can already test nice features such as JSON, HTTP, localization helper, but that's the tip of the iceberg, I hope 😉

Thanks for joining, or sharing: GitHub - indiscripts/IdExtenso: ExtendScript Framework for InDesign Ninjas

Best,

Marc

Report · Apr 24, 2017

Thanks Marc.

Very interesting and high quality stuff there.

Thanks for sharing.

Trevor

Report · Apr 24, 2017

Hi Marc,

To be honest, I didn't give this a try at this time but certainly will asap. Thanks however for the effort and spirit for sharing such a ressource !

Loic

Report · May 08, 2017

Very nice! Thanks for sharing!

Cheers,

Kris

Report · Nov 13, 2017

Hi colleagues,

Thanks for your kind feedback.

Just to mention that IdExtenso has progressed from ‘alpha’ to ‘beta’ version. Not yet an official jump, but something a bit more consistent 😉

And now the framework has an API browser. Call $$.help() to see it in action:

Hope you'll like it.

Best,

Marc

GitHub - indiscripts/IdExtenso: ExtendScript Framework for InDesign Ninjas

Report · Nov 13, 2017

Just curious what are those numbers about? 1.7111 etc.

Report · Nov 13, 2017

Trevorׅ a écrit
Just curious what are those numbers about? 1.7111 etc.

Versioning!

…and easy to decipher: all modules have a YYMMDD number. The displayed version is nothing but YYMMDD/1e5 😉

Best,

Marc

Report · Nov 14, 2017

So we shouldn't expect version 3 to come out too soon

Report · Nov 14, 2017

Indeed 😉

“Qui vivra verra…”

Report · Nov 17, 2018

Hi colleagues,

A short message to inform IdExtenso's users that version 1.81117 provides a patch to the parseInt(…) function which, in ExtendScript, has a funny behavior:

// ExtendScript bug
parseInt( ":", 11 ) === 10  // Should return NaN
parseInt( "=", 16) === 13   // Should return NaN
parseInt( "a?", 16) === 175 // Should return 10

Fixed here: IdExtenso/core/Ext/$$.global.jsxinc

Best,

Marc

Report · Nov 18, 2018

Makes one wonder how the bug was created, what is the relationship between : and 10 ?

Using base 36 (or 17 up) provides

: 10

; 11

< 12

= 13

> 14

? 15

@ 16

Looking at the ascii table provides the key ASCII Table | ASCII character codes table

48 30 00110000 0 zero

49 31 00110001 1 one

50 32 00110010 2 two

51 33 00110011 3 three

52 34 00110100 4 four

53 35 00110101 5 five

54 36 00110110 6 six

55 37 00110111 7 seven

56 38 00111000 8 eight

57 39 00111001 9 nine

58 3A 00111010 : colon

59 3B 00111011 ; semicolon

60 3C 00111100 < less than

61 3D 00111101 = equality sign

62 3E 00111110 > greater than

63 3F 00111111 ? question mark

64 40 01000000 @ at sign

65 41 01000001 A

66 42 01000010 B

67 43 01000011 C

68 44 01000100 D

69 45 01000101 E

70 46 01000110 F

So now we know!

Report · Nov 18, 2018

Hi Trevor,

Yes, the bug probably comes from a permissive code in the function const bool String::parse(String &,int &) from ExtendScript's sccore.dll.

It basically allows character codes in the range [0x3A..0x3F] to get meaning when the radix increases:

With radix 16 (hex), the bug also affects the scheme Number("0x..."), as shown below.

// Example with radix==16 (0x...)
// ";" == "\x3B" is interpreted as 11 (= 10 + 0x3B-0x3A)
// "=" == "\x3D" is interpreted as 13 (= 10 + 0x3D-0x3A)
// ---
alert( Number("0x;=") );      // => 189 (!) i.e. 11*16 + 13
alert( parseInt(";=", 16) );  // => 189 (!) idem

(There are good reasons to suppose that String::parse(String&, int&) is internally invoked in either case.)

@+

Marc

Report · Mar 26, 2019

Hi colleagues,

A message to inform IdExtenso's users that the Web module has been deeply re-designed and improved in a way that makes all HTTP strategies safer and easier to identify.

Here are the dependencies regarding http and https transactions:

Web / HttpSocket implements a basic HTTP 1.x Socket client.
Web / HttpSecure.Mac invokes curl via AppleScript.
Web / HttpSecure.Win invokes XMLHTTP via VBS.

These different strategies are intended to be transparent from the API standpoint: simply call $$.Web.get(httpURI) to download the target. Options and returned value detailed here: $$.Web.get(...) method.

Note: HttpSocket can only address pure http requests, but this is a safe and pretty fast approach despite the “obsolescence” of ExtendScript's Socket object. What makes it an essential brick of the Web module is that it still works when InDesign is in “modal state”. In other words you can use it from within a ScriptUI dialog. The HttpSecure snippets use OS-dependent components that involve app.doScript(…) and therefore require the nonmodal state.

I'd be very grateful to users for getting feedback and bug reports regarding this module, as this is to a large extent a “black-magic” solution. The best way to test it is to run the PlaceWebImage.jsx demo script in InDesign and try various image URLs, based on either http or https.

Thanks,

Marc

More on IdExtenso project: GitHub - indiscripts/IdExtenso: ExtendScript Framework for InDesign Ninjas

Report · Mar 14, 2019

Hello! We've been experimenting with IdExtenso a bit. Specifically, the PlaceWebImage test. It seems like the exact thing we're looking for. However, It sometimes works, and sometimes does not, and we can't seem to figure out exactly why. One issue seems to be HTTPS, is there support for that? If so, could you point me in the right direction of pulling in an image from HTTPS?

Using the default image as an example (http://indiscripts.com/blog/public/IndiscriptsLogo.png ). This works just fine and places the image in. If I add the HTTPS (https://indiscripts.com/blog/public/IndiscriptsLogo.png ), it fails with the error: Cannot place this file. No filter found for requested operation. Even though the image appears to be valid in my browser. I've also tried pulling in from random sites, and some seem to work, but others throw the same error (even if they're not HTTPS). Could you possibly shed some light on why this error is occurring?

I've included the log that is generated below, if that helps.

=======  New Logging Stage:  TRACE (2019-03-14 16:28:37) =======
               001  [TRACE]  $$ > IdExtenso is loading in engine 'main'...
               003  [TRACE]  $$ > Env [190311] Calling onEngine().
               005  [TRACE]  $$ > Env [190311] Calling onLoad().
               009  [TRACE]  Env > OS: Windows 10/64 10.0  
                             InDesign:        CC14 (14.0.1.209) [Dark UI]
                             ExtendScript:    4.5.6 (build: 80.1060872)
                             ScriptUI:        6.1.8 (core: 6.2.2/Drover)
                             IdExtenso:       1.90303 [run #6]
                             Engine:          "main" [non-persistent]
                             Script (JSX):    PlaceWebImage.jsx [~/AppData/Roaming/Adobe/InDesign/Version 14.0/en_US/Scripts/Scripts Panel/IdExtenso-master/tests]
                             DOM version:     14.0 [OK]
                             Undo Mode:       SCRIPT_REQUEST
                             Preferences:     Redraw=true ; Level=INTERACT_WITH_ALL ; Unit=AUTO_VALUE
                             Display:         Screens: 1 ; 96 ppi ; Primary #0: [0,2560]x[0,1560] ; Workspace: [0,2560]x[0,1560]
                             User:            "djwilson" on DUSTIN
                             Locale:          ENGLISH/en_US
                             Running Code:    JSX Stream
               011  [TRACE]  $$ > File [180307] Calling onLoad().
               013  [TRACE]  $$ > IdExtenso is now loaded. (Loading time: 12ms.)
16:30:07     89512  [TRACE]  Web > https required for uri "https://indiscripts.com/blog/public/IndiscriptsLogo.png".
             89533  [TRACE]  Web > HTTP Header Content-Type: "image/png".
             89535  [TRACE]  Web > HTTP Header Content-Length: "2271".
             89537  [TRACE]  Web > HTTP Header Alt-Svc: "quic=\":443\"; ma=2592000; v=\"35,39,43,44\"".
             89538  [TRACE]  Web > HTTP Header Expires: "Thu, 21 Mar 2019 21:28:26 GMT".
             89540  [TRACE]  Web > HTTP Header Last-Modified: "Mon, 23 Oct 2017 22:36:49 GMT".
             89542  [TRACE]  Downloaded data: "\u5089\u474E\u0A0D\u0A1A"
             89551  [WARNG]  ERROR (wild) > Cannot place this file. No filter found for requested operation.
                             Stack: [PlaceWebImage.jsx] :: receiveError_$Error$_([Error:Error: Cannot place this file. No filter found for requested operation.])
16:33:45    307588  [TRACE]  $$ > IdExtenso is unloading (KEEP_DORMANT=false)...
            307591  [TRACE]  $$ > Log Calling onUnload().
            307593  [TRACE]  $$ > Env Calling onUnload().
            307596  [TRACE]  $$ > IdExtenso is now unloaded. (Unloading time: 8ms.)
-------  End Logging Stage:  TRACE (307603ms) -------

Report · Mar 15, 2019

Hi Dustin,

Thanks a lot for your bug report.

HTTPS is really the hard part of the Web module, specially on the Windows side. (In my opinion, VBS is the worst of all scripting languages.)

Anyway, your trace log helped me discover an important clue. The downloaded data string (89542) is obviously truncated:

"\u5089\u474E\u0A0D\u0A1A"

Fortunately, those few bytes show what's going wrong: XMLHTTP returns a responseBody property in 'raw bytes' form. The CStr() function cannot digest these data. Also, since the initial bytes of a PNG are known to be

89 50 4E 47…,

we see how the downloaded stream

\u5089\u474E…

should be interpreted and ordered.

So I rewrote the routine that runs the VBS and parse the result. In VBS, a poorly documented function—Escape(str)—allows to recover the entire stream in a strange format ("%u5089%u474E…") That's weird but the string is no longer truncated. From then I invoke a short replace function through the regex /%u[\dA-F]{4}|%[\dA-F]{2}|./ and it seems to properly unescape the result.

I then tested PlaceWebImage with the following urls:

https://forums.adobe.com/community/image/3331/2.png

https://images.pexels.com/photos/1159670/pexels-photo-1159670.jpeg?auto=compress&cs=tinysrgb&dpr=2&h...

https://m.media-amazon.com/images/M/MV5BOTI4ZmNmNjgtMDAwOS00Mzc2LTg0YzMtODc0ODQ0NTQ2NzRjXkEyXkFqcGde...

and it worked 🙂

Now, I'm surprised that https://indiscripts.com/blog/public/IndiscriptsLogo.png did not instantly fail, since SSL is not available on my server. Here again, your trace log reveals interesting things:

Web > HTTP Header Alt-Svc: "quic=\":443\"; ma=2592000; v=\"35,39,43,44\"".

which relates to a HTTP Alternative Service (another obscure topic, I'm afraid.)

Please, give a try to the updated Web module and keep me informed:

IdExtenso/$$.Web.jsxlib at master · indiscripts/IdExtenso · GitHub

Best,

Marc

Report · Mar 15, 2019

Marc,

Thank you so much for taking a look a this and getting back to me. The updated version works perfectly! I don't have too much experience with VBS, but I feel for you!

This solves our first issue of getting images from our DAM into InDesign, which has been a very large pain point for us!

Our next task is to tackle getting JSON data into our InDesign documents, and while you're here I may ask if you have any quick examples of that we can work off of?

Report · Mar 15, 2019

Out of curiosity, what's the DAM of yours ?

Report · Mar 15, 2019

Loic, we use one called ResourceSpace (Open Source Digital Asset Management (DAM) Software: ResourceSpace ). It suits our needs well, and it's open source. Our goal is to eventually have a panel in InDesign that our team can use to pull in images and JSON data from our other sources.

Report · Jun 29, 2023

Hi colleagues,

Just a quick note to mention that a completely unsuspected bug has been discovered in ExtendScript CS4/CS5 (not the most up-to-date environment, I agree, but this may still be of some interest to researchers!) It turns out that the basic expression myString.indexOf(…) is unreliable when processing byte strings or similar encoded streams that may contain '\u0000' aka '\0' characters (U+0000 in Unicode).

→ Further detail:
https://github.com/indiscripts/IdExtenso/blob/master/CHANGELOG.md#230628

Unnoticed until today, this critical malfunction can be worked around by rewriting String.prototype.indexOf, which has been done yesterday in the special string extension available in IdExtenso.

→ Patched code:
https://github.com/indiscripts/IdExtenso/blob/9e9d28a129699763b0954ae018e09b41f38ba0bf/core/Ext/%24%...

(Do not hesitate to give me feedback or open a GitHub issue if you detect any problem with that code.)

Best,

Marc

Adobe Community

[ANN] IdExtenso: InDesign JSX Framework