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

[Jim Gettys]

Seems like a plan to me.

In general, we should work closely with upstream package maintainers:
the freetype folks have been very helpful in the past, so I cannot
foresee problems here..  Making our own modifications when not
absolutely necessary is a long term recipe for
madness.
                         - Jim

On Mon, 2004-03-15 at 10:38, Egbert Eich wrote:
> I would like to propose the following solution:
> 
> -  Lets try to find a way to solve the problem using the existing API.
>    If that's not possible:
>    -  Bring up this issue with the upstream freetype maintainers and
>       lobby them for adding a proper way of obtaining the required information
>       thru a public API.
>    -  restore the code for the case where HasFreetype2 is set to "NO"
>       ie. the case where the freetype code that is shipped with the 
>       monolithic tree is compiled into a .a library.
>       This will be done with the understanding that it is an 'emergency fix' 
>       for those people who suffer from this problem so much that they
>       cannot wait for the proper support in freetype to come up.
>       It may even be legal as the freetype projects encourage people
>       to include their code into other projects if necessary.
> 
> 
> Egbert.
> 
> 
> Keith Packard writes:
>  > 
>  > 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
>  > 
>  > 
>  > _______________________________________________
>  > release-wranglers mailing list
>  > release-wranglers at freedesktop.org
>  > http://freedesktop.org/mailman/listinfo/release-wranglers
> 
> _______________________________________________
> release-wranglers mailing list
> release-wranglers at freedesktop.org
> http://freedesktop.org/mailman/listinfo/release-wranglers
-- 
Jim Gettys <Jim.Gettys at hp.com>
HP Labs, Cambridge Research Laboratory