[sldev] UTF-8 open source fonts
Lawson English
lenglish5 at cox.net
Sat Aug 25 23:41:37 PDT 2007
Alissa Sabre wrote:
>> A little more research revealed that different people with clients on
>> different OS's or even the same OS show different subsets of chars.
>>
>
> It is true.
>
> Currently SL viewer uses OS supplied font files for shwoing non
> Latin-1 characters. Not all OS installation have a complete set of
> required font files.
>
> I agree it is a problem.
>
>
>> The problem appears to be that the included ASCII fonts are supplemented
>> on-the-fly with whatever is available on the local OS, but whatever
>> algorithm is being used to choose those supplemental characters doesn't
>> always work.
>>
>
> I'm not sure what you mean by "doesn't always work". I believe I
> understand what's happening under the current implementation. It is
> very simple scheme. Unless a user customized the settings, SL viewer
> uses per-OS fixed ordered list of font files to try, and it searches
> for a character (or a glyph, if you prefer this wording) in the given
> list of font files.
>
> This mechanism always works as expected. The problem is that the
> expectation is that of the developer, as opposed to of the users...
> \
>
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. Likewise, the special graphics characters that include chess
pieces and astrological signs show in the pallete but no in chat/IM or
llSetText. Don't know how many Israeli SL users there are, but it seems
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.
>> Linden Labs should standardize on existing open source unicode fonts
>> such as those found here:
>>
>> http://www.unifont.org/fontguide/
>>
>
> I don't think "LL should". It is reasonable that an application
> program to rely on the OS supplied font files.
>
>
If they exist and are contained in the list used by the client.
> In practice, I know no usable free-of-charge Chinese or Japanese
> fonts. Yes, there are some suggestions on the page you referred to,
> but the Chinese fonts available there have lower quality than those
> supplied by Apple as part of MacOS distribution.
>
> I'm not eligible to evaluate the quality of typography for other
> scripts, but I don't expects high-quality free-of-charge fonts are
> available for many minor scripts, either.
>
> I don't want to bound SL to such low quality fonts.
>
>
Fair enough.
>> a known
>> multi-language set of fonts will always be available in any SL distribution.
>>
>
> I agree this is a good thing, however.
>
> So, I'd like to suggest that future SL viewer distribution to
> contain more font files either free-of-charge fonts or LL could buy
> licenses of selected commercial fonts. It will fain "world-wide
> compatibility" of SL viewer. However, I also suggest that unless the
> SL viewer bundled fonts are high quality ones, those fonts should be
> considered as a _last_resort_, and SL viewer should use OS supplied
> font files wherever they are available.
>
A related issue would be an integer llGetCharWidth(string char) to
return the charWidth of a given UTF-8 character. 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. Of course if different fonts are used on various OS's this may
be impossible.
More information about the SLDev
mailing list