EE There is a subsetting mechanism already (see XLFD specs), you can
EE use a bracket notation like : ...-iso8859-1[65 70 80_90] means only
EE use glyps 65, 70, 80-90. I don't know if this has ever been
EE implemented with any renderer.
It is implemented in all of our renderers with the
CY But do XFree86's developers accept our patches for libfreetype.a?
I do not believe that TTCap is a good idea, and will not implement it
in the FreeType backend.
The way to go is to implement all font configuration through
fontconfig. Unlike fonts.dir, the fontconfig cache is an extensible
JS Well, X-TT's 'competitor' is not freetype module, but fontconfig
JS (+FT2 + Xft)
Hear, hear.
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
DD A practical engineering solution is about getting the results you
DD need today with the resources available. It doesn't matter if
DD TTCap one day becomes unnecessary because of the availability of
DD better fonts.
Just to clarify, Yamauchi-san is referring to a TTCap field that
specifies
EE Saying 'core fonts need to go way' is equivalent to saying
EE 'lets change the core protocol'. That's out of the question.
I don't think the protocol spec requires the existence of any fonts
beyond fixed and cursor.
Juliusz
EE Generating fonts for asian character sets takes much more effort,
EE therefore it can be expected that TTCap will remain a valid
EE 'workaround' for a long time.
TTCap was based on the IMHO erroneous assumption that it is better to
hack extensions to fonts.dir rather than provide an extensible
From: Juliusz Chroboczek [EMAIL PROTECTED]
Subject: Re: [Fonts] After-XTT's extension of the encoding field.
Date: 04 Sep 2003 17:04:08 +0200
I do not believe that TTCap is a good idea, and will not implement it
in the FreeType backend.
However, I already started the experiment of
From: Juliusz Chroboczek [EMAIL PROTECTED]
Subject: Re: [Fonts] After-XTT's extension of the encoding field.
Date: 04 Sep 2003 17:17:59 +0200
Message-ID: [EMAIL PROTECTED]
TTCap was based on the IMHO erroneous assumption that it is better to
hack extensions to fonts.dir rather than provide an
