[build system] look for system-wide installed binaries

[paride]

A minor, wishlist issue relevent for downstream packaging.

It would be nicer if the build scripts did look if the sfnt2woff-zopfli-build and woff2_compress binaries are installed system-wide (i.e., in the $PATH), before looking in the user's home directory.

As an alternative, it would be nice to be able to override the SFNTWOFF_BIN and WOFF2_BIN variables with environment variables.

[chrissimpkins]

We're currently doing this with our Python build dependencies and I was actually thinking through whether to begin to pin those to specific versions. The problem on our end is that it is very difficult to keep up with all of the build dependency releases and confirm that there were not changes that affect our compiles in a way that requires manual visual review before we release. To my knowledge, there is not an approach available to automate testing of rendering diffs so that we can have confidence that the shapes that users see do not change as build dependencies are modified. It is possible to perform a text dump of the binary data in the font files then diff this, but they are enormous files and the last attempt at this with my visual diff/merge tool ran my system out of memory... When you can view the diff, there are always changes with timestamps and other parts of the compiled file (version number strings, etc) that change so there is not a simple approach to say that the file did not change vs. it did change.

I would definitely be willing to implement the env variable override of these settings with the above caveat. If you do override, I would suggest that you be prepared to visually proof the files or have some form of diff approach on hand before you release them to Debian/Ubuntu users. Is this something that you would like to PR in to the shell scripts that we use for the build?

[paride]

I have prepared a simple patch so the scripts fallback to system-wide installed binaries, but only if these are not found in the "unprivileged" ($HOME/...) installation directories used by --install-dependencies. The "unprivileged" installation always takes precedence, so the behavior of your script is largely untouched. I'll wait for the sfnt2woff-zopfli package to be accepted in Debian before submitting the PRs (I think @fabiangreffrath will review it shortly), to be sure that the patches do work well for what will finally land in Debian.

About the visual check, no problem in doing it. I may prepare a LaTeX document to compile and check before releasing new versions. I want the Debian packaged Hack font to be excellent.

[chrissimpkins]

Prefer to use an environment variable approach instead of a hard coded path so that this can be modified by others on different paths as necessary? I liked this idea that you had. It seems to be the most flexible for all. Thoughts?

[chrissimpkins]

About the visual check, no problem in doing it. I may prepare a LaTeX document to compile and check before releasing new versions. I want the Debian packaged Hack font to be excellent.

Paride, we modify the version strings as compiled with fontmake from UFO using the font-v tool. This takes place outside of the current scripted build workflow. I haven't added another dependency because I know that you and the Fedora team are working through the licensing issues with the current set of dependencies that we have here. It isn't mandatory but it might be helpful to you. We currently add the git commit SHA1 hash at build time to the version string so that we have a link back to the source state at build. This git commit SHA1 stamp is automated (detection of the git commit and write to the OpenType tables) with the tool. It also provides the option to add any Debian and/or Ubuntu specific metadata to the version string that might be helpful to you in these packaged builds. This can be any free text that you'd like.

It's available here if any of this is of use:

https://github.com/source-foundry/font-v

cc: @spstarr : see above as it also applies to Fedora builds if helpful

[paride]

