TySE aims to handle international script well. This requires TySE to react to the challenges of bidrectional typsetting. The foundation of this is to implement the Unicode Standard’s Annex UAX#9, the Unicode Bidirectional Algorithm.
Unicode Bidirectional Algorithm From the Unicode Annex document:
This annex describes specifications for the positioning of characters in text containing characters flowing from right to left, such as Arabic or Hebrew.
The Unicode Standard prescribes a memory representation order known as logical order.
HTMLbook is the core DOM of our documents. Background for this decision can be found in this Conference Paper and an O’Reilly Radar Page.
From the O’Reilly page:
“In this paper, I argue that HTML5 offers unique advantages to authors and publishers in comparison to both traditional word processing and desktop publishing tools like Microsoft Word and Adobe InDesign, as well as other markup vocabularies like DocBook and AsciiDoc. I also consider the drawbacks currently inherent in the HTML5 standard with respect to representing long-form, structured text content, and the challenges O’Reilly has faced in adopting the standard as the new source format for its toolchain.
One of TySE’s design goals is to have concurrency built in from the ground up. One focues area of improving performace through concurrency is the data flow starting with the internal document model all the way to a printable document.
The document creation flow is of course central to the TySE application. At its core lives an engine not unlike a web browser: a formatting engine based on HTML and CSS.
TySE is a complex piece of software. However, even the smartest designer of any software is unable to predict every context the software will be used in. The challenge to software engineers is to prepare their systems for the unexpected.
Dealing with the Unexpected There are a couple of strategies to deal with this challenge. One of them is to make your system programmable by others. TySE follows this concept by allowing you to script it (in Moonscript and Lua).
But that’s not the only trade-off to consider when dealing with layout and design. HTMLbook is all about the semantics of a book’s content: authors and publishers define elements like chapters, figures, table of content etc. HTMLbook does not define how these elements are supposed to be displayed, i.e. does not say anything about layout or design. This is left to other technologies, one of which may be CSS. Let’s leave the topic of styling aside for now and focus on layout.