mozdev.org

sila    

resources: Home Mailing List Installation Source Code Bugs Screenshots
Project SILA Technical Design Document

Project SILA Technical Design Document

Author: Frank Yung-Fong Tang <ytang0648@aol.com>
Version: 0.01

Purpose of This Document

This document defines the goal, requirements, and dependency of project SILA. This document also discusses the high level architect of project SILA after a high level overview of the Mozilla text processing and display subsystem.

Project Goal

To enable minority language communities to publish on the Internet by making Mozilla Internet application suite (Browser, Email , Newsgroups, HTML Composer, Address Book, IRC Chat program) integrated with silgraphite technology to display complex writing system correctly.

Project Requirements

  1. Platform Requirements: Microsoft Windows 2000 and Microsoft Window XP
  2. Functional Requirements:
    1. Complex writing system display in
      1. Browser,
      2. HTML Editor (Composer),
      3. Email,
      4. Newsgroups,
      5. Address Book, and
      6. IRC Chat
    2. Text display
    3. Only focus on supporting what silgraphite support
    4. Left-to-right writing systems (Note: Mozilla all ready support some right-to-left writing systems such as Hebrew and Arabic)
  3. Language Requirements: The following language data will be used to test SILA
    1. Burmese
    2. Burkinafaso (Latin script)

Due to the limit of project time, we decide the following is OUT OF THE SCOPE of this project. We may work on the following issues in the future releases
  1. Different Operating Systems other than Microsoft Windows 2000 and XP.
  2. Right-to-left writing systems (Note: Mozilla already support Hebrew & Arabic without silgraphite.)
  3. Text keyboard input
  4. Text selection and cursor movement

Project Dependency

This project is heavily depending on the following software technologies still under development:
  1. Mozilla- the open source Internet application suite project (www.mozilla.org).
  2. silgraphite- the open source complex writing system rendering engine (silgraphite.sil.org)
In additional, this project also depend on the following stable software technologies
  1. COM- the component technology on Microsoft Windows: We will use COM to integrate the two technologies above together

Design

This session discuss how we architect project SILA. Since Mozilla is the foundation of this project, we need to first review the Mozilla components which handle text processing and display. We will also briefly review the key features provided by silgraphite. Finally, we will outline the high level architect of SILA.

Mozilla Text Processing Subsystems Overview

The following components in Mozilla process text information:
  1.  The network library, Necko, receive bytes streams in TCP/IP pockets, block by block.
  2. Necko pass blocks of byte stream to the HTML parser, XML parser, JavaScript interpreter, or CSS parser depend on the MIME type
  3. The HTML parser, XML parser, JavaScript interpreter or CSS parser
    1. find out the text encoding (charset) of the incoming data from meta data,  attached label or other sources,
    2. call appropriate Unicode converter to convert the bytes stream into Unicode text data stream,
    3. parse the Unicode text data stream into tokens according to the (markup or programming) language lexicon, and then
    4. The HTML content sink build up content model according to the (markup or programming) language syntax.
  4. The view system invokes the layout subsystem reflow process to build up the frame model:
    1. read text data from the content model,
    2. call the “line breaker” to find out logical (purely depend on the Unicode text data) line break opportunity,
    3. read style information from the style model,
    4. call the platform specific GFX (Graphics) subsystem to measure the width of each line break opportunity to decide where to break the line, the size of each frame, and the position of each frame,
    5. call the platform specific GFX (Graphics) subsystem to display the text according to the associate style and giving position.
  5. The Window specific GFX (Graphics) subsystem is a very powerful and complex subsystem. Basically, the interface provide 3 main features for the purpose of text display:
    1. Create a virtual font by information from CSS or user preferences
    2. Measure the size of a Unicode string by giving a virtual font
    3. Render the Unicode string by giving a virtual font and screen coordinate

The Design, Features and Architect of Mozilla Text Display Subsystems

Since the goal of SILA project is to render the text of complex writing system on Microsoft Windows, most of (if not all) the integration points are reside the Windows specific GFX (Graphics) subsystem. We review the design of this component in details in this session. The ultimate text display code is inside the Windows specific GFX subsystem. We will only discuss the part which related to virtual font, text measuring and text rendering.

Each virtual font in the Mozilla GFX subsystem is a defined order to accessing (if necessary) all the installed font to measure or render a giving Unicode string. The order is depend on:
  1. The given CSS font-family property, or HTML <font> face attribute of that node or it’s inherited value
  2. The per-language group font preference value, selecting by the source charset (text encoding) of the document, and the CSS generic font-family name
  3. Other font preference value in the same language group
  4. Font preference value of other language group
  5. The rest of the installed font
When the subsystem performs Unicode text measurement and rendering, it will first use the highest priority font to render all the text. It exams the ‘CMAP’ of each font to decide which Unicode characters could be measure/render by the first font. If the ‘CMAP’ of such font do not have a valid slot for such Unicode code point, then the GFX will load the next font in the order to measure/render that particular characters which cannot be render by first font. GFX repeats this process through the list until all the Unicode code point could be render or it exams every single installed fonts.

