[Fonts] After-XTT's extension of the encoding field.

[Egbert Eich]

The After-XTT project which has picked up the long orphaned
xtt truetype font renderer has submitted patches to xtt which
recently were committed to the CVS.
One of the changes prepares for the extention of the font encoding field:

[From the changelog]
 - Preparation for extending the encoding field of XLFD.  X-TT permits
   the following additional XLFD format:
   "-foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.0"
   "-foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.1"
   The last number can be used to indicate the plane number of a huge
   character set.

This will work around an Xlib problem that the XCharStruct
array of huge - but sparsely populated - fonts can get large.

To get a uniform behavior it would be desirable if the 'plane' field 
would be interpreted equally by all renderers.


Ideas/comments/opinions on this extensions?


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

Re: [Fonts] After-XTT's extension of the encoding field.

[Owen Taylor]

On Tue, 2003-07-29 at 04:44, Egbert Eich wrote:
> The After-XTT project which has picked up the long orphaned
> xtt truetype font renderer has submitted patches to xtt which
> recently were committed to the CVS.
> One of the changes prepares for the extention of the font encoding field:
> 
> [From the changelog]
>  - Preparation for extending the encoding field of XLFD.  X-TT permits
>the following additional XLFD format:
>"-foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.0"
>"-foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.1"
>The last number can be used to indicate the plane number of a huge
>character set.
> 
> This will work around an Xlib problem that the XCharStruct
> array of huge - but sparsely populated - fonts can get large.
> 
> To get a uniform behavior it would be desirable if the 'plane' field 
> would be interpreted equally by all renderers.
> 
> 
> Ideas/comments/opinions on this extensions?

Let the poor thing die in peace... 

Old X fonts are pretty much irretrievably broken, we have a good
replacement system. Adding extensions such as the above that are
basically API extensions (they do no good unless the app knows about
them) doesn't make sense at this point.

Regards,
Owen


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

Re: [Fonts] After-XTT's extension of the encoding field.

[Egbert Eich]

Owen Taylor writes:
 > On Tue, 2003-07-29 at 04:44, Egbert Eich wrote:
 > > The After-XTT project which has picked up the long orphaned
 > > xtt truetype font renderer has submitted patches to xtt which
 > > recently were committed to the CVS.
 > > One of the changes prepares for the extention of the font encoding field:
 > > 
 > > [From the changelog]
 > >  - Preparation for extending the encoding field of XLFD.  X-TT permits
 > >the following additional XLFD format:
 > >"-foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.0"
 > >"-foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.1"
 > >The last number can be used to indicate the plane number of a huge
 > >character set.
 > > 
 > > This will work around an Xlib problem that the XCharStruct
 > > array of huge - but sparsely populated - fonts can get large.
 > > 
 > > To get a uniform behavior it would be desirable if the 'plane' field 
 > > would be interpreted equally by all renderers.
 > > 
 > > 
 > > Ideas/comments/opinions on this extensions?
 > 
 > Let the poor thing die in peace... 
 > 
 > Old X fonts are pretty much irretrievably broken, we have a good
 > replacement system. Adding extensions such as the above that are
 > basically API extensions (they do no good unless the app knows about
 > them) doesn't make sense at this point.
 > 

Well, in legacy apps you usually specify the fonts using app defaults.
There is a subsetting mechanism already (see XLFD specs), you can
use a bracket notation like : ...-iso8859-1[65 70 80_90] means only
use glyps 65, 70, 80-90. I don't know if this has ever been
implemented with any renderer. 
Using a new notation like a.b to mark pages assigns it to this
purpose, limiting future encoding specifications.
However one could extend the bracket notation to mark pages instead
of individual fonts or font ranges.

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Owen Taylor]

