Re: improvement of font selection

2006-03-29 Thread Behdad Esfahbod 
On Wed, 29 Mar 2006, Petr Tomasek wrote:

> Also I would be very surprised, persian letters would not
> include arabic characters. In fact, I have used persian
> fonts for writing arabic. Can You show me an example of
> a font, that has _only_ persian glyphs?

Some of the farsiweb.info fonts for example don't have the proper
Arabic-style numerals of U+0660..U+0669, as Persian uses
U+06F0..U+06F9.  Or the U+06A4 ARABIC LETTER VEH which is used in
modern Arabic for transliterating foreign names, but not in
Persian, or various other characters encoded in the range
U-0670..U+06D5 that are used in Arabic language of different
countries, as well as other languages written in the Arabic
script.

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-29 Thread Petr Tomasek 
> > So IMHO the right way for font selection would be (unless
> > specified otherway in the fonts.conf of course) to try to select
> > the font (for particular unicode block) that covers this block
> > best.
> 
> In fact, I prefer the other way around.  If there are two fonts A
> and B, A supports the entire Arabic block, B supports only the
> glyphs needed for rendering Persian, I prefer B for Persian for
> obvious reasons.
> 

I have seen many cases, where mixing the fonts was not only visualy
incompatible, but worse, where for example accent came from
another font than the letter the accent should be placed at,
it simply doesn't work, since you cannot use any OT tables
to place the accent properly (I've seen this with biblical hebrew).

Also I would be very surprised, persian letters would not
include arabic characters. In fact, I have used persian
fonts for writing arabic. Can You show me an example of
a font, that has _only_ persian glyphs?

P.T.

-- 
Petr Tomasek 
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-29 Thread Behdad Esfahbod 
On Wed, 29 Mar 2006, Kenichi Handa wrote:

> > Apart from not checking the available OpenType tables in the
> > font, Pango is handling the rest already.  It's a bug when it's
> > not doing, and the OpenType table thing is a known missing
> > feature.
>
> Then, my proposal is to improve Pango toward that missing
> feature, isn't it?

Yes, it is.  Help is welcome like always, but I'll see if I can
use your patch to implement this.

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-29 Thread Behdad Esfahbod 
On Wed, 29 Mar 2006, Petr Tomasek wrote:

> But not everyone is capable of creating his own fonts.conf!

As this is a developer list, we are not talking about users
creating this file directly.

> >From my experience, the problem is that many time a font
> is choosen for particular unicode block, that covers only
> part of it, even if you have installed font, that covers
> it totally (or almost).
>
> So IMHO the right way for font selection would be (unless
> specified otherway in the fonts.conf of course) to try to select
> the font (for particular unicode block) that covers this block
> best.

In fact, I prefer the other way around.  If there are two fonts A
and B, A supports the entire Arabic block, B supports only the
glyphs needed for rendering Persian, I prefer B for Persian for
obvious reasons.

> P.T.

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-28 Thread Kenichi Handa 
In article <[EMAIL PROTECTED]>, Behdad Esfahbod <[EMAIL PROTECTED]> writes:

> Great.  Still something's wrong that you are not seeing lang=si
> passed to fontconfig.  No idea what.

I'll investigate it when I have more time.

> Apart from not checking the available OpenType tables in the
> font, Pango is handling the rest already.  It's a bug when it's
> not doing, and the OpenType table thing is a known missing
> feature.

Then, my proposal is to improve Pango toward that missing
feature, isn't it?

>> The fonts provide sufficient information; i.e. which glyphs
>> are available, which OpenType tables are available, which
>> features for which scripts are available.  As far as that
>> information is correct, how can we blame them?

> That's not enough.

But, those are all what a font can provide.

> An ugly font if as good as a beautiful font
> as far as these metrics are concerned.  If you have ten fonts,
> each having glyphs for ten scripts, with varying degrees of
> quality and aesthetics, you have to manually order then in your
> fonts.conf for each script, cause they cannot be ordered
> independent of the script you are interested in.  Whether A is
> better than B depends on which script you are interested in,
> while if your fonts each had glyphs for a single script, you
> could easily compare every two fonts and say either 1) A is
> better than B, 2) B is better than A, 3) they don't compare,
> because they have glyphs for different scripts.  This way, the
> only thing you need to handle in fonts.conf is to order fonts of
> each script, and handle the differences between preferred fonts
> of languages using the same script.

Of course, it's users responsibility to order fonts properly
if he has multiple fonts supporting a specific script and he
prefer one to the other.  One may accept such a task for his
native script/language.  But, usually, for scripts/languages
that he is not native, he don't (and don't want to) care
about the quality.  Quality is of course somewhat important,
but the more important thing is that a text is rendered
correctly.

---
Kenichi Handa
[EMAIL PROTECTED]
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-28 Thread Petr Tomasek 
> > are available, which OpenType tables are available, which
> > features for which scripts are available.  As far as that
> > information is correct, how can we blame them?
> 
> That's not enough.  An ugly font if as good as a beautiful font
> as far as these metrics are concerned.  If you have ten fonts,
> each having glyphs for ten scripts, with varying degrees of
> quality and aesthetics, you have to manually order then in your
> fonts.conf for each script, cause they cannot be ordered
> independent of the script you are interested in.  Whether A is
> better than B depends on which script you are interested in,
> while if your fonts each had glyphs for a single script, you
> could easily compare every two fonts and say either 1) A is
> better than B, 2) B is better than A, 3) they don't compare,
> because they have glyphs for different scripts.  This way, the
> only thing you need to handle in fonts.conf is to order fonts of
> each script, and handle the differences between preferred fonts
> of languages using the same script.

But not everyone is capable of creating his own fonts.conf!

>From my experience, the problem is that many time a font
is choosen for particular unicode block, that covers only
part of it, even if you have installed font, that covers
it totally (or almost).

So IMHO the right way for font selection would be (unless
specified otherway in the fonts.conf of course) to try to select
the font (for particular unicode block) that covers this block
best.

P.T.
-- 
Petr Tomasek 
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-28 Thread Behdad Esfahbod 
On Tue, 28 Mar 2006, Kenichi Handa wrote:

> Thank you.  That worked.

Great.  Still something's wrong that you are not seeing lang=si
passed to fontconfig.  No idea what.


> >> but I think it's a big pain to list up all such fonts
> >> for many languages.
>
> > Well, yes, it's a big pain when people stuff (crappy) glyphs for
> > lots of different scripts in a font.
>
> I still think that the source of the pain is in
> inappropriate font selection mechanism.  It is a renderer's
> responsibility to choose a proper font as far as it is going
> to do some automatic font selection.

