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

Add parsing anchor table format 2 #238

Merged
merged 8 commits into from
Feb 26, 2022
Merged

Add parsing anchor table format 2 #238

merged 8 commits into from
Feb 26, 2022

Conversation

brianpopow
Copy link
Contributor

Prerequisites

  • I have written a descriptive pull-request title
  • I have verified that there are no overlapping pull-requests open
  • I have verified that I am following matches the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
  • I have provided test coverage for my change (where applicable)

Description

This adds parsing Anchor table format 2.
The difference to format 1 is, that there is a additional Index to glyph contour point, which should be used for hinting.

We dont support hinting yet, right? The output looks correct from what I can tell without it.

closes #237

@codecov
Copy link

codecov bot commented Feb 14, 2022

Codecov Report

Merging #238 (f4c9f35) into main (0856c1f) will decrease coverage by 0%.
The diff coverage is 47%.

Impacted file tree graph

@@         Coverage Diff         @@
##           main   #238   +/-   ##
===================================
- Coverage    84%    83%   -1%     
===================================
  Files       182    183    +1     
  Lines      8938   8985   +47     
  Branches   1420   1425    +5     
===================================
+ Hits       7531   7542   +11     
- Misses     1083   1118   +35     
- Partials    324    325    +1     
Flag Coverage Δ
unittests 83% <47%> (-1%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...nts/Tables/AdvancedTypographic/GPos/AnchorTable.cs 38% <13%> (-51%) ⬇️
...es/AdvancedTypographic/GPos/LookupType3SubTable.cs 57% <34%> (-6%) ⬇️
src/SixLabors.Fonts/GlyphPositioningCollection.cs 88% <81%> (-1%) ⬇️
...es/AdvancedTypographic/AdvancedTypographicUtils.cs 89% <100%> (-1%) ⬇️
....Fonts/Tables/AdvancedTypographic/GPos/AnchorXY.cs 100% <100%> (ø)
...es/AdvancedTypographic/GPos/LookupType4SubTable.cs 90% <100%> (ø)
...es/AdvancedTypographic/GPos/LookupType5SubTable.cs 89% <100%> (ø)
...es/AdvancedTypographic/GPos/LookupType6SubTable.cs 74% <100%> (ø)
src/SixLabors.Fonts/TextLayout.cs 86% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0856c1f...f4c9f35. Read the comment docs.

@JimBobSquarePants
Copy link
Member

We dont support hinting yet, right?

We actually do, it's hidden behind a property in the TextOptions type.

I think the provided index represents the index of the point in the GlyphOutline.ControlPoints.

I had a quick look at hb-ot-layout-gpos-table.hh line 426-434 and I think we should be returning that point if the index is viable and we have hinting enabled. I could be horribly wrong though as I found it impossible to actually navigate through the various levels of indirection to see exactly what get_glyph_contour_point_for_origin does.

@brianpopow
Copy link
Contributor Author

I had a quick look at hb-ot-layout-gpos-table.hh line 426-434 and I think we should be returning that point if the index is viable and we have hinting enabled. I could be horribly wrong though as I found it impossible to actually navigate through the various levels of indirection to see exactly what get_glyph_contour_point_for_origin does.

This looks about right. To really get this correct, I think we need a real world example where this feature is actually used. The one example from microsoft docs does not do it for me. I wish they would provide fonts along those examples.

@JimBobSquarePants
Copy link
Member

I wish they would provide fonts along those examples.

Completely agree, the savings in development time would be incredible!

I think we should go ahead and grab the point from the contour points when possible. I'd have to double check to see if we should be scaling the value like Harfbuzz does. I'm surprised they don't have a test font squirreled away somewhere.

@@ -45,7 +45,8 @@ public static AnchorTable Load(BigEndianBinaryReader reader, long offset)
return anchorFormat switch
{
1 => AnchorFormat1.Load(reader),
_ => throw new NotSupportedException($"anchorFormat {anchorFormat} not supported. Should be '1'.")
2 => AnchorFormat2.Load(reader),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As somebody who knows nothing about fonts, making these error messages more descriptive might be helpful too. If I knew that my font format wasn't supported, I'd just pick a different one.

 3 => throw new NotSupportedException($"Variable fonts (format 3) are not supported. Read: https://docs.sixlabors.com/articles/fonts/anchorTableFormats.html")
 _ => throw new NotSupportedException($"Fonts using anchor table format {anchorFormat} are not supported. Read: https://docs.sixlabors.com/articles/fonts/anchorTableFormats.html")

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't link to docs from exception messages. The maintenance burden of tracking URL changes would be too much.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's fair enough, was just a thought

@JimBobSquarePants
Copy link
Member

@brianpopow I decided to actually go ahead and implement anchor format 2 table as I'm fairly confident of the approach. I've also added the font to the solution so we can test it.

I've been trying various character combinations to see if I can trigger the table but have so far failed.

@brianpopow
Copy link
Contributor Author

I've been trying various character combinations to see if I can trigger the table but have so far failed.

I tried to look through the harfbuzz tests for examples, but so far also without luck. I am pretty sure there must be an example there, but dont know how to find one.

@JimBobSquarePants
Copy link
Member

I tried to look through the harfbuzz tests for examples, but so far also without luck. I am pretty sure there must be an example there, but dont know how to find one.

@behdad @khaledhosny Would you possibly be able to help here? We're looking for example fonts and tests that allow us to test features using AnchorTable Formats 2 and 3.

@behdad
Copy link

behdad commented Feb 24, 2022

@behdad @khaledhosny Would you possibly be able to help here? We're looking for example fonts and tests that allow us to test features using AnchorTable Formats 2 and 3.

I'm not aware of any fonts using those currently.

@JimBobSquarePants
Copy link
Member

Thanks @behdad at least this means if we make a mistake, no one will see it 😂

@JimBobSquarePants
Copy link
Member

@brianpopow I'm gonna merge this as-is since we can't provide a test font. I'll add an issue to flesh out AnchorFormat3 to add Device table support.

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

Successfully merging this pull request may close these issues.

anchorFormat 2 not supported. Should be '1'.
4 participants