Closed Bug 234035 Opened 21 years ago Closed 13 years ago

freetype2 2.1.8 compile error: FTC_Image_Cache_* APIs are not available any more

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.5alpha

People

(Reporter: jshin1987, Assigned: jshin1987)

References

Details

(Keywords: intl)

Attachments

(5 files, 6 obsolete files)

trace of mozilla with patch but crashing on printing
20.05 KB, text/plain
Details
patch for gtk2+xft only
6.74 KB, patch
jshin1987
: review+
bryner
: superreview+
Details | Diff | Splinter Review
patch part 2 (for builds with '--enable-freetype2' )
32.48 KB, patch
Details | Diff | Splinter Review
profiling result (with and without patch)
282.44 KB, application/x-gzip
Details
Freetype 2.1.8 patch for mozilla 1.7.7
17.14 KB, patch
Details | Diff | Splinter Review 
FTC_Image_Cache_* APIs are not available any more in recent freetype2 library.
They're replaced by FTC_ImageCache* APIs, but their calling sequences are
different. I wrote to the freetype list how long ago new APIs were introduced to
determine whether or not check it at a run-time.
Summary: freetype2 : FTC_Image_Cache_* APIs are not available any more → freetype2 : FTC_Image_Cache_* APIs are not available any more
I can't compile Mozilla, presumably because of this bug and because my version
of freetype is too recent (9.6.3).  I tried substituting version 2.0.9 of
freetype, and that eliminated complaints about a missing FTC_Image_Cache, but
led to other compilation and linking errors -- just too much for me to deal
with.  So I hope someone can fix this.
I also noticed this problem and when I changed all FTC_Image_Cache to
FTC_ImageCache the build crossed that stage and again failed at FTC_Image_Desc
for same reason . Looks like FTC_Image_Desc is also deprecated.
Please see this URL for about comments on Freetype 2.1.8

http://mail.gnome.org/archives/epiphany-list/2004-April/msg00057.html

When I tried compiling Mozilla with freetype 2.1.7 it went fine. So probably we
can wait on this bug for the next release of freetype?
Severity: normal → major
Summary: freetype2 : FTC_Image_Cache_* APIs are not available any more → freetype2 2.1.8 compile error: FTC_Image_Cache_* APIs are not available any more
*** Bug 241290 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> There are patches in NetBSD package.
> See cvsweb or commit messages for detail.
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/mozilla/patches/
> http://mail-index.netbsd.org/pkgsrc-changes/2004/04/29/0025.html

I had the same problem compiling mozilla with freetype 2.1.8. Those patches
solved the problem. I am typing this up in my patched mozilla right now. There
appear to be no ill effects from the patches. Will they be integrated into the
main mozilla tree anytime soon, because as distributions begin upgrading their
freetype libraries more and more people will have this problem compiling mozilla.
Attached patch FreeType-2.1.9 patch (obsolete) — — Splinter Review 
Attached patch contains (as its name implies) all modifications to FreeType and
Mozilla CVS source trees du jour.
Flags: blocking1.8a2?
Flags: blocking1.7?
Flags: blocking1.7?
Has this patch been applied to the source tree yet? If not, any idea when?
Thanks for the patch.

This is a thorny issue. mozilla.org build machines still have old freetype
library and so do most developers' machines. Therefore, the patch as it stands
cannot be committed. 

We can add a lot of #ifdef'd code, but I'm not sure how to handle this problem.

Actually, it's a bit more complicated than that because we have to deal with
both compile-time and run-time dependency. I guess we have to worry less about
the latter than the former because new APIs appear to have been introduced quite
a long time ago.

  
0 prob. Wait & C until this issue becomes real issue.

Comment on attachment 149334 [details] [diff] [review]
FreeType-2.1.9 patch



Thanks for the patch.  I realized that new APIs have been around for over a
year (if not a lot longer) and most Linux distributions have a version of
freetype with them (including RH9, FC1, SuSE 9.x, Mandrake) although legacy
APIs (currently used by Mozilla) were removed only recently. So, this patch
should be rather safe. 