Apart from not checking the available OpenType tables in the
font, Pango is handling the rest already.  It's a bug when it's
not doing, and the OpenType table thing is a known missing
feature.


> The fonts provide sufficient information; i.e. which glyphs
> are available, which OpenType tables are available, which
> features for which scripts are available.  As far as that
> information is correct, how can we blame them?

That's not enough.  An ugly font if as good as a beautiful font
as far as these metrics are concerned.  If you have ten fonts,
each having glyphs for ten scripts, with varying degrees of
quality and aesthetics, you have to manually order then in your
fonts.conf for each script, cause they cannot be ordered
independent of the script you are interested in.  Whether A is
better than B depends on which script you are interested in,
while if your fonts each had glyphs for a single script, you
could easily compare every two fonts and say either 1) A is
better than B, 2) B is better than A, 3) they don't compare,
because they have glyphs for different scripts.  This way, the
only thing you need to handle in fonts.conf is to order fonts of
each script, and handle the differences between preferred fonts
of languages using the same script.

> ---
> Kenichi Handa
> [EMAIL PROTECTED]

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-28 Thread Kenichi Handa 
In article <[EMAIL PROTECTED]>, Behdad Esfahbod <[EMAIL PROTECTED]> writes:
> I didn't test this one, try something like this:

>  
>   
>
>  freesans
>
>   
>  

> wrapped in the  and test for the language.  Not sure if it
> works.  If it doesn't, you may want to raise it on the fontconfig
> list and we'll make it work there.

Thank you.  That worked.

>> but I think it's a big pain to list up all such fonts
>> for many languages.

> Well, yes, it's a big pain when people stuff (crappy) glyphs for
> lots of different scripts in a font.

I still think that the source of the pain is in
inappropriate font selection mechanism.  It is a renderer's
responsibility to choose a proper font as far as it is going
to do some automatic font selection.

The fonts provide sufficient information; i.e. which glyphs
are available, which OpenType tables are available, which
features for which scripts are available.  As far as that
information is correct, how can we blame them?

---
Kenichi Handa
[EMAIL PROTECTED]

___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-28 Thread Behdad Esfahbod 
On Tue, 28 Mar 2006, Kenichi Handa wrote:

> Just a short reply to the last part.
>
> In article <[EMAIL PROTECTED]>, Behdad Esfahbod <[EMAIL PROTECTED]> writes:
>
> > Well, yes, it's a big pain when people stuff (crappy) glyphs for
> > lots of different scripts in a font.  The solution is to not use
> > (or completely blacklist) FreeSans in the first place.
>
> That's not acceptable because FreeSans/FreeSerif/FreeMono
> series are quite good/handy for rendering
> Latin/Greek/Cyrillic/Ethiopic/symbols/etc.  We can't blame
> them for not supporting all scripts.

Then make a Latin/Greek/Cyrillic font out of it.  This very
thread is a proof that they should be blamed...

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-28 Thread Kenichi Handa 
Just a short reply to the last part.

In article <[EMAIL PROTECTED]>, Behdad Esfahbod <[EMAIL PROTECTED]> writes:

> Well, yes, it's a big pain when people stuff (crappy) glyphs for
> lots of different scripts in a font.  The solution is to not use
> (or completely blacklist) FreeSans in the first place.

That's not acceptable because FreeSans/FreeSerif/FreeMono
series are quite good/handy for rendering
Latin/Greek/Cyrillic/Ethiopic/symbols/etc.  We can't blame
them for not supporting all scripts.

---
Kenichi Handa
[EMAIL PROTECTED]
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-27 Thread Behdad Esfahbod 
On Tue, 28 Mar 2006, Kenichi Handa wrote:

> Yes, I'm now testing the latest CVS code.  FcPatternPrint
> printed:
>   lang: "c"(s)
> and
>   lang: "en"(s)

This is not good.  When I run gedit in en_US but type Arabic,
lang=ar is passed to fontconfig, as expected.  I have no idea why
this is not working for you.

> But, it's not good to require locale change just for having
> a correct rendering.

Indeed.


> By the way, it seems that fontconfig always put higher
> priority to "family" than "lang".  So, I get this result.

It's not quite always, but most of the time.  Search for
"bindings" in this page:

  http://www.fontconfig.org/fontconfig-user.html

> % fc-match --sort freeserif:lang=si
> FreeSerif.ttf: "FreeSerif" "Medium"
> FreeSerifBold.ttf: "FreeSerif" "Bold"
> FreeSerifItalic.ttf: "FreeSerif" "Italic"
> FreeSerifBoldItalic.ttf: "FreeSerif" "BoldItalic"
> lklug.otf: "LKLUG" "Regular"
> [...]
>
> Doesn't it mean that if a user prefer freeserif in general
> in some application, Pango puts freeserif in pattern, thus
> lklug doesn't come first even for rendering Sinhala in that
> application.  This is just my guess.  I don't know exactly
> how Pango builds up pattern.  But, at least, when I select
> freeserif in gedit->Edit->Preferences->Font&Colors, even in
> sl_SI.UTF-8 locale, gedit again tries to use freeserif.

Yes, that's the idea: if you specify a font and that font
supports Sinhala, you get it.

You can still override that by adding configuration like this for
example:




Tahoma


Roya




> You wrote:
> > Anyway, combining the language test with rejectfont allows for
> > per-language blacklisting.
>
> That technique will solve this problem (I don't know how to
> write it in .fonts.conf, could you teach me so that I can
> try),

I didn't test this one, try something like this:

 
  
   
 freesans
   
  
 

wrapped in the  and test for the language.  Not sure if it
works.  If it doesn't, you may want to raise it on the fontconfig
list and we'll make it work there.


> but I think it's a big pain to list up all such fonts
> for many languages.

Well, yes, it's a big pain when people stuff (crappy) glyphs for
lots of different scripts in a font.  The solution is to not use
(or completely blacklist) FreeSans in the first place.


--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-27 Thread Kenichi Handa 
In article <[EMAIL PROTECTED]>, Behdad Esfahbod <[EMAIL PROTECTED]> writes:

>> The fonts selected are these (I got this information by
>> adding printf() in pango/modules/indic/indic-fc.c).
>> 
>> U+0D86 -> LKLUG
>> U+0DBA U+0DD4 U+0DB6 -> FreeSerif
>> U+0DDD -> LKLUG
>> U+0DC0 U+0DB1 U+0DCA -> FreeSerif
>> 
>> lklug contains all corresponding glyphs, but glyphs for
>> U+0D86 and U+0DDD are missing in freeserif.  Of course the
>> resulting rendering is incorrect.