In summary, the real font(s) used by the Mozilla for a given text node is mainly control by the following three factors:
  1. The font-family property in CSS
  2. The Unicode code points
  3. The  ‘CMAP’ table of the font

Key Features provided by silgraphite

silgraphite help Window base application to render text in complex writing systems by reading data from graphite enabled TTF fonts.

silgraphite read the additional Graphics specific TrueType table and analysis the given Unicode text to perform text measuring and rendering of complex writing system.  Please see the silgraphite documentation for details. We will not discuss them in this session.

In order to work with silgraphite, the calling software needs to implement two helper classes. The first one implements the IGrTextSrc interface to maintain the text data. The second class implements the IGrGraphics interface to read TrueType font table and call operating system to measure/render the “glyphs” (not the “characters”).

The calling software should create a GrEngine for a specific font. It should associate an IGrGraphics to the GrEngine when initialize the GrEngine. It then passed Unicode string to the FindBreakPoint method of the GrEngine object to create one ore more IGrSegment. Then it calls the measurement and rendering method of the IGrSegment. These methods will call the methods implemented in the IGrGraphics to interact with the operating system.

High Level Architect of SILA

In order to integrate the silgraphite into Mozilla, we need to address the following architect issues first:
WHEN to call silgraphite?
To answer the first question, we first need to look into the graphite enabled font. A graphite enable font is really just a standard TrueType font (possible also OpenType or AAT) with additional Graphite specific table. The ‘CMAP’ of the graphite enable font follow the same rule as standard TrueType font. Therefore, we can share the same ‘CMAP’ exams code with other TrueType fonts. Mozilla should call the silgraphite only when it try to use the graphite enable font to measure or render Unicode text which covered by it.

Since every graphite enable font includes a ‘Silf’ table, we can distinguish a graphite enable font by check the existence of this table in the TrueType font directory. If a font includes such TrueType table, then we will call silgraphite to perform the text measurement or rendering.
HOW to call silgraphite
To reduce the maintain cost and reduce the need to use most of the code across different version of Mozilla, we define a generic COM based interface to separate the silgraphite specific code from the Mozilla specific code. The part which implements the silgraphite specific part will be implement in a COM based DLL, currently named mg2.dll (Mozilla Graphite Together). This DLL include a static linked silgraphite library of a stable version. It hides all the details of how to work with the silgraphite APIs. The Mozilla code will be change to call such generic COM interface.  And the Mozilla patch implement all the details of how to work under the Mozilla GFX virtual font look up and text measurement/rendering subsystem.

How to Generate Contents Work Nicely with SILA

To make contents (HTML) work nicely with SILA, we need to
  1. Clearly specify the font name in the CSS font-family property, this is essential to work with Latin base graphite enable fonts or text in Unicode block which non graphite enable font may cover those characters in the ‘CMAP’.
  2. Use correct and appropriate Unicode code points. Either use UTF-8 to encode the document, or use text encoding neutral escaping mechanism in each languages to specify the Unicode code point.  
Please refer the CSS1, CSS2 and HTML 4.01 specification from w3c.org site for details.

Project Risks & Solution

  1. Stability of Mozilla: Since this project heavily depends on Mozilla, the status of the Mozilla project is the biggest risk of this project. To address this, we decide the following:
    1. Base the Mozilla 1.0 branch (which Netscape 7, Netscape 7.01, Netscape 7.02 based on) to produce the Alpha build
    2. Base on the Mozilla 1.4 branch (which Netscape 7.1 based on) to produce the Beta 2 build.
  2. Stability of silgraphite: The bugs and stability of silgraphite also greatly impact this project. In order to reduce the risk, we decide to static link the silgraphite library into the mg2.dll. The version of the silgraphite will base on the addressed issues in the silgraphite source, number of changes around the date and trial testing result.

Project Release Plan

Based on the status of the project, we release the binary in the following format:
  1. Patched gkgfxwin.dll + mg.dll in zip file: We release Alpha build by include a modified gkgfxwin.dll based on the same branch of Netscape7.0 (or Mozilla 1.0) and mg2.dll. In order to use it, the user have to first download the Netscape 7.0 (or Mozilla 1.0) separately, download the package to replace the gkgfxwin.dll manually, and call the COM registry program come with Windows to register the mg2.dll.
  2. Mozilla files + mg2.dll + setup.bat in zip file: We release in this way in Beta cycle until we finish the required installer changes. This require the user to download the patched Mozilla in a zip file and run a setup.bat batch program after unzip the zip to install.
  3. Mozilla installer include everything: This is the ideal way to release Project SILA. We should ship Beta 2 in this method. This requires installer changes in addition to the run time GFX, silgraphite integration. The user will use the installer exactly the same way they use the Mozilla installer.


For questions or comments about sila, please send a message to the sila mailing list.
Copyright © 2000-2008. All rights reserved. Terms of Use & Privacy Policy.