search

microsoft / cascadia-code

This is a fun, new monospaced font that includes programming ligatures and is designed to enhance the modern look and feel of the Windows Terminal.
Other
25.65k stars 804 forks source link

Add variable font to Google Fonts with a new name #321

Open eliheuer opened 4 years ago

eliheuer commented 4 years ago

Description of the new feature/enhancement (with images if possible)

Cascadia Code has a new variable font release and Google Fonts now has support for variable fonts, so I want to reopen discussion about adding Cascadia Code to Google Fonts.

Progress was blocked due to uncertainty around the RFN (reserved font name), but an issue about this was recently closed with the conclusion that the RFN will remain: https://github.com/microsoft/cascadia-code/issues/56.

I'm interested in feedback from the contributors to Cascadia Code on what the name used on Google Fonts should be, some suggestions from the RFN issue are:

Tacoma Terminal
Kirkland Kode
Cascade Copy
Caskaydia Cove

And there was also the twitter poll:

cascadia-code-twitter-poll.png

I like Seattle Code, but I'm not sure if that would technically work with the RFN because "Code" is used in both names. There is a precedent for this issue with NerdFonts, which is using the name Caskaydia Cove to keep both names unique: https://github.com/ryanoasis/nerd-fonts/releases/tag/v2.1.0

Also, as Aaron mentioned in the previous issue, a fork would be difficult to keep updated for a well maintained and popular open-source typeface like this. So I want to see if this project is open to a pull request adding a new build script that would build the variable font under a new name and make all the adjustments needed to pass the Font Bakery QA tests. Both myself and @RosaWagner are available to help with the pull request for this build script. @davelab6 might have some thoughts on this as well.

One last thing to note, if someone with the legal authority to do so wants to permit Google Fonts to use the output of an approved upstream build script, that process is covered in the official SIL guide to the RFN:: https://scripts.sil.org/cms/scripts/page.php?item_id=OFL_web_fonts_and_RFNs

There are two ways for those wishing to modify OFL fonts to avoid the RFN restriction altogether:

1) Encourage the author to release the font without RFNs. This is a perfectly valid and useful strategy, however the author would need to understand the benefits they are giving up, and the overall negative effect of allowing many different versions bearing the same name to be widely distributed. As a result, we don't generally recommend it.

2) Sign a separate agreement with the author that allows the use of RFNs. This is the preferred method. It assumes that the author has significant trust in the the expertise and intentions of the modifier. There is no prescribed format for this agreement, as legal systems vary. Authors may wish to add specific clauses to further restrict use, require author review of Modified Versions, establish user support mechanisms or provide terms for ending the agreement. Such agreements are usually not public, and apply only to the main parties. However, it would be very beneficial for web font services to clearly state when they have established such agreements, so that the public is clear that their service is operating appropriately.

For example, FFF Foundry may give ABC Corp permission to use their RFN "Foo" and distribute a Modified Version called "Foo". XYZ Ltd, however, cannot further modify that font and release it using "Foo" unless they also sign an agreement with FFF Foundry.

Proposed technical implementation details (optional)

Below is a recent FontBakey report showing the issues this new build script would need to address.

Fontbakery report at commit fc21fae

Fontbakery version: 0.7.27

[2] Family checks
πŸ”₯ FAIL: Does font file include unacceptable control character glyphs? * [com.google.fonts/check/family/control_chars](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/family/control_chars) 
--- Rationale ---

Use of some unacceptable control characters in the U+0000 - U+001F range can
lead to rendering issues on some platforms.

Acceptable control characters are defined as .null (U+0000) and CR (U+000D) for
this test.
* πŸ”₯ **FAIL** The following unacceptable control characters were identified: CascadiaCode.ttf: uni0009 [code: unacceptable]
⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available? * [com.google.fonts/check/ftxvalidator_is_available](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/ftxvalidator_is_available) 
--- Rationale ---

There's no reasonable (and legal) way to run the command `ftxvalidator` of the
Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc.

If Font Bakery is not running on an OSX machine, the machine running Font
Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure
call (rpc).

There's an ssh example implementation at:
https://github.com/googlefonts/fontbakery/blob/master/prebuilt/workarounds
/ftxvalidator/ssh-implementation/ftxvalidator
* ⚠ **WARN** Could not find ftxvalidator.

[17] CascadiaCode.ttf
πŸ”₯ FAIL: Checking file is named canonically. * [com.google.fonts/check/canonical_filename](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/canonical_filename) 
--- Rationale ---

