Re: font combinations

Malcolm-Rannirl wrote:

> From the discussion, it sounds like it is possible to have different fonts 
> with different unicode ranges used for the same piece of text, and have the 
> appropriate glyphs selected automatically.

> Did I understand correctly, and if so, how is this set up?

What I have learned is that if you are using GTK+ 2 with Xft 1, the
set up is better in configuation file /etc/X11/XftConfig or your own
~/.xftconfig.  If you are using GTK+ 2 with Xft 2, the configuration
file is /etc/fonts/fonts.conf or your own ~/.fonts.conf.

Owen Taylor wrote:

> > What I am trying to say is that the current implementation goes to
> > far to combine different Chinese fonts together or even different CJK
> > fonts together.  In my opinion, that is bad.  They could be in different
> > combined font, not in one combined font.
> I don't understand this distinction; the idea is that you specify
> a single alias (say "Sans-serif") to be used for an entire document;
> and you want the system to "do the right thing". Being able to
> do the right thing without user intervention.

This is how I understand it:

There are two kinds of font: physical font and logical font.  A logical
font may consists one or more physical fonts.  The phsical fonts in a
logical font work as a per character fallback list: if the glyph for a
character can not be found in the first physical font in the list, try
the next phisical font in the list, and so on.

The problem is how to generate the physical font list for a logical
font.  This list may be changing depends on the language, for example.
A generic logical font like 'sans-serif' may be/has to be different when
display Chinese and Japanese.  This leads to the question: Should we be
able to define different 'sans-serif' in 'fonts.conf' like 'sans-serif for
Chinese' and 'sans-serif for Japanese'?  Mozilla has a dialog box to do
that. Or how should we specify the same 'sans-serif' behave differently
for Chinese and Japanese?  I'd like the system "do the right thing" as
I ask it to or I will be able to correct it in case the system does not.

Keith Packard wrote:

> I am still planning on adopting pure CSS2 matching for fontconfig -- I 
> have a sense that CSS2 matching would solve this problem; I'll go and read 
> that spec again and try to make sense of this.  If it does, it may be that 
> we should always supply the language tag to fontconfig and expect that the 
> matching rules will generate a reasonable match.

I just read the font section of CSS2.  It doesn't seem to say anything about
how it should work with language tag.  The matching algorithm started at
font family name.  I think language should be checked before family name.

As a user, this is what I would like:

1.  If I specify a physical font for a text segment, then no matching is
needed.  Just ignore language tag, font substitute, etc.  If a character
can not be displayed by the font, leave it as a blank square;

2.  If I specify a phisical font for a text segment, language tag should be
examined first.  Depending on the language tag, the font substitution list
could be different.  The CSS2 matching algorithm can be applied here.


Yao Zhang

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]