To-Do List to publish AR One Sans

[vv-monsalve]

HI @niteeshy, the following would be the first To-Do tasks to solve some reported Fails for AR One Sans

Reported Fails

🔥 FAIL: Validate defaults on fvar table match registered fallback names in GFAxisRegistry. (com.google.fonts/check/gf_axisregistry/fvar_axis_defaults)

> >Check that axis defaults have a corresponding fallback name registered at the Google Fonts Axis Registry, available at https://github.com/google/fonts/tree/main/axisregistry > >This is necessary for the following reasons: > >To get ZIP files downloads on Google Fonts to be accurate — otherwise the chosen default font is not generated. The Newsreader family, for instance, has a default value on the 'opsz' axis of 16pt. If 16pt was not a registered fallback position, then the ZIP file would instead include another position as default (such as 14pt). > >For the Variable fonts to display the correct location on the specimen page. > >For VF with no weight axis to be displayed at all. For instance, Ballet, which has no weight axis, was not appearing in sandbox because default position on 'opsz' axis was 16pt, and it was not yet a registered fallback positon. > * 🔥 **FAIL** The defaul value opsz:0.0 is not registered as an axis fallback name on the Google Axis Registry. You should consider suggesting the addition of this value to the registry or adopted one of the existing fallback names for this axis: [name: "6pt" value: 6.0 , name: "7pt" value: 7.0 , name: "8pt" value: 8.0 , name: "9pt" value: 9.0 , name: "10pt" value: 10.0 , name: "11pt" value: 11.0 , name: "12pt" value: 12.0 , name: "14pt" value: 14.0 , name: "16pt" value: 16.0 , name: "17pt" value: 17.0 , name: "18pt" value: 18.0 , name: "20pt" value: 20.0 , name: "24pt" value: 24.0 , name: "28pt" value: 28.0 , name: "36pt" value: 36.0 , name: "48pt" value: 48.0 , name: "60pt" value: 60.0 , name: "72pt" value: 72.0 , name: "96pt" value: 96.0 , name: "120pt" value: 120.0 , name: "144pt" value: 144.0 ] [code: not-registered]

🔥 FAIL: STAT table has Axis Value tables? (com.adobe.fonts/check/stat_has_axis_value_tables)

> >According to the OpenType spec, in a variable font, it is strongly recommended that axis value tables be included for every element of typographic subfamily names for all of the named instances defined in the 'fvar' table. > >Axis value tables are particularly important for variable fonts, but can also be used in non-variable fonts. When used in non-variable fonts, axis value tables for particular values should be implemented consistently across fonts in the family. > >If present, Format 4 Axis Value tables are checked to ensure they have more than one AxisValueRecord (a strong recommendation from the OpenType spec). > >https://docs.microsoft.com/en-us/typography/opentype/spec/stat#axis-value-tables > * 🔥 **FAIL** STAT table is missing Axis Value for 'opsz' value '0.0' [code: missing-axis-value-table] * 🔥 **FAIL** STAT table is missing Axis Value for 'opsz' value '0.0' [code: missing-axis-value-table]

To-Do

• [x] Define a point size value for the small sizes (currently is 0, which is not valid)

[vv-monsalve]

Reported Fails

🔥 FAIL: Check a font's STAT table contains compulsory Axis Values. (com.google.fonts/check/STAT)

> >Check a font's STAT table contains compulsory Axis Values which exist in the Google Fonts Axis Registry. > >We cannot determine what Axis Values the user will set for axes such as opsz, GRAD since these axes are unique for each font so we'll skip them. > * 🔥 **FAIL** Compulsory STAT Axis Values are incorrect: | Name | Axis | Current Value | Current Flags | Current LinkedValue | Expected Value | Expected Flags | Expected LinkedValue | | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | | Regular | wght | 400.0 | 2 | 700.0 | 400.0 | 2 | 700.0 | | Medium | wght | N/A | N/A | N/A | 500.0 | 0 | None | | SemiBold | wght | N/A | N/A | N/A | 600.0 | 0 | None | | Bold | wght | 700.0 | 0 | None | 700.0 | 0 | None | [code: bad-axis-values]