A font's filename must be composed in the following manner:
<familyname>-<stylename>.ttf

- Nunito-Regular.ttf,
- Oswald-BoldItalic.ttf

Variable fonts must list the axis tags in alphabetical order in square brackets
and separated by commas:

- Roboto[wdth,wght].ttf
- Familyname-Italic[wght].ttf
* πŸ”₯ **FAIL** The file 'CascadiaCode.ttf' must be renamed to 'CascadiaCode[wght].ttf' according to the Google Fonts naming policy for variable fonts. [code: bad-varfont-filename]
πŸ”₯ FAIL: Substitute copyright, registered and trademark symbols in name table entries. * [com.google.fonts/check/name/unwanted_chars](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/unwanted_chars) * πŸ”₯ **FAIL** NAMEID #0 contains symbols that should be replaced by '(c)'. [code: unwanted-chars]
πŸ”₯ FAIL: Are there non-ASCII characters in ASCII-only NAME table entries? * [com.google.fonts/check/name/ascii_only_entries](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/ascii_only_entries) 
--- Rationale ---

The OpenType spec requires ASCII for the POSTSCRIPT_NAME (nameID 6).

For COPYRIGHT_NOTICE (nameID 0) ASCII is required because that string should be
the same in CFF fonts which also have this requirement in the OpenType spec.

Note:
A common place where we find non-ASCII strings is on name table entries with
NameID > 18, which are expressly for localising the ASCII-only IDs into Hindi /
Arabic / etc.
* πŸ”₯ **FAIL** Bad string at [nameID 0, 'utf_16_be']: 'b'© 2020 Microsoft Corporation. All Rights Reserved.'' [code: bad-string] * πŸ”₯ **FAIL** There are 1 strings containing non-ASCII characters in the ASCII-only NAME table entries. [code: non-ascii-strings]
πŸ”₯ FAIL: Copyright notices match canonical pattern in fonts * [com.google.fonts/check/font_copyright](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/font_copyright) * πŸ”₯ **FAIL** Name Table entry: Copyright notices should match a pattern similar to: "Copyright 2019 The Familyname Project Authors (git url)" But instead we have got: "Β© 2020 Microsoft Corporation. All Rights Reserved." [code: bad-notice-format]
πŸ”₯ FAIL: There must not be VTT Talk sources in the font. * [com.google.fonts/check/vttclean](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/vttclean) 
--- Rationale ---

The goal here is to reduce filesizes and improve pageloading when dealing with
webfonts.

The VTT Talk sources are not necessary at runtime and endup being just dead
weight when left embedded in the font binaries. The sources should be kept on
the project files but stripped out when building release binaries.
* πŸ”₯ **FAIL** Some tables containing VTT Talk (hinting) sources were found in the font and should be removed in order to reduce total filesize: TSI0, TSI1, TSI2, TSI3, TSI5 [code: has-vtt-sources]
πŸ”₯ FAIL: Variable font weight coordinates must be multiples of 100. * [com.google.fonts/check/varfont_weight_instances](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/varfont_weight_instances) 
--- Rationale ---

The named instances on the weight axis of a variable font must have coordinates
that are multiples of 100 on the design space.
* πŸ”₯ **FAIL** Found a variable font instance with 'wght'=350.0. This should instead be a multiple of 100. [code: bad-coordinate]
πŸ”₯ FAIL: Name table entries should not contain line-breaks. * [com.google.fonts/check/name/line_breaks](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/line_breaks) 
--- Rationale ---

There are some entries on the name table that may include more than one line of
text. The Google Fonts team, though, prefers to keep the name table entries
short and simple without line breaks.

For instance, some designers like to include the full text of a font license in
the "copyright notice" entry, but for the GFonts collection this entry should
only mention year, author and other basic info in a manner enforced by
com.google.fonts/check/font_copyright
* πŸ”₯ **FAIL** Name entry LICENSE_DESCRIPTION on platform WINDOWS contains a line-break. [code: line-break]
πŸ”₯ FAIL: Name table strings must not contain the string 'Reserved Font Name'. * [com.google.fonts/check/name/rfn](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/rfn) 
--- Rationale ---

Some designers adopt the "Reserved Font Name" clause of the OFL license. This
means that the original author reserves the rights to the family name and other
people can only distribute modified versions using a different family name.

Google Fonts published updates to the fonts in the collection in order to fix
issues and/or implement further improvements to the fonts. It is important to
keep the family name so that users of the webfonts can benefit from the
updates. Since it would forbid such usage scenario, all families in the GFonts
collection are required to not adopt the RFN clause.

This check ensures "Reserved Font Name" is not mentioned in the name table.
* πŸ”₯ **FAIL** Name table entry ("Microsoft supplied font. You may use this font to create, display, and print content as permitted by the license terms or terms of use, of the Microsoft product, service, or content in which this font was included. You may only (i) embed this font in content as permitted by the embedding restrictions included in this font; and (ii) temporarily download this font to a printer or other output device to help print content. Any other use is prohibited. The following license, based on the SIL Open Font license (https://scripts.sil.org/OFL), applies to this font. Additional license terms may be found on the GitHub repository for this font (https://github.com/microsoft/cascadia-code/blob/master/LICENSE). Permission is hereby granted, free of charge, to any person obtaining a copy of the Font Software, to use, study, copy, merge, embed, modify, redistribute, and sell modified and unmodified copies of the Font Software, subject to the following conditions: 1) Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself. 2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user. 3) No Modified Version of the Font Software may use the Reserved Font Name(s) unless explicit written permission is granted by the corresponding Copyright Holder. This restriction only applies to the primary font name as presented to the users. 4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font Software shall not be used to promote, endorse or advertise any Modified Version, except to acknowledge the contribution(s) of the Copyright Holder(s) and the Author(s) or with their explicit written permission. 5) The Font Software, modified or unmodified, in part or in whole, must be distributed entirely under this license, and must not be distributed under any other license. The requirement for fonts to remain under this license does not apply to any document created using the Font Software. THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE.") contains "Reserved Font Name". This is an error except in a few specific rare cases. [code: rfn]
πŸ”₯ FAIL: Check variable font instances have correct coordinate values * [com.google.fonts/check/varfont_instance_coordinates](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/varfont_instance_coordinates) * πŸ”₯ **FAIL** Instance "SemiLight" wght value is "350.0". It should be "300.0" [code: bad-coordinate] * πŸ”₯ **FAIL** Check has either failed or produced a warning. See our wip spec for further info https://gist.github.com/m4rc1e/8f4c4498519e8a36cd54e16a004275cb
πŸ”₯ FAIL: Check variable font instances have correct names * [com.google.fonts/check/varfont_instance_names](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/varfont_instance_names) * πŸ”₯ **FAIL** Instance name "SemiLight" is incorrect. It should be "Light" [code: bad-name] * πŸ”₯ **FAIL** Check has either failed or produced a warning. See our wip spec for further info https://gist.github.com/m4rc1e/8f4c4498519e8a36cd54e16a004275cb [code: bad-instance-names]
πŸ”₯ FAIL: Checking OS/2 usWinAscent & usWinDescent. * [com.google.fonts/check/family/win_ascent_and_descent](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/family/win_ascent_and_descent) 
--- Rationale ---