> This doesn't look good.  Can you put a FcPatternPrint in
> pango/pangofc-fontmap.c just before the FcFontSort call to print
> out the pattern, and then see what pattern is searched for when
> you open the Sinhala text in gedit?  It should have lang=si.  You
> are using latest Pango, right?  Not that it makes any different,
> just to make sure we are looking at the same code.

Yes, I'm now testing the latest CVS code.  FcPatternPrint
printed:
lang: "c"(s)
and
lang: "en"(s)

But, when I start gedit as this:

% LANG=sl_SI.UTF-8 gedit FILENAME

FcPatternPrint prints these:
lang: "si"(s)
lang: "sl-si"(s)
and only lklug is used, thus the text is rendered correctly.

But, it's not good to require locale change just for having
a correct rendering.

By the way, it seems that fontconfig always put higher
priority to "family" than "lang".  So, I get this result.

% fc-match --sort freeserif:lang=si
FreeSerif.ttf: "FreeSerif" "Medium"
FreeSerifBold.ttf: "FreeSerif" "Bold"
FreeSerifItalic.ttf: "FreeSerif" "Italic"
FreeSerifBoldItalic.ttf: "FreeSerif" "BoldItalic"
lklug.otf: "LKLUG" "Regular"
[...]

Doesn't it mean that if a user prefer freeserif in general
in some application, Pango puts freeserif in pattern, thus
lklug doesn't come first even for rendering Sinhala in that
application.  This is just my guess.  I don't know exactly
how Pango builds up pattern.  But, at least, when I select
freeserif in gedit->Edit->Preferences->Font&Colors, even in
sl_SI.UTF-8 locale, gedit again tries to use freeserif.

You wrote:
> Anyway, combining the language test with rejectfont allows for
> per-language blacklisting.

That technique will solve this problem (I don't know how to
write it in .fonts.conf, could you teach me so that I can
try), but I think it's a big pain to list up all such fonts
for many languages.

---
Kenichi Handa
[EMAIL PROTECTED]
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-27 Thread Behdad Esfahbod 
On Tue, 28 Mar 2006, Kenichi Handa wrote:

> Ah!  You are right.  I was short sight.  I was only thinking
> about adding fonts in this kind of parts.
>
> 
>   
>   Bitstream Vera Serif
>   Times New Roman
> [...]
>   
>
> So, I tried this setting to prefer lklug to freeserif for
> sinhara.
>
> 
> 
> si
> 
> 
> lklug
> 
> 
>
> Then, fc-match surely returns lklug for :lang=si.  But when
> I open a Sinhala file with gedit, it seems that gedit (or
> pango; I don't know) prefer freeserif over lklug.  The file
> contains this character sequence ("hello" in Sinhara):
>
>   U+0D86 U+0DBA U+0DD4 U+0DB6 U+0DDD U+0DC0 U+0DB1 U+0DCA
>
> The fonts selected are these (I got this information by
> adding printf() in pango/modules/indic/indic-fc.c).
>
>   U+0D86 -> LKLUG
>   U+0DBA U+0DD4 U+0DB6 -> FreeSerif
>   U+0DDD -> LKLUG
>   U+0DC0 U+0DB1 U+0DCA -> FreeSerif
>
> lklug contains all corresponding glyphs, but glyphs for
> U+0D86 and U+0DDD are missing in freeserif.  Of course the
> resulting rendering is incorrect.

This doesn't look good.  Can you put a FcPatternPrint in
pango/pangofc-fontmap.c just before the FcFontSort call to print
out the pattern, and then see what pattern is searched for when
you open the Sinhala text in gedit?  It should have lang=si.  You
are using latest Pango, right?  Not that it makes any different,
just to make sure we are looking at the same code.


--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-27 Thread Kenichi Handa 
In article <[EMAIL PROTECTED]>, Behdad Esfahbod <[EMAIL PROTECTED]> writes:

> On Mon, 27 Mar 2006, Kenichi Handa wrote:
>> Unfortunately, AFAIK, fonts.conf doesn't allow per-script
>> (or per-language) settings, and we can't say some font is
>> broken or not without specifying a script or language.

> I keep hearing this (this is the third time in the past couple of
> months), but I don't believe it's true.  For example, I just
> hacked a tiny fonts.conf to change font selection for Arabic and
> Persian.

Ah!  You are right.  I was short sight.  I was only thinking
about adding fonts in this kind of parts.



Bitstream Vera Serif
Times New Roman
[...]


So, I tried this setting to prefer lklug to freeserif for
sinhara.



si


lklug



Then, fc-match surely returns lklug for :lang=si.  But when
I open a Sinhala file with gedit, it seems that gedit (or
pango; I don't know) prefer freeserif over lklug.  The file
contains this character sequence ("hello" in Sinhara):

  U+0D86 U+0DBA U+0DD4 U+0DB6 U+0DDD U+0DC0 U+0DB1 U+0DCA

The fonts selected are these (I got this information by
adding printf() in pango/modules/indic/indic-fc.c).

  U+0D86 -> LKLUG
  U+0DBA U+0DD4 U+0DB6 -> FreeSerif
  U+0DDD -> LKLUG
  U+0DC0 U+0DB1 U+0DCA -> FreeSerif

lklug contains all corresponding glyphs, but glyphs for
U+0D86 and U+0DDD are missing in freeserif.  Of course the
resulting rendering is incorrect.

---
Kenichi Handa
[EMAIL PROTECTED]
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-27 Thread Behdad Esfahbod 
On Mon, 27 Mar 2006, Kenichi Handa wrote:

> Unfortunately, AFAIK, fonts.conf doesn't allow per-script
> (or per-language) settings, and we can't say some font is
> broken or not without specifying a script or language.

I keep hearing this (this is the third time in the past couple of
months), but I don't believe it's true.  For example, I just
hacked a tiny fonts.conf to change font selection for Arabic and
Persian.

Before:

[EMAIL PROTECTED] ~]$ fc-match :lang=fa
roya.ttf: "Roya" "Regular"
[EMAIL PROTECTED] ~]$ fc-match :lang=ar
roya.ttf: "Roya" "Regular"

After adding this to ~/.fonts.conf:






ar


Homa




