Release: Xtags 4/5/6.1.3 for InDesign CS2/CS3/CS4
May 25, 2010 by cpr
This release of Xtags for InDesign adds standard white and black color names for XPress cross-compatibility, and adds more intelligent handling of non-style-applying @ characters in text (e.g., as used for email addresses).
(This release includes all release notes back to the beginning of the CS2/CS3/CS4 series.)
These release bundles include the InFlow companion plug-in, which must be installed for Xtags to work.
(See changes at Xtags 6/22.214.171.124 release, as these versions overlap.)
Changes at Xtags for InDesign 4/5/126.96.36.199 release
- Added support for QuarkXPress’s “white” and “black” standard color names (in English, German and French). For example,
<c"white">will no longer result in an “undefined color” error. (We added this for better portability between XPress and InDesign workflows.)
At-signs (@) appearing in, for example, e-mail addresses, within the body of a paragraph are no longer treated specially, so long as there is an end-of-paragraph or some other tag-like character(s) (less-than (<), greather-than (>), and at-sign (@)) between it and the next (if any) colon (:). Meaning, so long as an @ doesn’t look like a paragraph style application, it will not be treated as one. For example, in
@pstyle1:Some text and email@example.com: Some more text.
Xtags will attempt to apply the paragraph style
mnop.xyz, because the
@mnop.xyz:looks like a paragraph style application, and there are no other special characters intervening. However, in
@pstyle1:Some text and firstname.lastname@example.org. Some more text.
pstyle1will be applied since the use of the @ no longer looks like a style application (there’s no colon between it and the end of the paragraph). Previously, all of the text from the @ to the end of the paragraph would be lost. If a colon must follow the e-mail address, as in the first example above, then you’ll need to continue escaping the at-sign, as in:
@pstyle1:Some text and abc<\@>mnop.xyz: Some more text.
unless there are other intervening characters that make it clear this is not a style application, as in:
@pstyle1:Some text and email@example.com. Another paragraph here.<\c>@pstyle2:In a new column now.
Changes at Xtags for InDesign 4/5/188.8.131.52 release
- Fixed a problem where text anchors imported via
&it(interpret InDesign Tags) were being renamed, such that they weren’t being found by their referring hyperlinks and cross-references.
Changes at Xtags for InDesign 4/5/184.108.40.206 release
Added a boolean
returned error summaryparameter to the
get text with Xtagsscripting method to provide an error reporting alternative to raising an error (which, in CS4, has the unfortunate side-effect of undoing the import). If
returned error summaryis specified and if one or more inline Xtags errors were generated, then the
get text with Xtagsmethod will return a non-empty string containing a summary of the errors. For example, a classic
get textwill allow an error to be raised and, in CS4, cause the import to be undone.
try get text with Xtags from myFile with error reporting on error errMsg display dialog errMsg end try
In CS4, if you’d like to be able to see any inline errors generated by the import, you’ll need to add the
returned error summaryoption.
try set errSummary to get text with Xtags from myFile ¬ with error reporting and returned error summary if (errSummary is not "") -- errSummary will be a non-empty string only if any -- inline errors were generated. display dialog errSummary end if on error errMsg -- Failures, still reported by a raised error, are captured here. display dialog "The Xtags import failed: " & errMsg end try
Changes at Xtags for InDesign 4/5/220.127.116.11 release
- Added an
fs"..."tag to support named font styles in InDesign character styles. A font style may now be specified without needing to also specify the family. For example,
<fs"Bold">bold<fs$>could now be used in place of
<f"Times-Bold">bold<f$>, if a
<f"Times">tag were already in effect.
- Added an
ff"..."tag to support font families in InDesign character styles. A font family may now be specified without need to also specify the style. For example,
<ff"Times New Roman">same style, new family<ff$>could now be used in place of
<f"Times New Roman Bold">same style, new family<f$>if a
<B>tag were already in effect, with any family.
- Fixed the few remaining bold/italic toggling problems with a font handling rewrite which avoids depending on InDesign’s own erratic toggling mechanism (shift-cmd-B/I). The
Itags should now work properly with all fonts, even when the font or desired style is missing. Do let us know if you find a typeface which does not play nicely with the
Itags! Normally, a
<B>(bold toggle) tag will only toggle between a family’s Regular and Bold styles. However, in some situations,
<B>will also work on a Book style (if the family reports that Book is its “plain” style), and
<B>will toggle to a weight other than Bold (Heavy, for example, if there’s no other “bold” candidate like Semibold, ExtraHeavy, etc.) and, if used after an
Icould produce a totally correct but invalid style name (the tags
<f"Times-Bold"><B>will properly generate the invalid style name “Bold Bold”, just as they would in QuarkXPress).
- Changed the export of text with applied character styles so that, when possible, style runs are now terminated with
<@$p>(return to the paragraph’s style, which is always None in InDesign) rather than
<@>(apply None style). This makes the text more “portable” between InDesign and XPress.
- Improved the export of text containing a missing font.
- Fixed a problem with the
f$tag where it wasn’t turning off the applied font’s style. For example,
<f"Times-Bold">a<f$>bwas leaving Bold set on
- Fixed a problem where importing or pasting tagged text into the middle of a paragraph was causing the loss of character formatting on text between the paragraph’s start and the insertion point.
Changes at Xtags for InDesign 4/5/18.104.22.168 release
- Removed a limitation (originating from QuarkXPress) that prevented rules from dipping more than half their weight below the baseline.
Changes at Xtags for InDesign 4/5/22.214.171.124 release
- Pictures may now be scaled down to 0.1%.
- Fixed a problem where overwriting an existing file while saving tagged text was sometimes
leaving extra characters after the newly exported tagged text.
- Fixed a problem where outputting a group could generate an
&otag with incorrect coordinates if the group had been moved since it was created.
- Fixed a problem with picture scaling where a size-to-height (
S) height specification could fail, if used in conjunction with a fit-to-width (
F) width specification.
Changes at Xtags for InDesign 4/5/126.96.36.199 release
- Fixed an incompatibility with InData where invoking a translation table from styled text containing XPress Tags was causing Xtags to crash.
Changes at Xtags for InDesign 4/5/188.8.131.52 release
- Fixed a problem in CS4 where text frames sized to their contents using “fit frame to contents” could leave the text frame too large.
- Fixed a problem in CS4 where “place as-anchored” unanchored frames (no x, y coordinates given) were not being placed correctly.
- Shrinking a text frame to fit its contents now properly accounts for non-zero text insets.
Changes at Xtags for InDesign 4/5/184.108.40.206 release
- Fixed a problem where a character style change made directly in front of an
&ittag might not stick to the text resulting from the
- A master page is now applied only if the target page isn’t already based on that master.
Changes at Xtags for InDesign 4/5/220.127.116.11 release
- Fixed a problem where box creation tags being imported to a master spread would fail. Tags imported to a master spread now place any created frames on that master spread.
- Fixed a problem where the
&ittag could produce a spurious paragraph if the InDesign Tags generated no text.
- Fixed a problem where HFS (Mac OS-style) paths containing a Windows/DOS-style separator (a slash or a backslash) were being treated as Windows/DOS paths. The paths
":pic01/05.png"will now import correctly. (Mac OS only)
Changes at Xtags for InDesign 4/5/18.104.22.168 release
- Fixed a problem where a paragraph style sheet application would be ignored, if followed immediately by an
Changes at Xtags for InDesign 4/5/22.214.171.124 release
- Fixed a problem where the content of text and picture frames created with rotation would be oddly squished or distorted.
- Fixed a problem in CS4 where rotated pictures positioned in their frames using “fit to box maintaining aspect ratio” weren’t being sized properly.
- Fixed a problem where rotated pictures positioned in their frames using “fill box maintaining aspect ratio” weren’t being sized properly. Even rotated pictures are now sized to completely fill their frames.
Changes at Xtags for InDesign 4/5/126.96.36.199 release
- When importing tags from a file, both the document’s folder and the source file’s folder will be searched when looking for pictures specified using a relative path, in that order. (What’s new is searching in the source file’s folder.)
- Fixed a problem with the application of master pages where, in some situations, text
would continue to import in the wrong text frame.
- Fixed the export of InCatalog text links such that their closing tag,
&Ce(), is now emitted before any trailing style changes, like
<B><&Cs>foo<&Ce(...)><BI>bar<I>. With the style change outside the link, an update of the text created with these tags no longer causes the loss of the style change.
Changes at Xtags for InDesign 4/5/6.1.2 release
- Added support for InDesign CS4.
- Errors regarding any failure to properly place an unanchored text box are now displayed.