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

Egbert Eich eich at pdx.freedesktop.org
Mon Mar 15 07:38:20 PST 2004



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



More information about the release-wranglers mailing list