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:
>From [EMAIL PROTECTED] Sun Nov 18 20:53:29 2001
> Yes, this is a font pattern. A unicode char map is currently specified
> only in a rather human hostile format -- it's an ascii formatted version of
> a sparse binary array. I'm not quite sure how to improve that format; one
> idea is to have a 'character set' value which represents a language
> encoding (Latin-1, etc) which is converted internally to the appropriate
> set of unicode chars.
The 'character set' idea will be very help. Internally, the unicode
char map is really a bitset. "An ascii formatted version of" the bitset can
be specified in a font pattern. 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.
> I don't know how java's UnicodeBlock is represented; I represent the
> coverage of a font as simply the set of unicode glyphs covered by the font.
I guess internally, it is similar to your bitset array. But they
have a pre-defined set of constants to make it simple to use. But the
pre-defined set are just Unicode blocks, not "character set" part of
an existing standard. I think if Xft have both, that will be wonderful.
> The application is expected to compute the set of glyphs needed to
> represent the data. A font covering a larger set of the needed glyphs
> will score higher in a match than a font covering a smaller set. If the
> application knows it wants to display in simplified Chinese, it can
> request that Unicode set. My idea is that the application should examine
> the presented data and request a font (or fonts) covering those glyphs,
> that way the data itself will drive the selection of fonts.
Since I haven't seen the actual API, the following may not be entirely
right. Say a typical use of Xft like:
font = XftFontOpenName(display, screen,
"times,songti-12:coverage=latin1,gb2312")
XftTextExtentsUtf8(display, font, utf8s, strlen(utf8s), &extents);
XftDrawStringUtf8(draw, &color, font, x, y, utf8s, strlen(utf8s));
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?
2. Will the extents and draw functions take care of multiple font files
access internally?
> Xft will not have any policy in this matter; the selection of appropriate
> fonts cannot be done at such a low level. What I'm thinking is that Xft
> will represent the set of fonts needed to cover the requested range as a
> list of fonts, ordered by the match against the pattern (not including the
> unicode subset). This way, the application can see which fonts more
> closely match the font requested by the user and choose an appropriate one
> for each portion of the text.
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.
Regards,
Yao Zhang
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
