Thursday, October 13, 2016

Replacing direct image references with key references in a DITA Project

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr
Let's say that you have a large DITA project and all the image references in your topics are direct, using the @href attribute like this:
<image href="../../images/Iris_sanguinea.jpg" scale="50"/>
and for better scalability and reuse you want to convert these direct references to DITA 1.2 key references:
<image keyref="Iris_sanguinea.jpg" scale="50"/>

Doing something like this manually means making replacements in hundreds of places and in addition manually building a DITA Map which maps the image file name to the image location.

This blog post will try to describe some steps that you can take in order to automate this change in your project:
  1. The first big step is the generation of the DITA Map which maps each image file name (which will be used as a key) to the image location. So the generated DITA Map will look like this:
    <!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">
    <keydef href="Iris_sanguinea.jpg" keys="Iris_sanguinea.jpg"/>
    We will assume that all images are placed in an images folder and we can create an ANT build file which lists all the images in a parameter and then calls an XSLT script to process the list of images further:
    <project basedir="." name="Create Image Keys Definition Map">
        <fileset id="dist.contents" dir="images/" includes="*"/>
        <property name="prop.dist.contents" refid="dist.contents"/>
        <xslt in="createKeyrefsMap.xsl" style="createKeyrefsMap.xsl" out="images/imageKeydefs.ditamap" destdir=".">
            <param name="filesList" expression="${prop.dist.contents}"/>
    The XSLT stylesheet createKeyrefsMap.xsl is responsible for creating the mapping DITA Map:
    <xsl:stylesheet xmlns:xsl=""
        <xsl:param name="filesList"/>
        <xsl:output doctype-public="-//OASIS//DTD DITA Map//EN" doctype-system="map.dtd" indent="yes"/>
        <xsl:template match="/">
                <xsl:call-template name="tokenizeString">
                    <xsl:with-param name="list" select="$filesList"/>
        <xsl:template name="tokenizeString">
            <xsl:param name="list"/>
            <xsl:param name="delimiter" select="';'"/>
                <xsl:when test="contains($list, $delimiter)">
                    <keydef href="{substring-before($list,$delimiter)}" keys="{substring-before($list,$delimiter)}"/>
                    <xsl:call-template name="tokenizeString">
                        <xsl:with-param name="list" select="substring-after($list,$delimiter)"/>
                    <keydef href="{$list}" keys="{$list}"/>

    So after this step you will have a new DITA Map with all image mappings, DITA Map which you can afterwards link in your main project's DITA Map.

  2. We still need to make changes to all DITA topics and replace all image hrefs with keyrefs. Oxygen has support for XML Refactoring actions and you can define custom XSLT scripts which can be applied to modify an entire set of topics. In the OXYGEN_INSTALL_DIR/refactoring folder you can add an XSLT script along with an XML description of the refactoring action. An XSLT script which would replace @href attributes on images with @keyref would look like this:
    <xsl:stylesheet xmlns:xsl=""
        <xsl:function name="f:getKeyref" as="xs:string">
            <xsl:param name="element" as="element()"/>
            <xsl:variable name="imageFile" select="tokenize(translate($element/@href, '\', '/'), '/')[last()]"/>
            <xsl:variable name="key" select="substring-before($imageFile, '.')"/>
            <xsl:value-of select="$key"/>
        <xsl:template match="node() | @*">
                <xsl:apply-templates select="node() | @*"/>
        <xsl:template match="image[@href and not(@keyref)]">
                <xsl:apply-templates select="@* except @href"/>
                <xsl:attribute name="keyref" select="f:getKeyref(.)"></xsl:attribute>
                <xsl:apply-templates select="node()"/>
    In the DITA Maps Manager view you can right click and choose Refactoring->XML Refactoring, then use your custom refactor action to modify all resources.

A set of samples, including the build file, XSLT stylesheets and refactor action XML descriptor can be found here:

Thursday, October 06, 2016

Customizing the DITA Visual Editing Experience

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

The Author visual editing experience in Oxygen is CSS driven. Let's say I have a team of writers using Oxygen and they want to visually edit DITA dl elements in a table-like layout.

All the validation, editing and publishing support Oxygen has for a specific XML vocabulary is defined in a framework configuration.

Instead of copying an entire framework configuration folder (like DITA or Docbook), modify and distribute it you can choose to extend that framework and distribute the extension. In this way, you will benefit of new functionality added to the base framework by newer Oxygen versions and still use your customizations.

