[sldev] UTF-8 open source fonts

[Alissa Sabre]

> I've found several instances where a glyph will show in the MacOS 
> character pallet but not show in chat/IM or llSetText. Specifically 
> Hebrew.

Oops, are you a Hebrew peaker?

I'm very sorry to say this, but current version of SL viewer can't
handle Hebrew properly.  It is not the font issue; it's not hard to
add a Hebrew font in SL viewer's list (just a one-line patch to the
source or simply editing settings.xml after install does the job), but
even if you do so, it doesn't allow you to chat in Hebrew.  At this
moment, the viewer orders Hebrew letters left to right, making them
totally unusable.

The same thing for Arabic script.  The SL viewer just can't handle
so-called right-to-left sripts at all.  See JIRA issues VWR-112 and
VWR-1629 for discussion.

# Supporting Arabic requires other efforts; proper handling of
  combining characters and cursiveness.  In short, we need full
  Unicode rendering facility rather than the current big-ASCII model.

I have some idea how we can achieve them.  One possibility is to use
pango.  I may try it eventually.

> Likewise, the special graphics characters that include chess 
> pieces and astrological signs show in the pallete but no in chat/IM or 
> llSetText.

Chess symbols and astrological signs should be technically easy.  We
can simply add appropriate font file on the list.  There is a small
problem, however.  MacOS has two font file directories; /Library/Fonts
and /System/Library/Fonts.  The current version of SL viewer only look
into the latter, while "Apple Symbols.ttf" that contains chess symbols
and astrological signs is in the former.  It should be easy to modify
the viewer so that it searches in /Library/Fonts, too.

> >> The problem appears to be that the included ASCII fonts are supplemented 
> >> on-the-fly with whatever is available on the local OS,

You called the mechanism "on-the-fly", but it is not "on-demand".  SL
viewer tries to *load* all available font files specified in the list
onto memory upon startup.  So, if we add a font file "Apple
Symbols.ttf" for chess symbols, your viewr will load the font
regardless you are actually using a chess symbol, and all other MacOS
users' viewer will, too.

If we are to add all font files that may possibly be used by a user to
the list, I believe we need some improvement on the font loading
mechanism so that the font file is only loaded when a glyph in the
font is actually used.

I'm personally not in favor of doing the modification now.  I would
try adopingt fontconfig before that, if I'm spending some time on the
font issues.  Of course, I have no objection if you do it.  The source
files you need to examine are:
linden/indra/llrender/llfont{,gl}.{h,cpp}

> Ascii graphics or 
> formatted text with llSetText and a variable width font is hard enough 
> without having to guess what is showing on various clients using various 
> OS fonts.

ASCII graphics?

Oh...  I have no interest on it.  I'm just afraid that the feature you
want may interfere with the international text support.

> that whatever the font list is for the Mac, its missing the one used by 
> the character pallete to generate these characters.
> 
> On the Windows side, these same characters show up sometimes and 
> sometimes not.

Hmm.  You first wanted to fill the gap of platform differences
regarding available characters and suggested SL to bundle a bunch of
free-of-charge font files and to use only those fonts.  You then
wanted Hebrew support, then chess symbols.  You now want all the MacOS
specific characters to be available in teh viewer.

I'm confused.  What is your point?


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/