[EMAIL PROTECTED] ~]$ fc-match :lang=fa
roya.ttf: "Roya" "Regular"
[EMAIL PROTECTED] ~]$ fc-match :lang=ar
homa.ttf: "Homa" "Regular"



So, you have per-language configuration.  Per-script may be a bit
harder.  It may be worth adding script support to fontconfig.
Anyway, combining the language test with rejectfont allows for
per-language blacklisting.

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-27 Thread Kenichi Handa 
In article <[EMAIL PROTECTED]>, Owen Taylor <[EMAIL PROTECTED]> writes:

>> Basically I agree with that.  But, my font requirement is
>> just "be sure to use correct OpenType fonts for such scripts
>> that require CTL".  Isn't it a general requirement?

> Yes, it's a long-standing known problem. Generally, it doesn't
> become a huge problem as long as some font for the script
> is explicitly configured in the fonts.conf aliases ahead of
> broken fonts.

Unfortunately, AFAIK, fonts.conf doesn't allow per-script
(or per-language) settings, and we can't say some font is
broken or not without specifying a script or language.  For
instance, FreeSerif.ttf has no problem with Latin, Greek,
etc, but not good for Tamil even if it contains Tamil
glyphs.  On the other hand, akruti1b.ttf is good for Tamil
but is broken for Latin (ASCII).  And, first of all, even if
we put akruti1b.ttf before FreeSerif.ttf, sorting may change
that order (or, am I wrong with that?  I don't know how
fontconfig score fonts).

> I probably misunderstood what you meant by avoiding FcFontSort...
> it sounded like you wanted to do something very different from
> it. FcFcontSort is Pango's font selection algorithm.

What I suggested is to use FcFontSetSort.  Actually,
FcFontSort delegates the actual sorting work to
FcFontSetSort.

