Documentation Center

Client Tools changes

Client Tools improvements for this version are explained.

General

All Client Tools benefit from the write and read performance improvements that were made in web services API 2.5.

New Installers

  • All .msi files (and assemblies) are now signed by our legal entity certificate "SDL PLC". This replaces the earlier signing by "SDL Trisoft" or even before that the yellow User Account Control (UAC) message indicating that "The publisher is unknown".
  • Updated preview components (GeckoFX/XULRunner) fixes AccessViolation (0xC000005) crashes related to Windows 7/8 with enabled Pen and Touch hardware devices/drivers. [SRQ-3008|SRQ-3809]
  • The Print the preview (Ctrl-P) button was disabled before and is now enabled again in all client tools preview windows. [TS-9513|TS-9606|TS-9505]

File 'Synchronize' Performance

After initial set up of an account in a client tool, the Synchronize is triggered which will receive the necessary metadata configuration, DTDs, catalog, preview stylesheets, etc. from the single-sourced configuration area on the web/app server. Furthermore at client tools startup time this action is triggered to make sure your configuration is up-to-date. The files will be transferred with HTTP compression provided by Microsoft Internet Information Services (IIS), and in parallel which reduces the waiting time. [TS-9047]

More throughput by group retrieval per 1000 objects

The web service data compression - introduced in 10.0.3 - allows for transfer of more data through one web service call without actually transferring more bytes. We raised the default page size from 300 which used to be visible by status messages like "Retrieving objects (300 of 24474)..." to 1000 resulting in "Retrieving objects (1000 of 24474)..." which essentially means that less web service calls are made to load list views. The configuration option @defaultPageSize restriction in Trisoft.PublicationManager.Host.exe.config of maximum 999 has been removed. [TS-9090|TS-6877]

Set Title plugin only triggered on editor templates

When a user manually creates a new object based on editor templates, the SETTITLE plugin inserts the FTITLE value in the <title> element. This is normal behavior. However, the same would occur when importing content with BatchImport or Content Importer. This is unwanted behavior, since it would overwrite a longer and usually correct title with a shorter file name acquired from the metadata. The SETTITLE plugin configuration modification addresses this issue.

If you want the plugin to make a distinction, we suggest you adapt your editor templates so they hold a <?ish-replace-title?>, which will trigger the plugin to override your document title. A title will not be forced for other new incoming objects.

See documentation "Prevent automatic document title overwriting during import".

Preview does dynamic link text resolving for <xref>, <link> and <topicref>

Starting from 11.0.0 the Insert dialog no longer filled in the Text to Display field, leaving it empty by default as suggested by the OASIS DITA standard in order to allow dynamic resolving afterwards. This results in, for example, an <xref> element without text body. It is now up to the XML editor to do just-in-time resolving of the title of the <xref>. The same goes for Publication Manager, which now shows the <xref> with a gray background (similar to @conref) to indicate that it is resolved text and not part of the actual XML document.

The behavior of JustSystems XMetaL 9 and 10 is now fine-tuned and usability changes on our Authoring Bridge implementation (before, when inserting an <xref> or <link>, the dynamic text resolving of XMetaL wasn't triggered and you had to do a manual Edit > Refresh all references (F11)). Our common efforts are packaged in this release. [TS-9780|TS-9779|TS-9784|TS-9790|SRQ-3272]

If the XML editor version behavior is insufficient for you, you can use an extra configuration option that we've added. This option will let you roll back to 10.0.x and earlier data behavior. The current behavior is that the Text to display field is no longer initialized with the logical object title (FTITLE), therefore our current templatespecification.xml configuration will assign the empty Text to display field value to variable (selecteditem:text). This results in an empty <xref> or <topicref> navtitle entry. Note that a user can still provide a value in the UI that will be passed to the variable for usage in the inserted XML element.

Two new variables are introduced for use in templatespecification.xml next to selecteditem:text [TS-9772|SRQ-3272|SRQ-3255|SRQ-3264]:
selecteditem:textortitle
When Text to display is empty the link text will be filled with the logical title (FTITLE) of the referenced object.
selecteditem:textordefault
When Text to display is empty the link text will be filled with the ./title of the referenced element, if the element has a title. Similar on how our client tools previews resolve it as introduced in the 11.0.0 release.

Verified Acrolinx on top of AuthoringBridge for XMetaL and oXygen

We verified that the JustSystems XMetaL 10 and 10J integrations with Content Manager Authoring Bridge work together with Acrolinx. The XMetaL server-side files were enriched with statements needed by Acrolinx in the DTD-related macro files for XMetaL 10 and 10J. These files are synchronized from the server. If Acrolinx is not installed on the client, these statements will just be ignored by XMetaL. We used the Acrolinx Plug-in for XMetaL 4.2.0 build 1153 (client_XMetaLV4.2_B1153.msi) to verify the behavior.
We verified that the <oXygen/> XML Author/Editor 17.1 integrations with Content Manager Authoring Bridge work together with Acrolinx. No server-side files changes are required here. We used the Acrolinx support for <oXygen/> 14.1+ 3.4.0 build 4179 to verify the behavior.