On Tue, 2003-07-29 at 10:09, Egbert Eich wrote:
> Owen Taylor writes:
>  > On Tue, 2003-07-29 at 04:44, Egbert Eich wrote:
>  > > The After-XTT project which has picked up the long orphaned
>  > > xtt truetype font renderer has submitted patches to xtt which
>  > > recently were committed to the CVS.
>  > > One of the changes prepares for the extention of the font encoding field:
>  > > 
>  > > [From the changelog]
>  > >  - Preparation for extending the encoding field of XLFD.  X-TT permits
>  > >the following additional XLFD format:
>  > >"-foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.0"
>  > >"-foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.1"
>  > >The last number can be used to indicate the plane number of a huge
>  > >character set.
>  > > 
>  > > This will work around an Xlib problem that the XCharStruct
>  > > array of huge - but sparsely populated - fonts can get large.
>  > > 
>  > > To get a uniform behavior it would be desirable if the 'plane' field 
>  > > would be interpreted equally by all renderers.
>  > > 
>  > > 
>  > > Ideas/comments/opinions on this extensions?
>  > 
>  > Let the poor thing die in peace... 
>  > 
>  > Old X fonts are pretty much irretrievably broken, we have a good
>  > replacement system. Adding extensions such as the above that are
>  > basically API extensions (they do no good unless the app knows about
>  > them) doesn't make sense at this point.
>  > 
> 
> Well, in legacy apps you usually specify the fonts using app defaults.

Sure, but you aren't exactly going to say "I want this font, but
everything I'm going to use comes from one plane". Or I see
that as unlikely, anyways.

Regards,
Owen


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

Re: [Fonts] After-XTT's extension of the encoding field.

[Egbert Eich]

Owen Taylor writes:
 > > 
 > > Well, in legacy apps you usually specify the fonts using app defaults.
 > 
 > Sure, but you aren't exactly going to say "I want this font, but
 > everything I'm going to use comes from one plane". Or I see
 > that as unlikely, anyways.
 > 

This extension came from the After-XTT people from Japan.
I'm sure they have some use for it. They would be the best
to comment on this.

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Chisato Yamauchi]

From: Egbert Eich <[EMAIL PROTECTED]>
Subject: Re: [Fonts] After-XTT's extension of the encoding field.
Date: Tue, 29 Jul 2003 18:11:21 +0200

> This extension came from the After-XTT people from Japan.

  I thought of this extension from a argument with
Jamus Su.  It seems that there were some discussion on 
some mail lists of supporting non BMP glyphs.
  For example,

  http://mail.nl.linux.org/linux-utf8/2000-12/index.html
   Re: X font aliases and UTF-8 xterm, Ienup Sung
 Re: X font aliases and UTF-8 xterm, Robert Brady 
 Re: X font aliases and UTF-8 xterm, Roman Czyborra 

  But I like no proposals in them which cause confusion obviously.
Therefore I think that we actually cannot but extend Encoding Field.
The extension of X-TT 1.4 does not have any problems about compatibility,
so I implemented this extention to X-TT without many discussion.
Even if this extension is not accepted, there is no necessity of
deleting this extension.

  In Japan, there are the "GT fonts" which includes 66773 glyphs.
To use "GT fonts", I implemented this extention.  It is also one of
the reasons.  I use them like:

  gt21.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.1
  gt22.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.2
  gt23.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.3
   :
   :

  The code range of "gt" is the same of that of "jisx0208".


Chisato Yamauchi
After X-TT Project
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] After-XTT's extension of the encoding field.

[Egbert Eich]

Chisato Yamauchi writes:
 > From: Egbert Eich <[EMAIL PROTECTED]>
 > Subject: Re: [Fonts] After-XTT's extension of the encoding field.
 > Date: Tue, 29 Jul 2003 18:11:21 +0200
 > 
 > > This extension came from the After-XTT people from Japan.
 > 
 >   I thought of this extension from a argument with
 > Jamus Su.  It seems that there were some discussion on 
 > some mail lists of supporting non BMP glyphs.
 >   For example,
 > 
 >   http://mail.nl.linux.org/linux-utf8/2000-12/index.html
 >Re: X font aliases and UTF-8 xterm, Ienup Sung
 >  Re: X font aliases and UTF-8 xterm, Robert Brady 
 >  Re: X font aliases and UTF-8 xterm, Roman Czyborra 
 > 
 >   But I like no proposals in them which cause confusion obviously.
 > Therefore I think that we actually cannot but extend Encoding Field.
 > The extension of X-TT 1.4 does not have any problems about compatibility,
 > so I implemented this extention to X-TT without many discussion.
 > Even if this extension is not accepted, there is no necessity of
 > deleting this extension.
 > 
 >   In Japan, there are the "GT fonts" which includes 66773 glyphs.
 > To use "GT fonts", I implemented this extention.  It is also one of
 > the reasons.  I use them like:
 > 
 >   gt21.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.1
 >   gt22.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.2
 >   gt23.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.3
 >:
 >:
 > 
 >   The code range of "gt" is the same of that of "jisx0208".
 > 

