source-foundry / font-v Goto Github PK

View Code? Open in Web Editor NEW

19.0 19.0 5.0 689 KB

Font version string reporting and modification library + executable tool

Shell 0.22% Python 99.78%

font library opentype otf python sha1 ttf typeface versioning

font-v's People

Contributors

Stargazers

Watchers

Forkers

ashang moyogo isabella232 zoiezhou daltonmaag

font-v's Issues

font-v Typeface Versioning Specification

Spec should:

not violate OpenType (name table ID 5) version string specification
extend OpenType spec with new DEV/REL status meta data
extend OpenType spec with new git commit SHA1 status meta data

Version substring definitions for this specification:

[Version];[Status];[Other Metadata 1];[Other Metadata ...]

where

Version is the version Major.Minor number label using OpenType definition formatting
Status is an indicator of source state at the time of font compilation and intent for general use of the font software. There can be multiple Status changes across a given Version.
Metadata are any data beyond the above definitions (compiler and post-compile tooling specific)

[libfv] Add public getter method for git commit sha1 hash substring state label

Rething short SHA handling with an eye on determenistic builds

This has become a little bit of a sore point for me working on Fontship. I'm keeping an eye on reproducible builds for fonts as a long term goal and one thing that changes on me is how long the SHA is. This is a moving target because ⓐ upstream Git keeps changing their defaults and ⓑ global user configs can change this. My local system is generating 8 character short SHAs, remote CI is giving me 7.

I'd like to either be able to specify the SHA myself (I have the information already, I could pass it to font-v and save it the trouble of looking it up) or at least a way to specify it manually. Currently the only workaround I can think of is to fiddle with the local working directory's Git config before running font-v which kind of feels aggressive to me.

See #2 for discussion of current handling.

Add option to define checksum / mod time recalculation on file writes

Based on discussion with Cosimo in 27feb56

Add version write to head.fontRevision for all version number changes

Should be formatted as MAJOR.MINOR with padding of the MINOR string with up to two zeroes (total of three digits). MAJOR can include one digit.

Version not set in CFFFont table

For fonts with CFF subroutines, there is a CFFFont element with a version property. This value is not getting set by font-v to match the surrounding font version.

For example here is a (simplified) diff of a font in the Libertinus font project with the version set by it's old internal build script and now my trying to build the same sources without inputting a version and setting the version later with font-v:

--- /home/caleb/scratch/Libertinus-6.12/LibertinusSans-Italic.otf	2020-06-28T15:56:49+03:00
+++ LibertinusSans-Italic.otf	2020-08-18T12:47:49.742210+03:00
@@ -2433,13 +2433,13 @@
   <head>
     <!-- Most of this table will be recalculated by the compiler -->
     <tableVersion value="1.0"/>
-    <fontRevision value="6.12"/>
-    <checkSumAdjustment value="0x30ef053d"/>
+    <fontRevision value="7.000"/>
+    <checkSumAdjustment value="0x4ed7a053"/>
     <magicNumber value="0x5f0f3cf5"/>
     <flags value="00000000 00000011"/>
     <unitsPerEm value="1000"/>
@@ -6966,7 +6966,7 @@
     <major value="1"/>
     <minor value="0"/>
     <CFFFont name="LibertinusSans-Italic">
-      <version value="6.120"/>
+      <version value="1.0"/>
       <Copyright value="Copyright Copyright 2012-2020 The Libertinus Project Authors."/>
       <FullName value="Libertinus Sans Italic"/>
       <FamilyName value="Libertinus Sans"/>

[libfv] Add support for FontVersion object instantation with a fontTools ttLib.TTFont object

Recommended (with associated source approach) by @graphicore in #15 (comment)

Avoids the need for calling code to obtain the font file path from the TTFont object (or other means).

Add .otf file testing

Version not set in Unique ID field

Similar to #104 I found another place font versions frequently show up that isn't being normalized:

Somehow nameID=3 (Apple docs: "Unique subfamily identification", Microsoft docs: "Unique font identifier") has come to be frequently filled with a fallback value (probably popularized by ufo2ft precedent) composed of the font version, the short foundry name plus the font name.

Here is an example, the original being straight ufo2ft output where it knew the major/minor version at build time, the update being a run where no version was available to ufo2ft and instead an attempt was made to normalize the font version after the fact with font-v:

--- /home/caleb/scratch/Libertinus-6.12/LibertinusSans-Italic.otf	2020-06-28T15:56:49+03:00
+++ LibertinusSans-Italic.otf	2020-08-18T12:47:49.742210+03:00
@@ -2540,13 +2540,13 @@
       Italic
     </namerecord>
     <namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">
-      6.120;ALIF;LibertinusSans-Italic
+      1.000;ALIF;LibertinusSans-Italic
     </namerecord>
     <namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
       Libertinus Sans Italic
     </namerecord>
     <namerecord nameID="5" platformID="3" platEncID="1" langID="0x409">
-      Version 6.120
+      Version 7.001;RELEASE
     </namerecord>
     <namerecord nameID="6" platformID="3" platEncID="1" langID="0x409">
       LibertinusSans-Italic

Obviously nameID=5 got set properly. Name №3 is a little trickier, but it might be worth looking at the string and seeing if the first segment looks like an OpenFV version string, and if it does update it.

Add head.fontRevision record to report output

Dependabot couldn't authenticate with https://pypi.python.org/simple/

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

Closer match of OpenFV formatting examples

Docs (see Readme and #19) suggests the goal here is to follow OpenFV, but in all the OpenFV examples there is a space between segments (i.e. Version 0.000; [shortsha] not Version 0.000;[shortsha]). Which end gives here, what should be the defaco normalization?

[libfv] Prepend `git-` string to git commit sha1 hash substrings

Suggested by Felipe in #15 (comment)

This would address the inability to uniquely parse the strings for a git sha1 hash alone as there is overlap with non-git sha1 hash words / strings that might happen to use the same set of characters in hex strings.

Refactor font-v report subcommand on libfv library

Add argument number testing for report and write commands

add to report command
add to write command

Add name record encoding to report --dev (optional dev data) information

Include the encoding of the name record in the stdout string reported to user when --dev flag used with the report command:

e.g.

$ font-v report --dev Something-Regular.ttf
Something-Regular.ttf [3/1/1033/5 (encoding='utf_16_be')]:
Version 3.000; c3bcf84-dev;

TODO:

Update documentation with this information

Add increment major/minor version subcommand

`get_git_root_path` should support worktrees

Git supports the concept of multiple working directories connected to different branches of the same repo: https://git-scm.com/docs/git-worktree.

get_git_root_path currently fails to handle it properly and raises OSError: Unable to determine git repository root for font file ....

Add regex test for version string format created from data entered on command line by user

Modify git commit SHA1 state label format

Will be revised to the following format:

[abcd123]
[abcd123]-dev
[abcd123]-release

from

abcd123
abcd123-dev
abcd123-release

as part of the new version specification that is in development. This facilitates parsing of the SHA1 hash string and elimination of duplicate substrings (see #7)

See: #19 (comment)

String encoding by platformID

Current approach:

if record.platformID == 0:
    record.string = version_string.encode('utf_16_be')  # Unicode platform ID gets UTF16 big endian
elif record.platformID == 1:
    record.string = version_string                      # Mac platform ID
elif record.platformID == 3:
    record.string = version_string.encode('utf_16_be')  # Windows platform ID gets UTF16 big endian

TODO:

add from __future__ import unicode_literals to module
let fontools encode proper string by platformID type (see #1 (comment))
use unicode alias and tounicode function in fonttools py23 module to encode properly before use of fonttools library for the string write (see #1 (comment))
test encoding of strings and exception handling for string encoding in Py 2 + 3

Per conversations with @davelab6 and @anthrotype, the platformID 1 version strings are not used to any significant degree any longer so the platformID writes should see limited use out there. It sounds as though there is some legacy use of the platformID 1 records on old versions of Mac (maybe even pre OS X) applications.

Review of numerous fonts (including commercial) shows that the platformID 1 version strings are almost universally present so we should still support the correct modification of this record here.

Remove font-v string encoding prior to name table modification with fonttools

This is handled for name tables by platformID on fonttools library end .

See #1 (comment)

Lines that require modification begin here:

https://github.com/source-foundry/font-v/blob/master/lib/fontv/app.py#L131

[libfv] Add libfv version string "linting" / error reporting

As discussed in #15 (comment)

[libfv] Add public getter method for version number

[libfv] Add fontv.libfv.FontVersion equality comparison support

From discussion here:

#15 (comment)

Add deprecation warning for FontVersion.get_version_string method

Following v0.6.0 refactor, the method name will be refactored to FontVersion.get_name_id5_version_string().

Deprecation warning added as of v0.6.0. Method will be removed in a future release.

Remove font checksum recalculations on file writes

Add major version / minor version iterator support

print resulting version string upon successfully running the write subcommand

A user will typically want to make sure the new version string is correct / looks good. So it is very likely that the user will run the report subcommand right after running the write subcommand like this:

Because of that I'd suggest the success message for the write subcommand to print something like this instead:

Version string successfully updated to: "Version 1.006; RELEASE"

So that there's no need to use report right after write.

`get_git_root_path` only checks three levels up

I’m generating fonts/otf/unhinted/instance_otf/NotoSansDuployan-Regular.otf in a Git repository and trying to use set_state_git_commit_sha1, but it can’t determine the commit hash because it can’t find the .git directory. Why is get_git_root_path limited to looking three levels up?

Fix Appveyor testing

This project will be affected by the Appveyor issue in source-foundry/ufodiff#17

requires modification of the Appveyor settings file

Add unicode_literals import to all modules

from __future__ import unicode_literals

See #1 (comment)

TODO:

add to current modules

Change interpreter to python3

Hello @chrissimpkins, it seems that your code supports Python 3, but by default the interpreter which is used is python, that is Python 2. This won't work out-of-the-box on Python3-only installations. Also, Python2 is going to reach its end of life in about one year. Please switch to python3.

Remove previous release / dev tag when present

e.g.

Version 1.000; DEV should convert to Version 1.000; RELEASE (and not Version 1.000; RELEASE; DEV) when the dev tag identified and vice versa.

TODO:

update docs with how this is approached as of v0.3.0
fix DEV/RELEASE duplication
fix sha1-dev/sha1-release duplication
fix sha1 only dupes

Add clear subcommand

to remove all metadata beyond Version [\d.]+ and start from scratch.

Add set_state and get_state public methods to libfv library

Add str method to libfv.FontVersion class

Support print(FontVersion) statements with informative human readable data

expose the font version string generation code for third-party programs to use them

Due to fonttools/fontbakery#1563 I've been wondering. I can do any of these:

copy/paste some of your python code into FontBakery
install font-v as a dependency and invoke it using subprocess.popen
refactor font-v so that the code that generates version strings can be nicely imported into fontbakery and used

I'd definitely prefer the third option!

So, I see that the bulk of the code is on app.py inside the main function. Would it be OK to move some of that functionality into a separate python file (it maybe could even be the utils.py file) and then export that as a python module ?

Fontbakery (and any other tool) could then do things like:

from fontv.utils import FontVersionObj as fvo
expected = fvo.compute_version_string(fontpath, sha1=True)

version string formatting

render in OTM_Light:

Can confirm that version string does not display in FontBook after font-v modifications.

Remove deprecated FontVersion.get_version_string method

Method deprecated as of v0.6.0. Replaced with FontVersion.get_name_id5_version_string() method.

There is currently a deprecation warning for calling code that uses the deprecated method. Use should convert to the new replacement method.

The deprecated method will be removed in a future release.

TODO:

fix in font-v executable
fix in libfv library

Encode version strings with fonttools unicode alias + cast with fonttools tounicode function

Transparent unicode encoding on Py 2 + 3

from fontTools.misc.py23 import unicode, tounicode

# cast all command line data to fontTools unicode type with tounicode function

See #1 (comment)

Move to Python 3.7+ support (remove Python 3.6 support)

The gitpython project recently removed Py 3.6 support. In order to include further library updates we will need to do the same.

Failing CI due to lack of Py 3.6 support in gitpython update ==> #153

Chance of short SHA1 hash collision at 7 character hash string

Currently using a default git commit SHA1 string size of 7 characters. Is this enough for typical typeface project?

source-foundry / font-v Goto Github PK

font-v's People

Contributors

Stargazers

Watchers

Forkers

font-v's Issues

Recommend Projects

Recommend Topics

Recommend Org