--===============1775956343==
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fcimW0vtDzK7cIxjcsU/"


--=-fcimW0vtDzK7cIxjcsU/
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-09-28 at 11:01 +0900, mpsuzuki@hiroshima-u.ac.jp wrote:
> Hi
>=20
> I think your proposal is a propose of "localized font name"
> (like Microsoft Windows fontmenu, or classic QuickDraw based
> fontmenu on MacOS) or "localized sample text" (like recent
> fontpanel on MacOS X). If I'm misunderstanding, please correct.
>=20
> There are a few problem:
>=20
> 1) font name in font file is localized? internationalized?

An ASCII name is (almost) always present; localized names are more often
present in commercial fonts. Fontconfig tags each name with the language
and territory so you can search for an appropriate name even if the font
provides multiple localized names (which TTF does support).

> 2) a font object knows its best script?

Fontconfig automatically detects language support by measuring coverage
against an approximate orthography for the language. This means that
even incorrect OS/2 tables will not accidentally mark a font as
supporting additional languages.

Fontconfig does use the OS/2 table to disambiguate among hanzi languages
-- a font covering all of GB18030 but which does not include Japanese in
the OS/2 code page range bits is not marked as supporting Japanese, even
though GB18030 includes all of the codepoints needed for Japanese
support.

This does rely on the fonts not setting code page range bits for the
wrong language; so far, that's been reasonably successful.

> 3) menu for fontset?
> --------------------
> Microsoft Windows and Mac OS X have a feature to lap over
> multiple TTFs. The font menu of Microsoft Windows don't have
> menu to control that, but fontpanel of Mac OS X provide to
> edit "font collection". How do you think about the requirement
> of such features?

Fontconfig also has this support, and Qt and Pango both avail themselves
of it. Unlike Windows or Mac OS X, it is entirely automatic so that
fontsets are constructed from available fonts to provide as complete a
coverage as the available fonts can provide.

> 4) heaviness
> ------------
> I think proposed fontmenu must access all font contents to
> render its fontname. I suppose both of Microsoft Windows and
> MacOS/Mac OS X uses kernel space font cache maximumly, but
> how about UNIX platforms? Thinking about the situation using
> xfs at remote server, scanning all font contents can be heavy
> work and users may be forced to wait. There's any proposal
> about that?

Client side fonts are quite efficient in this regard, rendering and
caching only glyphs which are actually used. This permits efficient use
of the actual font for the font menu. It's not as fast as using a single
font for all menu entries, but the benefit to the user is probably worth
the cost in most environments.

-keith


--=-fcimW0vtDzK7cIxjcsU/
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDOf/mQp8BWwlsTdMRAg2XAJ42fZ5dB54bb9IsGmE4bg6O2DSlegCaAhje
guNajDvYYQQMfLLyklBxWYU=
=72TE
-----END PGP SIGNATURE-----

--=-fcimW0vtDzK7cIxjcsU/--

--===============1775956343==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

 =

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<

--===============1775956343==--