>-    void    imageCacheLookup(in FTC_Image_Cache cache, in FTC_Image_Desc_p desc,
>+    void    imageCacheLookup(in FTC_ImageCache cache, in FTC_ImageType_p desc,

Perhaps, 's/desc/type/' would be better.

>Index: gfx/src/freetype/nsFreeType.cpp


>-nsFreeType2::ImageCacheLookup(FTC_Image_Cache cache, FTC_Image_Desc *desc,
>+nsFreeType2::ImageCacheLookup(FTC_ImageCache cache, FTC_ImageType *desc,
>                               FT_UInt glyphID, FT_Glyph *glyph)

same here.


>Index: gfx/src/ps/nsFontMetricsPS.cpp

>-  mImageDesc.font.face_id    = (void*)mEntry;
>-  mImageDesc.font.pix_width  = mPixelSize;
>-  mImageDesc.font.pix_height = mPixelSize;
>-  mImageDesc.image_type = 0;
>+  mImageDesc->face_id = (FTC_FaceID)&mEntry;
>+  mImageDesc->width  = mPixelSize;
>+  mImageDesc->height = mPixelSize;
>+  mImageDesc->flags = 0;

same here: s/mImageDesc/mImageType/   




>Index: gfx/src/ps/nsFontMetricsPS.h

>-  FTC_Image_Desc  mImageDesc;
>+  FTC_ImageType   mImageDesc;

 ditto and a couple of other places. 



>-  if (nsFreeType2::gFreeType2Autohinted)
>-    mImageDesc.image_type |= ftc_image_flag_autohinted;
>-
>-  if (nsFreeType2::gFreeType2Unhinted)
>-    mImageDesc.image_type |= ftc_image_flag_unhinted;

   Shouldn't we  'OR' |mImageType->flag| with FT_LOAD_FORCE_AUTOHINT and
FT_LOAD_NO_HINTING, respectively?

>-
>   PRUint32  num_embedded_bitmaps, i;
>   PRInt32*  embedded_bitmapheights;
>   mFaceID->GetEmbeddedBitmapHeights(&num_embedded_bitmaps,
>@@ -218,7 +211,6 @@ nsFreeTypeFont::nsFreeTypeFont(nsITrueTy
>         if (embedded_bitmapheights[i] == aPixelSize) {
>           embedded_bimap = PR_TRUE;
>           // unhinted must be set for embedded bitmaps to be used
>-          mImageDesc.image_type |= ftc_image_flag_unhinted;
>           break;
>         }
>       }

same here.
Attachment #149334 - Flags: review+
(In reply to comment #11)
> (From update of attachment 149334 [details] [diff] [review])
 
> Thanks for the patch.  I realized that new APIs have been around for over a
> year (if not a lot longer) and most Linux distributions have a version of
> freetype with them (including RH9, FC1, SuSE 9.x, Mandrake) although legacy
> APIs (currently used by Mozilla) were removed only recently. So, this patch
> should be rather safe. 

As far as FTC_ImageCache* APIs are concerend, the above is the case. However,
the signature of FTC_ImageType (FTC_ImageTypeRec_) has changed recently. For
instance,  in freetype 2.1.5, it's defined as 

  typedef struct  FTC_ImageTypeRec_
  {
    FTC_FontRec  font;
    FT_Int32     flags;

  } FTC_ImageTypeRec;


while in freetype 2.1.9, it's defined as 

  typedef struct  FTC_ImageTypeRec_
  {
    FTC_FaceID   face_id;
    FT_Int       width;
    FT_Int       height;
    FT_Int32     flags;

  } FTC_ImageTypeRec;

This difference is a real headache....
Status: NEW → ASSIGNED
Flags: blocking1.8a2? → blocking1.8a2-
*** Bug 252218 has been marked as a duplicate of this bug. ***
freetype 2.1.9 API
http://freetype.sourceforge.net/freetype2/docs/reference/ft2-cache_subsystem.html#FTC_ImageCache_Lookup
  FT_EXPORT( FT_Error )
  FTC_ImageCache_Lookup( FTC_ImageCache  cache,
                         FTC_ImageType   type,
                         FT_UInt         gindex,
                         FT_Glyph       *aglyph,
                         FTC_Node       *anode );

different with the patch.
The patch works for me with freetype 2.1.9.  I had to fix Xft.h too but that's
not mozilla's fault.
Attachment #149334 - Flags: superreview?(blizzard)
Comment on attachment 149334 [details] [diff] [review]
FreeType-2.1.9 patch

this cannot go in as it is. The way FT2 library has changed over the time makes
it rather hard to come up with a patch that will build and run across versions
of FT2.
Attachment #149334 - Flags: superreview?(blizzard)
Attachment #149334 - Flags: review+
I've applied the patch and it works well for normal builds but I'm having
problems with an SVG-enabled build. It fails at line 443 in
/mozilla/layout/svg/renderer/src/libart/nsSVGLibartGlyphMetricsFT.cpp with the
error 
nsSVGLibartGlyphMetricsFT.cpp:443: error: `FTC_Image_Desc' undeclared (first use
this function)
I've tried hacking at it with gedit but I know nothing about c++ and I've only
got the patch for guidance so I've only succeeded in changing the error
I had this problem too -- I had to disable SVG.  And although the patch worked
on Firefox, it caused certain crashers in Mozilla (mail).  So in the end I
simply downgraded my Freetype to 2.1.7 and make do with hoping that the Freetype
interface gets unbroken, as this never should have happened anyway during a
stable release series...

*** Bug 247430 has been marked as a duplicate of this bug. ***
*** Bug 255259 has been marked as a duplicate of this bug. ***
The dependency on Freetype 2.1.7 should be mentioned in the build instructions
at http://www.mozilla.org/build/unix-details.html, with warnings that newer
versions will not work, similar to libIDL.
That's a good idea. I wrote to leaf (the author of the document) to add such a
warning. 

Those build instructions http://www.mozilla.org/build/unix-details.html seem to
be a bit out of date. They say libIDL-0.8.x won't work but I have no problem
building with libIDL-0.8.3. Same thing with autoconf - it says autoconf-2.5x
won't work but autoconf-2.59 doesn't give me any trouble
If freetype > 2.1.7 doesn't work, we should have a configure check to stop the
build.  People generally don't read the build instructions.

libIDL-0.8.x only works if you're building against gtk2. Are you actually using
autoconf-2.59 to regenerate mozilla/configure and running a full build or do you
just have it installed?  2.59 still fails to regenerate configure here.

libIDL-0.8.3 works for gtk1 if you make a symbolic link called
/usr/bin/libIDL-config pointing at /usr/bin/libIDL-config-2 . I think you're
probably right about autoconf, I either do ./configure, make or make -f client
make so maybe autoconf isn't used at all. 
I don't think a check in the configure script is the answer as the patch
http://bugzilla.mozilla.org/attachment.cgi?id=149334&action=view works and a
configure check would need to be removed by the patch. The Mozilla code needs to
be updated to live with the current tools people are using. It shouldn't stay
fixed in the past depending on legacy versions. Gnome and everything else on my
computer built cleanly with freetype-2.1.9. Nothing else needed patching. The
Mozilla code is the odd one out.
(In reply to comment #25)

> be updated to live with the current tools people are using. It shouldn't stay
> fixed in the past depending on legacy versions. 

  Not everyone is actively updating their libraries to the bleeding-edge
version. FC1 has FT 2.1.3 and FC2 has FT 2.1.7. I guess other major
distributions haven't updated their FT2 to 2.1.8 or newer, either.
  
> Gnome and everything else on my
> computer built cleanly with freetype-2.1.9. 

That doesn't say much. Most, if not all, of Gnome don't directly rely on
freetype. Pango takes a special measure to protect itself against the whim of
FT2 APIs (basically, it's statically linked against FT2)

> Nothing else needed patching. The
> Mozilla code is the odd one out.

Mozilla can be made to compile both with 2.1.7 or earlier and 2.1.8 or later
with #ifdef's. However, that doesn't solve the problem of Mozilla compiled with
one version of FT2 not being runnable where the other version of FT2 is
installed. If there's a way for that, let me know. 



FC3 will most likely have FT2 > 2.1.8 as Rawhide now contains 2.1.9.
I want some feedback as to how to proceed. We have three options:

1) keep our code as it is now and block building with FT 2.1.8 or later at the
configuration time : new Linux distribution users would suffer. Even if we do
this, this bug should be kept open because eventually more and more people will
have 2.1.8 or later. 

2) check the FT2 version at the configuration time and add #ifdef'd blocks so
that Mozilla will build with both FT <= 2.1.7 and FT >= 2.1.8. However, a binary
built with FT <= 2.1.7 won't run where FT >= 2.1.8 is installed and vice versa.
For instance, mozilla.org's tinder boxes have FT <= 2.1.7 so that nightlies
built there won't be run on upcoming FC3 with FT 2.1.9.  

3)  In addition to what we do at 2), add some wrappers over FT2 APIs so that a
binary built with FT <= 2.1.7 can be run where FT >= 2.1.8 is available and vice
versa (if it can be done with not much hassle)

4) statically build with libfreetype2 ......

What would you say?
I've started mozilla building with static FT 2.1.7. Is it's licence unrestrictive
enough to include the source tree into the mozilla source (just like XFree86
does) ? Ideally freetype.org developers shouldn't have changed their API without
bumping up the major version of the library. This is what library versioning
is for.
I see in-tree FT2 and static linking to be the only solution, personally. :(

The mostly-BSD-ish license looks amenable to this (but IANAL):
http://www.freetype.org/license.html


Oh, of course there is potentially another option: don't use FT2's glyph cache
at all (which in fairness they've always described as 'experimental' AFAICS).

Moz's codebase has its own tried-and-tested cache classes out of the wazoo I
think.  What's more, assuming that we end up shunting the glyph pixel data off
to belong to the X server (or other rendering device) eventually and that the X
server's capacity for glyphs is as large as we might want to cache, there's
probably no reason to keep the glyph pixel data around at the library or
application level at all, so we can save memory.

Another possible solution to the FreeType version madness would be compilation
with the latest release and runtime detection like this 1:

FT_Error   ftError;
FT_Library ftLibrary;
FT_Int     ftMajor, ftMinor, ftPatch;

ftError = FT_Init_FreeType(&ftLibrary);
FT_Library_Version(ftLibrary, &ftMajor, &ftMinor, &ftPatch);
*** Bug 258829 has been marked as a duplicate of this bug. ***
Why don't we just stick with stable apis?  Do we really need the caching apis?
current checkouts still don't work!!
though patch seems to be applied.

Did you apply the patch in comment #56 of this bug
http://bugzilla.mozilla.org/show_bug.cgi?id=190031#c56 and add this to your
mozconfig
ac_add_options --disable-freetype2
yes. tried a current checkout with and without patch.
and i always use --disable-freetype2.
i don't use any .mozconfig file.
The patch attached as FreeType-2.1.9.patch solved the compile issues I had with
mozilla-1.7.3 on slackware 8.0, gcc-3.4.2, glibc-2.3.2 and freetype-2.1.9
It seems that the current trunk source includes additional freetype2-related codes.
I had compile errors in nsFontMetricsPS.cpp, and manually modified it by
following the existing patch, but I couldn't get rid of this error.

  /usr/X11R6/include/freetype2/freetype/ftcache.h: in member function `virtual
     nscoord nsFontPSXft::GetWidth(const PRUnichar*, unsigned int)':
  /usr/X11R6/include/freetype2/freetype/ftcache.h:661: error: too few arguments
     to function `FT_Error FTC_ImageCache_Lookup(FTC_ImageCacheRec_*,
     FTC_ImageTypeRec_*, unsigned int, FT_GlyphRec_**, FTC_NodeRec_**)'
  nsFontMetricsPS.cpp:1155: error: at this point in file

Maybe this error is related to the things written in comment #14, but it is too
much for me because I have no experience in programming.
Could someone solve this problem?
Here is the patch I used to build recent trunk Firefox. However, now I got
segfault every time I print preview in nsFontPSXft::Init().
you can refer to the patch  bug
http://bugzilla.mozilla.org/show_bug.cgi?id=190031#c56

FTC_Manager_Lookup_Size() need be devided into two steps in FT2.1.8:
1. first do FTC_Manager_LookupSize()
2. then do FTC_Manager_LookupFace().

After do that, mozilla will not crash now.
Thanks, Ervin. Print Preview works fine now.
I tried to patch firefox 1.0pr sources and current cvs with patches available 
here and also with those from http://bugzilla.mozilla.org/show_bug.cgi?id=190031

Yup, at least it compiles.
But it seems that selecting Helvetica (or some other fonts) as standard serif 
font and exiting from firefox preferences is still enough to make it crash with 
the following:
/home/james/files/firefox/run-mozilla.sh: line 159:  4665 Segmentation fault     
 "$prog" ${1+"$@"}
Attachment #159821 - Attachment is obsolete: true
Here is updated patch I used to build my trunk Firefox. There is no problem so
far. I am sure about 1.0PR, but if it applied okay, should work as well.
I have a mozilla built from CVS on Oct 2.  I applied the patch from attachment
159281 [details] [diff] [review].  I am using freetype 2.1.9 and enabled gtk2 and xft.  The patch applied
fine and mozilla built without problems.  Whenver I try to click OK after
changing a font in edit -> preferences or whenever I visit certain webpages that
I frequent, mozilla segfaults with an error of "$prog" ${1+"$@"}.  Any ideas or
what else should I submit to help track this down?
Oops, I meant 159844 in the previous comment.
*** Bug 263199 has been marked as a duplicate of this bug. ***
patch works but printing to a file creates a coredump!

Any progress on this guys ?  Jungshik what's you decision on this ?
(In reply to comment #49)
> Which patch? Printing to a file works for me with a build patched with both
> https://bugzilla.mozilla.org/attachment.cgi?id=149334&action=view and
> https://bugzilla.mozilla.org/attachment.cgi?id=156865&action=view

second one with mozilla 1.8a4 release :-(
This patch https://bugzilla.mozilla.org/attachment.cgi?id=159844&action=view
solved my compilation problem in 1.8alpha4 please remove the other patches as
they are causing confusion and are out dated
to comment #52: This patch crashes my mozilla when I try to print :-(
I'm afraid that you are right. After recompiling I got seg faults when trying to
print. This happens all the time. I've created a trace and attached that to the
bug report.
After applying the patch as in comment 52 mozilla now crashes while trying to
print. A trace has been attached I hope this helps on the debugging of the
problem
I'm trying to implement what's suggested in comment #31 and comment #34. That
is, get rid of all the dependence on FT2 cache APIs. For the screen rendering,
it shouldn't make much difference in perf. because X server itself has caching
mechanism as suggested in comment #31. For printing, perf. shouldn't be much of
a concern in the first place. 

This should fix the problem for Xft + gtk2 (--enable-xft, --disable-freetype2)
that uses FT2 APIs only for printing.

I'll extend this to fix the problem for a build with freetype2 enabled.
In the previous patch, I forgot to get rid of a few lines of FT-cache related
member variables in nsFontMetricsPS.h
Attachment #162199 - Attachment is obsolete: true
Comment on attachment 162207 [details] [diff] [review]
fix v2 for Xft+gtk2 that should work for any version of FT2



>@@ -337,18 +337,16 @@ public:
> #endif
> 
>   nsXftEntry *mEntry;
>   FT_Face getFTFace();
> 
> protected:
>   PRUint16        mPixelSize;
>-  FTC_Image_Desc  mImageDesc;
>   FT_Library      mFreeTypeLibrary;
>   FTC_Manager     mFTCacheManager;
>-  FTC_Image_Cache mImageCache;

'FTC_Manager mFTCacheManager' should be removed as well.
With or without freetype2 enabled, printing works fine. However, with freetype
enabled, the screen rendering with FT2 doesn't work. For gtk2(+xft), this
doesn't matter because freetype is not used for the screen rendering.
Attachment #162207 - Attachment is obsolete: true
I've tested the patch in comment 58 and it works fine at first sight. Mozilla
also stopped crashing when doing any print related stuff. I'll test the newer
patch tomorrow.
I'm gonna fix this bug in two steps (and maybe one more step in which I'll add
caching if necessary). In the first step, I'll just fix gtk2+xft build which is
the default build option for firefox. It's also used by most Linux distribution
builders. This patch also includes the fix for gtk2 + xft.

In the second step, I'll fix x11core + freetype. Attachment 162239 [details] [diff] is my first
shot at that, but the screen rendering doesn't work while the printing works
fine. 

re: comment #61
Thanks for testing. You don't need to test attachment 162239 [details] [diff] [review] because you must
be building with gtk2=xft (otherwise, my previous patch wouldn't have changed
anything). This patch is almost identical to attachment 162207 [details] [diff] [review]. Nonetheless,
it'd be nice if you could test this with FT 2.1.8 or later.
Attachment #149334 - Attachment is obsolete: true
Attachment #159844 - Attachment is obsolete: true
Attachment #162239 - Attachment is obsolete: true
Comment on attachment 162261 [details] [diff] [review]
patch for gtk2+xft only 

asking for review.
Attachment #162261 - Flags: review?(Ervin.Yan)
I tested version 3 of the patch. It's working fine with Freetype-2.1.9 here on
linux from scratch. I also installed Slackware 10 so I could test it building
against freetype-2.1.7 and it works fine there too.
Now this works fine with my build with 'enable-freetype2' and FT 2.1.7 or
earlier, but it should work just fine with FT 2.1.8 or later because it doesn't
use any FT2 caching APIs.
Comment on attachment 162272 [details] [diff] [review]
patch part 2 (for builds with '--enable-freetype2' )

FYI, I could apply this patch to 1.7/1.0 aviary branch as well. I haven't tried
to build a branch build with this patch (I need to enable freetype2, but my
branch build is configured for gtk2+xft)
(In reply to comment #62)

> I'm gonna fix this bug in two steps (and maybe one more step in which I'll add
> caching if necessary). 

The last step (adding our own glyph caching) seems to be necessary. I've been
testing it with a debug build (with zillions of lines of debug output passing by
in my xterm) and the debug output kinda of hides the perf. degradation caused by
my patch (that does not use FT2 glyph caching any more). When I made an
optimized build, the perf. difference became too obvious to miss. It may not be
so conspicuous when printing non-CJK pages, though.  Even for CJK pages, it's
still 'tolerable' (it's only for printing as far as the patch for gfx2+xft is
concerned). It's rather simple to add our own glyph caching, but I'd rather get
attachment 162261 [details] [diff] [review] checked in first before adding it (which I expect to be able
to work on next weekend)
I'm currently testing patch 8&9 combined and all works fine so far. I've tried
to compile gnome with xft and freetype2 but the ./configure script doesn't allow
for this. So I'm running with xft only for now.
confirming. both patches works ok on Slack current (10+)
I'm not all that concerned about printing performance, as long as we're not
talking minutes.  I think that working slowly is better than not working faster.
Comment on attachment 162261 [details] [diff] [review]
patch for gtk2+xft only 

asking for r/sr. 
I'm not concerned about the printing perf.  much either. I planned to work on
it this weekend, but I'm afraid I can't. I'll next week when I'll also try to
fix SVG.
Attachment #162261 - Flags: superreview?(dbaron)
Attachment #162261 - Flags: review?(blizzard)
Attachment #162261 - Flags: review?(Ervin.Yan)
current firefox checkout, patch 162261:

CC -o nsPostScriptObj.o -c -DOSTYPE=\"IRIX6\" -DOSARCH=\"IRIX\"
-DHAVE_DEPENDENT_LIBS -I../.. -I../../../../mozilla/gfx/src/ps/.. 
-I../../../../mozilla/gfx/src/ps/../shared -I../../../dist/include/xpcom
-I../../../dist/include/string -I../../../dist/include/widget
-I../../../dist/include/pref -I../../../dist/include/caps
-I../../../dist/include/locale -I../../../dist/include/uconv
-I../../../dist/include/view -I../../../dist/include/necko
-I../../../dist/include/imglib2 -I../../../dist/include/unicharutil
-I../../../dist/include/gfx -I../../../dist/include
-I/mnt/3/moz/obj2/dist/include/nspr     -I. -I/usr/nekoware/include
-I/usr/nekoware/include/freetype2      -KPIC  -I/usr/local/include
-I/usr/nekoware/include  -LANG:exceptions=OFF -woff 3262 -G 4 -n32  -DNDEBUG
-DTRIMMED -O3 -I/usr/nekoware/include/glib-2.0
-I/usr/nekoware/lib/glib-2.0/include -I/usr/nekoware/include/pango-1.0
-I/usr/nekoware/include -I/usr/nekoware/include/freetype2
-I/usr/nekoware/include/gtk-2.0 -I/usr/nekoware/include/atk-1.0
-I/usr/nekoware/lib/gtk-2.0/include    -I/usr/local/include
-I/usr/nekoware/include  -DMOZILLA_VERSION=\"1.8a5\" -DIRIX=1
-DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DSTDC_HEADERS=1
-DHAVE_ST_BLKSIZE=1 -DHAVE_SIGINFO_T=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1
-DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1
-DHAVE_DIRENT_H=1 -DHAVE_GETOPT_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1
-DHAVE_NL_TYPES_H=1 -DHAVE_MALLOC_H=1 -DHAVE_X11_XKBLIB_H=1
-DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_CDEFS_H=1 -DHAVE_LIBM=1
-DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 -DFUNCPROTO=15 -DHAVE_XSHM=1 -DHAVE_RANDOM=1
-DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1
-DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_STAT64=1 -DHAVE_LSTAT64=1
-DHAVE_FLOCKFILE=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STRTOK_R=1
-DHAVE_LANGINFO_CODESET=1 -DHAVE_I18N_LC_MESSAGES=1
-DMOZ_DEFAULT_TOOLKIT=\"gtk2\" -DMOZ_WIDGET_GTK2=1 -DMOZ_ENABLE_XREMOTE=1
-DMOZ_X11=1 -DMOZ_DISTRIBUTION_ID=\"org.mozilla\" -DMOZ_PHOENIX=1
-DMOZ_XUL_APP=1 -DMOZ_APP_NAME=\"firefox\" -DMOZ_ENABLE_XFT=1
-DMOZ_ENABLE_COREXFONTS=1 -DMOZ_EXTRA_X11CONVERTERS=1 -DOJI=1 -DIBMBIDI=1
-DMOZ_VIEW_SOURCE=1 -DACCESSIBILITY=1 -DMOZ_XPINSTALL=1 -DMOZ_JSLOADER=1
-DHAVE_GSSAPI_GSSAPI_H=1 -DMOZ_MATHML=1 -DMOZ_LOGGING=1
-DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DMOZ_PROFILELOCKING=1
-DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1
-DNS_PRINT_PREVIEW=1 -DNS_PRINTING=1 -DMOZ_ACCESSIBILITY_ATK=1
-DMOZILLA_LOCALE_VERSION=\"1.8a\" -DMOZILLA_REGION_VERSION=\"1.8a\"
-DMOZILLA_SKIN_VERSION=\"1.5\"  -D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT
../../../../mozilla/gfx/src/ps/nsPostScriptObj.cpp
cc-1253 CC: WARNING File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.h,
Line = 289
  The declaration of a member with the same name as its class is invalid.

    nsFontPS   *fontps;
                ^

cc-1552 CC: WARNING File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.cpp,
Line = 947
  The variable "rv" is set but never used.

          nsresult rv;
                   ^

cc-1020 CC: ERROR File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.cpp,
Line = 1064
  The identifier "nsXftFaceRequester" is undefined.

    fterror = FTC_Manager_New(mFreeTypeLibrary, 0, 0, 0, nsXftFaceRequester,
                                                         ^

cc-1552 CC: WARNING File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.cpp,
Line = 1360
  The variable "leading" is set but never used.

    nscoord leading, emHeight, emAscent, emDescent;
            ^

cc-1253 CC: WARNING File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.h,
Line = 289
  The declaration of a member with the same name as its class is invalid.

    nsFontPS   *fontps;
                ^

cc-1020 CC: ERROR File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.cpp,
Line = 2412
  The identifier "nsXftFaceRequester" is undefined.

    error = FTC_Manager_New(mFreeTypeLibrary, 0, 0, 0, nsXftFaceRequester,
                                                       ^

2 errors detected in the compilation of
"../../../../mozilla/gfx/src/ps/nsFontMetricsPS.cpp".
gmake[4]: *** [nsFontMetricsPS.o] Error 2
gmake[4]: *** Waiting for unfinished jobs....
gmake[4]: Leaving directory `/mnt/3/moz/obj2/gfx/src/ps'
did you apply the patch at all? If you did, how come you got an error like this? 

 The identifier "nsXftFaceRequester" is undefined.

    fterror = FTC_Manager_New(mFreeTypeLibrary, 0, 0, 0, nsXftFaceRequester,

Note that the line was removed by my patch.

(In reply to comment #73)
> did you apply the patch at all? If you did, how come you got an error like this? 
> 
>  The identifier "nsXftFaceRequester" is undefined.
> 
>     fterror = FTC_Manager_New(mFreeTypeLibrary, 0, 0, 0, nsXftFaceRequester,
> 
> Note that the line was removed by my patch.
> 

sure i did.
checked out before, applied the patch and made a firefox.
anyway, trying 1.8a4 at the moment. let's see...

I checked out aviary branch @ Mon Oct 25 20:09:33 CDT 2004, applied patch 8 and
I get these failures:
Hunk #1 FAILED at 1024.
Hunk #2 FAILED at 1045.
Hunk #3 FAILED at 1114.
Hunk #4 FAILED at 2377.
4 out of 4 hunks FAILED -- saving rejects to file gfx/src/ps/nsFontMetricsPS.cpp.rej
patching file gfx/src/ps/nsFontMetricsPS.h
Hunk #1 FAILED at 337.
Hunk #2 FAILED at 471.
2 out of 2 hunks FAILED -- saving rejects to file gfx/src/ps/nsFontMetricsPS.h.rej

I've been using the same commands as in the past to apply the patch with no
problem. First I saw this was about 3 days ago I think.
Comment on attachment 162261 [details] [diff] [review]
patch for gtk2+xft only 

Jshin, this patch look OK for me. I test it to print 27000 Chinese characters
with GB18030 encoding, the performance seems not regressive.

sorry for late reply.
Comment on attachment 162261 [details] [diff] [review]
patch for gtk2+xft only 

Ervin, thanks for testing.  Can you add 'r' flag to this patch? 

In my test, the perf. loss couldn't be missed although tolerable. Perhaps,
we're just applying slightly different metrics to the same phenonmenon :-).
Anyway,  if there's any need to deal with perf., I'll do it after landing this.
Attachment #162261 - Flags: review?(blizzard) → review?(Ervin.Yan)
jshin: I have no permission to edit the attachment 162261 [details] [diff] [review].

maybe you need ask someone else to give "r=" flag for your this patch.
Ervin, can you go through the patch to see if there's anything wrong and let me
know the result? Then, I'll flag it per your review. 

Asking for consideration here: Firefox 1.0 will fail to compile on FC3 and RHEL4
without this bug fixed.
Flags: blocking-aviary1.0?
(In reply to comment #80)
> Asking for consideration here: Firefox 1.0 will fail to compile on FC3 and RHEL4
> without this bug fixed.

As I wrote in my reply to your query a week ago, that's not the case (although I
like to fix this bug asap and like to get your support :-)) *unless* you want to
compile with '--enable-freetype2'. (So far, RedHat hasn't enabled freetype2 in
any of Mozilla builds made for RHEL and FCs). Note that my patch for bug 190031
hasn't been landed in aviary-1.0/mozilla 1.7 branches so that you don't need
attachment 162261 [details] [diff] [review].

(In reply to comment #80)
> Asking for consideration here: Firefox 1.0 will fail to compile on FC3 and RHEL4
> without this bug fixed.

That may be so, but even without the fix, the binaries provided by mozilla.org
will run just fine on FC3, won't they? If so, then I don't see why this bug
should be a blocker.

It should be high priority (for the reason you mentioned), but not a blocker, IMO.
> *unless* you want to compile with '--enable-freetype2'.

note that this is the default...
(In reply to comment #83)
> > *unless* you want to compile with '--enable-freetype2'.
> 
> note that this is the default...

Actually, RedHat has always compiled their Mozilla builds with
'--disable-freetype2'. So what I meant was that 'unless  you enable freetype2 by
not adding '--enable-freetype2'. 
(In reply to comment #84)
> '--disable-freetype2'. So what I meant was that 'unless  you enable freetype2 by
> not adding '--enable-freetype2'. 
You mean --disable-freetype2


jshin, I have go through the patch in attachment 162261 [details] [diff] [review], they are all OK for me.
Thanks.
Comment on attachment 162261 [details] [diff] [review]
patch for gtk2+xft only 

flagging with 'r' per Ervin's review. (thanks).
Attachment #162261 - Flags: review?(Ervin.Yan) → review+
Ervin, can you also test 'patch part2' (for builds with '--enable-freetype2')
attachment 162272 [details] [diff] [review]? I ran out of the disk space to build an optimized build with
freetype2 enabled. (as I wrote before, with a debug build, it's sorta hard to
tell the perf. loss). This patch affects the screen rendering (which is more
critical than printing) as well. Well, not many people are interested in
freetype builds any more. Nonetheless, I don't wanna make it regress perf-wise . 
got the following with a current firefox checkout (normal head, not aviary):

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|? gfx/src/ps/.nsType8.cpp.swp
|? gfx/src/ps/UnBatang.raw
|? gfx/src/ps/nsType8.cpp.new
|? gfx/src/ps/output.ps
|Index: gfx/src/ps/nsFontMetricsPS.cpp
|===================================================================
|RCS file: /cvsroot/mozilla/gfx/src/ps/nsFontMetricsPS.cpp,v
|retrieving revision 1.45
|diff -u -7 -p -r1.45 nsFontMetricsPS.cpp
|--- gfx/src/ps/nsFontMetricsPS.cpp     20 Aug 2004 09:11:25 -0000      1.45
|+++ gfx/src/ps/nsFontMetricsPS.cpp     15 Oct 2004 22:55:11 -0000
--------------------------
Patching file gfx/src/ps/nsFontMetricsPS.cpp using Plan A...
Reversed (or previously applied) patch detected!  Assume -R? [y] n
Apply anyway? [n] 
Hunk #1 ignored at 1024.
Hunk #2 ignored at 1045.
Hunk #3 ignored at 1114.
Hunk #4 ignored at 2377.
4 out of 4 hunks ignored--saving rejects to gfx/src/ps/nsFontMetricsPS.cpp.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: gfx/src/ps/nsFontMetricsPS.h
|===================================================================
|RCS file: /cvsroot/mozilla/gfx/src/ps/nsFontMetricsPS.h,v
|retrieving revision 1.26
|diff -u -7 -p -r1.26 nsFontMetricsPS.h
|--- gfx/src/ps/nsFontMetricsPS.h       20 Aug 2004 09:11:25 -0000      1.26
|+++ gfx/src/ps/nsFontMetricsPS.h       15 Oct 2004 22:55:12 -0000
--------------------------
Patching file gfx/src/ps/nsFontMetricsPS.h using Plan A...
Hunk #1 failed at 337.
Hunk #2 failed at 471.
2 out of 2 hunks failed--saving rejects to gfx/src/ps/nsFontMetricsPS.h.rej
done
jshin: I will test the patch part2 these days and give you the result.
we may be able to add this to the branch after 1.0 but the patch is large and
we're not going to block on this. distributors are encouraged to add this or
similar patch to their builds if needed.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Attachment #162261 - Flags: superreview?(dbaron) → superreview?(bryner)
*** Bug 257160 has been marked as a duplicate of this bug. ***
Attachment #162261 - Flags: superreview?(bryner) → superreview+
attachment 162261 [details] [diff] [review] was landed. 
*** Bug 262263 has been marked as a duplicate of this bug. ***
Comment on attachment 162272 [details] [diff] [review]
patch part 2 (for builds with '--enable-freetype2' )

FYI, this patch fixes my builds on Fedora Core 3 w/2.6.9 kernel.
Comment on attachment 162272 [details] [diff] [review]
patch part 2 (for builds with '--enable-freetype2' )

According to my *very unscientific* test (just browsing a dozen web sites in
English, Chinese, Japanese, and Korean) with and without this patch, we don't
have to worry about perf. loss much. I'll take a profile with and without the
patch.
*** Bug 271761 has been marked as a duplicate of this bug. ***
I finally took profiles of two optimized builds (one with and the other without
attachment 162272 [details] [diff] [review] applied. actually, I was leaking mFace so that I filled it
up). With the patch applied (no glyph image  cache utilized), about a fifth of
the total running time was spent in nsFreeTypeXImage::DrawString() (and
functions called by it) while the figure is about 5% without the patch. A
similar increase (3% -> 12%) was observed for nsFreeTypeFont::GetWidth. In both
cases, LoadGlyph() was responsible for about 90% of time. So, glyph image
caching is rather critical.

Here comes my dillemma. Given that these days few Linux users use X11core+FT2
builds, is it worth adding our own glyph caching? 

for the record, I'm uploading the profiling results with and without attachment
162272 [details] [diff] [review] applied.
Flags: blocking1.8b?
This patch (part 2) fixes build on Slackware current.
Flags: blocking1.8b? → blocking1.8b-
Asa: why? 
This is a ready to go patch, fixing the bug, and it would be great to have it
for beta cycle to test if this will not regress.
I can't find any reason to leave this not checked in :(
it doesn't have reviews, and there seems to be some severe perf issues
associated with the patch, isn't that reason enough?
On a 'modern' machine, it's not so noticable (before taking a profile, I didn't
notice it on my P3 800MHz, 512MB). Anway, I rolled out my own 'glyph/font
cache', but have had a trouble making it work right. Actually, Mozilla keeps
crashing in ft_new_glyph() with my patch (not uploaded).   I'll try to get this
done before 1.8beta...

asa, how much do we care about the perf. of X11core/freetype2 build (on Linux)?
On linux, only few would use such a build these days (well, some people don't
like Xft) although it's still the default build config for the suite. [1] Is it
important to embedders? If not, we may just go ahead with the current patch
pending r/sr (I'll ask for r/sr later if we decide we don't care about the perf.)

[1] With dbaron's recent fix of a long standing Xft-build crash, it may be
finally time to switch to Xft.
Target Milestone: --- → mozilla1.5alpha
*** Bug 281166 has been marked as a duplicate of this bug. ***
(In reply to comment #104)
> *** Bug 281166 has been marked as a duplicate of this bug. ***

Well, but _Sunbird_ fails to *run* on a FT 2.1.8 machine while here's we talk
only about _Firefox_ fails to *compile*.


*Birds, FF, and Mozilla suite all share the same Gfx code. Note that this bug is
filed under 'Core : Gfx'. 

The issue in both cases is that we use freetype APIs that aren't available any
longer on some systems.  Whether we detect it at compile time or runtime is not
really interesting here.

Is "patch part 2" obsolete, here, or should it have review requests associated
with it?
It still works, but I'm waiting for some 'policy' input from drivers or some
people like that. See comment #98 and comment #103.

If you have questions for drivers, you're best to mail drivers@mozilla.org;
bugmail's a bad way to get policy issues discussed properly.
(In reply to comment #107)
> The issue in both cases is that we use freetype APIs that aren't available any
> longer on some systems.  Whether we detect it at compile time or runtime is not
> really interesting here.

But why does a Thunderbird 1.0 binary print without problems where a Sunbird 0.2
binary does "crash"?


Because they're different from different branch-points, I suspect.  Reading the
code might tell you more; I'm relatively confident that this bug is isomorphic
to the one I dup'd here.
(In reply to comment #111)
> Because they're different from different branch-points, I suspect.  Reading the
> code might tell you more; I'm relatively confident that this bug is isomorphic
> to the one I dup'd here.

Yes, I share your opinion.

But: It might be that Sunbird and Thunderbird/Firefox use different compile
options so that changing the compile options in Sunbird can solve the bug for
the user temporaraly. 

If I look at the first reporting date, I'll suspect that the bug will be fixed
in ~ 2 month. :(
(In reply to comment #111)
> Because they're different from different branch-points, I suspect.  

TB 1.0 is built with gtk2 + xft and it doesn't rely on FT2 at all. Freetype
printing in gtk2+xft was added in bug 190031 after aviary 1.0 branch was cut in
last May. As for SB 0.2, there are two possibilities. If it's built with gtk1 +
freetype2, it'll be fixed by my patch part2. If it's built with gtk2+xft, but
still has a problem with freetype printing, it's probably because it's built
before my patch part1 - attachment 162261 [details] [diff] [review] (that fixed the problem with FT2
printing in gtk2+xft) was checked in 

> Reading the code might tell you more; I'm relatively confident that this bug
is isomorphic
> to the one I dup'd here.

Yes, you're absolutely right. Bug 281166 is a dupe of this bug whichever (of two
possibilites mentioned above) may be the case. In both cases, one can work
around the problem by disabling freetype printing (go to 'about:config', look
for 'freetype' and you'll see which pref. to set to false).
 
re comment #109 : yeah, I know. I was kinda lazy. I wrote to drivers@....

Comment on attachment 162272 [details] [diff] [review]
patch part 2 (for builds with '--enable-freetype2' )

This patch is starting to suffer from bitrot.
*** Bug 284763 has been marked as a duplicate of this bug. ***
*** Bug 284942 has been marked as a duplicate of this bug. ***
*** Bug 288882 has been marked as a duplicate of this bug. ***
What is the status of this bug? I failed to build Mozilla Suite 1.7.6 with
Freetype 2.1.9. I can attach the build log from my own mozilla build script if
necessary.

Does a GTK2+Xft2 build also needs a patch? My (need to be updated) Firefox build
is GTK+Xft2 and did not suffer from the FT2 2.1.4 to 2.1.9 migration, unlike my
Seamonkey 1.7.5 (which is GTK1+Freetype2) where I lost the font anti-aliasing.

I have to update as soon as possible (security!) and I cannot use the official
binaries because I changed a lot of things on my Linux system.
(In reply to comment #118)

> Does a GTK2+Xft2 build also needs a patch? My (need to be updated) 

No, it doesn't. The necessary patch (attachment 162261 [details] [diff] [review]) has already been landed.
Mozilla 1.7.6/Firefox 1.0.x don't have that patch (because it's not necessary)
but should be fine if gtk2+xft is used instead of the default gtk1+freetype2+X11. 




This patch modifies the mozilla-1.7.7 release to use freetype 2.1.8 as provided
with X-4.5.0.  I have run it for a day and it seems OK but of course it needs
more testing.  The patch also modifies the svg renderer interface file that
comes with the release. but because libart is not included, I can't test this
at all.  It may not even compile.  Sorry, but I just don't have time to mess
with the CVS version.  Apply the patch from the top level mozilla directory
with -p1.
(In reply to comment #120)
> Created an attachment (id=181857) [edit]
> Freetype 2.1.8 patch for mozilla 1.7.7
> 
> This patch modifies the mozilla-1.7.7 release to use freetype 2.1.8 as provided
> with X-4.5.0.  I have run it for a day and it seems OK but of course it needs

Thanks for the patch, but your approach has already been tried. Due to the
incompatible change made by freetype folks, we have some headache here and I
decided to take a different approach.  See comment #28 and comment #62 (and
other related comments). 

Anyway, it's not a high priority item any more because we chagned the default
build option to gtk2 + xft even for suite. Firefox had been built with gtk2+xft
for a while when we switched. 



It is my understanding that the X guys plan to eliminate Xft in upcoming
releases in favor of freetype.  That was my main motivation for fixing this
now.  

As has already been pointed out, the freetype guys have made the serious
error of changing the ABI without changing the libfreetype version number. 
This has been further compounded by the release of X-4.5.0 with freetype
2.1.8.  The previous version X-4.4.0 had freetype 2.1.4 with the old ABI. 
So now we're stuck with incompatible versions of libfreetype.so.6, depending
on which version of X is installed.

If Xft disappears, it seems to me that until the libfreetype version issue
is resolved the only viable solution for binary releases to the general
public is to statically link libfreetype.  At least with this patch, you can
statically link a newer version.

Static linking of included source can be set as the build default in the
source package, with an option to use the system libfreetype.  If this
option is selected, the configure script tests for a compatible version of
libfreetype on the system and dies if it is not available.  As time passes
and systems are upgraded, the problem will go away (assuming the freetype
guys refrain from introducing more ABI changes under libfreetype.so.6).

Yours,
Joseph

(In reply to comment #122)
> It is my understanding that the X guys plan to eliminate Xft in upcoming
> releases in favor of freetype.  That was my main motivation for fixing this
> now.  

That doesn't make sense.  They're not competitors; they're different layers. 
(As I understand it, Freetype deals with font data, Xft deals with doing
client-side font rendering, and fontconfig deals with finding fonts.)
(In reply to comment #122)
> It is my understanding that the X guys plan to eliminate Xft in upcoming
> releases in favor of freetype.  That was my main motivation for fixing this
> now.  

Where did you hear that? As David wrote, it doesn't make any sense. 
OK, I misread the documentation and the comment above is silly.  Moreover, had I
not gotten confused in this way, I would never have bothered to make this patch.
 Sorry for the noise.  Do with the patch as you see fit.

However, doing font rendering without Xft does make sense.  Xft is a wrapper
around freetype, fontconfig, and Xrender.  The freetype cache issue aside, it is
probably just as easy to access fontconfig directly to select fonts, and to
render glyphs directly with freetype.  One then has the option of composing an
image with the resulting bitmap/graymap using Xrender, or to just pass it to
core X when that isn't necessary.
(In reply to comment #125)
> One then has the option of composing an
> image with the resulting bitmap/graymap using Xrender, or to just pass it to
> core X when that isn't necessary.

...which is a lot of code.  It's also already been written in a library called Xft.
Since it seems that no one has mentioned it, I wish to report that Firefox 1.0.4
seems to be no longer compilable with Freetype2 "9.7.3", with the same symptoms;
the patch also fails to apply. (Mozilla 1.0.0 was compilable.)
*** Bug 294883 has been marked as a duplicate of this bug. ***
Hello, all:

I am compiling mozilla 1.7.8 in my FreeBSD 5.3 (i386), in which FreeType 2.1.9 
is installed. 

There are so many patches here. Which one shall I apply?

If I want to build with the option "--enable-default-toolkit=gtk2 --enable-xft -
-enable-freetype2", does that mean I must apply "patch for gtk2+xft only" 
(162261) and "patch part 2 (for builds with '--enable-freetype2' )" (162272)?

Or just one of them is enough?

I am really lossed in this long thread. 

Thank you,
(In reply to comment #129)
> If I want to build with the option "--enable-default-toolkit=gtk2 --enable-xft -
> -enable-freetype2", does that mean I must apply "patch for gtk2+xft only" 
> (162261) and "patch part 2 (for builds with '--enable-freetype2' )" (162272)?
You can not enable xft and freetype2 at the same time.


(In reply to comment #130)
> You can not enable xft and freetype2 at the same time.

I know this should be a separate bug, but as recent as 1.0.0 this was "possible"
(i.e., it did not generate compile time errors).

(In reply to comment #132)
> 1.0.x is not "recent"

What do you mean by that? The most current version is 1.0.4 but 1.0.x is "not
recent"?

We can't have the case where the most recent version is not recent!
(In reply to comment #133)
> (In reply to comment #132)
> > 1.0.x is not "recent"
> 
> What do you mean by that? The most current version is 1.0.4 but 1.0.x is "not
> recent"?

1.0.4 is the most recent *released* version, but the development efforts are put
on the trunk. 1.0.x branched off the trunk more than a year ago. 

Anyway, you're right that it's possible to have both xft and freetype for 1.0.x
branch. The patch to block freetype from being enabled with xft+gtk2 was landed
only on the trunk. (for bug 190031)

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla&command=DIFF_FRAMESET&file=configure.in&rev2=1.1361&rev1=1.1360

Anyway, can you tell me why you wanna enable freetype for gtk2+xft? Is it for
printing? Then, I'll tell you what patches to apply (there are a few patches to
apply)
(In reply to comment #134)
> Anyway, can you tell me why you wanna enable freetype for gtk2+xft? Is it for
> printing? Then, I'll tell you what patches to apply (there are a few patches 
to
> apply)

Actually, I don't mind whether freetype2 is enabled or not. What I care is to 
successfully compile mozilla 1.7.8 by the option "--enable-default-
toolkit=gtk2 --enable-xft". 

Can you tell me which patch(es) I should apply to the src?

Thanks,
(In reply to comment #135)
> Actually, I don't mind whether freetype2 is enabled or not. What I care is to 
> successfully compile mozilla 1.7.8 by the option "--enable-default-
> toolkit=gtk2 --enable-xft". 
> Can you tell me which patch(es) I should apply to the src?

Btw, my OS is FreeBSD 5.3 (i386), on which FreeType 2.1.9 was installed before. 

With the above mentioned configure options, I compiled the src and met the 
following error: 

------------------------------------------------
In file included from nsFreeType.h:39,
                 from nsFreeType.cpp:48:
../../../dist/include/gfx/nsIFreeType2.h:53: error: `GetImageCache' declared as 
a `virtual' field
...[snipped]
nsFreeType.cpp:392: error: `FTC_Image_Cache' was not declared in this scope
nsFreeType.cpp:392: error: `aCache' was not declared in this scope
nsFreeType.cpp:393: error: expected `,' or `;' before '{' token
nsFreeType.cpp: In member function `void nsFreeType2::ClearGlobals()':
nsFreeType.cpp:429: error: `mImageCache' undeclared (first use this function)
nsFreeType.cpp:429: error: (Each undeclared identifier is reported only once 
for each function it appears in.)
nsFreeType.cpp: In member function `PRBool nsFreeType2::InitLibrary()':
nsFreeType.cpp:668: error: `mImageCache' undeclared (first use this function)
gmake[4]: *** [nsFreeType.o] Error 1
gmake[4]: Leaving directory `/usr/src/mozilla/gfx/src/freetype'
gmake[3]: *** [libs] Error 2
gmake[3]: Leaving directory `/usr/src/mozilla/gfx/src'
gmake[2]: *** [libs] Error 2
gmake[2]: Leaving directory `/usr/src/mozilla/gfx'
gmake[1]: *** [tier_9] Error 2
gmake[1]: Leaving directory `/usr/src/mozilla'
gmake: *** [default] Error 2
------------------------------------------------

Pls advise me on which patch(es) to apply, 

Thanks. 
I've already answered off-line, but to prevent others from asking the same
question again (in addition, because the build document, having been revised for
the trunk, doesn't mention about this), I'll answer here. If you don't care
about printing in gtk2+xft, just disable freetype2 using '--disable-freetype2'
(in mozconfig, it's 'ac_add_options --disable-freetype2'). You don't need any
patch for the 1.0.x/1.7.x branches. 
(In reply to comment #137)
> I've already answered off-line, but to prevent others from asking the same
> question again (in addition, because the build document, having been revised for
> the trunk, doesn't mention about this), I'll answer here. If you don't care
> about printing in gtk2+xft, just disable freetype2 using '--disable-freetype2'
> (in mozconfig, it's 'ac_add_options --disable-freetype2'). You don't need any
> patch for the 1.0.x/1.7.x branches. 

(I'm attempting to compile Firefox 1.0.4 so I can try to implement a fix to the
old "geometry" resource problem--hopefully in a way that can be accepted into
the code base.)

Does disabling freetype2 prevent any printing, assuming the default toolkit is
gtk2/xft, or is the impact less severe that that?

I do need to print, but if the only impact is that the characters might have
slightly different appearance and/or spacing, I could live with that.
(In reply to comment #138)

> Does disabling freetype2 prevent any printing, assuming the default toolkit is
> gtk2/xft, or is the impact less severe that that?

It doesn't unless you  need to print characters other than Latin. Non-latin
characters can be printed, too, but the result is not so good. Anyway, those who
care about that can apply my latest patch to bug 215219 to 1.0.x branch source.
(it does more than just enabling a better quality printing)


These patches are not meeting this problem.  With the freetype2 build they    
disable the lib when >2.1.8 is used and with <2.1.8 they cause anomalies. I   
dont think its fair to really say the issue is the versioning (I assume you   
expect them to call this freetype3) when the makefile doesnt actually use the  
the freetype-config it calls.  Freetype is a non-issue for every other build  
that uses it and can be built w/ either version.  The major action of the lib  
has not as far as I understand, only the names of a couple functions.  It takes  
a real CS to jam up a major project that has enough headaches as is for written  
code as piddly as freetype is.  
> only the names of a couple functions

AIUI the functions were removed, not renamed
*** Bug 301051 has been marked as a duplicate of this bug. ***
Hi,

I'm having a problem with the freetype apparently asswell. I get the following
message when compliling:


In file included from
/home/cputter/Sandbox_Alpha/mozilla/gfx/src/ps/nsDeviceContextPS.h:50,
                 from
/home/cputter/Sandbox_Alpha/mozilla/gfx/src/ps/nsDeviceContextPS.cpp:55:
/home/cputter/Sandbox_Alpha/mozilla/gfx/src/ps/nsFontMetricsPS.h:344: error: '
   FTC_Image_Desc' is used as a type, but is not defined as a type.
/home/cputter/Sandbox_Alpha/mozilla/gfx/src/ps/nsFontMetricsPS.h:347: error: '
   FTC_Image_Cache' is used as a type, but is not defined as a type.
/home/cputter/Sandbox_Alpha/mozilla/gfx/src/ps/nsFontMetricsPS.h:481: error: '
   FTC_Image_Desc' is used as a type, but is not defined as a type.
gmake[5]: *** [nsDeviceContextPS.o] Error 1
gmake[5]: Leaving directory
`/home/cputter/Sandbox_Alpha/mozilla/objdir-x86_64-linux-gnu/gfx/src/ps'
gmake[4]: *** [libs] Error 2
gmake[4]: Leaving directory
`/home/cputter/Sandbox_Alpha/mozilla/objdir-x86_64-linux-gnu/gfx/src'
gmake[3]: *** [libs] Error 2
gmake[3]: Leaving directory
`/home/cputter/Sandbox_Alpha/mozilla/objdir-x86_64-linux-gnu/gfx'
gmake[2]: *** [tier_9] Error 2
gmake[2]: Leaving directory
`/home/cputter/Sandbox_Alpha/mozilla/objdir-x86_64-linux-gnu'
gmake[1]: *** [default] Error 2
gmake[1]: Leaving directory
`/home/cputter/Sandbox_Alpha/mozilla/objdir-x86_64-linux-gnu'
gmake: *** [build] Error 2


I'm running Suse 9.3, on Athlon 64.  Here's my mozconfig file:

#
# See http://www.mozilla.org/build/ for build instructions.
#

# Options for client.mk.
mk_add_options MOZ_CO_PROJECT=calendar
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-x86_64-linux-gnu

# Options for 'configure' (same as command-line options).
ac_add_options --enable-application=calendar

ac_add_options --disable-mailnews
ac_add_options --disable-tests
ac_add_options --enable-optimize
ac_add_options --enable-static
ac_add_options --disable-debug
ac_add_options --disable-shared


ac_add_options --enable-plaintext-editor-only
ac_add_options --enable-necko-protocols=about,http,ftp,file,jar,res
ac_add_options --enable-storage
ac_add_options --disable-accessibility
ac_add_options --disable-activex
ac_add_options --disable-activex-scripting
ac_add_options --disable-installer
ac_add_options --disable-jsd
ac_add_options --disable-mathml
ac_add_options --disable-necko-disk-cache
ac_add_options --disable-oji
ac_add_options --disable-view-source
ac_add_options --disable-logging
ac_add_options --disable-plugins
ac_add_options --disable-cookies

ac_add_options --enable-default-toolkit=gtk2
ac_add_options --disable-freetype2
ac_add_options --enable-xft


Is this related to the same bug, or something totally different?
Product: Core → Core Graveyard
the third patch from the top works well with 1.5.0.12 final (17.26 KB)
only required one minor correction and that was all
We now bundle a much later version of Freetype (2.4.6) so I believe this has been fixed.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: