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.

Sign up for GitHub

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

Jump to bottom

Severe hinting issues on web fonts #121

Closed
vitorsr opened this issue Jun 22, 2023 · 6 comments
Closed

Severe hinting issues on web fonts #121

vitorsr opened this issue Jun 22, 2023 · 6 comments

Comments

@vitorsr
Copy link

vitorsr commented Jun 22, 2023

Affects all Chromium browsers on a pristine Windows 11 image.

https://adobe-fonts.github.io/source-serif/

Cause: SourceSerif4Variable-Roman.otf.woff2 is loaded instead of SourceSerif4Variable-Roman.ttf.woff2... which in turn appears to not have hinting.
@frankrolf
Copy link
Member

Thank you – this is a known issue, see #114.
Source Serif is the first CFF2 font to be hinted, so some weirdness is to be expected :-)

In the meantime, If you need Source Serif VF, I recommend using the (unhinted) TTF for the time being.

@frankrolf
Copy link
Member

@vitorsr May I ask you to make the same screenshot on a recent version of Chrome? The bug should be fixed.

@vitorsr
Copy link
Author

vitorsr commented Oct 21, 2023

Thanks. I have made the same screenshot and it appears to be mitigated.

However I should note that hinting is still off for some opsz and wgth variations such as opsz=8 wght=700 in the example below. Moreover it does not seem to be specific to Windows as Chromium’s Skia renderer appears to use FreeType’s CFF2 driver.

Windows 11 Pro 22H2 Ubuntu 22.04.3 LTS

@frankrolf
Copy link
Member

Thank you for your help!

AnuthaDev pushed a commit to freetype/freetype that referenced this issue Dec 14, 2023
@skef @lemzwerg
[CFF] Extract BlueValues as Fixed rather than Int.
8eab511 
This is a follow-up to commit 26a7f04,

  [cff] Make blend operator work with floats in private dicts.

which addressed the 'party baseline' bug.  However, the reporting user
indicated that the default location and some other points in design space
rendered OK, but other points in design space still had problems.  The most
obvious issue being that the x-heights of lower-case letters did not align;
see

  adobe-fonts/source-serif#121 (comment)

After some analysis we determined that this was due to an interaction
between `BlueValue` rounding and the zone-based algorithm.  In short, for a
point to be considered in a zone it must fall within the bounds of the zone.
(There is a slop factor in some cases, but only a very small one.)  In the
Adobe-contributed side of the code, point values are not integer-rounded,
instead they're kept as (some form of) fixed.  Rounding just the `BlueValues`
means that points that need to be considered within a zone will fall outside
of it at some points in design space.

The majority of this patch changes the storage and parsing of `BlueValues`
to keep them as `FT_Fixed`.  No significant code changes were needed because
the values are converted to `Fixed` anyway when stored in `CF_BlueRec`.  No
attempt was made to address problems in the older pshinter code beyond
converting the values from `FT_Fixed` to `FT_Short` when copying the private
dictionary.  (However, as the point values are also rounded in that code,
the problem is much less likely to occur, although inconsistency between
rounding and truncation could cause an analogous problem.)

* include/freetype/internal/cfftypes.h (CFF_PrivateRec): Use `FT_Fixed` for
`blue_values`, `other_blues`, `family_blues`, and `family_other_blues`.

* src/cff/cffload.c (cff_blend_doBlend): Updated.

* src/cff/cffobjs.c (CFF_fixedToInt): New macro.
(cff_make_private_dict): Use it.

* src/cff/cffparse.h (cff_kind_delta_fixed): New enum value.

* src/cff/cffparse.c (do_fixed): Updated.
(CFF_FIELD_DELTA, CFF_FIELD_DELTA_FIXED, CFF_DELTA_KIND): New set of macros,
replacing `CFF_FIELD_DELTA`.
(cff_parser_run): Updated to handle fixed-float deltas.

* src/cff/cfftoken.h: Updated to use `CFF_FIELD_DELTA_FIXED` for blue
values.

* src/psaux/psblues.c (cf2_blueToFixed): Removed, no longer needed.
(cf2_blues_init): Updated.

* src/pxaux/psft.c, src/pxaux/psft.h (cf2_getBlueValues, cf2_getOtherBlues,
cf2_getFamilyBlues, cf2_getFamilyOtherBlues): Updated signatures.

* src/psaux/psobjs.c (t1_make_subfont): Updated.
devshgraphicsprogramming pushed a commit to Devsh-Graphics-Programming/freetype that referenced this issue May 7, 2024
@skef @devshgraphicsprogramming
[CFF] Extract BlueValues as Fixed rather than Int.
77017f0 
This is a follow-up to commit 26a7f04,

  [cff] Make blend operator work with floats in private dicts.

which addressed the 'party baseline' bug.  However, the reporting user
indicated that the default location and some other points in design space
rendered OK, but other points in design space still had problems.  The most
obvious issue being that the x-heights of lower-case letters did not align;
see

  adobe-fonts/source-serif#121 (comment)

After some analysis we determined that this was due to an interaction
between `BlueValue` rounding and the zone-based algorithm.  In short, for a
point to be considered in a zone it must fall within the bounds of the zone.
(There is a slop factor in some cases, but only a very small one.)  In the
Adobe-contributed side of the code, point values are not integer-rounded,
instead they're kept as (some form of) fixed.  Rounding just the `BlueValues`
means that points that need to be considered within a zone will fall outside
of it at some points in design space.

The majority of this patch changes the storage and parsing of `BlueValues`
to keep them as `FT_Fixed`.  No significant code changes were needed because
the values are converted to `Fixed` anyway when stored in `CF_BlueRec`.  No
attempt was made to address problems in the older pshinter code beyond
converting the values from `FT_Fixed` to `FT_Short` when copying the private
dictionary.  (However, as the point values are also rounded in that code,
the problem is much less likely to occur, although inconsistency between
rounding and truncation could cause an analogous problem.)

* include/freetype/internal/cfftypes.h (CFF_PrivateRec): Use `FT_Fixed` for
`blue_values`, `other_blues`, `family_blues`, and `family_other_blues`.

* src/cff/cffload.c (cff_blend_doBlend): Updated.

* src/cff/cffobjs.c (CFF_fixedToInt): New macro.
(cff_make_private_dict): Use it.

* src/cff/cffparse.h (cff_kind_delta_fixed): New enum value.

* src/cff/cffparse.c (do_fixed): Updated.
(CFF_FIELD_DELTA, CFF_FIELD_DELTA_FIXED, CFF_DELTA_KIND): New set of macros,
replacing `CFF_FIELD_DELTA`.
(cff_parser_run): Updated to handle fixed-float deltas.

* src/cff/cfftoken.h: Updated to use `CFF_FIELD_DELTA_FIXED` for blue
values.

* src/psaux/psblues.c (cf2_blueToFixed): Removed, no longer needed.
(cf2_blues_init): Updated.

* src/pxaux/psft.c, src/pxaux/psft.h (cf2_getBlueValues, cf2_getOtherBlues,
cf2_getFamilyBlues, cf2_getFamilyOtherBlues): Updated signatures.

* src/psaux/psobjs.c (t1_make_subfont): Updated.
@frankrolf frankrolf mentioned this issue Jun 28, 2024
Open
@skef
Copy link

skef commented Aug 13, 2024

The fix for the more recent problem, which was committed to FreeType's source base last December, is now part of FreeType 2.13.3, released on August 12th. Once this gets into a released version of Chrome we'll retest.

@vitorsr
Copy link
Author

vitorsr commented Aug 13, 2024

Thanks @skef, I am a big fan of your work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@frankrolf @skef @vitorsr