Dai Banna SIL Fonts   (version 2.1)  6 June 2008
Read Me
_______________________________________________________________

These files constitute the latest Unicode release of the Dai Banna SIL Fonts.  The package includes a set of eight font files for displaying texts in the New Tai Lue script.

After decompressing the package archive, follow the instructions in the User Guide (DaiBannaSIL.pdf) to install the fonts.  You will need Adobe Reader version 4 or later to view the documentation.  The reader is available at no cost at:
	http://www.adobe.com/products/acrobat/readstep2.html

You may (and are encouraged to) freely share these fonts and utilities with your friends and co-workers, but must comply with the terms set forth in the SIL Open Font License (OFL.txt).


KNOWN FONT ISSUES

< No smart line-breaking for numbers and CCV words >
The lack of space in New Tai Lue text makes standard applications unable to avoid undesirable intraword line-breaking.  With Graphite-enabled applications, smart line-breaking behaviours built into the Dai Banna SIL font package can be realised.  However, only basic word-break opportunities are accounted for in the current release.  Breaking behaviours for numbers and special CCV structures have yet to be added.

< Latin glyphs deformed at certain sizes on screen >
When viewed on screen, the tilde character (~) flattens to a straight line at 10 points regular or italic as well as at 7 points or below regardless of style.  Similarly, the equal sign (=) bleeds into a thick line at a size of 8 points or below.  This is likely a font hinting issue which we hope will be fixed by the next revision.  All characters print well even at small sizes notwithstanding.

KNOWN APPLICATION ISSUES

< Imbalanced character spacing on screen >
There are character combinations that will result in letters either running into each other or standing too far apart on screen.  This is more noticeable at a font size of 10 points or smaller.  The fonts do have kerning information that will respace these letters correctly.  While there is possible room for kerning improvement, many programs, however, do not support kerning at all.  In those cases you can manually insert thin spaces (U+2009, included in Dai Banna SIL) if you wish.  In any case, character spacing looks fine in print.

In OpenOffice.org.sil Writer 2.4rc6-1, full justification can sometimes create the above character spacing problem in a run of New Tai Lue text even at large font sizes.  It is advised that full justification not be used for New Tai Lue text in this application until the problem is fixed in a newer version.

< Assertion errors in Graphite-enabled OpenOffice 2.4 - Windows >
OpenOffice.org.sil Writer 2.4rc6-1 may flag an assertion error multiple times on opening a document containing New Tai Lue data in a Dai Banna SIL font.  This is due to a known bug in the Graphite integration code base.  To work around, simply press the "Ignore" button multiple times until no more error messages appear.

< Chinese punctuation marks rendered in other fonts instead - Windows >
Although the Dai Banna SIL fonts contain glyphs for some characters in the CJK Symbols and Punctuation block and the Halfwidth and Fullwidth Forms block, certain applications on Microsoft Windows XP Pro SP2 and SP3 will automatically choose a default Asian text font to display these characters instead.  This is *not* a defect of our fonts but rather a failure of the applications and/or operating system to recognise Dai Banna SIL as containing Asian (CJK) glyphs.

E.g., in a run of New Tai Lue text displayed in Dai Banna SIL Book, Microsoft Word 2003 renders all Chinese punctuation using SimSun and there is no way to override it, for Dai Banna SIL Book is not even allowed to be selected as an Asian text font.

In the case of OpenOffice.org.sil Writer 2.4rc6-1, the same faulty font fall-back mechanism applies, but it can be overridden: just highlight the whole run of New Tai Lue text and select one of the Dai Banna SIL fonts in the font combo box.  Subsequent input of Chinese punctuation will then also be displayed correctly.  Alternatively, you can input all New Tai Lue characters and Chinese punctuation via the Insert Special Character dialog box using one of the Dai Banna SIL fonts.  All characters so inserted will be displayed in the correct font.

