Release: InData 3.5.1 for InDesign 2024-2026

Update

To update, download and install the latest version from the product’s installation section.

Changes

• Fixes support for InDesign 2026’s Flex layout containers. Flex items that appear in a prototype are now copied to the output just like other page items.
• Uses applied formatting when importing dates and numbers from Excel spreadsheets. Previously, dates were imported as epoch offsets (like "45782″ for a cell containing the date “5/5/25”), and prices were imported as raw numbers (like “4.5” for a cell containing “$4.50”).
• Fixes a problem introduced by the 3.3 release that can cause InDesign to shut down unexpectedly when updating headers if a master page header/footer item can’t be overridden on the local page.
• Fixes string comparisons performed by the is, =, is not, <>, !=, <, <=, >, >=, contains, is in, is not in operators and the offset, replace, and replaceAll functions so that they properly handle Unicode diacritical marks (both precomposed and decomposed), ligatures, and characters that are subject to locale-specific peculiarities.
  
  Prior to this release, Unicode strings were compared as individual code points (character by character). Unfortunately, this approach didn’t allow for decomposed combining marks, handle ligature expansion (where Æ compares as AE), or honor traits of a locale that might require knowledge of the character’s neighbors or position.
  
  Now, Unicode string comparison is performed holistically in the context of the system’s locale using the venerable International Components for Unicode (ICU) open source library.
  
  With the exception of ligatures, this change should not affect existing imports since — and with apologies for the circular reasoning here — imports that already work likely don’t rely on what this change addresses. After updating to this release, imports of text containing ligature characters may not work as expected since Æ, for example, has never been seen as a match to any character besides itself before.
  
  How String Comparisons are Performed
  
  In general, comparisons of character strings differ depending on whether the test is for equality (= and != operators) or for string order (<, <=, >, >=)¹. In tests for equality, the case of letters and all diacritical marks are ignored, so all of the following strings will be seen as equal: Ann ann ÁNN ánn Ânn ânn.
  
  In tests involving string order, case and diacritical marks are taken into consideration only when two character strings would compare as equal under the test for equality. In this case, all upper-case letters, regardless of diacritical mark, are always less than every version of the same lower-case letter, again regardless of diacritical marks.
  
  To illustrate, a < à < á < â < ä < ã < å shows the ordering of diacritical marks, from least to greatest, for the letter a. Likewise, o < … < ö < õ < ø shows the ordering for the letter o.
  
  Thus, A is less than a, Ab is less than ab, but Ac is greater than ab, since the difference between the A’s is significant only if the entire strings compare equal otherwise. Similarly, año is greater than ano and greater than Año, but Año is greater than Ano.
  
  Ligatures are handled by expanding them to their two-letter equivalents. Thus, for tests of equality, the character Æ tests as equal to AE. For the purposes of the comparison operators, the ligature characters are greater than their two character equivalents.
  
  ¹ Unlike offset, which uses a case-insensitive “equality” search, the replace and replaceAll functions use a case- and diacritic-sensitive search when finding the pattern to be replaced.
• Fixes upcase, downcase, wordcase, [the] number of chars, [the] number of words and the word operator when used with Unicode strings containing combining diacritical marks, ligatures, and characters subject to locale-specific peculiarities.
• Enhances set worddelimiters to accept a bracket expression like “[a-z]” for describing the set of characters that separate words within expressions. A string that begins with “[“ and ends with “]” is now interpreted as a Unicode set pattern (as described in ICU’s UnicodeSet documentation) instead of a list of characters. The default delimiters are space and all control codes (Unicode C0 & C1).
• Enhances set wordcharacters to accept a bracket expression like “[a-z]” for describing the set of characters that are considered part of words. All other characters are considered word delimiters. A string that begins with “[“ and ends with “]” is now interpreted as a Unicode set pattern (as described in ICU’s UnicodeSet documentation) instead of a list of characters.