>> At least, the curren font selection of Pango has
>> unacceptable unreliableness (it may selects an unusable
>> font).  I think my change is to make it acceptable
>> unreliableness (i.e. if there's an usable font, use it) with
>> a help of shaper's "cover" function.

> But, because of the trimming, it's likely that there will
> be a usable font, but you won't see it.

Ok, then I change my wording to "if there's a non-trimmed
usable font, use it".  My patch will work better if trimming
problem is fixed, but it still provides possibility of
improvement without that fixing.  Actually, I have many
Indic and SEA fonts but most of them have different
coverages in Latin or symbol parts, thus are not trimmed.

>> > If we need to extend the shaper interface, we need to extend
>> > the shaper interface.
>> 
>> Yes, "If we need to".  But, I don't think "we need to" for
>> the current problem.

> I'm not sure about that. Someone needs to investigate how
> things would work if we were doing our own trimming.

I can't follow your discussion.  The current main problem is
to allow shaper engine to select a preferred font among what
Pango finds.  That can be solved without extending the
current interface, can't it?

To improve which fonts Pango finds is another problem
(i.e. the problem of sorting and trimming).  It may or may
not require extending of the interface.

> I don't think you can simply pass trim=False, then use
> character-by-character coverage, because then you have to keep the list
> of 1000 fonts around forever.

Right.  That's why I proposed to exclude unusable fonts
before sorting with trim=False.  This pre-exclusion won't
work well for English.  Then, we may need to add a new API
for shaper engine to control how to do that if you don't
want to hard-code some special treatment for English.

---
Kenichi Handa
[EMAIL PROTECTED]
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-27 Thread Owen Taylor 
On Mon, 2006-03-27 at 17:14 +0900, Kenichi Handa wrote:
> Hi,
> 
> In article <[EMAIL PROTECTED]>, Owen Taylor <[EMAIL PROTECTED]> writes:
> 
> > If someone really has very particular font requirements, then
> > they probably should just specify them. A user can specify
> > a font of 
> 
> >  "Palatino,Kochi Mincho"
> 
> > And get exactly that. The more magic we do on font selection, the less
> > likely that the user will understand what's going on.
> 
> Basically I agree with that.  But, my font requirement is
> just "be sure to use correct OpenType fonts for such scripts
> that require CTL".  Isn't it a general requirement?

Yes, it's a long-standing known problem. Generally, it doesn't
become a huge problem as long as some font for the script
is explicitly configured in the fonts.conf aliases ahead of
broken fonts.

> > There's a pretty big advantage to being reasonably consistent
> > with the way fontconfig works in other programs. If we invent
> > our own font sorting algorithms, then we lose that advantage.
> 
> > And I definitely don't want to introduce some Pango specific
> > configuration of language-specific fontsets. 
> 
> I've proposed two things; patch to pango-context, and
> avoiding of FcFontSort.  But, I didn't propose any new
> font-sorting algorithm, and I don't understand what you mean
> by "configuration of language-specific fontsets".

I probably misunderstood what you meant by avoiding FcFontSort...
it sounded like you wanted to do something very different from
it. FcFcontSort is Pango's font selection algorithm.

> >> > The right thing to do is probably duplicate the trimming code
> >> > from fontconfig and combine it with our own logic ... if you
> >> > look at how trimming is implemented in fontconfig, it's not
> >> > doing anything that we could do ourselves as efficiently.
> >> 
> >> That doesn't solve the problem (1) above. 
> 
> > But what's the problem in (1) or (2)? A lot of work has been done
> > to try and make that not a performance bottleneck, and it doesn't
> > generally seem to be one. If it works with 1000 Latin fonts,
> > then it should work with 1000 Latin fonts + 5 Hindi fonts.
> 
> If there's really no performance problem in (1) and (2), and
> Pango can implement its own trimming efficiently, that's ok
> for me.  I just want Pango not to trim necessary fonts.
> 
> >> By the way, regardless of modifying Pango along that line or
> >> not, I think the patch I proposed doesn't make the situation
> >> worse.  And, even if it's not that reliable now, there
> >> surely exist a case that the patch works.
> 
> > There's a performance penalty from the patch, right?
> 
> No, I don't think so.  It seems that
>PANGO_ENGINE_SHAPE_GET_CLASS (engine)->covers ()
> always returns PANGO_COVERAGE_EXACT or PANGO_COVERAGE_NONE
> (at least on GNU/Linux), right?
> Then, my patch changes nothing.
> 
> When some shape engine implemets its own "covers" that may
> return PANGO_COVERAGE_APPROXIMATE on some fonts, the
> performance problem may rise, but it's only when a user
> doesn't have an "exact" font for a character he is going to
> render.  And, even in that case, if trimming is done
> properly, the "covers" function doesn't have to check 1000
> fonts but only 10 or more fonts.  I believe that's kind of
> inefficiency is ignoreable on a system where fontconfig's
> FcFontSort has no problem in sorting 1000 fonts.

OK, I thought I remembered that the basic shaper set an
"approximate" coverage, but I was misremembering. Indeed
there is no performance problem if all shapers return
EXACT or NONE. (Also no improvement.)

> > I'm not crazy about slowing down performance to get an 
> > inherently unreliable result.
> 
> At least, the curren font selection of Pango has
> unacceptable unreliableness (it may selects an unusable
> font).  I think my change is to make it acceptable
> unreliableness (i.e. if there's an usable font, use it) with
> a help of shaper's "cover" function.

But, because of the trimming, it's likely that there will
be a usable font, but you won't see it.

> >> Which OTF features are required depends on a
> >> script/language.  So, to make that work, we need another
> >> callback function in shaper to provide that kind of
> >> information.  The above methods (step 1..3) I proposed
> >> doesn't require such a change.
> 
> > If we need to extend the shaper interface, we need to extend
> > the shaper interface.
> 
> Yes, "If we need to".  But, I don't think "we need to" for
> the current problem.

I'm not sure about that. Someone needs to investigate how
things would work if we were doing our own trimming.

I don't think you can simply pass trim=False, then use
character-by-character coverage, because then you have to keep the list
of 1000 fonts around forever.

Regards,
Owen


___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-27 Thread Kenichi Handa 
Hi,

In article <[EMAIL PROTECTED]>, Owen Taylor <[EMAIL PROTECTED]> writes:

> If someone really has very particular font requirements, then
> they probably should just specify them. A user can specify
> a font of 

>  "Palatino,Kochi Mincho"

> And get exactly that. The more magic we do on font selection, the less
> likely that the user will understand what's going on.

Basically I agree with that.  But, my font requirement is
just "be sure to use correct OpenType fonts for such scripts
that require CTL".  Isn't it a general requirement?

> There's a pretty big advantage to being reasonably consistent
> with the way fontconfig works in other programs. If we invent
> our own font sorting algorithms, then we lose that advantage.

> And I definitely don't want to introduce some Pango specific
> configuration of language-specific fontsets. 

I've proposed two things; patch to pango-context, and
avoiding of FcFontSort.  But, I didn't propose any new
font-sorting algorithm, and I don't understand what you mean
by "configuration of language-specific fontsets".

>> > The right thing to do is probably duplicate the trimming code
>> > from fontconfig and combine it with our own logic ... if you
>> > look at how trimming is implemented in fontconfig, it's not
>> > doing anything that we could do ourselves as efficiently.
>> 
>> That doesn't solve the problem (1) above. 

> But what's the problem in (1) or (2)? A lot of work has been done
> to try and make that not a performance bottleneck, and it doesn't
> generally seem to be one. If it works with 1000 Latin fonts,
> then it should work with 1000 Latin fonts + 5 Hindi fonts.

If there's really no performance problem in (1) and (2), and
Pango can implement its own trimming efficiently, that's ok
for me.  I just want Pango not to trim necessary fonts.

>> By the way, regardless of modifying Pango along that line or
>> not, I think the patch I proposed doesn't make the situation
>> worse.  And, even if it's not that reliable now, there
>> surely exist a case that the patch works.

> There's a performance penalty from the patch, right?

No, I don't think so.  It seems that
   PANGO_ENGINE_SHAPE_GET_CLASS (engine)->covers ()
always returns PANGO_COVERAGE_EXACT or PANGO_COVERAGE_NONE
(at least on GNU/Linux), right?
Then, my patch changes nothing.

When some shape engine implemets its own "covers" that may
return PANGO_COVERAGE_APPROXIMATE on some fonts, the
performance problem may rise, but it's only when a user
doesn't have an "exact" font for a character he is going to
render.  And, even in that case, if trimming is done
properly, the "covers" function doesn't have to check 1000
fonts but only 10 or more fonts.  I believe that's kind of
inefficiency is ignoreable on a system where fontconfig's
FcFontSort has no problem in sorting 1000 fonts.

> I'm not crazy about slowing down performance to get an 
> inherently unreliable result.

At least, the curren font selection of Pango has
unacceptable unreliableness (it may selects an unusable
font).  I think my change is to make it acceptable
unreliableness (i.e. if there's an usable font, use it) with
a help of shaper's "cover" function.

>> Which OTF features are required depends on a
>> script/language.  So, to make that work, we need another
>> callback function in shaper to provide that kind of
>> information.  The above methods (step 1..3) I proposed
>> doesn't require such a change.

> If we need to extend the shaper interface, we need to extend
> the shaper interface.

Yes, "If we need to".  But, I don't think "we need to" for
the current problem.

Regards,

---
Kenichi Handa
[EMAIL PROTECTED]
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-24 Thread Owen Taylor 
On Thu, 2006-03-23 at 14:24 +0900, Kenichi Handa wrote:
> Hi, thank you for the response.
> 
> In article <[EMAIL PROTECTED]>, Owen Taylor <[EMAIL PROTECTED]> writes:
> 
> > The problem is fontconfig ... since we ask fontconfig
> > to "trim" the results when calling FcFontSort(), only one
> > Japanese (say) font will be returned. If there is another
> > Japanese font further down the list, it won't be returned
> > unless it has new characters that the previous fonts don't
> > have.
> 
> Yes, I've noticed that problem and also the other problems.
> In short, I think we should avoid using FcFontSort.
> 
> > So, I don't think your patch will work out reliably - 
> > the font with "APPROXIMATE" or "FALLBACK" coverage may
> > keep your "EXACT" font from being found at all.
> 
> > On the other hand, if you don't trim the results you'll get
> > every single font in the system in the returned list, which
> > would be horrible for performance and memory usage.
> 
> But the method used in FcFontSort has some problems
> especially in such a case that we want Hindi fonts (several
> are available) but there are a huge number of non-Hindi
> fonts.
> 
> (1) It calculates scores of many unnecessary non-Hindi
> fonts, and sorts all of them.
> 
> (2) To trim it, it also checks charsets of such unnecessary
> fonts.
> 
> (3) The trimming algorithm is to check a charset against the
> union of all previous fonts.  Thus, if one previous font
> supports [a b] and another supports [a c], a new font
> supporting [b c] is excluded.  But, sometimes, what we
> want is a font supporting [b c].

If someone really has very particular font requirements, then
they probably should just specify them. A user can specify
a font of 

 "Palatino,Kochi Mincho"

And get exactly that. The more magic we do on font selection, the less
likely that the user will understand what's going on.

There's a pretty big advantage to being reasonably consistent
with the way fontconfig works in other programs. If we invent
our own font sorting algorithms, then we lose that advantage.

And I definitely don't want to introduce some Pango specific
configuration of language-specific fontsets. 

> > The right thing to do is probably duplicate the trimming code
> > from fontconfig and combine it with our own logic ... if you
> > look at how trimming is implemented in fontconfig, it's not
> > doing anything that we could do ourselves as efficiently.
> 
> That doesn't solve the problem (1) above. 

But what's the problem in (1) or (2)? A lot of work has been done
to try and make that not a performance bottleneck, and it doesn't
generally seem to be one. If it works with 1000 Latin fonts,
then it should work with 1000 Latin fonts + 5 Hindi fonts.

>  The way, I can
> think of, to avoid the above problems is this (at least for
> non English fonts):
> 
> 1. Get a fontset by FcFontList() by LANG pattern.  Perhaps
>we must add "generic" fonts (for serif, etc; not that
>many) to the resulting list.
> 
> 2. Use FcFontSetSort() on it without trimming.
> 
> 3. Ask shaper to select the best one.
> 
> By the way, regardless of modifying Pango along that line or
> not, I think the patch I proposed doesn't make the situation
> worse.  And, even if it's not that reliable now, there
> surely exist a case that the patch works.

There's a performance penalty from the patch, right?

I'm not crazy about slowing down performance to get an 
inherently unreliable result.

> > The other possibility - which could work Graphite and for 
> > OpenType, but maybe not as well for you - is to get fontconfig 
> > to sort the returned fonts based on what tables they contain,
> > and thus prefer the fonts with silf or GSUB/GPOS tables.
> 
> Which OTF features are required depends on a
> script/language.  So, to make that work, we need another
> callback function in shaper to provide that kind of
> information.  The above methods (step 1..3) I proposed
> doesn't require such a change.

If we need to extend the shaper interface, we need to extend
the shaper interface.

Regards,

Owen


___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-22 Thread Kenichi Handa 
Hi, thank you for the response.

In article <[EMAIL PROTECTED]>, Owen Taylor <[EMAIL PROTECTED]> writes:

> The problem is fontconfig ... since we ask fontconfig
> to "trim" the results when calling FcFontSort(), only one
> Japanese (say) font will be returned. If there is another
> Japanese font further down the list, it won't be returned
> unless it has new characters that the previous fonts don't
> have.

Yes, I've noticed that problem and also the other problems.
In short, I think we should avoid using FcFontSort.

> So, I don't think your patch will work out reliably - 
> the font with "APPROXIMATE" or "FALLBACK" coverage may
> keep your "EXACT" font from being found at all.

> On the other hand, if you don't trim the results you'll get
> every single font in the system in the returned list, which
> would be horrible for performance and memory usage.

But the method used in FcFontSort has some problems
especially in such a case that we want Hindi fonts (several
are available) but there are a huge number of non-Hindi
fonts.

(1) It calculates scores of many unnecessary non-Hindi
fonts, and sorts all of them.

(2) To trim it, it also checks charsets of such unnecessary
fonts.

(3) The trimming algorithm is to check a charset against the
union of all previous fonts.  Thus, if one previous font
supports [a b] and another supports [a c], a new font
supporting [b c] is excluded.  But, sometimes, what we
want is a font supporting [b c].

> The right thing to do is probably duplicate the trimming code
> from fontconfig and combine it with our own logic ... if you
> look at how trimming is implemented in fontconfig, it's not
> doing anything that we could do ourselves as efficiently.

That doesn't solve the problem (1) above.  The way, I can
think of, to avoid the above problems is this (at least for
non English fonts):

1. Get a fontset by FcFontList() by LANG pattern.  Perhaps
   we must add "generic" fonts (for serif, etc; not that
   many) to the resulting list.

2. Use FcFontSetSort() on it without trimming.

3. Ask shaper to select the best one.

By the way, regardless of modifying Pango along that line or
not, I think the patch I proposed doesn't make the situation
worse.  And, even if it's not that reliable now, there
surely exist a case that the patch works.

> The other possibility - which could work Graphite and for 
> OpenType, but maybe not as well for you - is to get fontconfig 
> to sort the returned fonts based on what tables they contain,
> and thus prefer the fonts with silf or GSUB/GPOS tables.

Which OTF features are required depends on a
script/language.  So, to make that work, we need another
callback function in shaper to provide that kind of
information.  The above methods (step 1..3) I proposed
doesn't require such a change.

---
Kenichi Handa
[EMAIL PROTECTED]
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-22 Thread Owen Taylor 
On Mon, 2006-03-13 at 16:38 +0900, Kenichi Handa wrote:
> Hi,
> 
> I'd like to suggest the attached patch to
> pango/pango-context.c.
> 
> Pango's shaper engine (struct _PangoEngineShapeClass) can
> have a callback function "covers", but it seems that it is
> not utilized that much.  In the function
> get_shaper_and_font_foreach(), the return value of
> (PangoCoverageLevel) _pango_engine_shape_covers() is simply
> checked against PANGO_COVERAGE_NONE, and if any other value
> is returned, that font is accepted.
> 
> I think it is better to try another font if
> PANGO_COVERAGE_FALLBACK or PANGO_COVERAGE_APPROXIMATE is
> returned here until PANGO_COVERAGE_EXACT is returned.
> 
> That way, pango can use a font most preferred by a shaper
> engine while falling back to APPROXIMATE or FALLBACK font.
> 
> What do you think?

When the shaper helps select the font there is a basic
problem ... I didn't think about it when I first created
the system, but discovered it later.

The problem is fontconfig ... since we ask fontconfig
to "trim" the results when calling FcFontSort(), only one
Japanese (say) font will be returned. If there is another
Japanese font further down the list, it won't be returned
unless it has new characters that the previous fonts don't
have.

So, I don't think your patch will work out reliably - 
the font with "APPROXIMATE" or "FALLBACK" coverage may
keep your "EXACT" font from being found at all.

On the other hand, if you don't trim the results you'll get
every single font in the system in the returned list, which
would be horrible for performance and memory usage.

The right thing to do is probably duplicate the trimming code
from fontconfig and combine it with our own logic ... if you
look at how trimming is implemented in fontconfig, it's not
doing anything that we could do ourselves as efficiently.

The other possibility - which could work Graphite and for 
OpenType, but maybe not as well for you - is to get fontconfig 
to sort the returned fonts based on what tables they contain,
and thus prefer the fonts with silf or GSUB/GPOS tables.

Regards,
Owen



signature.asc
Description: This is a digitally signed message part
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-14 Thread Kenichi Handa 
In article <[EMAIL PROTECTED]>, Behdad Esfahbod <[EMAIL PROTECTED]> writes:

>> Another reason for the change request is that we are now
>> developping a multilingual library m17n-lib
>> (http://www.m17n.org/m17n-lib), and it contains CTL (complex
>> text layout) rendering facility.  We can provide a pango
>> module using this library (single module can render many
>> scripts), but in that case also, the same problem happens.

> I know that library for a few years now, but never really looked
> into it in detail.  Any reason it has a separate CTL facility
> than Pango in the first place?

There are several reasons, but the biggest technical
difference with Pango is that it performs CTL not by
hard-coded program but by external database files which are
easily fixed/tuned/augmented.  Actually, even
non-C-programer can work on it.  For example, the attached
is for Arabic CTL.

---
Kenichi Handa
[EMAIL PROTECTED]

;; ARAB-OTF.flt -- Font Layout Table for Arabic OpenType font
;; Copyright (C) 2004
;;   National Institute of Advanced Industrial Science and Technology (AIST)
;;   Registration Number H15PRO112

;; This file is part of the m17n database; a sub-part of the m17n
;; library.

;; The m17n library is free software; you can redistribute it and/or
;; modify it under the terms of the GNU Lesser General Public License
;; as published by the Free Software Foundation; either version 2.1 of
;; the License, or (at your option) any later version.

;; The m17n library is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; Lesser General Public License for more details.

;; You should have received a copy of the GNU Lesser General Public
;; License along with the m17n library; if not, write to the Free
;; Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
;; 02111-1307, USA.

;;;  ARAB-OTF.flt
;;;
;;; For Arabic OpenType fonts to draw the Arabic script.


;; Step 0: Move Kazakh high hamza.

(category
 ;; p: high hamza carrier (p for positive)
 ;; n: high hamza suppressor (n for negative)
 ;; x: don't care
 (0x0600 0x06FF ?x)
 (0x0674 0x0678 ?p)
 (0x0643?n)
 (0x06AF?n)
 (0x06D5?n)
 (0x200C?x)
 (0x200D?x)
 (0x25CC?x)
 (0xFB50 0xFDFF ?X) ; Arabic Presentation Froms-A
 (0xFE70 0xFEFC ?X) ; Arabic Presentation Froms-B
 )

(generator
 (0
  (cond
   ;; If a presentation from is found, draw the whole sequence as is.
   (".*X.*" = *)

   (".*p.*" ; If a high hamza is found,
(cond
 (".*n.*"   ;   and a suppressor exists,
  rmhamza *);   then remove the high hamza.
 (0 ;   Otherwise, move the high
  0x674 rmhamza *)));   hamza to the beginning.
   (0 = *))); If no high hamza, do nothing.

 (rmhamza
  (cond
   ((0x0674))
   ((0x0675)0x0627)
   ((0x0676)0x0648)
   ((0x0677)0x06C7)
   ((0x0678)0x0649)
   ("." =

;; Step 1: ccmp

(category
 ;; D: Dual-joining (beh, teh, etc. & zwj)
 ;; R: Right-joining (alef, dal, thal, reh, zain)
 ;; U: Non-joining (Hamza, etc. & zwnj)
 ;; T: Transparent (combining marks)
 (0x060C 0x060F ?U)
 (0x0610 0x0615 ?T)
 (0x061B?U)
 (0x061F?U)
 (0x0621?U)
 (0x0622 0x0623 ?R)
 (0x0624?R)
 (0x0625?R)
 (0x0626?D)
 (0x0627?R)
 (0x0628?D)
 (0x0629?R)
 (0x062A 0x062E ?D)
 (0x062F 0x0632 ?R)
 (0x0633 0x0647 ?D)
 (0x0648?R)
 (0x0649 0x064A ?D)
 (0x064B 0x0658 ?T)
 (0x0660 0x066D ?U)
 (0x066E 0x066F ?D)
 (0x0670?T)
 (0x0671 0x0673 ?R)
 (0x0674 0x0678 ?U)
 (0x0679 0x0687 ?D)
 (0x0688 0x0699 ?R)
 (0x069A 0x06C3 ?D)
 (0x06C4 0x06CB ?R)
 (0x06CC 0x06CE ?D)
 (0x06CF?R)
 (0x06D0 0x06D3 ?D)
 (0x06D4?U)
 (0x06D5?R)
 (0x06D6 0x06E4 ?T)
 (0x06E5 0x06E6 ?U)
 (0x06E7 0x06E8 ?T)
 (0x06E9?U)
 (0x06EA 0x06ED ?T)
 (0x06EE 0x06EF ?R)
 (0x06F0 0x06F9 ?U)
 (0x06FA 0x06FC ?D)
 (0x06FD 0x06FE ?U)
 (0x06FF?D)
 (0x200C?U)
 (0x200D?D)
 (0x25CC?U)
 (0xFB50 0xFDFF ?X) ; Arabic Presentation Froms-A
 (0xFE70 0xFEFC ?X) ; Arabic Presentation Froms-B
 )

;; (generator
;;  (0
;;   otf:arab=ccmp))

;; Step 2: Initial, medial, or final.

(generator
 (0
  (cond

Re: improvement of font selection

2006-03-14 Thread Behdad Esfahbod 
On Tue, 14 Mar 2006, Kenichi Handa wrote:

> In article <[EMAIL PROTECTED]>, Behdad Esfahbod <[EMAIL PROTECTED]> writes:
>
> > I am curious what made you to write the patch originally.  What
> > problems does it solve for you.
>
> For instance, to display Tamil, I'd like to use akruti1b.ttf
> font which have a proper OTF tables for Tamil, but I also
> have FreeSerif.ttf which contains many glyphs including
> Tamil but not sufficient OTF tables.  And, it's not
> decidable which font (akruti1b or FreeSerif) is tried at
> first by Pango (without listing fonts carefully in
> fonts.conf).

Ok then, so your usecase is like my Arabic case that I described
in the bug.  I like to make this change.


> Another reason for the change request is that we are now
> developping a multilingual library m17n-lib
> (http://www.m17n.org/m17n-lib), and it contains CTL (complex
> text layout) rendering facility.  We can provide a pango
> module using this library (single module can render many
> scripts), but in that case also, the same problem happens.

I know that library for a few years now, but never really looked
into it in detail.  Any reason it has a separate CTL facility
than Pango in the first place?

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-14 Thread Kenichi Handa 
In article <[EMAIL PROTECTED]>, Behdad Esfahbod <[EMAIL PROTECTED]> writes:

> I am curious what made you to write the patch originally.  What
> problems does it solve for you.

For instance, to display Tamil, I'd like to use akruti1b.ttf
font which have a proper OTF tables for Tamil, but I also
have FreeSerif.ttf which contains many glyphs including
Tamil but not sufficient OTF tables.  And, it's not
decidable which font (akruti1b or FreeSerif) is tried at
first by Pango (without listing fonts carefully in
fonts.conf).

In such a situation, ideally, pango/modules/indic/indic-fc.c
can provide a proper "covers" function that returns
PANGO_COVERAGE_EXACT for akruti1b but
PANGO_COVERAGE_FALLBACK for FreeSerif by checking the font
contents.

But, to enable such an improvement, the patch I sent is
necessary as you see.

Another reason for the change request is that we are now
developping a multilingual library m17n-lib
(http://www.m17n.org/m17n-lib), and it contains CTL (complex
text layout) rendering facility.  We can provide a pango
module using this library (single module can render many
scripts), but in that case also, the same problem happens.

>> If the discussion on my patch will mainly be done on bug CC
>> (instead of gtk-i18n-list), I'll subscribe to it.  But, as
>> I'm quite overloaded, I'd like to avoid subscribing to
>> unnecessary mailing list.   Could you please advise me?

> Yes, the discussion is done on bugzilla, but you are not
> subscribing to any mailing lists, just to that specific bug and
> you will only get comments added to that bug.  You need to create
> a GNOME bugzilla account first and add your email address to the
> CC of the bug.

I see.  I've just done it (I hope I did it correctly).

---
Kenichi Handa
[EMAIL PROTECTED]
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-13 Thread Behdad Esfahbod 
On Mon, 13 Mar 2006, Kenichi Handa wrote:

> In article <[EMAIL PROTECTED]>, Behdad Esfahbod <[EMAIL PROTECTED]> writes:
>
> > I filed your request as a bug here:
>
> >   http://bugzilla.gnome.org/show_bug.cgi?id=334392
>
> Thank you.
>
> > Can you add yourself to the bug CC and also comment there about
> > what uses you see for this patch?
>
> I can't think of anything to be added.  Do you have some
> specific question?

I am curious what made you to write the patch originally.  What
problems does it solve for you.

> If the discussion on my patch will mainly be done on bug CC
> (instead of gtk-i18n-list), I'll subscribe to it.  But, as
> I'm quite overloaded, I'd like to avoid subscribing to
> unnecessary mailing list.   Could you please advise me?

Yes, the discussion is done on bugzilla, but you are not
subscribing to any mailing lists, just to that specific bug and
you will only get comments added to that bug.  You need to create
a GNOME bugzilla account first and add your email address to the
CC of the bug.

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-13 Thread Kenichi Handa 
In article <[EMAIL PROTECTED]>, Behdad Esfahbod <[EMAIL PROTECTED]> writes:

> I filed your request as a bug here:

>   http://bugzilla.gnome.org/show_bug.cgi?id=334392

Thank you.

> Can you add yourself to the bug CC and also comment there about
> what uses you see for this patch?

I can't think of anything to be added.  Do you have some
specific question?

If the discussion on my patch will mainly be done on bug CC
(instead of gtk-i18n-list), I'll subscribe to it.  But, as
I'm quite overloaded, I'd like to avoid subscribing to
unnecessary mailing list.   Could you please advise me?

---
Kenichi Handa
[EMAIL PROTECTED]
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: improvement of font selection

2006-03-13 Thread Behdad Esfahbod 
Hello,

I filed your request as a bug here:

  http://bugzilla.gnome.org/show_bug.cgi?id=334392

Can you add yourself to the bug CC and also comment there about
what uses you see for this patch?

Thanks
behdad




On Mon, 13 Mar 2006, Kenichi Handa wrote:

> Hi,
>
> I'd like to suggest the attached patch to
> pango/pango-context.c.
>
> Pango's shaper engine (struct _PangoEngineShapeClass) can
> have a callback function "covers", but it seems that it is
> not utilized that much.  In the function
> get_shaper_and_font_foreach(), the return value of
> (PangoCoverageLevel) _pango_engine_shape_covers() is simply
> checked against PANGO_COVERAGE_NONE, and if any other value
> is returned, that font is accepted.
>
> I think it is better to try another font if
> PANGO_COVERAGE_FALLBACK or PANGO_COVERAGE_APPROXIMATE is
> returned here until PANGO_COVERAGE_EXACT is returned.
>
> That way, pango can use a font most preferred by a shaper
> engine while falling back to APPROXIMATE or FALLBACK font.
>
> What do you think?
>
> If the patch is accepted, the next step will be to modify
> each shape engine to supply proper "covers" function if the
> default "covers" function is not enough.  For instance,
> indic shaper should accept only proper OTFs.
>
> ---
> Kenichi Handa
> [EMAIL PROTECTED]
>
> *** pango-context.c   04 Apr 2005 14:07:57 +0900  1.74
> --- pango-context.c   22 Jul 2005 16:59:41 +0900
> ***
> *** 867,872 
> --- 867,873 
> GSList *engines;
> PangoEngineShape *shape_engine;
> PangoFont *font;
> +   PangoCoverageLevel level;
>   } GetShaperFontInfo;
>
>   static gboolean
> ***
> *** 884,894 
>
> level = _pango_engine_shape_covers (engine, font,
> info->lang, info->wc);
> !   if (level != PANGO_COVERAGE_NONE)
>   {
> info->shape_engine = engine;
> info->font = g_object_ref (font);
> !   return TRUE;
>   }
>   }
>
> --- 885,899 
>
> level = _pango_engine_shape_covers (engine, font,
> info->lang, info->wc);
> !   if (level > info->level)
>   {
> info->shape_engine = engine;
> +   if (info->font)
> + g_object_unref (info->font);
> info->font = g_object_ref (font);
> !   info->level = level;
> !   if (level == PANGO_COVERAGE_EXACT)
> ! return TRUE;
>   }
>   }
>
> ***
> *** 926,931 
> --- 931,937 
> info.wc = wc;
> info.shape_engine = NULL;
> info.font = NULL;
> +   info.level = PANGO_COVERAGE_NONE;
>
> info.engines = state->exact_engines;
> if (state->enable_fallback)
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>
>

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list