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

FontView uses default font widths if HVAR table does not have a width mapping table. #17

Closed
readroberts opened this Issue Jan 27, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@readroberts

readroberts commented Jan 27, 2017

FontView uses default font widths if HVAR table does not have a width mapping table. ttgxvar.c::ft_var_load_hvar() seems to survive loading the table, and reasonably sets face->blend->hvar_table->widthMap.mapCount to 0.

However, tt_hadvance_adjust() at line 807 then does the check:
if ( gindex >= face->blend->hvar_table->widthMap.mapCount )
{
FT_TRACE2(( "gindex %d out of range\n", gindex ));
error = FT_THROW( Invalid_Argument );
goto Exit;
}

The width mapping table is optional in the HVAR table; and the Adobe Type group now has two test fonts which show this issue.

By the way I am not familiar with the gyp build system. What is the simplest way to get a debug build, non-optimized and with all symbols? Debugging the regular build with lldb was a bit challenging. Do I edit 'common.gypi' or edit build.py so that args.release is set to '', or something else?

@brawer

This comment has been minimized.

Show comment
Hide comment
@brawer

brawer Jan 28, 2017

Contributor

Thanks for the report; filed FreeType bug 50170.

Would Adobe contribute a test font (just 1-2 glyphs) to Unicode’s text rendering tests? You’d help making sure that this is getting fixed across all OpenType implementations.

Contributor

brawer commented Jan 28, 2017

Thanks for the report; filed FreeType bug 50170.

Would Adobe contribute a test font (just 1-2 glyphs) to Unicode’s text rendering tests? You’d help making sure that this is getting fixed across all OpenType implementations.

@brawer

This comment has been minimized.

Show comment
Hide comment
@brawer

brawer Jan 30, 2017

Contributor

@readroberts, if you can’t contribute a test font to Unicode, could you send me your font by e-mail so I can try to reproduce? @lemzwerg wrote on the FreeType bug:

Please test with the current git of FreeType! I believe this has been fixed already.

Contributor

brawer commented Jan 30, 2017

@readroberts, if you can’t contribute a test font to Unicode, could you send me your font by e-mail so I can try to reproduce? @lemzwerg wrote on the FreeType bug:

Please test with the current git of FreeType! I believe this has been fixed already.

@miguelsousa

This comment has been minimized.

Show comment
Hide comment
@miguelsousa

miguelsousa Jan 30, 2017

Contributor

@brawer I'll work on a test font

Contributor

miguelsousa commented Jan 30, 2017

@brawer I'll work on a test font

@brawer

This comment has been minimized.

Show comment
Hide comment
@brawer

brawer Feb 1, 2017

Contributor

Added test case HVAR-1 to Unicode text rendering tests. @readroberts, do you want me to cut a new release of FontView, or is it OK to wait until @lemzwerg has cut a new FreeType release?

Contributor

brawer commented Feb 1, 2017

Added test case HVAR-1 to Unicode text rendering tests. @readroberts, do you want me to cut a new release of FontView, or is it OK to wait until @lemzwerg has cut a new FreeType release?

@miguelsousa

This comment has been minimized.

Show comment
Hide comment
@miguelsousa

miguelsousa Feb 1, 2017

Contributor

@brawer if a new release of FontView shows the correct advances, it will be helpful to have it available. Thanks.

Contributor

miguelsousa commented Feb 1, 2017

@brawer if a new release of FontView shows the correct advances, it will be helpful to have it available. Thanks.

@brawer brawer closed this in d3a78ee Feb 1, 2017

@brawer

This comment has been minimized.

Show comment
Hide comment
@brawer

brawer Feb 1, 2017

Contributor

Sure, no problem. I’ve cut fresh releases for fontview and fontdiff, both tagged as v0.2.2. Travis is still working on the release binaries. When they’re fully built, Travis should push ZIP files for downlod to the respective GitHub release pages.

Contributor

brawer commented Feb 1, 2017

Sure, no problem. I’ve cut fresh releases for fontview and fontdiff, both tagged as v0.2.2. Travis is still working on the release binaries. When they’re fully built, Travis should push ZIP files for downlod to the respective GitHub release pages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment