[PATCH] luaharfbuzz: Provide interface for variable fonts
Hi, please consider the attached patch for luahbtex. It adds a Lua interface for HarfBuzz's functions around variable fonts. It is an adoption of recent upstream luaharfbuzz changes with additional LuaJIT support. While corresponding busted tests are included too, the font needed to actually run these tests has not been added to the fonts directory since sending binary files in diffs via email is problematic and I don't think that anyone is running these tests from the LuaTeX repo anyway. Best regards, Marcel
On Mon, Aug 2, 2021 at 6:57 PM Marcel Fabian Krüger
Hi,
please consider the attached patch for luahbtex. It adds a Lua interface for HarfBuzz's functions around variable fonts.
It is an adoption of recent upstream luaharfbuzz changes with additional LuaJIT support. While corresponding busted tests are included too, the font needed to actually run these tests has not been added to the fonts directory since sending binary files in diffs via email is problematic and I don't think that anyone is running these tests from the LuaTeX repo anyway.
1) why 2 files ? 2) Makefile.in is not necessary 3) can you make each patch as a separate file, and then make a zip (o tar )? -- luigi
On Mon, Aug 02, 2021 at 07:12:56PM +0200, luigi scarso wrote:
On Mon, Aug 2, 2021 at 6:57 PM Marcel Fabian Krüger
wrote: Hi,
please consider the attached patch for luahbtex. It adds a Lua interface for HarfBuzz's functions around variable fonts.
It is an adoption of recent upstream luaharfbuzz changes with additional LuaJIT support. While corresponding busted tests are included too, the font needed to actually run these tests has not been added to the fonts directory since sending binary files in diffs via email is problematic and I don't think that anyone is running these tests from the LuaTeX repo anyway.
1) why 2 files ?
Whenever I checkout the sources from git, svn or the web interface I get files with UNIX line ending, but some months ago you mentioned that a patch couldn't be applied because it should have used Windows line endings instead. Therefore I added a .win version with Windows line endings to avoid issues but still included the other patch since that's the one I actually tested locally.
2) Makefile.in is not necessary Ok, I dropped it.
3) can you make each patch as a separate file, and then make a zip (o tar )? Sure, I added a zip of the individual patches.
Best, Marcel
On Mon, Aug 2, 2021 at 8:40 PM Marcel Fabian Krüger
1) why 2 files ?
Whenever I checkout the sources from git, svn or the web interface I get files with UNIX line ending, but some months ago you mentioned that a patch couldn't be applied because it should have used Windows line endings instead. Therefore I added a .win version with Windows line endings to avoid issues but still included the other patch since that's the one I actually tested locally.
Do you remember the email ? All code should be with UNIX line ending Sure, I added a zip of the individual patches.
Patches applied, but I don't have variation.c, which is mentioned in luaharfbuzz.am.patch and so variation.c.patch cannot be applied . -- luigi
On Tue, Aug 03, 2021 at 11:51:16AM +0200, luigi scarso wrote:
On Mon, Aug 2, 2021 at 8:40 PM Marcel Fabian Krüger
wrote: 1) why 2 files ?
Whenever I checkout the sources from git, svn or the web interface I get files with UNIX line ending, but some months ago you mentioned that a patch couldn't be applied because it should have used Windows line endings instead. Therefore I added a .win version with Windows line endings to avoid issues but still included the other patch since that's the one I actually tested locally.
Do you remember the email ? All code should be with UNIX line ending
Hi Luigi, Oops, looking back I realized that I remembered it incorrectly: The issue was that the file couldn't get applied because the *patch* had Windows lineendings. Not sure how that happened but anyway I stand corrected.
Sure, I added a zip of the individual patches.
Patches applied, but I don't have variation.c, which is mentioned in luaharfbuzz.am.patch and so variation.c.patch cannot be applied .
Actually variation.c.patch is supposed to create a new file, so it should work even if the file doesn't exists yet. Not sure how standard that format is though, it seems to be a git extension which got picked up by GNU patch but not by many other tools. I added the full file variation.c as an attachment. It belongs at source/texk/web2c/luatexdir/luaharfbuzz/src/luaharfbuzz/variation.c Best, Marcel
On Tue, Aug 3, 2021 at 1:44 PM Marcel Fabian Krüger
Oops, looking back I realized that I remembered it incorrectly: The issue was that the file couldn't get applied because the *patch* had Windows lineendings. Not sure how that happened but anyway I stand corrected.
Indeed, that was the case.
I added the full file variation.c as an attachment. It belongs at source/texk/web2c/luatexdir/luaharfbuzz/src/luaharfbuzz/variation.c
and again your variation.c attached has Windows line endings. Anyway, variation.c from variation.c.patch is ok, it is the same of luaharfbuzz-master . In general Windows line endings are not a problem for me, because I am used to run dos2unix before. The default diff (i.e. without ignoring blanks) is annoying because it says that all the lines differ, and I don't run diff -b because spaces matter in comments . Committed revision 7447. -- luigi
On Tue, Aug 03, 2021 at 11:51:16AM +0200, luigi scarso wrote:
Patches applied, but I don't have variation.c, which is mentioned in luaharfbuzz.am.patch and so variation.c.patch cannot be applied .
Sadly I introduced a bug here: Named instances queried from face objects use 1-based indices, while the related Font method to set the current instance still uses a zero based index. I attached a patch to fix this issue. Best regards, Marcel
On Wed, Aug 4, 2021 at 2:11 PM Marcel Fabian Krüger
On Tue, Aug 03, 2021 at 11:51:16AM +0200, luigi scarso wrote:
Patches applied, but I don't have variation.c, which is mentioned in luaharfbuzz.am.patch and so variation.c.patch cannot be applied .
Sadly I introduced a bug here: Named instances queried from face objects use 1-based indices, while the related Font method to set the current instance still uses a zero based index.
I attached a patch to fix this issue.
Best regards, Marcel
Committed revision 7448. -- luigi
participants (2)
-
luigi scarso
-
Marcel Fabian Krüger