xc/lib/font/FreeType/ in "XORG-RELEASE-1"-branch differs fromXfree86 trunk...

[Keith Packard]

Around 16 o'clock on Mar 15, Chisato Yamauchi wrote:

>  KeithP, you don't understand CJK environment at all.  At least, we
> Japanese always use TrueType fonts which have embedded-bitmap and
> thousands of glyphs.  It seems that Westerners generally want to ignore
> CJK environments and CJK specific promlems.

Yes, I do understand the issues of your environment.  I've been doing X
font support for some time now, having written the X font library and
designed the X font services protocol.  Han languages were a key motivator
for the new font architecture I developed, an environment where glyphs are
rasterized incrementally as needed by the application rather than all at
once before the first glyph even appears.

If you want to talk about performance improvements, client-side fonts are
the way to get them.  Right now, we're only talking about making the horror
know as core fonts slightly less horrible.

>  Your result is 8 or more times slower than mine.

That's more like what I expected.  With data like this, I can't imagine it
will take much convincing to get the FreeType developers to add whatever
API changes are needed to improve this.  Figure out what they are and 
submit a patch.

> Such problems are unrelated to your life.  However they are serious problems
> for us.  Don't ignore actual problems and don't kill our environments, please.
> If you ignore the problem, I think that the freedesktop.org is never free.

Yes, they're unrelated to my life, but not because I don't display Han 
glyphs on my screen on a regular basis.  I spent three years building a 
replacement system to eliminate the performance and memory problems 
implicit in the core font architecture.  I don't use core fonts any more, 
and when I find an application that I need to use which does, I fix it.  
So far, I've fixed Qt, Gtk+, Mozilla, Tk and Fltk.

> I just sent mail to David Turner to know a optimal method.  It is better
> surely to use only public API.

It's not "better", it's my requirement to create a system which can be
supported in the future.  Already, I've succeeded in getting you working
with Mr. Turner, which is precisely what I want you to do.

> If it is trivial, tell me the method.  My method is as a result of my
> difficulties.

I suggest that FT_Load_Glyph will return glyphs of format
FT_GLYPH_FORMAT_BITMAP whenever the bitmap is being used.  If we assume 
that all glyphs are either BITMAP or OUTLINE, then we can simply ask for a 
single glyph and set a flag in the font indicating whether that was 
returned as BITMAP to mark fonts which need the slower method of computing 
metrics.

I don't see why this wouldn't work, please try it out if you think it has 
merit.

> But your code assumes that if the font has embedded-bitmaps, all glyphs of 
> all sizes are embedded-bitmap.  There cannot be no such thing by any means.

Not quite; the slow method generates correct results for either kind of
glyphs.  My change was the minimum needed to generate the right values
while still being able to compile the font library in the absense of the
full FreeType source code.

As I said, you can commit whatever changes you like to solve this problem 
as long as you restrict yourself to the published API for the dependent 
libraries. Otherwise, most people will not be able to compile your code as 
FreeType is not part of the X window system and shouldn't be shipped as 
such.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/release-wranglers/attachments/20040315/1424eff7/attachment.pgp