A font's winAscent and winDescent values should be greater than the head
table's yMax, abs(yMin) values. If they are less than these values, clipping
can occur on Windows platforms
(https://github.com/RedHatBrand/Overpass/issues/33).

If the font includes tall/deep writing systems such as Arabic or Devanagari,
the winAscent and winDescent can be greater than the yMax and abs(yMin) to
accommodate vowel marks.

When the win Metrics are significantly greater than the upm, the linespacing
can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7
(Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead.
This means the font developer can control the linespacing with the typo values,
whilst avoiding clipping by setting the win values to values greater than the
yMax and abs(yMin).
* πŸ”₯ **FAIL** OS/2.usWinAscent value should be equal or greater than 2280, but got 2226 instead [code: ascent] * πŸ”₯ **FAIL** OS/2.usWinDescent value should be equal or greater than 1220, but got 480 instead [code: descent]
πŸ”₯ FAIL: Are there unwanted tables? * [com.google.fonts/check/unwanted_tables](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/unwanted_tables) 
--- Rationale ---

Some font editors store source data in their own SFNT tables, and these can
sometimes sneak into final release files, which should only have OpenType spec
tables.
* πŸ”₯ **FAIL** The following unwanted font tables were found: Table: TSI0 Reason: Table contains data only used in VTT Table: TSI1 Reason: Table contains data only used in VTT Table: TSI2 Reason: Table contains data only used in VTT Table: TSI3 Reason: Table contains data only used in VTT Table: TSI5 Reason: Table contains data only used in VTT They can be removed with the gftools fix-unwanted-tables script.
πŸ”₯ FAIL: Does the font have a DSIG table? * [com.google.fonts/check/dsig](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/dsig.html#com.google.fonts/check/dsig) 
--- Rationale ---

Microsoft Office 2013 and below products expect fonts to have a digital
signature declared in a DSIG table in order to implement OpenType features. The
EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not
impact Microsoft Office 2016 and above products. 

This checks verifies that this signature is available in the font.

A fake signature is enough to address this issue. If needed, a dummy table can
be added to the font with the `gftools fix-dsig` script available at
https://github.com/googlefonts/gftools

Reference: https://github.com/googlefonts/fontbakery/issues/1845
* πŸ”₯ **FAIL** This font lacks a digital signature (DSIG table). Some applications may require one (even if only a dummy placeholder) in order to work properly. You can add a DSIG table by running the `gftools fix-dsig` script. [code: lacks-signature]
⚠ WARN: Is the Grid-fitting and Scan-conversion Procedure ('gasp') table set to optimize rendering? * [com.google.fonts/check/gasp](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/gasp) 
--- Rationale ---

Traditionally version 0 'gasp' tables were set so that font sizes below 8 ppem
had no grid fitting but did have antialiasing. From 9-16 ppem, just grid
fitting. And fonts above 17ppem had both antialiasing and grid fitting toggled
on. The use of accelerated graphics cards and higher resolution screens make
this approach obsolete. Microsoft's DirectWrite pushed this even further with
much improved rendering built into the OS and apps.

In this scenario it makes sense to simply toggle all 4 flags ON for all font
sizes.
* ⚠ **WARN** The gasp table has a range of 9 that may be unneccessary. [code: non-ffff-range] * ⚠ **WARN** The gasp table has a range of 50 that may be unneccessary. [code: non-ffff-range] * ⚠ **WARN** The gasp range 0xFFFF value 0x0A should be set to 0x0F. [code: unset-flags]
⚠ WARN: Glyph names are all valid? * [com.google.fonts/check/valid_glyphnames](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/valid_glyphnames) 
--- Rationale ---

Microsoft's recommendations for OpenType Fonts states the following:

'NOTE: The PostScript glyph name must be no longer than 31 characters, include
only uppercase or lowercase English letters, European digits, the period or the
underscore, i.e. from the set [A-Za-z0-9_.] and should start with a letter,
except the special glyph name ".notdef" which starts with a period.'

https://docs.microsoft.com/en-us/typography/opentype/spec/recom#post-table

In practice, though, particularly in modern environments, glyph names can be as
long as 63 characters.
According to the "Adobe Glyph List Specification" available at:

https://github.com/adobe-type-tools/agl-specification
* ⚠ **WARN** The following glyph names may be too long for some legacy systems which may expect a maximum 31-char length limit: numbersign_underscore_parenleft.liga, asciitilde_asciitilde_greater.liga and less_dollar_greater.liga.BRACKET.600 [code: legacy-long-names]
⚠ WARN: Checking correctness of monospaced metadata. * [com.google.fonts/check/monospace](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/name.html#com.google.fonts/check/monospace) 
--- Rationale ---

There are various metadata in the OpenType spec to specify if a font is
monospaced or not. If the font is not truly monospaced, then no monospaced
metadata should be set (as sometimes they mistakenly are...)

Requirements for monospace fonts:

* post.isFixedPitch - "Set to 0 if the font is proportionally spaced, non-zero
if the font is not proportionally spaced (monospaced)"
  www.microsoft.com/typography/otspec/post.htm

* hhea.advanceWidthMax must be correct, meaning no glyph's width value is
greater.
  www.microsoft.com/typography/otspec/hhea.htm

* OS/2.panose.bProportion must be set to 9 (monospace). Spec says: "The PANOSE
definition contains ten digits each of which currently describes up to sixteen
variations. Windows uses bFamilyType, bSerifStyle and bProportion in the font
mapper to determine family type. It also uses bProportion to determine if the
font is monospaced."
  www.microsoft.com/typography/otspec/os2.htm#pan
  monotypecom-test.monotype.de/services/pan2

* OS/2.xAvgCharWidth must be set accurately.
  "OS/2.xAvgCharWidth is used when rendering monospaced fonts, at least by
Windows GDI"
  http://typedrawers.com/discussion/comment/15397/#Comment_15397

Also we should report an error for glyphs not of average width.

Please also note:
Thomas Phinney told us that a few years ago (as of December 2019), if you gave
a font a monospace flag in Panose, Microsoft Word would ignore the actual
advance widths and treat it as monospaced. Source:
https://typedrawers.com/discussion/comment/45140/#Comment_45140
* ⚠ **WARN** Font is monospaced but 38 glyphs (2.3399014778325125%) have a different width. You should check the widths of: ['uni0308', 'uni0307', 'gravecomb', 'acutecomb', 'uni030B', 'uni0302', 'uni030C', 'uni0306', 'uni030A', 'tildecomb', 'uni0304', 'hookabovecomb', 'uni0312', 'uni031B', 'dotbelowcomb', 'uni0326', 'uni0327', 'uni0328', 'uni0340', 'uni0341', 'uni0308.case', 'uni0307.case', 'gravecomb.case', 'acutecomb.case', 'uni030B.case', 'uni0302.case', 'uni030C.case', 'uni0306.case', 'uni030A.case', 'tildecomb.case', 'uni0304.case', 'hookabovecomb.case', 'uni031B.case', 'acutecomb.loclPLK', 'acutecomb.case.loclPLK', 'uni0342', 'brevecombcy', 'brevecombcy.case'] [code: mono-outliers]
⚠ WARN: Does GPOS table have kerning information? * [com.google.fonts/check/gpos_kerning_info](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/gpos.html#com.google.fonts/check/gpos_kerning_info) * ⚠ **WARN** GPOS table lacks kerning information. [code: lacks-kern-info]

Summary

πŸ’” ERROR πŸ”₯ FAIL ⚠ WARN πŸ’€ SKIP β„Ή INFO 🍞 PASS πŸ”Ž DEBUG
0 14 5 83 7 66 0
0% 8% 3% 47% 4% 38% 0%

Note: The following loglevels were omitted in this report:

aaronbell commented 4 years ago

Thanks for the bug report and offer of assistance! The decision to create a separate build script for exporting a Google Fonts compatible version is really up to @cinnamon-msft and team. So I'll leave it to them to consider.

I did want to comment on the Fails from Font Bakery: 1) Inclusion of uni0009 was a specific request from a user (#183). I will need additional information regarding issues around this glyph to justify its removal. [edit] In re-reading through that thread and other notes, it appears that the addition of this glyph was not the ultimate resolution to the issue, so I think that this glyph can actually be removed (though it will require fixing a few glyphs' hints). 2) The build process requires a post-process trip through VTT to implement the hints. I feel that this makes the font quality much improved on Windows. Unless someone wants to implement ttfautohint (to our satisfaction), then the VTT requirement will remain. 3) What is the issue with the SemiLight weight? I recall something around how CSS only will accept multiples of 100, but CSS now supports variable font implementation directly, so it may not be an issue anymore. 4) The license statement is IIRC standard to Microsoft. I'll leave it to @cinnamon-msft if they are OK with modifying it. 5) The WinAscent and WinDescent are set intentionally. I don't intend to modify them. Doing so may cause problems with the box drawing characters. And extending the WinAscent and WinDescent beyond their current values is unnecessary. 6) Adding a DSIG is unnecessary, especially for this font which is specifically intended for coding.

And on the Warnings 7) The GASP table has been set correctly. Though if the font is rehinted via ttfautohint, then the GASP table may need to change. 8) The glyph name warning does not appear to be problematic at this time. These longer names have been in use both by us, and Fira Code, for quite some time and there have not been any issues thus far. 9) The warning about monospaceness is an open question. In reading through the discussion about these glyphs, some feel that they should be zero width, and others feel they should be monowidth like all the other glyphs. I've chosen to follow zero width. 10) Font is monospace, so no kerning info. πŸ˜„

aaronbell commented 4 years ago

As a follow up on item 5 above (winAscent and winDescent), I picked 2226 based on the tallest alphabetic character (αΊͺ). Nothing else of consequence extends above that value (pretty much just the box drawing characters). So IMO it doesn't make sense to set the winAscent above that.

Similarly, the winDescent is -480, which is the max alphabetic descender depth. If anything clips below that, it is fine.

davelab6 commented 1 year ago

@nguyen-dows curious about your thoughts on this

nguyen-dows commented 1 year ago

Hi @davelab6, I chatted briefly with Aaron online about this. From my understanding, Font Bakery and Google’s requirements have changed in the last two years. I'll defer to Aaron's judgement and expertise to charter the best course for Cascadia Code :)

alexmyczko commented 1 year ago

Like Arkpandora fonts using Aerial (although I would have found Arielle a better name), Tymes and Veranda. Let me suggest to you "Ciscodia Code" as alternative name.