The steps below describe how an extension of the DITA framework which removes certain elements from the content completion list can be constructed and shared:
  1. Create somewhere on your disk, in a place where you have full write access a folder structure like: custom_frameworks/dita-extension.
  2. In that folder create a new CSS stylesheet called for example custom.css which will keep your custom CSS styles:
        display:table !important;
        display:table-row !important;
    dt, dd {
        display:table-cell !important;
        border: 1px solid black;
        padding: 2px;
  3. In the Document Type Association / Locations preferences page add in your Additional frameworks directories list the path to your custom_frameworks folder. Then click Apply in the Preferences dialog.
  4. In the Document Type Association Preferences page select the DITA document type configuration and use the Extend button to create an extension for it.
  5. Give a custom name to the extension, for example DITA - Custom and then change its Storage to external, then save it to a path like: path/to/.../custom_frameworks/dita-extension/dita-extension.framework.
  6. Make changes to the framework configuration, in the Author tab click the CSS tab and add a reference to your custom CSS. Do not set a title for the CSS and also do not check the Alternate checkbox as you want your CSS to apply by default.
  7. Click OK to close the dialog and then either OK or Apply to save the preferences changes.

After you perform the steps above you will have in the dita-extension folder a fully functioning framework which can be shared with others:

To check that your framework extension works, you can create a new DITA topic and insert a dl element inside it. It should now be presented in a table-like layout.

In order to know which CSS styles to override for a specific DITA element, you can right click inside that element in the Author visual editing mode and use the Inspect Styles action to see all CSS styles defined for it by default. You can also define alternate CSS styles which are applied manually by the writer by using the Author toolbar Styles drop down menu.

Monday, October 03, 2016

DITA Linking Usage Survey

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

A couple of weeks ago I published a survey which was intended as an overview about DITA Linking habits. A big thank you to everyone who took it. The entire set of survey results, including the answers to open questions can be found here:

Here are some comments I have about the results:
  • Most projects (including ours) seems to approach linking with a mixture between DITA 1.1 href's and DITA 1.2 keyrefs. In my opinion this is caused by a variety of factors among which the most important could be:
    • Technical writers who are not comfortable using indirection (keyrefs)
    • The project was started using href's and not all links have been converted to keyrefs
  • Almost everyvody using related links uses a relationship table to manage them. And that's good.
  • There are projects where related links, chunking and collection-type are not used at all. And I think this is not because the projects are not complex, but because the main output delivery format for those projects is PDF. In a DITA Reuse survey I opened last year there was a clear indication that PDF was still the most used output format:
Although harder to quantify I usually like answers to open questions best because you get a better idea about the difficulties of linking in DITA:
  • The large set of DITA linking possibilities make the standard harder to use. Too many options, harder for writers to understand and use keyrefs or relationship tables. There seems to be a need to have a best practice involving linking and DITA.
  • Various writers have various writing styles, leading to inconsistent projects.
  • Problems with the publishing part, even when the right DITA content is used for links (for example abbreviated-form) the publishing engine might have issues which break the link in the final output.
  • Problems with link management, with having a clear idea of outbound and inbound links and their target. Problems with broken links.
  • The tools used for editing DITA sometimes hide the complexity and even the type of link which gets created. Also the tools should help the writer easier find the target content to link to.

Wednesday, September 21, 2016

Migrating DITA Open Toolkit PDF Customizations

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

We daily encounter clients who have PDF customizations created for older DITA Open Toolkit versions and they want to migrate to a new Oxygen version (which includes a newer DITA Open Toolkit publishing engine distribution).

Most XHTML-based customizations are quite easily accomplished just by using a custom CSS. But as the standard PDF publishing obtained with the DITA Open Toolkit is XSL-FO based, it requires XSLT customizations.

As a general rule, when making a customization of any kind you should keep some kind of notes about what you achieved during the customization and through what means, this will help you migrate your customization to a new DITA Open Toolkit version.

Oxygen 18 comes with two DITA Open Toolkit distributions (1.8.5 and 2.x), you can choose which DITA OT distribution to use in the Preferences->DITA page. DITA OT 2.x is newer and it comes with DITA 1.3 support so you should try to update directly to it.

First of all, if you are happy with the output obtained using your current DITA OT distribution, you can continue using that DITA OT as an external DITA OT, you can copy it from inside the old Oxygen installation to an external location and in Oxygen 18.0 the same Preferences->DITA page allows you to choose an external DITA OT distribution to use:

If you still want to migrate:

No proper implemented customization should modify the base "org.dita.pdf2" plugin contents. The customization folder should be either kept external to the DITA Open Toolkit distribution:

or it should be provided via a PDF customization plugin:

In the DITA Open Toolkit documentation there is also a best practices about PDF customizations:

The main idea is to have all your changes in one place.

While the DITA Open Toolkit evolves, various XSLT templates might change, they might be renamed or removed completely. There is a migration guide here:

Even without reading the guide, you need to determine what XSLT templates are not getting called anymore in your customization (you can add xsl:message's for this) and then try to find in the base PDF plugin the templates which need to be overridden instead.

So this is why having some notes about all aspects that your PDF customization should cover is useful in the long run, you can use the notes to see if all aspects of your customization are still applied with a newer DITA OT and for the aspects which no longer work you can easily locate the places in XSLT where the customization was done.

Tuesday, August 23, 2016

Converting Subject Scheme Map Values to a DITAVAL

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

Let's say you already have a Subject Scheme Map in your project and you use it to control attribute values:

In the Oxygen Colors and Styles Preferences page you can also assign various colors and styles to each profiling attribute (name, value) combination. One option for this is to manually re-add attributes and values in that list. Another option would be to create an XSLT stylesheet to gather all profiling attribute names and values from the Subject Scheme map and create a DITAVAL file. The stylesheet would look like this:

<xsl:stylesheet xmlns:xsl=""
    <xsl:output indent="yes"/>
    <xsl:template match="/">
            <xsl:for-each select="subjectScheme/enumerationdef">
                <!-- For each attribute name -->
                <xsl:if test="subjectdef/@keyref and attributedef/@name">
                    <xsl:variable name="attrName" select="attributedef/@name"/>
                    <xsl:variable name="keyref" select="subjectdef/@keyref"/>
                    <!-- For each key value -->
                    <xsl:for-each select="//*[@keys=$keyref]/*//@keys">
                        <xsl:variable name="attributeValue" select="."/>
                        <prop action="flag" att="{$attrName}" val="{$attributeValue}"/>

After you obtain the DITAVAL, you can import it directly in the Colors and Styles preferences page. If the DITAVAL file has flagging information, that information will be directly used to style each attribute value.

A possibility to enhance this workaround is to specify profiling styles for each attribute value directly in the Subject Scheme map using the <data> element like:
<subjectdef keys="linux">
    <data name="color" value="yellow"/>
in which case the XSLT stylesheet would create the DITAVAL by picking colors directly from the Subject Scheme Map:
<prop action="flag" att="{$attrName}" val="{$attributeValue}">
        <!-- Here you can also set flagging colors depending on the profiling attribute value -->
        <xsl:when test="data[@name='color']">
            <xsl:attribute name="color" select="data/@value"/>
In this way your Subject Scheme Map will keep both the controlled attribute values and various colors and styles which can later be used to create a DITAVAL and either publish with those styles or import the DITAVAL in Oxygen in order to highilight various elements with various colors:

Monday, June 27, 2016

Guided DITA Authoring Solution Overview

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

We've had past blog posts about how Oxygen can be used to impose various editing behaviors for your team. In this blog post, we are going to try to bring all of these solutions together in a comprehensive overview.

Learning to Work with DITA and Oxygen

You can find useful links for learning to edit DITA using Oxygen in this previous blog post:

Migrating to DITA

There are multiple reasons why you would want to migrate from unstructured content to structured:

This older blog post details some possibilities of migrating Word documents to DITA: You also have ways to migrate from XML-based standards (like DocBook or XHTML to DITA) using a set of predefined transformation scenarios.

Implementing Your own Style Guide

Let's say you are a team of technical writers collaborating on a DITA-based project and suppose that you have your own various best practices in regards to which elements to use and when to use them. So, at some point you gather a set of HTML resources that explain how various DITA elements should be used, you store them on an internal server, and you want all your team members to have access to that set of HTML resources directly from Oxygen. This blog post provides more details and useful links to help you get started:

Imposing Controlled Attribute Values

If you want to impose DITA attribute values that need to be set for profiling or general use, this blog post should cover all you need to know about this:

Restricting the Visual Editing Experience

The entire visual editing experience using the Author editing mode in Oxygen is CSS driven. Oxygen has support for defining various CSS layers that can be applied when editing DITA content. For example, if you choose to create a Lightweight DITA topic in Oxygen, it has a special editing layer that allows it to be edited with a combination of buttons, hints, and form controls.

Imposing Business Rules and Structure Restrictions to the DITA Content

In most cases, instead of relying on people to memorize numerous internal documentation style rules, you can convert many of these rules to Schematron and allow the application to automatically signal the content author when a rule is violated. You can also add quick fixes to show authors various ways to rectify the problem. This blog post contains more details about this:

Running Batch Validation Checks on all of Your DITA Content

The Validate and Check For Completeness tool available in the DITA Maps Manager view performs a lot of different consistency checks on all your DITA topics. It can also be used to apply Schematron business rules on all of your topics:

Sharing DITA Editing Customizations with Your Team

Most of the custom editing behaviors, toolbar, and menu buttons that are available when editing DITA content are defined in the DITA framework configuration. A framework configuration's general anatomy is described here:

The framework configuration can be shared with all of your team members. For example, here is a way to restrict team members from using certain DITA elements: Furthermore, here is a way to distribute new DITA file templates to your team:

Sharing Global Application Settings with Your Team

Let's say you want all of your team members to enable the automatic spell checker when writing documentation, or you want all of them to use a custom term dictionary or a custom set of learned words. This older blog post offers some hints about how global Oxygen settings can be distributed to your team members:

Collaboration, Content Management, and Version Tracking

All major Component Management Systems (CMSs) have plugins that can be installed in Oxygen to provide access to the CMS: Even if you lack the funds to buy a commercial CMS, there are still plenty of open source version tracking solutions that allow collaboration for a single DITA project: For example, the Oxygen User's Manual is written in DITA and we use a GitHub private repository to collaborate on it:

Allowing Subject Matter Experts to Review Content

Many technical writers are interested in having their content reviewed by the subject matter experts who are directly involved in building the tools. Oxygen has support for change tracking and adding comments directly in the edited content. Subject matter experts do not necessarily need to have the standalone version of Oxygen installed. The Oxygen Web Author is an online editing and reviewing solution that allows them to add comments and propose changes directly in the DITA content by using any device with a web browser (laptop, tablet, phone):

I hope this overview will help you to implement a complete guided authoring experience using Oxygen. As usual, if you have any questions or suggestions, they are welcome.

Monday, June 20, 2016

Enable Massive Contributions with oXygen XML Web Author and GitHub

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr
Early in 2016, a new product was added to the oXygen XML set of tools - the oXygen XML Web Author. It leverages the power of oXygen XML Author (which basically runs on the server side) and provides access to XML authoring from any modern device that supports a browser capable of rendering HTML5+JavaScript, including desktops and mobile devices like your smart phone or tablet.

The real power of web-based XML authoring can be seen when it is integrated as part of a workflow, simplifying it by reducing a large number of steps to just a few. This is what the GitHub connector provides!

If you have XML content on GitHub, you can then provide a link that will open a file in the oXygen XML Web Author and anyone will be able to review or edit it just by accessing the link and saving (a GitHub account is of course required).

When you save a file, assuming you do not have commit access on that repository, the GitHub connector will automatically:
  • fork the project into your account, if it is not already
  • create a new branch from the edited branch
  • commit your changes on this newly created branch
  • create a pull request from your newly created branch to the originally edited branch
  • switch the editor to your branch so further save operations will just add new commits to your branch, thus updating the pull request with new changes
This is a great simplification of the contribution process, a contributor just follows a link and saves the file, and all the magic to create the pull request happens automatically.

If the XML source is published, then it is possible to include an "Edit this page" link on the published format that will allow immediate access to the editor. An example of such access is provided for the DITA-OT documentation project. The development branch is published at and every page contains an "Edit this page" link at the bottom that gives immediate access to the DITA topic that page is generated from.

For example, the page shows the DITA 1.3 support in DITA-OT and the "Edit this page" link will send you to the DITA_v1-3-support.dita topic. If you edit a file and then save it, a pull request with your changes will be automatically generated. Content contribution cannot be easier than this!

Next, we plan to have the "Edit this page" link available in every page of the oXygen documentation, which is also hosted on GitHub at
Hope you find this useful!

Guided Authoring: Enforcing Editing Rules

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

Webinar - Guided Authoring:
Enforcing Editing Rules

This webinar presented a way of imposing various rules that your content authors need to follow, such as grammar rules, document structure guidelines, business requirements, style preferences, or rules for the generated output. 

When editing documents there are various rules that you want your content authors to follow, such as grammar rules, document structure guidelines, business requirements, style preferences, or rules for the generated output. To enforce these rules, companies often use grammar checking apps, custom schemas or best practice guides.

For content authors, there are usually too many rules to remember them all when writing content. The best approach for this challenge is to signal the user when a rule violation is detected and offer suggestions to help them solve possible rule problems and maintain integrity in their documentation.

A recording of the event, sample files, and slides are available on our website: 

Discover the technology behind the fix proposals for business rules by attending our next webinar: Understanding and Developing Schematron Quick Fixes - Jul 14, 2016

Tuesday, June 14, 2016

DITA-OT Day 2016

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr
Oxygen XML Editor is happy to organize the 3rd edition of the DITA-OT Day event, which will take place this year in Munich, Germany, on November 13:

This is a great chance to meet the main DITA-OT developers, Jarno Elovirta and Robert Anderson, as well as other contributors and users of the most used project in the DITA community!

More, there is no registration fee, it is a free event!
Because lunch and coffee breaks are provided, we need to know how many of you will be there, so registration is required:

The DITA-OT Day shares the same location as DITA Europe, the Hilton Munich City hotel, and it takes place the day just before DITA Europe.  It is also two days after the TCWorld conference, which takes place in Stuttgart, so it is very convenient to attend DITA-OT Day if you also plan to go to DITA Europe or/and TCWorld.

We are working on putting together the agenda for this year and we are collecting proposals for interesting topics. If you want to contribute please submit a proposal as described at:

If you did not attend the DITA-OT Day event before, check out the agenda and recordings of the previous events:

Hope to see many of you at DITA-OT Day 2016!

Wednesday, May 25, 2016

How to Migrate from Word to DITA

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr
The need for migrating Microsoft Office® Word documents to XML formats, and particularly to DITA, is quite a frequently encountered situation. As usual, migration from proprietary formats to XML is never perfect and manual changes need to be made to the converted content. However, the methods below should help you find the best approach for your particular case:

 Method 1
  1. Open the Word document in MS Office, select all the content, and copy it.
  2. Open Oxygen and create a new DITA topic in the Author visual editing mode. 
  3. Paste the selected content. Oxygen's smart paste functionality will attempt to convert the content to DITA.
Method 2
  1. Save your MS Office Word document as HTML.
  2. Once you obtain that HTML, you have two possibilities:
    • In Oxygen, Select File->Import->HTML File to import the HTML as XHTML. Then open the XHTML in Oxygen and in the "Transformation Scenarios" view there should be four pre-configured transformation scenarios to convert XHTML to DITA topics, tasks, references, or concepts.
    • Open the HTML file in any Web browser, select all of its content, and copy it. Then open Oxygen, create a new DITA topic in the Author visual editing mode, and paste the selected content. Oxygen's smart paste functionality will attempt to convert the HTML to DITA.
Method 3
  1. Open the Word document in the free Libre Office application and save it as DocBook
  2. Open the DocBook document in Oxygen.
  3. Run the predefined transformation scenario called DocBook to DITA.
Method 4
  1. If the Word document is in the new DOCX format you can open it in Oxygen's Archive Browser view and then open the document.xml file contained in the archive.
  2. Run the predefined transformation scenario called DOCX DITA. This ANT scenario runs the following build file: OXYGEN_INSTALL_DIR/frameworks/dita/DITA-OT/plugins/net.sourceforge.dita4publishers.word2dita/build-word2dita.xml over the DOCX archive and should produce a DITA project that contains a DITA map and multiple topics. 
  3. You may need to do some reconfiguring to map DOCX styles to DITA content. 
Note: This method may also be helpful if you want to run it automatically with scripts, since it is based on the DITA OT and DITA For Publishers plugins.

Monday, May 16, 2016

Upcoming DITA Webinars

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr
In the next few months we will host a series of DITA-related webinars that will cover almost every aspect of working with DITA in oXygen XML Editor. The first 3 webinars are scheduled as follows:
  1. Getting started with DITA using oXygen XML Editor
    Thu, May 26, 2016 8:00 AM - 9:00 AM PDT
    This webinar will focus on introductory concepts of working with DITA documents in oXygen XML Editor, covering everything from creating DITA maps and topics from scratch to basic publishing using out-of-the-box transformation scenarios. You will also learn how to edit simple topics, create cross references, insert images and tables, and how to benefit from intelligent features such as smart paste or validate and check for completeness.
    You can register to attend at
  2. DITA reuse and filtering
    Thu, Jun 30, 2016 8:00 AM - 9:00 AM PDT
    This webinar will focus on advanced features that justify your return on investment from using DITA. REUSE is the key word and it can be implemented either directly through content references or indirectly through profiling/conditional content.
    You can register to attend at
  3. DITA publishing with oXygen XML Editor
    Jul 28, 2016 8:00 AM - 9:00 AM PDT
    In this webinar, we will explore DITA publishing options available in oXygen XML Editor to produce and customize various output formats such as WebHelp, HTML, PDF, or EPUB.
    You can register to attend at
After these 3, we plan to host 4 more webinars that will cover:
  • The support for the new DITA 1.3 standard in oXygen XML Editor.
  • How you can use oXygen XML Web Author to enhance collaboration between contributors and reviewers.
  • A detailed look into how you can maintain the integrity of your DITA maps and topics by using the validate and check for completeness feature, as well as imposing various editing rules.
  • How we create the oXygen User Guide, set up our workflow, enforce project-specific rules, and publish our documentation.

If you want us to cover other DITA-related topics in these webinars, please use the Comments section to let us know.
See you soon!

Friday, May 13, 2016

Collaboration and Document Review in Oxygen XML Editor 18

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

Collaboration and Document Review in Oxygen XML Editor 18

The reviewing process involves a continuous interaction between authors, reviewers, and subject matter experts.
The visual Author mode now allows you to collaborate more easily and effectively with others through comment threads by providing a new reply to comment action and allowing you to mark comments as being resolved.

Reply to comments

You can collaborate with other members of your team more easily, taking advantage of the improved annotation support. You can now reply to comments added by others and you can also start new comment threads. Everyone that has access to the project can see the comment threads and join the discussion at any time.

Mark as done

The Mark as done option allows you to mark a discussion thread as being completed. This is useful for marking comments that have been addressed, leaving only those that still need some attention.

Watch the following video to see more about Collaboration and Document Review in oXygen XML Editor 18:

Friday, May 06, 2016

XML Three Way Diff in Oxygen XML Editor 18

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

The new XML-aware three-way file comparison feature helps you solve conflicts and merge changes between multiple modifications of the same file. It is especially helpful for teams that have multiple authors working concurrently on the same documents.

Three-Way File Comparison Support
A three-way file comparison feature was added to the file comparison tool to help you solve conflicts and merge changes between multiple modifications.
 It is especially helpful for teams who have multiple authors editing and committing the same documents. It provides a comparison between a local change, a remote change, and the base (ancestor) revision.

Multiple Algorithms for Three-Way Comparisons
You can use Lines, XML Fast, and XML Accurate algorithms for the three-way comparison feature in the file comparison tool and in the Compare view in Syncro SVN Client.
  • Lines - Computes the differences at line level, meaning that it compares the files looking for identical lines of text.
  • XML Fast - Works well on large files or fragments, but it is less precise than XML Accurate.
  • XML Accurate - More precise than XML Fast, at the expense of speed and memory. It compares two XML files or fragments looking for identical XML nodes.

Integration with version system
The Files Comparison tool can be integrated with file versioning systems in order to visualize changes in a side-by-side manner ans solve conflicts.
Second-Level Comparison
The File Comparison tool now automatically performs a second level comparison for the Lines, XML Fast, and XML Accurate algorithms. After the first comparison is finished, the second level comparisons are processed on text nodes using a word level comparison, meaning that it looks for identical words. This second level comparison makes it easier to spot precise differences and you can merge or reject the precise modifications.

Ignore Nodes by XPath Option
A new option was added on the toolbar of the File Comparison tool and in the Compare view in the Syncro SVN Client. You can enter an XPath 2.0 expression to ignore certain nodes when comparing using the XML Fast or XML Accurate algorithms.

This demonstration will show you how the oXygen three-way comparison feature works and how you can use it with file versioning systems.

Wednesday, May 04, 2016

What's new in oXygen 18.0 - Webhelp Responsive System

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

In oXygen 18.0 we released a new HTML5-based online help publishing system called WebHelp Responsive. It has the ability to adapt to any device and screen size to provide an optimal viewing and interaction experience. Nearly all aspects of its layout can be customized and it also includes a variant that allows online users to provide feedback in your documentation.

A short video demonstration covering the basic functionality and customization options is available here:

As an example, our Oxygen 18.0 user's manual is published from DITA using the new WebHelp Responsive system. The DITA 1.3 specification available on our web site was also published using this modern WebHelp system.

For now you can choose between nine beautiful skins for the tiled display:

and nine skins for the tree display:

I hope you'll all enjoy it and we are looking forward to any feedback or improvement suggestions you may have for it.