🔥 FAIL: Check variable font instances (com.google.fonts/check/fvar_instances)

> >Check a font's fvar instance coordinates comply with our guidelines: https://googlefonts.github.io/gf-guide/variable.html#fvar-instances > * 🔥 **FAIL** fvar instances are incorrect: - Add missing instances | Name | current | expected | | :--- | :--- | :--- | | Regular | wght=400.0, opsz=0.0 | wght=400.0, opsz=0.0 | | Medium | N/A | wght=500.0, opsz=0.0 | | SemiBold | N/A | wght=600.0, opsz=0.0 | | Bold | wght=700.0, opsz=0.0 | wght=700.0, opsz=0.0 | [code: bad-fvar-instances]

To-Do

• [x] Create the intermediate instances Medium and SemiBold to provide all the intermediate positions in the range (400 -- 700). This is required due to the API will generate those instantiated static fonts by default. You can find more details about it in the Instantiated Static Fonts section on the Variable Fonts Requirements of the GF-Guide

[vv-monsalve]

Reported Fail

🔥 FAIL: Check family name for GF Guide compliance. (com.google.fonts/check/name/family_name_compliance)

> >Checks the family name for compliance with the Google Fonts Guide. https://googlefonts.github.io/gf-guide/onboarding.html#new-fonts > >If you want to have your family name added to the CamelCase exceptions list, please submit a pull request to the camelcased_familyname_exceptions.txt file. > >Similarly, abbreviations can be submitted to the abbreviations_familyname_exceptions.txt file. > >These are located in the Lib/fontbakery/data/googlefonts/ directory of the FontBakery source code currently hosted at https://github.com/googlefonts/fontbakery/ > * 🔥 **FAIL** "AR One Sans" contains an abbreviation. [code: abbreviation]

To-Do

• [ ] Before we create the exception, we need to confirm if the name is accepted in a case-by-case scenario. I'll return to you later about this topic.

@davelab6 could you please confirm this?

[niteeshy]

@vv-monsalve Thanks for reviewing the files and getting back with the feedback. I have been contemplating the right axis for the family and I think that the Grade (GRAD) axis would be better suited for this type of family. Since the Two versions are designed to accommodate the resolution changes of the AR/VR headsets. And they are duplexed to retain the glyph width to avoid any reflow.

Hence I wanted to share few changes with you to discuss them:

1. Change of axis from 'opsz' to 'GRAD' (Value -1 [Low resolution] and +1 for [High resolution]
2. Change the instance naming pattern from 'Regular L' for low resolution, 'Regular H' for high resolution to 'Regular' for low resolution and 'Regular Retina' for High resolution.

Please share your feedback on this and I will make the changes accordingly.

[vv-monsalve]

@niteeshy GRAD doesn't seem the best option either here. I've sent you an email to set up video call to better review this and find the best candidate.

[vv-monsalve]

Following today's meeting, these are the next steps:

• [x] Reading the Axis Registry Protocol in the GF Guide before creating a new Axis Proposal issue in the Axis Registry repository
• [x] Discussed name for it would be AR Resolution
• [x] Please provide all the detailed info that could better inform the reasoning around the axis, e.g. Axis range values
• [x] Update the source and font files to match the Axis proposal
• [x] Provide design details in the Readme file (here) that could better inform the decision-making around the axis as well as how this blended axis could be brake into parametric ones in the future

[niteeshy]

@vv-monsalve I have completed the tasks above: One small change: The name of axis that I feel will be more relevant is "AR Retinal Resolution" ARRR

Here is the draft proposal, should I post it as new axis proposal?

Administrative Information

Proposers name: Niteesh Yadav Proposal name: AR Resolution (Augmented Reality Resolution) Date of submission: 2023-04-12 New or revised proposal: New

General Technical Information

Font project using the axis

AR One Sans Repository

Short description of what the axis does

Overview: The AR Resolution proposal aims to improve the user experience of AR/VR headsets by enabling resolution-specific enhancements. As the resolution of these headsets continues to evolve towards retina resolution (60 PPD), it becomes increasingly challenging for designers to create scalable experiences that cater to a wide range of devices. Traditionally, designers have optimized text for the latest technology, resulting in substandard experiences for users with previous-generation devices.

To address this issue, the proposal suggests using typefaces with resolution-specific adjustments that are duplexed (uni-width). This approach empowers designers to create a single design that can be rendered across a large range of headsets, regardless of resolution. By mapping the AR retinal resolution (ARRR) to the PPD resolution of the headsets, users can enjoy the best possible experience as the typeface is rendered based on their device's resolution.

AR One Sans, designed by Niteesh Yadav, provides an example of size-specific adjustment in typefaces. For instance, the font includes light traps that help to reduce the glow at the junctions of the strokes of letters. Additionally, the font features flaring at the end of strokes that optimizes the shape of letters to minimize the rounding effect that can occur with rectangular strokes, making them appear more like rounded rectangles.

Overall, the AR Retinal Resolution proposal seeks to provide a solution to the challenge of designing scalable experiences for a wider audience by enabling designers to create designs that work across a range of devices, resulting in a better user experience for all users.

Image

GIF illustrating the flaring (one of the adjustments) on ARRR axis.

Proposed Axis Details

Tag: ARRR Name: AR Retinal Resolution Valid numeric range: 0 to 60

Description: Resolution-specific enhancements in AR/VR typefaces optimize text without changing the width of the letters, maintaining consistent spacing and kerning, and preserving layout and line breaks. This ensures a consistent design and layout across different resolutions, making designs accessible and easy to read, regardless of the headset's resolution.

Scale interpretation: In the proposed resolution-specific adjustments for AR/VR typefaces, the lower value of the axis corresponds to the PPD of low-resolution headsets, while the upper value corresponds to 60 PPD, which is considered retina resolution. Beyond this point, the effect of adjustments on legibility and readability becomes negligible. Therefore, by limiting the adjustments to this range, designers can optimize the legibility and readability of their typefaces for a wide range of headsets while minimizing the amount of adjustment work required.

Recommended Use: Is to map the ARRR to the resolution of headsets and render the typefaces according to that.

Reference PPD values of headsets: Varjo XR-3: 70 PPD in its focus area and 30 PPD in its peripheral area. Hololens 2 (AR): 47 PPD Oculus Quest (VR): 14.4 PPD PSVR (VR): 9.6 PPD

Other Supporting Information

Pixel Density in AR/VR headsets VR headset PPD table Importance of retinal resolution in AR/VR

[vv-monsalve]

Here is the draft proposal, should I post it as new axis proposal?

Please open a new axis proposal issue in the googlefonts/axisregistry repo following the Add Axis template.

Some notes after reading the draft:

• The "Administrative Information" of the above draft will not be needed as that information would be automatically registered/reported but GitHub.
• In the "Overview" section
  • Update the name to "AR Retinal Resolution" (it still says AR Resolution).
  • Review the clarity in "with resolution-specific adjustments that are duplexed (uni-width)".
  • You would like to include a mention on why the x-height is increased in the low resolution range

Thanks for the detailed information. Let's continue the discussion around the axis there, once created.

[davelab6]

Is there a way to convert ppd to Points? Would there be a font with both opsz and ARRR axes?

[niteeshy]

@davelab6

1. I'm not too sure about the conversion of PPD to points. To calculate the HMD’s pixel density in PPD (the number of pixels per degree it presents to the eye), the number of pixels in a horizontal display line has to be divided by the horizontal field of view provided by the lens. Example: Oculus Quest has a resolution of 1440x1600 per-eye and FOV of 93° horizontal, so the PPD come out to be 15.31 (1440/93). I was looking at PPD as a reference unit since it would be easy to understand based on the retinal resolution concept. Any specific reason to convert it into points?

2. Yes, there is a possibility of having opsz alongside ARRR as it can make it easy for designers to deliver size-specific variants/ adjustments.

[vv-monsalve]

@niteeshy would you like to create the proposal issue in the Axis Registry repo? Otherwise, I could do it for you. This discussion should happen there ;)

[davelab6]

Per (2) then I think this axis regisration should proceed, looking forward to continuing the discussion in the axis registry repo :)