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

Bug #1379869 reported by Bungeman
This bug affects 1 person
Affects Status Importance Assigned to Milestone
freetype (Ubuntu)

Bug Description

This is reported in relation to . See 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

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

src/autofit$ perl ../tools/ 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


which would bring 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 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.

Revision history for this message
Bungeman (bungeman) wrote :
Revision history for this message
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 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.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

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)
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