Thanks Chris. I think we know quite precisely what is built and distributed in Debian (it's a precise git tag). At the same time we can't assume the font is built from a git repository (it is built from a tarball that is generated from git, but it's not a git repository itself). Still adding some information could be useful, even the simple fact that it is a Debian build. If I package font-v I'll let you know...

[chrissimpkins]

Sounds good. Figured it would be worth mentioning as there may be Debian specific metadata now or in the future that is worth capturing in your builds.

[fabiangreffrath]

We currently add the git commit SHA1 hash at build time to the version string so that we have a link back to the source state at build.

We should make sure that this doesn't get in the way of the reproducible builds effort: https://wiki.debian.org/ReproducibleBuilds

[chrissimpkins]

@fabiangreffrath @paride see the new issue reports that I just posted today about pinning Python dependencies and using an explicit git commit time to define data in the OpenType tables:

https://github.com/source-foundry/Hack/issues/400

https://github.com/source-foundry/Hack/issues/401

Please weigh in and let us know how this affects you on Debian.

[chrissimpkins]

We are trying to make these builds completely determined by source at a specific commit. The compiler currently timestamps OpenType tables in the font binaries so the time of build will make your text diff of an OpenType table dump and hash comparison of font binaries differ from those that we push as releases based upon this difference (but nothing else in the font binary changes). Interested in your opinions about these issues from the Linux packaging standpoint.

[chrissimpkins]

If helpful, we will be adding this shell script to the repository. It does not add any additional dependencies (save for git but I am assuming that is not an issue...) and can be used to directly diff the OpenType tables across any two font builds.

https://github.com/source-foundry/Hack/issues/402

[chrissimpkins]

We should make sure that this doesn't get in the way of the reproducible builds effort: https://wiki.debian.org/ReproducibleBuilds

@fabiangreffrath this is not currently implemented as part of our make based build workflow. I suggested this to Paride as it is an option if you need to maintain any state metadata in the compiled binaries for any reason. As is, your make builds will compile a version string with the definitions that fontmake uses based upon the source files along with ttfautohint applied metadata. This will include version strings that look like this:

Version X.XXX; [ttfautohint metadata]

Our changes do not lead to non-reproducible builds assuming that you build at the same git commit. Our release file version strings look like this:

Version X.XXX;abcd123-release;[ttfautohint metadata]

where abcd123 represents the git commit sha1 short hash for the git commit used to build and -release indicates that it is a release build (contrasted with -dev builds that represent WIP towards the next release).

[chrissimpkins]

Paride, if the fonts are being compiled prior to distribution to users why is this necessary? Does a move to a newer version of a dependency automatically invalidate prior versions or would it be possible to compile these pinned versions of C/C++ projects each time the fonts are built for a new Debian release? I am trying to tackle the balance between pinned versions and unpinned versions across all of our dependencies. I'd be interested in how you are addressing this with the ttfautohint project. Does Debian build with the current packaged releases of Harfbuzz and FreeType when that project is built? This is a separate, additional issue because we recently ran into problems with ttfautohint when I tried to bump the ttfautohint, Harfbuzz, and FreeType release versions. Are you using Debian packaged ttfautohint or are you hinting with the scripted version compiled with the build scripts in this repository?

[spstarr]

@chrissimpkins sfnt2woff-zopfli is not in Fedora nor any package review for this yet... I'll have to look at packaging this also.

[spstarr]

@chrissimpkins likewise for your font-v program, I can get it packaged as well

[paride]

@chrissimpkins they are compiled prior to distribution, and I am using the Debian packaged ttfautohint (remember: no external dependencies).

If a build-dependency is upgraded, then the package is rebuilt only if upgraded, or if the maintainer explicitly marks it to be rebuilt. Otherwise it is not.

Also remember that Debian "stable" is mostly a frozen distribution once it's released. The rolling ones are the "testing" and "unstable" branches, mostly used by developers or enthusiasts.

[chrissimpkins]

sfnt2woff-zopfli

font-v

ty @spstarr !

[chrissimpkins]

@paride @spstarr The comments are now being distributed across a few threads here but all are related to how we make this build process as consistent, reproducible, and stable as possible so that what your users see is what they would see if they install from this repository. I am struggling with how to provide upstream help with this in light of the build approach that is used on Linux distros. I am assuming that this is not a new problem because you are already distributing other fonts with the same approach. This may be the first time that both repos compile fonts from source with this set of build tooling based upon the fact that these tools are just being approved on both distros? Let's see how it works. I am open to suggestions if there is anything that we can do to be of help.

[paride]

@chrissimpkins for sure it's one of the first times, but the software is really the same, just packaged differently. I think that for other fonts built from source, the authors just trust the build process...

[chrissimpkins]

I think that for other fonts built from source, the authors just trust the build process...

My compulsiveness is showing? I trust nothing :)

Actually, I absolutely trust the tools and that they will do the right thing within the confines of what they test inside their respective projects as well as semantically version according to the changes that they make based upon their project-specific tests. We wouldn't use them if that were not the case. The problem is that we haven't established a simple way to test against that assumption across the entire build chain at the compiled font level in order to assure all involved (including myself on builds released through this repo) that what you build with one set of build dependency versions will be similar to what is built with another combination. This is why you are sensing my hesitancy about these build issues. We have had some issues in the past with SemVer semantics as the indicator to let us know when/if it is ok to escalate versions of the tools because these assumptions about backwards incompatibility are challenging to test in some cases at the build tooling and final font binary level and errors can be made in any of the projects that we can't detect upstream until they are rendered on specific platforms x renderers. It all kind of boils down to a simple lack of control of the entire process for someone who likes to have a handle on the levers of control over the moving parts. Unfortunately, in typeface software, there are way too many moving parts across the spectrum of build to render ever to have any semblance of control to reach that level of quality assurance. I've discussed this process with professionals in typeface development and the testing for many out there is manual. They load the fonts up in software that will be commonly used to display the type (e.g., Adobe design products, Microsoft Office products) and look at it across platforms where different renderering approaches might be used to display the typeface. I use something similar here. I am now viewing our releases across a select set of glyphs in commonly used software development text editors across platforms and over our design target sizes, intentionally including some editors (ahem, JetBrains) that have caused us some troubles in the past. Clearly, if you add up the number of different possible editors by platform it is not feasible to test across anything but a small range of the spectrum of possible renders of the face out there. Even with the limited number of editors, this is a tremendous amount of work and I do it because I expect the face to reach that standard. I don't expect anyone downstream to take this level of interest in the quality. If you do, that is great but you really shouldn't need to spend your time on this. We should be able to deliver you software source and an approach that you and others can use to test the software quality similar to the way that this is done for other forms of software. You should only need to build and test it with that tooling. The reason that we are having these conversations is to attempt to offload that issue from you and other packagers and back onto the upstream authors in this project. This is a shortcoming in typeface software development. I would like to see if we can create a better testing approach to make what is currently a manual process more automated. Those challenges to make Hack behave like other forms of software are a big part of what make it enjoyable for me. I appreciate all of your feedback as I think aloud about these issues.

Ultimately, it is only a typeface. I recognize that. I like to think that we set the quality standard bar a bit higher than that statement implies though. :)

[chrissimpkins]

@spstarr font-v is 100% optional and not part of the scripted build process here. We use it after the scripted build to label build files with the git commit SHA1 that was used at compile time. This is automated as a simple, single command with that tool and can be easily scripted if that is helpful at all. You can also use it to add any other free text metadata that you'd like to your builds if there are any Fedora specific needs that should be maintained in the font binaries. It writes to the nameID 5 table of the fonts (and another table with only the version number if you happen to use it to change the version number string, likely irrelevant for your use case because this will be defined in the source).