ryanoasis
Update Inconsolata to v3.000
Description
Update Inconsolata to current release v3.000.
https://github.com/googlefonts/Inconsolata
Only small changes visually, but of course completely different from the paths (because now the source is a 2D variable font).
Small letter t changed a bit. Under the letter dot and block-building glyphs changed. Subscript numerals.
Requirements / Checklist
- [x] Read the Contributing Guidelines
- [x] Verified the license of any newly added font, glyph, or glyph set
What does this Pull Request (PR) do?
Update source font files. Update generated files.
How should this be manually tested?
Any background context you can provide?
Discussion #774
What are the relevant tickets (if any)?
Screenshots (if appropriate or helpful)
This does not include all the new widths and weights. This PR includes only bold and regular, and so it just updates but does not expand.
It also does not touch the very old InconsolataGo and Inconsolata LGC that we also have...
Now that the github action is rebuilding the fonts on merging to master I think we should change font updates and new font PRs to not actually update the patched-fonts/ directory and let that happen in the pipeline instead. I think just a spot check by a user is sufficient going forward. I'd see this as a welcome change but not sure what everyone else thinks
I'd see this as a welcome change but not sure what everyone else thinks
In my opinion this is an excellent change, as with this we exactly know that the patched font in the repo is the same as we would create, and not some user patched it with an older font-patcher or did some manual adjustments afterwards. Manual changes might be helpful sometimes, but the knowledge about them will be lost (or be nonexisting if not mentioned in the PR).
One small drawback is that you can not immediately see the patch results. One possible solution would be this:
- On (any) PR the workflow is run (on changed fonts)
- But without back-commiting of the patched fonts (as this will be impossible in the general case)
- Only the artifacts for changed fonts will be generated
- If a change for
font-patcheris PRed there are no changed fonts, this is ok I believe (-> no artifacts, needs exhaustive testing anyway) - If a font is added or changed that fonts are patched and artifacts generated for them
For this to work we need to find out which font files are changed and which are already up-to-date in the repo. This might be tricky, but doable.
Why is the SVG workflow triggered? This is a bug? This PR does not touch any relevant files. Maybe because I force pushed, so all the commits since the OLD master are considered?