OK, so you are not selecting different ranges but different files?
Is it a standard procedure to distribute one font accross several
files or was the single file just split into separate ones just to
avoid blowing up the XFontStruct?

Two further issues:
1. would it be possible to convert xtt to use freetype2 instead
of freetype1? This would allow us to remove the freetype1 sources
from the tree.

2. it is planned to extend the freetype module to meet all core
font requirements, also is planned to convert all bitmapped fonts to
bitmapped truetype fonts. This would to some extend collide with the
xtt renderer: whichever renderer is loaded first would be chosen to
render all available formats it can handle. Which features does xtt
offer which the freetype module is lacking of?

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Chisato Yamauchi]

> OK, so you are not selecting different ranges but different files?
> Is it a standard procedure to distribute one font accross several
> files or was the single file just split into separate ones just to
> avoid blowing up the XFontStruct?

  "GT fonts" is a quite special fonts. The code ranges of all files
follow that of jisx0208.  
  There is "Konjakumojikyo fonts" which inclues over 10 glyphs in Japan.
Although I have not tried it yet, it seems that it also use the existing code
set and all glyphs are divided into many files. 

  Although the pliability of handling such special fonts is also important,
non BMP plane in XLFD is now the most important problem.  Confusion is
already seen such as linux-utf8 list.  An official definition should be
indicated right now.  Why has XFree86 left this?

> Two further issues:
> 1. would it be possible to convert xtt to use freetype2 instead
> of freetype1? This would allow us to remove the freetype1 sources
> from the tree.
> 2. it is planned to extend the freetype module to meet all core
> font requirements, also is planned to convert all bitmapped fonts to
> bitmapped truetype fonts. This would to some extend collide with the
> xtt renderer: whichever renderer is loaded first would be chosen to
> render all available formats it can handle. Which features does xtt
> offer which the freetype module is lacking of?

  I also think that it is not good that many font backends exist.

  Why do we persist in X-TT?  The reason is that "libfreetype.a"
does not useful at all in CJK.  Especially the following two points are fatal.

  - Handling a proportional multi-bytes fonts is too slow.
(The loading speed of libfreetype.a is 20 times slower than 
 that of X-TT 1.4; I show a benchmark in next email.)

  - The modification of a font(such as auto italic and double striking, etc.)
cannot be used at all.

  That is, "libfreetype.a" should also have all options of "TTCap".

  Have you seen CJK's *TYPICAL* fonts.dir of TrueType fonts?
It is following:

kochi-mincho.ttf -kochi-kochi mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0
ds=m:kochi-mincho.ttf -kochi-kochi mincho-bold-r-normal--0-0-0-0-c-0-jisx0208.1983-0
eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
mincho-medium-i-normal--0-0-0-0-c-0-jisx0208.1983-0
ds=m:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
mincho-bold-i-normal--0-0-0-0-c-0-jisx0208.1983-0
bw=0.5:kochi-mincho.ttf -kochi-kochi 
mincho-medium-r-normal--0-0-0-0-c-0-jisx0201.1976-0
bw=0.5:ds=m:kochi-mincho.ttf -kochi-kochi 
mincho-bold-r-normal--0-0-0-0-c-0-jisx0201.1976-0
bw=0.5:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
mincho-medium-i-normal--0-0-0-0-c-0-jisx0201.1976-0
bw=0.5:ds=m:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
mincho-bold-i-normal--0-0-0-0-c-0-jisx0201.1976-0
bw=0.5:kochi-mincho.ttf -kochi-kochi mincho-medium-r-normal--0-0-0-0-c-0-iso8859-1
bw=0.5:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
mincho-medium-i-normal--0-0-0-0-c-0-iso8859-1
bw=0.5:ds=m:kochi-mincho.ttf -kochi-kochi mincho-bold-r-normal--0-0-0-0-c-0-iso8859-1
bw=0.5:ds=m:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
mincho-bold-i-normal--0-0-0-0-c-0-iso8859-1
fc=0x3400-0xe7ff:vl=y:kochi-mincho.ttf -kochi-kochi 
mincho-medium-r-normal--0-0-0-0-p-0-iso10646-1
fc=0x3400-0xe7ff:vl=y:ds=m:kochi-mincho.ttf -kochi-kochi 
mincho-bold-r-normal--0-0-0-0-p-0-iso10646-1
fc=0x3400-0xe7ff:vl=y:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
mincho-medium-i-normal--0-0-0-0-p-0-iso10646-1
fc=0x3400-0xe7ff:vl=y:ds=m:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
mincho-bold-i-normal--0-0-0-0-p-0-iso10646-1
fs=c:kochi-mincho.ttf -kochi-kochi pmincho-medium-r-normal--0-0-0-0-p-0-jisx0208.1983-0
fs=c:ds=mb:kochi-mincho.ttf -kochi-kochi 
pmincho-bold-r-normal--0-0-0-0-p-0-jisx0208.1983-0
fs=c:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
pmincho-medium-i-normal--0-0-0-0-p-0-jisx0208.1983-0
fs=c:ds=mb:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
pmincho-bold-i-normal--0-0-0-0-p-0-jisx0208.1983-0
fs=c:bw=0.5:kochi-mincho.ttf -kochi-kochi 
pmincho-medium-r-normal--0-0-0-0-p-0-jisx0201.1976-0
fs=c:bw=0.5:ds=mb:kochi-mincho.ttf -kochi-kochi 
pmincho-bold-r-normal--0-0-0-0-p-0-jisx0201.1976-0
fs=c:bw=0.5:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
pmincho-medium-i-normal--0-0-0-0-p-0-jisx0201.1976-0
fs=c:bw=0.5:ds=mb:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
pmincho-bold-i-normal--0-0-0-0-p-0-jisx0201.1976-0
fs=c:bw=0.5:kochi-mincho.ttf -kochi-kochi 
pmincho-medium-r-normal--0-0-0-0-p-0-iso8859-1
fs=c:bw=0.5:ds=mb:kochi-mincho.ttf -kochi-kochi 
pmincho-bold-r-normal--0-0-0-0-p-0-iso8859-1
fs=c:bw=0.5:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
pmincho-medium-i-normal--0-0-0-0-p-0-iso8859-1
fs=c:bw=0.5:ds=mb:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
pmincho-bold-i-normal--0-0-0-0-p-0-iso8859-1
hi=y:fc=0x3400-0xe7ff:vl=y:kochi-mincho.ttf -kochi-kochi 
pmincho-medium-r-normal--0-0-0-0-p-0-iso10646-1
hi=y:fc=0x3400-0xe7ff:vl=y:ds=mb:kochi-mincho.ttf -kochi-kochi 
pmincho-bold-r-normal--0-0-0-0-p-0-iso10646-

Re: [Fonts] After-XTT's extension of the encoding field.

[Jungshik Shin]

On Sat, 2 Aug 2003, Chisato Yamauchi wrote:

>   Although the pliability of handling such special fonts is also important,
> non BMP plane in XLFD is now the most important problem.  Confusion is
> already seen such as linux-utf8 list.  An official definition should be
> indicated right now.  Why has XFree86 left this?

  That's because XFree86 is moving away from 15year-old XLFD-based
approach. As Owen wrote, we'd better let that poor thing rest in peace
and move along. With fontconfig/Xft, we don't need to worry about XLFD
any more except for the sake of backward compatibility.  For non-BMP
characters, there isn't much issue with back. comp.  to worry about.

If you take a look at Mozilla's gfx/src/gtk/nsFontMetricsGTK.cpp
and gfx/src/gtk/nsFontMetricsXft.cpp
(or gfx/src/windows/nsFontMetricsWin.cpp) at
, you'll know what I mean.
Mozilla developers have put tremendous amount of 'heroic' efforts to make
CSS-style font selection work with XLFD-based font names. However,
a much simpler and shorter fontconfig based code(in
nsFontMetricsXft.cpp) works better that nsFontMetricsGTK.cpp (for XLFD-based
font names).

