Around 18 o'clock on Nov 18, yao zhang wrote:

> Does "font pattern" mean something like
> 
>     family=times:size=12:weight=bold:slant=oblique
> 
> as described in your Xft tutorial?  If yes, how the Unicode character
> map is represented/specified?

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.

> Related to my question earlier, what exactly does "Unicode coverage"
> look like?  One way I can think of is something like Java's
>      java.lang.Character.UnicodeBlock
> If that is the case, there are several problems when the "coverage"
> is applied to a particular font:

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.

> 1.  The coverage may not be complete.

This isn't relevant -- the coverage representation is independent of any 
particular encoding or locale, it's just the subset of Unicode covered by 
the font.

> For example, a simplified Chinese TTF may cover part of the UnicodeBlock
> CJK_UNIFIED_IDEOGRAPHS, and another traditional Chinese TTF may also
> cover part the the same block.  When you say "fonts missing the fewest
> glyphs in the desired range match more tightly than fonts missing more of
> the glyphs", what is the meaning of it?

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.

> Again, both traditional Chinese and simplified Chinese fonts have a lot
> glyphs in common, if the font pattern is something like
> 
>     times,traditional_cn_font,simplified_cn_font-12
> 
> Is the glyphs in 'traditional_cn_font' are used for the common part?  What
> about
>
>    times,simplified_cn_font,traditional_cn_font-12

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.  

Consider a document which has *many* traditional characters not covered by
the simplified set; I would expect the user would prefer that to be
displayed entirely with the traditional font rather than using a "ransom
note" style and interspersing traditional and simplified forms.  For 
reasons such as these, I'm leaving the actual selection of fonts to the 
application itself and providing only matching information.

> Is it possible to specify a pattern like
> 
>     family=times:size=14,family=fangsong:size=12
> 
> Because a 14 point 'times' may look better than a 12 point one when
> showing together with a 12 point 'fangsong'.

Not directly in the font pattern like this.  The redesign does allow the 
individual font patterns to be post-edited when the font is opened so that 
the user could customize the system to change the size of one or more 
faces.  I'll try to think how such a pattern could make sense in the 
current model.

[EMAIL PROTECTED]        XFree86 Core Team              SuSE, Inc.


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

Reply via email to