Microsoft WordPad will display in the correct font as long as you are typing the characters into the document.  As soon as you copy and paste a Chinese punctuation mark, WordPad will default to SimSun just like Word 2003.  (There used to be a work-around: highlight the characters in concern, select 'Western' in the Font Script combo box and select one of the Dai Banna SIL fonts in the Font combo box.  However, this no longer works with SP3.)  Even if every character is typed, when you save, close and re-open the document, all Chinese punctuation will revert to SimSun AND, worse, all New Tai Lue characters will turn into boxes and cannot be displayed at allchanging the font simply has no effect.

Both SIL WorldPad 2.4.2006.12069 and Microsoft NotePad do not exhibit such font fall-back problems.

< Line does not break after certain Chinese punctuation - Windows >
Whereas Microsoft NotePad breaks every punctuation correctly, WordPad does not break after U+3002 or U+FF0E and Word 2003 even *prevents* a break after U+FF0E despite trailing spaces whether U+0020 or U+3000.  These are failures of the respective applications and/or operating system and are *not* related to our font package.  As for Microsoft Excel 2003, no break opportunities can be observed at all (in a cell with text-wrapping enabled).  It is not known whether this is by design or an oversight of the spreadsheet application.

< Anomalous smart line-breaking behaviours in Graphite-enabled OpenOffice 2.4 - Windows >
In OpenOffice.org.sil Writer 2.4rc6-1, New Tai Lue text is often wrapped in a way that leaves too much space on the right enough to fit the first word on the following line, but on a few occasions the last line of text overshoots the right margin where a break should have occurred.  This is *not* a problem with the Dai Banna SIL fonts but rather a defect of the application.  In the same version of Calc, no break opportunities can be observed at all (in a cell with text-wrapping enabled).  It is not known whether this is by design or an oversight of the spreadsheet application.

< Changed document layout across different OpenOffice versions - Windows >
New Tai Lue text documents created in standard OpenOffice.org 2.3.1 may occupy more pages in the Graphite-enabled OpenOffice.org.sil 2.4 even though nothing in the document or the font (apart from the code points of the two digit ones) has been changed.  This is due to smart line-breaking capabilities of the font being realised in the Graphite-enabled Writer 2.4.  In particular, intraword breaks as seen in standard Writer 2.3.1 are now avoided by properly wrapping the first part of the word to the next line.  As a result, what used to fill one page may now overflow to another.  If this is undesirable, a possible work-around is to adjust the page margins and/or paragraph indentations to make the page accommodate the same amount of data as before.

< Misleading highlight on selection in Graphite-enabled OpenOffice 2.4 - Windows >
When a re-ordrant vowel, its base consonant, or the following consonant is selected, the visual highlight does not correspond to the character selected but either spans two characters or none at all, making it very difficult to copy and paste correctly.  This is *not* a defect of our font package but rather a limitation of the application suite.  Until better handling is available in a newer version, the only work-around is to get used to this anomaly through practice and carefulness.

< Extra spaces on pasting in Graphite-enabled OpenOffice 2.4 - Windows >
In OpenOffice.org.sil Writer 2.4rc6-1, an extra space may be added before and/or after an arbitrary consonant character being copied from and pasted into a run of New Tai Lue text as if the character were a word in itself.  This is an application defect rather than a font problem.  To get around the problem, just delete the extra spaces.

< Wrong autofit row height in Microsoft Excel 2003 - Windows >
In a cell containing New Tai Lue text wrapped into multiple lines, the autofit function in Excel 2003 may fail to compute the correct row height when the column width falls in a certain range.  On some occasions a blank line is left before the first line of text while in other situations the last few lines of text are cut off.  This faulty behaviour is *not* a defect of our fonts but a bug of the application.  Manual height adjustment can remove the blank line in the first scenario, but there is no way to show the missing lines in the second except by editing the cell via pressing F2 or double-clicking.


Non-Roman Script Initiative
SIL International 
7500 West Camp Wisdom Rd.
Dallas, TX 75236   USA 
Phone (972) 708-7495 
Fax (972) 708-7387
Email: sil_fonts@sil.org
WWW: scripts.sil.org
