Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support variable ttfs without HVAR #21

Closed
stenson opened this issue Sep 30, 2019 · 7 comments
Closed

Support variable ttfs without HVAR #21

stenson opened this issue Sep 30, 2019 · 7 comments

Comments

@stenson
Copy link

stenson commented Sep 30, 2019

I brought this topic up on the Font Tools & Tech discord and was instructed to file an issue here for support of TrueType-flavored VFs built without the optional HVAR table. The original issue was described here: #19, though HVAR is not mentioned specifically in the issue title.

I believe the issue could be solved by using the hb_ft series of functions instead of the hb_ot series (which I've attempted in a fork of uharfbuzz, but had no success)

@behdad
Copy link
Member

behdad commented Sep 30, 2019

A tool to add HVAR table to an existing font is a good tool to have in FontTools.

A way to make uharfbuzz use hb-ft is also good to have.

@ebraminio
Copy link
Contributor

ebraminio commented Jun 24, 2020

HarfBuzz callback now support calculating extents for font without HVAR (from the var glyphs themselves) (IIUC?) so this can be closed I believe.

About hb-ft part, we should either take control of freetype compile also which is unlikely, or rely on #45 for hb-ft for ones need it. After compiling freetype and adding the library to include_dirs/libraries just as #49, and FT_FREETYPE_H should to header compilation so hb_ft_font_set_funcs can be accessed then be called to hb_font_t equivalent object. Guess doesn't worth the hassle however.

@justvanrossum
Copy link
Collaborator

Confirmed that VF without HVAR now works correctly.

@behdad
Copy link
Member

behdad commented Jun 24, 2020

HarfBuzz callback now support calculating extents for font without HVAR (from the var glyphs themselves) (IIUC?) so this can be closed I believe

Can you remind me where this was done? I want to review. My concern is that our glyph loading is super slow currently. We might want to add a cache. The change you note exposes our extreme slowness right now. Which I'm not saying we should back down, but like to assess and plan how to fix the performance issue. Related: harfbuzz/harfbuzz#1389

@ebraminio
Copy link
Contributor

Can you remind me where this was done? I want to review. My concern is that our glyph loading is super slow currently. We might want to add a cache. The change you note exposes our extreme slowness right now.

When CFF/CFF2 was implemented I guess, harfbuzz/harfbuzz#1113 maybe harfbuzz/harfbuzz@c0c85b8

@ebraminio
Copy link
Contributor

And oh the gvar part, harfbuzz/harfbuzz@b9ff43c which guess no different from CFF/CFF2 part.

@ebraminio
Copy link
Contributor

ebraminio commented Jun 24, 2020

[..] We might want to add a cache.

Guess should be benchmarked first harfbuzz/harfbuzz#2457 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants