patches-freetype/fix-incorrect-korean-fonts-rendering.patch appears incorrect

Bug #1379869 reported by Bungeman on 2014-10-10
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
freetype (Ubuntu)
Undecided
Unassigned
Trusty
High
Unassigned

Bug Description

This is reported in relation to https://bugs.launchpad.net/freetype/+bug/1310017 . See https://bugs.launchpad.net/freetype/+bug/1310017/comments/21 for comment on related bug report.

I have an issue with the patch for FreeType in debian/patches-freetype/fix-incorrect-korean-fonts-rendering.patch . It appears to be incorrect. It claims to apply

http://git.savannah.gnu.org/cgit/freetype/freetype2.git/patch/?id=98e510ee94e552e9e9f80891aa87b2b472d0f276

but it does not. It applies the above patch, but also runs

src/autofit$ perl ../tools/afblue.pl afblue.dat < afblue.hin > afblue.h

to regenerate the afblue.h. However, it does not also re-generate afblue.c. The re-generation is itself suspect, as this appears to have been run without FreeType commits

991cbcce97527e74ca3751dd04b89e393420549c
c46fa86bd585639bf4311809ba561675267e99af
741f736662476403cbcac3b9bf0756134f53ce1b
6dce136937ab8c436413ce617ffb5ddb329f3ecc
181fd071ee58b4b59257a2a162ea0a928057aa8d

which would bring afblue.pl up to date with this change. (I believe that these commits should be considered a part of a cumulative fix.) It would be nice if afblue.c and afblue.h were generated as part of the build to avoid these sorts of issues, but the initial check-in (8b8be78385a2e564ebd62983512b81e541dff622) indicates this was not done to avoid a perl build dependency.

I would like to request that this patch be re-built to match the FreeType commit. Particularly that after the re-built patch is applied the src/autofit/afblue.h file look as much like http://git.savannah.gnu.org/cgit/freetype/freetype2.git/plain/src/autofit/afblue.h?id=98e510ee94e552e9e9f80891aa87b2b472d0f276 as possible. Equivalently the output of

git diff trusty:src/autofit/afblue.h 98e510ee94e552e9e9f80891aa87b2b472d0f276:src/autofit/afblue.h

should have no material differences. I have done this manually, and am attaching a new fix-incorrect-korean-fonts-rendering.patch which shows what should be the correct patch. I believe that the error in the existing patch may lead to incorrect behavior, as af_blue_stringsets will be out of alignment with af_blue_strings.

Bungeman (bungeman) wrote :
Jinkyu Yi (jincreator) wrote :

Hi, I'm the author of fix-incorrect-korean-fonts-rendering.patch

As you figured out fix-incorrect-korean-fonts-rendering.patch is not exactly same with 98e510ee94e552e9e9f80891aa87b2b472d0f276
And I found out I didn't mention it. My bad.

Due to version difference, the original patch can't applied in Ubuntu's one.
If I remember correctly, afblue.h and Changelog diff makes hunk error.
So I regenerated afblue.h only by using afblue.pl in 2.5.2's one, not latest one.
Maybe I didn't regenerate afblue.c because it didn't make hunk error(but maybe warning).
So yes, that file contains only patch of 98e510ee94e552e9e9f80891aa87b2b472d0f276 with afblue.h only regenerated.

I apologize for did it in wrong way.

The attachment "Revised version of existing patch." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Steve Langasek (vorlon) on 2015-09-12
Changed in freetype (Ubuntu):
status: New → Invalid
Changed in freetype (Ubuntu Trusty):
status: New → Triaged
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers