[sldev] win32 libs zipfile on wiki seems rather empty...

Alissa Sabre alissa_sabre at yahoo.co.jp
Thu Dec 11 15:33:34 PST 2008


Geneko:
> Although frankly let's replace it with DejaVu Condensed or one of the 
> many nice Libre font families out there.

Tofu:
> DejaVu might be a great option.  Good license, and pretty good
> coverage for the file size.  Any other suggestions?

DejaVu is fine if we use Latin/Cyrillic/Greek only.  Some scripts in
DejaVu are very low quality.  This is a well known fact, that even the
DejaVu maintainer agrees on.  They are intentionally adding garbages
into the font because they believe it facilitate their goals.  One of
the reason they do so is that DejaVu assumes each user picks up parts
of the DejaVu glyph collection and supplement some others with other
fonts, using a flexible font synthesis system such as fontconfig, as
his/her need.

I believe the current SL font choosing system is too prmitive to use
DejaVu properly.  I would support the idea to use DejaVu if LL
extracts Latin/Cyrillic/Greek (and some punctuation) portion of the
font and use it.  I'm not in favor of use of DejaVu as a whole.

I see some problems of the current SL fonts.  However, my fundamental
question on the font is bit different:  Do we really need a set of
_SL_fonts_?  Why not just use platform's standard font?  I'm asking
this because I see no big advantage to do so, and I see several
disadvantage in the _current_ SL fonts.

# I believe this is third time I raise this question on this list...

> Changing our default font is a surprisingly large effort because of
> truncation issues, but I think it could be worth it (though the
> call isn't mine personally) - but we have to make a good font
> decision (ideally both a sans and a sansmono).

I konw it, because I'm using platform's font in the VWR-10131 patches,
and the differences of the font metrics affect a lot of places of the
viewer behaviour.  But, Tofu, please remember that SL font has only
Latin-1 coverage.  Chinese, Japanese and Korean UI (among the current
LL supported languages) use platform specific fallback fonts.  I
believe the right direction is changing the viewer code to handle
various fonts so that any good font works with the viewer, as opposed
to looking for a single set of (better) SL font and hard-code to that
particular SL fonts.

---

P.S., I'm have a problem rendering Arabic scripts on MacOS with my
pango patch now.  The reason is that Apple doesn't provides some
critical information to pango called OpenType Layout Tables in their
fonts.  DejaVu, on the other hand, contains partial Arabic glyphs with
OLT.  It appeals to me...  I'm uploading a new pango patch (VWR-10131)
in this weekend, and Arabic-speaking Macintosh users can test it next
week and can see what I'm saying.  Arabic text using pango and Apple
font is, ah, terrible.  Arabic using pango and DejaVu is acceptable
although not very good...

    Alissa Sabre
--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/


More information about the SLDev mailing list