Around 16 o'clock on Nov 19, yao zhang wrote:

> Thanks for the clarification.  I am really eager to see your new Xft APIs.
> In the mean time, I hope you don't mind those "dumb" questions from
> me:

I'm taking my time because I've made plenty of mistakes in this area in 
the past -- getting questions from people hoping to build software with 
this interface is the best possible data I can have.  Thanks for your 
input.

> But a group of pre-defined bitsets should
> also be specified by the "character set" part of an existing standard (not
> the "encodinging" part of the standard): "Latin-1", "GB2312", "BIG5", "CJK
> Unified Ideographs", etc.  Those string constant are just aliases to the
> underline unicode char maps.  It is very useful since most existing fonts
> are design for one particular character set of a standard anyway.

New fonts for western languages are designed to satisfy many locales and
encodings at once -- Verdana has more than 600 glyphs and works for dozens
of languages.  I'd like to deprecate the use of existing encoding names as 
that will only confuse the user; let's investigate the Unicode world and 
see if there are well defined and named subsets for various areas of the 
world.

> 1.  Is there a way to check 'font' returned by XftFontOpenName() really
>     satisfy the coverage request?  Is there a set of coverage access
>     functions in Xft?

Yes.  You can discover what glyphs are covered by the font, either singly 
or in terms of set operations.

> 2.  Will the extents and draw functions take care of multiple font files
>     access internally?

I'm not planning on that right now; Owen Taylor has convinced me that 
doing this down in Xft will lead to "ransom note" typography.  Selecting 
the font for various regions of a document must take more document context 
into account -- replacing a single glyph in a western word makes it very 
difficult to read, even replacing individual words can be jarring.

> Is that means after XftFontOpenName(), the application maybe able to
> examine the 'font' returned in terms of a: its coverage; b: list of fonts
> kept inside it?  And some how, this list of fonts can be re-arranged
> by a sophisticated application?  I was thinking 'XftFont' is an opaque
> structure before.

Certainly applications can ask questions about the coverage of a 
particular font, but right now there's no plan on merging multiple fonts 
into a single Xft font object, rather the application level will be 
responsible for selecting among several fonts for each rendering request.

[EMAIL PROTECTED]        XFree86 Core Team              SuSE, Inc.


_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Reply via email to