Release: Xtags 3.14.1 for QuarkXPress 2016/2017/2018

February 4, 2019 by

This patch fixes conditional picture imports and lets old-style Mac-Roman/Win-Latin files contain embedded utf-8-encoded Unicode characters.

Changes

  • Fixes conditional picture importing (where a picture’s path has a leading ?), which was broken back in the 3.8 release.
  • Supports arbitrary utf-8-encoded Unicode characters within Macintosh- and Windows-encoded text files (those with a leading <e0> or <e1>, respectively). We improved on the policy adopted in the 3.13 release, where a single, embedded utf-8-encoded character would automatically — and sometimes problematically — upgrade the whole file’s encoding to Unicode, by retaining the original encoding and processing any Unicode characters as one-offs. This change allows legacy files containing both special, “high-ASCII” characters and new-style, utf-8-encoded Unicode characters to import without producing an error.
  • Gives an alert when invalid Unicode characters have been replaced with the Unicode replacement character (U+FFFD) during an import.
  • Fixes the encoding tag of tagged text put on the clipboard with Copy with Xtags (to be <e9>, for utf-8). (macOS only)
  • Fixes a problem introduced in the 3.13 release where Xtags would silently abort an import if an invalid byte sequence for a utf-8-encoded Unicode character was found. Now, the import continues up to, but not including, the bad sequence (leaving the insertion point to indicate where in the tagged text the bad sequence was found) and then displays an error alert.
  • Fixes a problem introduced in the 3.13 release in which the encoding tag (<eN>) was being ignored if Xtags detected any utf-8-encoded characters in the imported text. The encoding tag now overrides whatever (8-byte) encoding Xtags has auto-detected, just like it did before the 3.13 release.

WordPress.org

© 2010 Em Software - Business WordPress Theme by ThemeShift