Apache OpenOffice (AOO) Bugzilla – Issue 6630
Support for freetype 2.1.x in gcach_ftyp.cxx
Last modified: 2003-02-13 13:08:59 UTC
[CCing to hdu based on CVS commit log for this file] In an attempt to compile OOo against the system libfreetype in Debian, I discovered some (internal!) macros have changed name. This patch changes the macro names used to the new names, while maintaining compatibility with the old libfreetype by #defining the macros using the old names if the new names do not exist. The patch does not actually make OOo work yet with the new libfreetype, due to what appears to be a bug in freetype itself. I was able to confirm that this patch does not break the OOo code by using LD_PRELOAD to test the built OOo against the older libfreetype.
Created attachment 2381 [details] Patch as used in Debian package
See also issue 6562 for a similar patch. Thanks a lot for the patch. We plan to upgrade soon for a lot of reasons but one has to be very careful, e.g. because new versions sometimes also have regressions, e.g. 2.1.2 is reported to have regressions like problems with text rotation and symbol display. We also need to be careful with synchronizing the update in vcl with the external project http://external.openoffice.org
Oops, I missed 6562, which does the same thing but uses the freetype version instead, sorry. > We also need to be careful with synchronizing the update > in vcl with the external project http://external.openoffice.org The reason for supplying you a patch in this form is that it can be applied well in advance of an update with the external project without breaking anything, and allowing people who are experimenting with replacing the freetype library with the system version, such as the Linux Distros, to compile vcl with both the new and old freetype version. The update in external can then be carried out in the future when the regression issues are fixed, without needing to synchronise with vcl. We are building packages for Debian with this patch applied, but using the internal libfreetype version since we have the same regression problems.
Good point. My top priority is the next SO milestone though and I cannot risc a regression at this point in time. An alternative would be branching, tagging it for OOo and merge later. I doubt this alternative would be worth the extra trouble.
Ah, fine - I wasn't aware of a looming SO milestone. Do you have an approximate timescale of that, or somewhere where I should have seen that, so I don't go pestering other developers with issues who are involved in a similar freeze? I'll just point people building OOo to this issue in the meantime.
> Do you have an approximate timescale of that, > or somewhere where I should have seen that Followups by private mail.
By the way, I couldn't find your name on the list of copyright-approved people: http://www.openoffice.org/copyright/copyrightapproved.html Before we can accept patches >=10 lines into OOo's CVS you should consider signing up at http://www.openoffice.org/contributing.html
Hi, update on this one. I'm on the JCA list now, and the problem with freetype has been fixed in their CVS. Can this patch be applied to the development branch yet?
Yes, we will go to 2.1.3 very soon.
Hi Herbert, is now "very soon"? Thanks, Stefan.
cp->hdu: i think we already use 2.1.3 on srx644, right ?
FT 2.1.3 was released on 2002/11/14. The RC2 was already used for the last couple of builds. The files and patch for the official release have been checked in today. Next respin of 644 will have it.
haggai->hdu: Thanks a lot for upgrading the used libfreetype in the developer branch. I actually intended this issue to address the problem that vendors have when building OOO_STABLE_1 using their own internal libfreetype. Do you have any objection to checking this patch into OOO_STABLE_1? It does not change existing builds - it only makes a difference if a vendor has prevented the build/deliver of the internal libfreetype supplied with the OOo source. Chris
> Do you have any objection to checking this patch into OOO_STABLE_1? > It does not change existing builds - it only makes a difference if > a vendor has prevented the build/deliver of the internal libfreetype > supplied with the OOo source. I'm not 100% confident it would work for OOO_STABLE_1, because too much has changed. We'll have it in the next OOo based on SRX644(?) and it will also work out of the box on OOo643. Would you like to test it on OOO_STABLE_1? If everything works including symbol fonts, font rotation or asian vertical characters I agree we should tag it; else it is just too much work to backport all needed changes.
I'm just talking about the patch I supplied (attachment 2381 [details]) - adding some #defines because of the macro name changes - not actually upgrading the supplied freetype. This patch affects no-one except those vendors who are explicitly using their own freetype, and those people already have this patch, or an unconditional variant, in their trees. I'd just like to get this in for 1.0.2 to allow everyone to pull this patch out of their separate trees. The patch is already well tested (we have been building with this patch since June). Having said that, I'll try to test 2.1.3 in stable_1 at some point, but as you say it is a lower priority and isn't so important.
Closing.