Adding yet another field to make XLFD more complex doesn't help a bit
in this respect. Besides, in your example (GT fonts), I don't see why
you need to extend XLFD. Couldn't you just use different numbers in
the last field of XLFD?

 >   gt21.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.1
 >   gt22.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.2
 >   gt23.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.3

Instead of the above, the following should work as well, shouldn't it?
Am I missing something?

 >   gt21.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-1
 >   gt22.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-2
 >   gt23.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-3


>   Why do we persist in X-TT?  The reason is that "libfreetype.a"
> does not useful at all in CJK.  Especially the following two points are fatal.

  Well, X-TT's 'competitor' is not freetype module, but fontconfig
(+FT2 + Xft)

>   - Handling a proportional multi-bytes fonts is too slow.
> (The loading speed of libfreetype.a is 20 times slower than
>  that of X-TT 1.4; I show a benchmark in next email.)

>  For the "with TTCap option" case, the option has been set to
>  "fc=0x3400-0xe7ff:fm=0x5a00".  This particular option setting
>  indicates that "xtt" handles the glyphs that are within the CJK
>  region (in unicode) with constant spacing, whose metrics are
>  similar to that of "0x5a00".

  This is a nifty idea that can be utilized in Freetype2 and/or
fontconfig, but it seems to me that the fact that there's that much difference
in the perf.  between two cases is yet another indication that
X11 core fonts have to go away.


>   - The modification of a font(such as auto italic and double striking, etc.)
> cannot be used at all.
>
>   That is, "libfreetype.a" should also have all options of "TTCap".
>

  Yeah, TTCap is useful, but it appears that we're trying to solve the
wrong problem turning away from the real issue. The real problem is
that we don't have quality CJK fonts in multiple styles.
Anyway, fontconfig offers 'artificial slanting' although it doesn't make
much sense to have 'italic' or 'slant' typefaces for CJK.

As for 'artificial bold',  there's a patch somewhere, but hasn't been
accepted because Freetype2 reportedly will come up with a better
solution for 'artificial bold'.

>   Have you seen CJK's *TYPICAL* fonts.dir of TrueType fonts?
> It is following:

 Not many people would be fond of tweaking fonts.dir/scale files
these days :-) Why would they when just dropping truetype fonts in
fontconfig in one of directories listed in the font search path
works like a charm?


  Jungshik

P.S. If merging X-TT and freetype module is not gonna happen soon,
it would be nice if X-TT makes use of fontenc library used by freetype
library. With fontenc library, freetype module doesn't have to hardcode
font encoding to Unicode mapping tables. Because font encodings are not
hard-coded, it's easy to add a new encoding although these days we don't
care much. Moreover, it'll cut down the size of X-TT significantly.
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] After-XTT's extension of the encoding field.

[David Dawes]

On Sat, Aug 02, 2003 at 10:10:03PM +0900, Jungshik Shin wrote:
>On Sat, 2 Aug 2003, Chisato Yamauchi wrote:
>
>>   Although the pliability of handling such special fonts is also important,
>> non BMP plane in XLFD is now the most important problem.  Confusion is
>> already seen such as linux-utf8 list.  An official definition should be
>> indicated right now.  Why has XFree86 left this?
>
>  That's because XFree86 is moving away from 15year-old XLFD-based
>approach. As Owen wrote, we'd better let that poor thing rest in peace
>and move along. With fontconfig/Xft, we don't need to worry about XLFD
>any more except for the sake of backward compatibility.  For non-BMP
>characters, there isn't much issue with back. comp.  to worry about.

Just so people don't get the wrong idea about what "XFree86" is
doing, core (server-side) font support will continue to be supported
and maintained while ever there are sections of our user base that
need it.  The same is true of our inclusion of the 'xtt' module as
an alternative to the 'freetype' module.

Non BMP planes in XLFD hasn't been addressed by XFree86 because it
wasn't a pressing issue for anyone.  It is being addressed now via
this discussion.  Since few people seem to be interested in this
issue, and if the death of XLFD is imminent, then it's probably
good enough for those who are interested to agree on how to handle
it according to their needs.

>  Yeah, TTCap is useful, but it appears that we're trying to solve the
>wrong problem turning away from the real issue. The real problem is
>that we don't have quality CJK fonts in multiple styles.

A practical engineering solution is about getting the results you
need today with the resources available.  It doesn't matter if
TTCap one day becomes unnecessary because of the availability of
better fonts.

David
-- 
David Dawes
Founder/committer/developer The XFree86 Project
www.XFree86.org/~dawes
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] After-XTT's extension of the encoding field.

[Egbert Eich]

Jungshik Shin writes:
 > On Sat, 2 Aug 2003, Chisato Yamauchi wrote:
 > 
 > >   Although the pliability of handling such special fonts is also important,
 > > non BMP plane in XLFD is now the most important problem.  Confusion is
 > > already seen such as linux-utf8 list.  An official definition should be
 > > indicated right now.  Why has XFree86 left this?
 > 
 >   That's because XFree86 is moving away from 15year-old XLFD-based
 > approach. As Owen wrote, we'd better let that poor thing rest in peace
 > and move along. With fontconfig/Xft, we don't need to worry about XLFD
 > any more except for the sake of backward compatibility.  For non-BMP
 > characters, there isn't much issue with back. comp.  to worry about.
 > 
 > If you take a look at Mozilla's gfx/src/gtk/nsFontMetricsGTK.cpp
 > and gfx/src/gtk/nsFontMetricsXft.cpp
 > (or gfx/src/windows/nsFontMetricsWin.cpp) at
 > , you'll know what I mean.
 > Mozilla developers have put tremendous amount of 'heroic' efforts to make
 > CSS-style font selection work with XLFD-based font names. However,
 > a much simpler and shorter fontconfig based code(in
 > nsFontMetricsXft.cpp) works better that nsFontMetricsGTK.cpp (for XLFD-based
 > font names).
 > 
 > Adding yet another field to make XLFD more complex doesn't help a bit
 > in this respect. Besides, in your example (GT fonts), I don't see why
 > you need to extend XLFD. Couldn't you just use different numbers in
 > the last field of XLFD?
 > 
 >  >   gt21.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.1
 >  >   gt22.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.2
 >  >   gt23.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.3
 > 
 > Instead of the above, the following should work as well, shouldn't it?
 > Am I missing something?
 > 
 >  >   gt21.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-1
 >  >   gt22.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-2
 >  >   gt23.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-3
 > 
 > 
 > >   Why do we persist in X-TT?  The reason is that "libfreetype.a"
 > > does not useful at all in CJK.  Especially the following two points are fatal.
 > 
 >   Well, X-TT's 'competitor' is not freetype module, but fontconfig
 > (+FT2 + Xft)
 > 
 > >   - Handling a proportional multi-bytes fonts is too slow.
 > > (The loading speed of libfreetype.a is 20 times slower than
 > >  that of X-TT 1.4; I show a benchmark in next email.)
 > 
 > >  For the "with TTCap option" case, the option has been set to
 > >  "fc=0x3400-0xe7ff:fm=0x5a00".  This particular option setting
 > >  indicates that "xtt" handles the glyphs that are within the CJK
 > >  region (in unicode) with constant spacing, whose metrics are
 > >  similar to that of "0x5a00".
 > 
 >   This is a nifty idea that can be utilized in Freetype2 and/or
 > fontconfig, but it seems to me that the fact that there's that much difference
 > in the perf.  between two cases is yet another indication that
 > X11 core fonts have to go away.
 > 

X11 core fonts need to stay for legacy applications and these
applications have to retain their present functionality.
Saying 'core fonts need to go way' is equivalent to saying
'lets change the core protocol'. That's out of the question.

If a well understood modification to core font handling gives you
a speed improvement for its present functionality it appears to
be a valid enhancement.

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Egbert Eich]

David Dawes writes:
 > 
 > Just so people don't get the wrong idea about what "XFree86" is
 > doing, core (server-side) font support will continue to be supported
 > and maintained while ever there are sections of our user base that
 > need it.  The same is true of our inclusion of the 'xtt' module as
 > an alternative to the 'freetype' module.

