Release: Xcatalog 6/7.3.0.9 for QuarkXPress 6/7

November 8, 2007 by cpr

This set of release notes covers the whole Xcatalog 6/7 series.

Changes at 6/7.3.0.9 release

Worked around a quirk with Microsoft’s ODBC SQL Server driver which was causing data updates of complex views to report “No rows found to update” even when the updates had been successful.
Fixed a problem introduced in 7.3.0.3 where incorrect page numbers of pages within sections were being displayed in error logs. (QuarkXPress 7 only)

Changes at 6/7.3.0.8 release

Fixed a problem where updating links from a MS SQL Server database via ODBC would fail with the error “Invalid cursor state.” (Windows only)
Enabled the Pro version’s ODBC support on Intel-based Macs. It’s no longer necessary to run QuarkXPress 7 under Rosetta to connect to an ODBC data source. (QuarkXPress 7/Mac OS only)

Changes at 6/7.3.0.7 release

Updating documents with styled prices requiring the removal of extra fractional digits (“19.950” being reformatted to “19.95”, for example) no longer causes QuarkXPress to hang.
Fixed a problem which was preventing AppleScripts from communicating with Xcatalog on Intel-based Macs. (Mac OS only)

Changes at 6/7.3.0.6 release

Fixed a problem where “View”-ing the error log would result in an empty document on an Intel-based Mac. (QuarkXPress 7 only)
Fixed a problem where importing a Euro character from a Windows snapshot would result in a not-equal character. (QuarkXPress 6/MacOS only)

Changes at 6/7.3.0.5 release

Corrected an issue that was preventing the ODBC/MS Access fix applied back in version 6.3/7.3 from working properly. (Windows only)

Changes at 6/7.3.0.4 release

Fixed a problem when working with a DBMS via ODBC where an Update Data of a field whose value hadn’t changed from the value already in the DBMS would result in an erroneous “Row not found” message.
As a side-effect of the above fix, we no longer update values in the database that haven’t changed. (This is all done transactionally so we’re safe from simultaneous updates.)
Fixed a problem where character style callouts like <@...> in imported fields marked as “tagged” were being ignored.

Changes at 6/7.3.0.3 release

Fixed an incorrect SQL “insert” statement that was causing all attempts to update an ODBC database to fail.
Improved the logging facility to support the longer, more descriptive messages being provided by modern ODBC drivers and managers. This addresses a problem where some ODBC errors were not being displayed at all, the result being a vague or empty log entry.
Fixed a minor problem where older 6.x serials were being forgotten in some situations and needed to be reentered on each restart.

Changes at 6/7.3.0.2 release

Fixed a problem where exporting page numbers was causing QuarkXPress to crash.

Changes at 6.3/7.3 release

The main new feature at the Xcatalog 7.3 release is full compatibility with QuarkXPress 7.0 (7.01 under Mac OS X–the first universal binary release), including complete Unicode support (which is a major change internally), and universal binary support under Mac OS X (10.4).

The Xcatalog 6.3 release keeps functional (and bug fix) compatibility with 7.3 except in 7.x-specific areas (such as Unicode).

Fixed a problem where exporting long strings (those containing more than 255 characters) to MS Access via ODBC on Windows would result in an “Invalid precision value” error. Such strings are
now sent as SQL_LONGVARCHAR rather than SQL_VARCHAR to work around an overly picky (in our opinion) MS Access ODBC driver.
Fixed a minor memory leak that could occur with each Data Descriptor selection.
The Select Data Descriptor and Get Data Snapshot dialogs now display all validly typed or named text files as selectable. Before, some valid files were being displayed as
unselectable in Mac OS X 10.4.
Xcatalog > Create Data… and Xcatalog > Create Data File… actions now attempt to create files that use the data’s original encoding. (7.x only)
Unless your Unicode encoded data snapshot file begins with a BOM (a special Unicode character which indicates which Unicode encoding a text file uses, but which is otherwise ignored) you need to tell Xcatalog to expect Unicode characters by selecting “Unicode” from the
character set popup in Xcatalog’s Data Snapshot preferences. Once selected, text files lacking a BOM or not encoded as UTF-16 will default to UTF-8.
FileMaker Online data is currently transfered only as MacRoman characters. We hope to support direct Unicode from/to FileMaker Pro 7 and 8 in the near future.
By default, ODBC conversations are performed with characters in the OS-native MacRoman / WinLatin set. To use a different encoding, specify the %”[incoming-encoding[:outgoing-encoding]]” qualifier in your DD’s key field. Supported encodings include: “m” for MacRoman, “w” for WinLatin, “u” for UTF-8 or, lastly, “utf-16” for UTF-16 (which triggers the use of wide characters (SQL_WCHARS) internally and may not work reliably on Mac OS). For example:
- %”u” – specifies UTF-8 for both incoming and outgoing data.
- %”m” – specifies MacRoman for both incoming and outgoing data.
- %”u:m” – specifies UTF-8 in and MacRoman out (which would be appropriate for FileMaker Pro 7)
Fixed a problem where a crash could occur upon Xcatalog > Select Data Descriptor… and Xcatalog > Open Data File… if the dialog’s initial folder contained a file with a name ending with a period. (Mac OS only)
Fixed a problem where pictures weren’t always being removed when updating picture boxes with empty or invalid pathnames.
Worked around a problem caused by non-conforming XTensions (like PSD Import) where loading a picture was causing Xcatalog to emit incorrect text in its error messages.
Failure to find the previously loaded DD on startup no longer issues logon dialogs if the DD was on a volume that is no longer mounted. (Mac OS only)
Fixed a problem where updating a picture using a relative path of the form “:a folder:a picture file with a very long name.tif” or “:a picture file with a very long name.tif” would result in a file not
found error even if the picture file actually existed. (Mac OS only)
When updating tagged text, reverting to the paragraph style’s character attributes via <@$p> no longer applies a random font/size/color if the paragraph style references a character style for its character attributes.
When updating tagged text, the character resulting from a numeric escape tag is now governed by the <e> tag and mapped into the current platform’s character set. So a Mac-based numeric escape tag like <\#170> now properly generates the TM symbol on Windows rather than a superscripted “a” character.
When extracting Xtags text, a missing font’s name is now included in the <f"..."> tag rather than being substituted with a question mark like <f"?">.
When extracting Xtags text, certain character attributes applied to text within a “none”-style paragraph with no character style applied are no longer dropped. For example, the <cW> tag is now properly emitted for a span of white text within a “none”-style paragraph with no character style applied.
For data, DD, and price styles files, Xcatalog now recognizes Unix/Mac OS X-style line-ends (a single line-feed, character 10) in addition to DOS and Mac OS (Classic) line-ends.
Prices formatted with a thousands separator (the “T” flag) no longer show up with garbage appended after the price. (Windows only)
Fixed a problem where updating long documents containing price styled fields could crash.
The tagger palette now honors price style associations set in the DD file using the “P” qualifier. Previously, the price style would revert back to “None” when such a field was selected.
The tagger palette’s price style popup no longer retains the previous data descriptor’s first price style when a new data descriptor is selected.
A problem in QuarkXPress 6 where the document’s home folder is “forgotten” when the document was opened on a network volume has been worked around (the problem arises because XPress now copies a remote documents to a local version before working on it). Now Xcatalog will
find pictures relative to the document’s folder even when that document is on a network volume. (Documents on a local volume were never a problem.)