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

x/image/font/gofont: Go fonts not representative of OpenType state of the art #37441

Closed
nim-nim opened this issue Feb 25, 2020 · 2 comments
Closed

x/image/font/gofont: Go fonts not representative of OpenType state of the art #37441

nim-nim opened this issue Feb 25, 2020 · 2 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unreleased

Comments

@nim-nim
Copy link

nim-nim commented Feb 25, 2020 •
edited

The Go and Go Mono font families are unfortunately not representative of the current OpenType state of the art.

This is not blocking their use on godoc or on Go user systems (font-using applications have layers on layers of backwards compatibility glue built in) but that is a problem when Go code uses them as representative OpenType test data.

In a modern OpenType font:

  1. Go Medium would be merged as a “Medium” style of the Go font family (OpenType Name ID 16/17 or 21/22 if 16/17 was not WWS compliant). Name ID 1/2 with their 4-style limits have long been deprecated in the OpenType spec, and are only present as a legacy layer.
    https://docs.microsoft.com/en-us/typography/opentype/spec/name#name-ids

  2. Go Smallcaps would be merged within the Go font family and would be accessed via OpenType features (which is already possible in LibreOffice, for example).
    https://docs.microsoft.com/en-us/typography/opentype/spec/features_pt#smcp

  3. There would be at least a style exercising the width axis

  4. To make Go ready for variable fonts, it should include a variable variant or at least set weight or slant in non variable fonts via the STAT table, not the legacy OS/2 system
    https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_wght

  5. If the Go project feels really ambitious, some optical sizing would be nice too, but that part of the OpenType spec is not totally baked yet

All of that does not matter if the Go fonts are no longer intended to be used as representative font test data in x/image and friends.
@gopherbot gopherbot added this to the Unreleased milestone Feb 25, 2020
@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 25, 2020
@dmitshur
Copy link
Contributor

/cc @nigeltao @robpike

@dmitshur dmitshur changed the title x/image: Go fonts not representative of OpenType state of the art x/image/font/gofont: Go fonts not representative of OpenType state of the art Feb 28, 2020
@nigeltao
Copy link
Contributor

nigeltao commented Feb 11, 2021 •
edited

The Go Fonts are first and foremost intended to be useful fonts. 1990s font formats (TTF) are still useful and the most frequently supported.

Being x/image test data is a secondary goal, and being comprehensive test data that exercises all far corners of OpenType is a non-goal. Even so, until x/image supports e.g. variable fonts (which would be a large but low-priority amount of work), whether or not the Go Fonts are variable fonts doesn't really matter for the "be x/image test data" secondary goal.

Finally, things like variability or optical sizing (for the fonts themselves, not for the x/image parser) are really a concern for the type foundry, Bigelow & Holmes. While I can pass feedback on, making big changes like this is largely out of the Go team's control.

@golang golang locked and limited conversation to collaborators Feb 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
4 participants
@dmitshur @nim-nim @nigeltao @gopherbot