Indeed core fonts should continued to be supported so that legacy
application continue to work as they do today.
However one should carefully deliberated if the functionality of
the core fonts should still be extended as has been done in the past.
This has not improved the quatlity of the code and introduced
some very questionable hacks.
These questionable hacks should be fixed or removed as they introduce 
instabilities or lead to unexpected results.

 > 
 > Non BMP planes in XLFD hasn't been addressed by XFree86 because it
 > wasn't a pressing issue for anyone.  It is being addressed now via
 > this discussion.  Since few people seem to be interested in this
 > issue, and if the death of XLFD is imminent, then it's probably
 > good enough for those who are interested to agree on how to handle
 > it according to their needs.

Care must be taken not to introduce more 'hacks' which may have
unexpected side effects. Estimating these side effects was the
reason why I started this discussion here.

 > 
 > >  Yeah, TTCap is useful, but it appears that we're trying to solve the
 > >wrong problem turning away from the real issue. The real problem is
 > >that we don't have quality CJK fonts in multiple styles.
 > 
 > A practical engineering solution is about getting the results you
 > need today with the resources available.  It doesn't matter if
 > TTCap one day becomes unnecessary because of the availability of
 > better fonts.
 > 

Indeed. Those used to plethora of font styles available for latin
character sets don't realize the pain of those who need fonts with
more than 256 glyphs.
Generating fonts for asian character sets takes much more effort,
therefore it can be expected that TTCap will remain a valid
'workaround' for a long time.

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Egbert Eich]

Chisato Yamauchi writes:
 > > OK, so you are not selecting different ranges but different files?
 > > Is it a standard procedure to distribute one font accross several
 > > files or was the single file just split into separate ones just to
 > > avoid blowing up the XFontStruct?
 > 
 >   "GT fonts" is a quite special fonts. The code ranges of all files
 > follow that of jisx0208.  
 >   There is "Konjakumojikyo fonts" which inclues over 10 glyphs in Japan.
 > Although I have not tried it yet, it seems that it also use the existing code
 > set and all glyphs are divided into many files. 

This definitely drives core fonts to the edge.
Core fonts were not designed for that. 

 > 
 >   Although the pliability of handling such special fonts is also important,
 > non BMP plane in XLFD is now the most important problem.  Confusion is
 > already seen such as linux-utf8 list.  An official definition should be
 > indicated right now.  Why has XFree86 left this?
 > 
 > > Two further issues:
 > > 1. would it be possible to convert xtt to use freetype2 instead
 > > of freetype1? This would allow us to remove the freetype1 sources
 > > from the tree.

Would it be possible to do that?

 > 
 >   Why do we persist in X-TT?  The reason is that "libfreetype.a"
 > does not useful at all in CJK.  Especially the following two points are fatal.
 > 
 >   - Handling a proportional multi-bytes fonts is too slow.
 > (The loading speed of libfreetype.a is 20 times slower than 
 >  that of X-TT 1.4; I show a benchmark in next email.)
 > 
 >   - The modification of a font(such as auto italic and double striking, etc.)
 > cannot be used at all.
 > 
 >   That is, "libfreetype.a" should also have all options of "TTCap".

I would agree that these are valid issues.

Has anybody looked at merging these XTT functionalities into the 
freetype module?

Egbert.

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Juliusz Chroboczek]

EE> There is a subsetting mechanism already (see XLFD specs), you can
EE> use a bracket notation like : ...-iso8859-1[65 70 80_90] means only
EE> use glyps 65, 70, 80-90. I don't know if this has ever been
EE> implemented with any renderer. 

It is implemented in all of our renderers with the exception of the
bitmap scaler.

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Juliusz Chroboczek]

CY> But do XFree86's developers accept our patches for libfreetype.a?

I do not believe that TTCap is a good idea, and will not implement it
in the FreeType backend.

The way to go is to implement all font configuration through
fontconfig.  Unlike fonts.dir, the fontconfig cache is an extensible
data structure that can be used to store any relevant information.

A very rough beginning can be found on

  http://www.pps.jussieu.fr/~jch/software/files/fcfpe.c

Please do not redistribute this code yet, and let me know if you want
to hack at it.

Juliusz

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Juliusz Chroboczek]

JS>   Well, X-TT's 'competitor' is not freetype module, but fontconfig
JS> (+FT2 + Xft)

Hear, hear.

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Juliusz Chroboczek]

DD> A practical engineering solution is about getting the results you
DD> need today with the resources available.  It doesn't matter if
DD> TTCap one day becomes unnecessary because of the availability of
DD> better fonts.

Just to clarify, Yamauchi-san is referring to a TTCap field that
specifies the metrics of glyphs in a given range.

The core protocol requires that the metrics of all glyphs be computed
at font open time (actually at QueryFont time).  In practice, this
requires rasterising all glyphs in a font when opening a font, which
for large fonts can take up to a few minutes.

To work around this problem, both X-TT and freetype trust the
fonts.dir file when the spacing is -c-.  While this works well with
ideographic fonts from the 1990s, it doesn't help with modern fonts,
which tend to have proportional Latin glyphs.

This extension is orthogonal to X-TT's ability to slant or bolden
fonts, which is what I believe you (David) are referring to.

(It is my opinion that the proper workaround is to have a general
mechanism that allows caching of glyph metrics across font
instantiations, and it wouldn't be difficult to convince Keith to add
such an interface to fontconfig.  I do not believe that fonts.dir is
the right place to store such information.)

Juliusz


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

Re: [Fonts] After-XTT's extension of the encoding field.

[Juliusz Chroboczek]

EE> Saying 'core fonts need to go way' is equivalent to saying
EE> 'lets change the core protocol'. That's out of the question.

I don't think the protocol spec requires the existence of any fonts
beyond fixed and cursor.

Juliusz

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Juliusz Chroboczek]

EE> Generating fonts for asian character sets takes much more effort,
EE> therefore it can be expected that TTCap will remain a valid
EE> 'workaround' for a long time.

TTCap was based on the IMHO erroneous assumption that it is better to
hack extensions to fonts.dir rather than provide an extensible
database for font-related information.  Today, we do have just such an
extensible database: fontconfig.

As far as the implementation goes, TTCap lives in the font backend,
which implies that somebody got the layering wrong.

I do not deny that TTCap does work around real problems.  However, I
do not believe that TTCap is something we want to follow.

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Chisato Yamauchi]

From: Juliusz Chroboczek <[EMAIL PROTECTED]>
Subject: Re: [Fonts] After-XTT's extension of the encoding field.
Date: 04 Sep 2003 17:04:08 +0200

> I do not believe that TTCap is a good idea, and will not implement it
> in the FreeType backend.

  However, I already started the experiment of enhancemnet of libfreetype.a

> The way to go is to implement all font configuration through
> fontconfig.  Unlike fonts.dir, the fontconfig cache is an extensible
> data structure that can be used to store any relevant information.

  Probably, I think that I understand what you want to do.
Perhaps you are going to do fundamental solution.
  Althougn I don't believe fontconfig itself, when can the people
in CJK use OpenType satisfactorily in XLFD?  Next release of XFree?


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

Re: [Fonts] After-XTT's extension of the encoding field.

[Egbert Eich]

Juliusz Chroboczek writes:
 > EE> Saying 'core fonts need to go way' is equivalent to saying
 > EE> 'lets change the core protocol'. That's out of the question.
 > 
 > I don't think the protocol spec requires the existence of any fonts
 > beyond fixed and cursor.
 > 

Right, but this doesn't solve the real problem. Look at all the
legacy apps  which rely on core font technology. These cannot
be satisfied with just cursor and fixed. Some of them have a 
very clear idea which font they want and even have this hardcoded
someplace. 
These apps exist and will continue to exist. Some of them are binary 
only and many of those cannot be fixed ie. converted to a new font 
rendering model.

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

Re: [Fonts] After-XTT's extension of the encoding field.

[Juliusz Chroboczek]

EE> Saying 'core fonts need to go way' is equivalent to saying
EE> 'lets change the core protocol'. That's out of the question.

>> I don't think the protocol spec requires the existence of any fonts
>> beyond fixed and cursor.

EE> Right, but this doesn't solve the real problem.

Sure.  I was just pointing out that the reason why we persist in
maintaining the morass of the core fonts system is of a pragmatic
nature, and not due to protocol requirements.

Juliusz



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