Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Support for freetype 2.1.x in gcach_ftyp.cxx | ||||||
---|---|---|---|---|---|---|---|
Product: | gsl | Reporter: | chris | ||||
Component: | code | Assignee: | hdu <hdu> | ||||
Status: | CLOSED FIXED | QA Contact: | issues@gsl <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | hdu, issues | ||||
Version: | OOo 1.0.1 | ||||||
Target Milestone: | OOo 1.1 Beta | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Issue Type: | PATCH | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
chris
2002-07-29 12:30:06 UTC
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. |