Standalone tool approach

[chrissimpkins]

Is it necessary based upon the processes being built for this to live in a typeface repository? A thought struck me this morning that this could be completely user driven and exist as a standalone tool independent of the typeface project git repository. My understanding is that the configuration happens at the configure step of the workflow, so it would be possible to simply modify anything that would be hard set as a constant within a typeface repository to something that works like the following:

$ ./configure --github=testrepo/coolfont --srcpath=src --fontname="Cool Font" --unicode-range=0020:0200

and/or

$ ./configure --archive="github.com/testrepo/coolfont.tar.gz" --srcpath=src --fontname="Cool Font" --unicode-range=0020:0200

assuming that all of the UFO parsing, linking, build processes can be generalized without the need for hard coding by the typeface developers.

The benefit is that this would allow users to drive this tool forward rather than requiring adoption by typeface developers. It would then be generalized to any project that uses open UFO source and is hosted anywhere with public remote access immediately on release here. It would also simplify the process of permitting users to benefit from updates to autofont as they happen here. They can either pull new changes or install with package managers (see suggestion below).

If this would work, it might even be possible to place an executable in front of all of the autotools tooling on PATH so that users could do something like the following:

$ autofont --archive="github.com/testrepo/coolfont.tar.gz" --srcpath=src --fontname="Cool Font" --unicode-range=0020:0200

and simply build anything out there that is UFO based in a highly configurable way. This could all be wrapped up in packages for package managers for distribution of autofont updates.

[jameslikeslinux]

No, it is not necessary for these build tools to live in the typeface repository. A standalone version a good idea that could be implemented fairly easily. In fact, I'm already doing a sort of crude version of this for my tests: downloading and unpacking Hack from a GitHub archive:

https://github.com/source-foundry/autofont/blob/1d860a90d59696574c925de3b369d044aceec144/test/fixtures/GNUmakefile

and then pointing configure at it:

https://github.com/source-foundry/autofont/blob/1d860a90d59696574c925de3b369d044aceec144/test/helpers#L25

it wouldn't take much effort to add that ability to the main configure/makefiles and make it configurable. I will keep this in mind as the project develops.

The reason I'd prefer to focus more on the ability of autofont to live inside of a font project is informed by years of maintaining packages for Solaris, Red Hat, and Gentoo. Namely, my experience tells me that:

1. OS package build environments should not be expected not to have internet access. All of a package's source and build tooling must be distributable (think of a source RPM). That's not to say the sources and build tooling have to be the same package, but it certainly helps. If they're not in the same package, then all of the distros would have to build and support autofont as a separate package, and that's a hard argument to make for a new, as of yet unproven, product. It is much easier to convince distros to build packages for fonts that already have a familiar configure; make; make install idiom built right into them.

2. At least in the early stages of the project, all of the features and tunables needed to support every typeface project's unique requirements may not exist, and by including autofont directly in the project, it gives ambitious developers an opportunity to fork and fix autofont, and use it while their change makes its way through the upstream review and release process.

3. It eliminates any question about whether a given typeface repository is supportable by autofont. If the repository has it, then you know it's supported.

TL;DR: We can and should support both approaches, my opinion is that the "resident" approach should be prioritized.

[chrissimpkins]

good idea that could be implemented fairly easily

👍

Approach seems to depend on whether you are primarily (or simultaneously) targeting end users or package maintainers. Definitely agree with self-contained code comments re: package maintainers. This is what all of our package maintainers demand and I am quite certain that anyone who tackles package maintenance will dig into autofont to customize as they want based upon broad distro/platform specific issues if they intend to use it for redistribution. My feeling is that customization with hinting adjustments are the most likely customization feature to take place in the redistribution package realm.

I see end users more attracted to the ability to subset (e.g. to create very slim web fonts for web sites/apps or mobile applications) and modify glyphs with alternates (replacements, extensions) which is something that redistribution packagers are less likely to use (clearly opinion, perhaps there are uses for this as well but my guess is that they largely attempt to maintain rather than modify the overall design with redistribution packages - if there are really significant platform specific rendering issues in the design the typeface has bigger problems than this tool will be able to correct and that is a fix that belongs in the upstream source). I think that it is fairly safe to assume end users who would be applying such a tool have internet access and could use it as a standalone approach to configurable builds.

At least in the early stages of the project, all of the features and tunables needed to support every typeface project's unique requirements may not exist

This is a very valid point. The processes that function within the confines of the UFO source specification should be standardized across repositories so long as they are using valid UFO and there is a valid filepath to it. The hinting will throw a wrench into the works because control instructions files will not have standard paths in the repo. Either these definitions are configurable and sit in repo (seems we are beginning to reach a lengthy list of configure configuration command line options at this stage...) or we define a "spec" for the use of the tool and developers are required to modify repo to meet that spec. The former seems to be the better approach. I guess the question becomes how to support users who want to customize a typeface when a development team has no interest in the implementation of support for this. That will be the group who have no approach to achieve what they want and this falls well within the bounds of free open source use. If this is a simple clone typeface repository, drop in autofont, and configure process, then this could be the solution for them. It is all performed as part of a downstream fork.

Thoughts about the approach to repository specific configurations? New dotfile? Constants in the autotools files that permit simple modifications?

It eliminates any question about whether a given typeface repository is supportable by autofont. If the repository has it, then you know it's supported.

Agree.