Introduction

CHILI publisher supports Backwards Compatibility; this means that newer version of the system will open older versions of content.

Newer versions of the software will however include improvements and new features. These new features did not exist in the previous document and will be added once the document is saved in the newer version.

Document format

A CHILI publisher document is XML-based. The Object Model (the syntax) is documented here.

This XML is markup of the content and the attributes. The markup adds metadata to the content, telling the system to make something look a certain way, where an image can be found in the asset library, etc.

An example (fictitious): “Lorem Ipsum” content, fit in a frame, where the frame has several elements to define the position and size.

<xml>
<frame x="10pt" y="10pt" width="200pt" hight="200pt">
<paragraph typeface="Ubuntu">
Lorem <CharacterStyle color="255,0,128">Ipsum</CharacterStyle>
</paragraph>
</frame>
</xml>

_{Example does NOT reflect actual CHILI publisher XML, example to illustrate the case}

Rendering

The rendering engine of CHILI publish is the logic that interprets the contents and markup in the (XML) document.

Rendering happens

On screen (browser)
On output creation (PDF, image, …)

Text Layout Engine (TLE)

Next to the positioning of images and frames in ouput, we also use the CHILI publish Text Layout Engine. We control the drawing of the characters, spacing between characters, leading between lines, etc. We have control over the fine grains in typography that is rendered on screen and in output.

Backward compatibility of Text Layout

The Text Layout Engine is part of the process of Continuous Improvement.

This means that improvements will have impact on the rendering of text and other elements on the design of your document.

Imagine an improvement in the calculation of spacing of the characters. This change leads to a tiny shift in movement, that better resembles the intent of the Font Designer. However, this change leads up to the hyphenation of word in a text frame (if you chose to hyphenate the content) since the frame was set to exactly match the space for the characters.

A change of 1 pixel / 1 pt / 1 µm / … leads to the frame being too small, a word will be hyphenated. Depending on the situation, this could also mean that the text add a line in that frame.

In the example above, we simulate the concept, by reducing the frame by a tiny amount to show the possible impact.

Improvements in the rendering engine might not happen with every version. Best practice is to check with new versions, how your document reacts. If you added warnings to your document e.g. on text overflow, this will also help to warn you on potential changes.

Major changes will be documented also in the Release Notes.

Output

If your output is digital, then tiny changes will almost have no (visible) effect. A new version of the rendered version will “look” similar to the eye, but might be off by 1 pixel; not visible for the human eye.

If your output relies on the use of film, plates or any other intermediate medium to create the output, you will need to check for (tiny) differences with an update. It’s then up to you to decide whether a new output needs to be generated.

While we guarantee the exact placement of the text frame, we cannot guarantee the exact same position of each glyph within the frame.

Summary

Due to the nature of continuous improvement, tiny changes might / will appear in the rendering engine.

If an improvement on the TLE is done, this will be included in the releasenotes. That is your cue to check the output.