Unified Text Layout Engine for FOSS Systems -Paper
1 like373 views
The document discusses the need for a unified text layout engine for free and open-source software systems to allow for consistent rendering of complex script languages across different applications and toolkits. It proposes adopting the International Components for Unicode (ICU) architecture as the basis for the unified engine. It also outlines IndiX's perspective, agreeing with using ICU but suggesting some enhancements, such as treating character sequences as indivisible sub-clusters and separating page layout from font-level OpenType layout operations.
Unified Text Layout Engine for FOSS Systems -Paper
- 1. Unified Text Layout Engine For FLOSS Systems Vinod Kumar &Siji Sunny, CDAC Mumbai At present, the Textual User Interface programs of FLOSSbased desktop systems often use different text layout engines: many GTKbased programs, including The Gimp and Inkscape, use Pango as the text layout engine; Open†Office uses IBM's ICU text layout classes; KDE programs use Qt's layout engine; while many applications use homegrown text layout engines: KOffice uses Qt's native shaping but has its own code for paragraph layout; and Scribus currently has its own code for the whole layout process but the development team is thinking about using a forked version of Qt's shaper. Because of differences in the layout engines operating “behind the scenes†, different software can exhibit differing levels of support for complex text layout (CTL) scripts like Arabic or Kannada. A unified text layout engine,independent of any specific toolkit,would allow developers to focus first on rendering text in all modern human scripts correctly and secondly , on doing so efficiently. ( almost verbatim copy from http://live.gnome.org/UnifiedTextLayoutEngine ) The idea of Unified Text Layout Engine For FLOSS was discussed at Open Discussion held at Gnome Live 2006 Boston™. The topic generated a lot of interest in FLOSS developers, but the outcome is not available as a recommendation. So as a continuation to that meet, we can carry forward the standardization of Unified Text Layout Engine in this conference and probe towards a constructive outcome. The existing text layout engines differ not only architecturally but also in the nitty gritty of their interfaces. It is impossible to unify the interfaces before a consensus on the architectural framework is reached. Moreover, once the architecture is in place, individual interfaces can be wrapped in Adaptors to present the unified interfaces. One of the observations the discussion at Gnome Live 2006 was: Existing APIs of pango, Qt and probably ICU must be maintained: otherwise it won't be a unified text layout engine, just yet another text layout engine. The Unified Text layout architecture and the adaptors for the existing toolkits appear to be the only way out. Indix Approach IndiX has strong opinions on the architecture and interfaces of a Unified Text Layout engine. IndiX has backed up its architecture with a successful implementation. We would like to articulate and present the IndiX view at a Unified Text Layout Engine in FOSS.IN 2007, Mozilla project day. We hope that the interaction and contribution will result in an Architecture for the Unified Text Layout Engine and later for its interfaces. Here we outline some of the architectural and interface issues where IndiX subscribes to or differs from others. • IndiX is of the opinion that the architecture of ICU is the best of the lot, conforming to the Unicode text processing principles. ICU is not an also ran. Unicode and ICU generalize the One code One Glyph of Latin to Many Codes Many Glyphs style of complex scripts. Moreover, ICU realizes the importance of treating Many Codes as a unit in layers where the corresponding Glyphs do not appear. Thus ICU has a specialized Character