Building Hack on Fedora tracker

[spstarr]

Is this issue resolved? Fedora still does not have the fonts, I've taken over the packaging but we need a way to build these fonts to satisfy Fedora's policy:

"Fonts SHOULD be built from source whenever upstream provides them in a source format"

[chrissimpkins]

We do not have an automated build chain at the moment. You can build them from the source with Font Forge. How are you building other fonts?

[mavit]

DejaVu, for example, comes with a Makefile containing the recipe for building the fonts. I see it calls a number of scripts to do the work, including several that call FontForge (e.g., generate.pe). If Hack is based on DejaVu, maybe these can be largely reused?

[davelab6]

Its easy to automate fontforge builds with FF script (PE) or Python

[spstarr]

This is Fedora's full build for DejaVu fonts:
http://pkgs.fedoraproject.org/cgit/rpms/dejavu-fonts.git/tree/

[mcepl]

Its easy to automate fontforge builds with FF script (PE) or Python

Then I guess you would have no problems to provide PR with those scripts, right? What I mean is that we shouldn’t just require upstream to fix our problems, but we should help.

[spstarr]

We can build the fonts manually in the .spec I just didn't know since that's not documented. If the DejaVu fonts build is the same for Hack, then Fedora can adapt this in our packaging.

[chrissimpkins]

@spstarr still interest in this? Any progress?

[spstarr]

Yes interested, just sidetracked in RL, are there any bugs I need to be aware of right now that impact building?

[spstarr]

I will be building today, finally.

[chrissimpkins]

just sidetracked in RL

Believe me, this was not a nudge. Just trying to clean up IR's. I am the last person to do this given my own capacity to attend to the project recently.

are there any bugs I need to be aware of right now that impact building

No Linux bugs that I am aware of that should cause issues for you

I will be building today, finally.

👍 Congrats!

When you have a chance, can I ask you to provide me with how you would like to handle Fedora build associated questions when/if we receive them in this repo?

[chrissimpkins]

@spstarr we should also update the README with this information when you are ready to go. For Fedora we currently include the following package manager instructions:

dnf-plugins-core :: heliocastro/hack-fonts :: hack-fonts

[spstarr]

Yes, I would like to work with you to ensure we need no custom patches in Fedora, so any new versions you drop, i can build and push in (or see about any automated build/add to rawhide)

[chrissimpkins]

@spstarr you've scripted the build process? We changed our release directory structure to facilitate releases on a different Linux distro. Let me know if there is anything that I can do on our end to help you with the Fedora releases.

[chrissimpkins]

Adding this information that was discussed in another IR and in the Haack fork repo re: hinting in the fonts based upon the title of this thread:

For ttf files (recommended for use across all platforms), I built with FontLab V as “pre-hinted” ttf build files, then used our ttfautohint based scripted hinting approach that is contained in the following script file:

https://github.com/chrissimpkins/Hack/blob/master/postbuild_processing/tt-hinting/autohint.sh

This uses hinting settings that are defined in the -TA- files in this directory:

https://github.com/chrissimpkins/Hack/tree/master/postbuild_processing/tt-hinting

These files apply optimized hinting to the main character set files that are used in code. We never ran through optimizations for extended character sets that were not commonly used in code because this was not our goal. If you replicate this approach, you will get hinting in your new ligature characters (ttfautohint hints all characters in the set) but you may need to tweak these if you find that they do not look as intended at certain glyph sizes.

For otf files, the build files are hinted with the built in otf hinting used in FontLab V. You will get good automated hinting of otf files in Glyphs as well (probably better c/w FontLab).

On OS X, the hinting is automated by the operating system and hints are ignored. TTF and OTF files should both look similar and good.

For Windows and Linux, the hints really, really matter (see a large number of the closed issue reports) and I suggest that you investigate how your new glyphs appear at a range of sizes commonly used in code editors if you are targeting these platforms.

[spstarr]

I started, a little, today more... I'll put up a .spec file on my fedora page soon.

[chrissimpkins]

@spstarr let me know if there is anything you need from us. Be happy to explain the hinting process if it would be helpful to you. Thanks Sean.

[spstarr]

@chrissimpkins I'm following all your changes right now I see 3.0 is coming but not yet. I'll have a spec file that builds this but not against 3.0, I don't want to say this week, but this weekend I should get more time.

[chrissimpkins]

@spstarr note the change in source structure if you are pulling source for your build. Once our build chain is in place this may be something you want to convert to. Part of the goal of this effort so that we offload this from you!

[chrissimpkins]

@spstarr OK if I hijack this thread to use for the general build toolchain conversation? Happy to create a new one if you want this to be Fedora specific.

[spstarr]

No problem this is fine

[chrissimpkins]

@spstarr great thanks. more updates re build chain coming this weekend

[chrissimpkins]

build dependencies will include Python 2.7 or Python 3.5+

[chrissimpkins]

desktop ttf file build dependencies will include:

• fontmake - v1.2.7+ (Python, available on PyPI pip install fontmake)
• ttfautohint v1.6+ (C, https://www.freetype.org/ttfautohint/)

[chrissimpkins]

New functionality was introduced in ttfautohint 1.6 that we will be using in our manual hints. v1.6+ will be mandatory for ttfautohint. fontmake does not necessarily need to be pinned to the current version at this stage. I will keep an eye on the fontmake project changes and update if they introduce something that we anticipate to break our builds in some fashion.

[spstarr]

An Update on dependencies for python-fontmake:

python-setuptools_scm_git_archive has been approved in Rawhide now
python-booleanoperations is in review, should be approved soon hopefully.
python-pyclipper is taking time, packager is working with upstream on de-bundling this

Once these clear, python-fontmake will be ready for review and I'll give it review then we can get onto getting Hack 3.0 in.

[chrissimpkins]

@spstarr excellent! good news! Thanks for the update

[chrissimpkins]

For those who re-distribute with our compiled fonts via Github releases, we will be adding tar.gz archives to the releases. The following archives will be supported:

• zip
• tar.gz
• tar.xz

The current archive file path format will be:

Hack-v3.000-ttf.zip
Hack-v3.000-ttf.tar.gz
Hack-v3.000-ttf.tar.xz
Hack-v3.000-webfonts.zip
Hack-v3.000-webfonts.tar.gz
Hack-v3.000-webfonts.tar.xz

Issue report #325 if you'd like to discuss. Note slight file path change from previous format:

Hack-v3_000-ttf.zip

[chrissimpkins]

Hack v3.000 PR is now available for review. Goal for release ~ 2 weeks.

#335

[chrissimpkins]

v3.000 release is now merged to master and live. Thanks all for your feedback and help with this major release!

[spstarr]

We are still blocked in Fedora, I'll see if I can intervene in the package review where possible.

[chrissimpkins]

@spstarr thanks! let us know if there is anything that we can do on our end. This an issue with build dependencies?

[spstarr]

@chrissimpkins Yes, python-booleanoperations, python-pyclipper dependencies for python-fontmake. The problem right now is python-pyclipper bundles systems libraries, upstream is looking at modifying their install to support the system libraries (see here: fonttools/pyclipper#10). If that is the solution, then the packaging for this can just set the environment variable accordingly to use the system lib.

For python-booleanoperations, it is blocked on python-pyclipper...

I've responded to the bugzilla tickets to see if they need help pushing the reviews. Though for python-pyclipper, I'm hoping that will be resolved soon. Otherwise, Fedora could provide distribution specific patches to use the system libs to workaround this in meantime.

[chrissimpkins]

@spstarr thanks for all of your help! sorry it is such a hassle.

[spstarr]

Further below:

"Yes, it is already done. The problem is the the latest polyclipping ABI is
different from the one used in this python package. We should also patch it to
use the latest ABI."

https://bugzilla.redhat.com/show_bug.cgi?id=1440992

[davelab6]

Fedora does have groups, there is no Font Development group,

There is the https://lists.fedoraproject.org/admin/lists/fonts.lists.fedoraproject.org/ tho

[chrissimpkins]

@spstarr do you want this issue report open until you complete the release process on Fedora? We pulled this into a discussion about the new scripted build approach but this was originally your thread for the Fedora redistribution package. Happy to reopen if this is helpful in any way.

[spstarr]

@davelab6 yeah, the mailing list, I meant there's no comps.xml group to automatically to install dependencies for fonts development in general.

[spstarr]

@chrissimpkins Let's leave it open please. Maybe we can rename this issue?

[chrissimpkins]

@davelab6 Dave, has there been any coordinated effort on the part of OS tool development teams to package up a set of "best practices" compilation/post-compile modification tools for the Linux distros? If not, do you think that this is something worthy of further discussion so that someone/a group of someones can help to establish a consistent set of commonly used tools across all interested Linux distros in order to avoid this issue for other typeface projects out there? It seems that this is currently driven by interested distro users who donate their time to make project specific packages happen. If we think a bit more generally about an approach, we could probably establish tooling that works for many projects x many Linux distros rather than attempting to reinvent the wheel with each new typeface that wants to release on a Linux distro with free software redistribution guidelines like Fedora/Debian/Ubuntu.

I am sure others have faced the issue, but I am guessing most are simply building with fontforge on Linux? With the availability of all of the excellent OS typeface tooling out there, it might make sense for tool authors to become more involved in driving these projects through the Linux review processes. The individuals who take the reins on that would have the opportunity to help define the build process standards on Linux distros given the time-intensive nature of these review processes for redistribution. This is definitely a disincentive for all involved.

[chrissimpkins]

@spstarr opened again. Feel free to rename however appropriate.

[chrissimpkins]

@spstarr any progress on the pyclipping library side with this issue? Is this still where things are stuck?

[chrissimpkins]

@spstarr It doesn't appear that there has been any progress in the linked Fedora thread since October. Is someone still working on this and if not can we close this issue report?

[bkmgit]

Building on Fedora can be partially done using

dnf -y install ttfautohint fonttools
pip install fontmake
git clone https://github.com/source-foundry/Hack
cd Hack

then as indicated at ryanoasis/nerd-fonts#70 (comment) change the contents of the files in postbuild_processing/tt-hinting/ so that the name of the glyph rather than the unicode number is used, for example for Hack-Bold-TA.txt

# U+0021 exclam glyph ID 580
exclam touch 22,23,24,25    y -0.5    @14

# U+0025 percent glyph ID 762
percent touch 0,1,16                     y 0.75   @10,11
percent touch 23,24,25                   y 0.25   @10,11
percent touch 17,18,32,46,47,48          y 0.5    @10,11
percent touch 57,58,71                   y -0.25  @10,11
percent touch 33,34,35,36                y 0.5    @10,11
percent touch 63,64,65                   y 0.75   @10,11

percent touch 23,24,25,63,64,65          y 0.5    @14
percent touch 17,18,32,57,58,71          y -0.5   @14

# U+002B plus glyph ID 765
plus  touch 0,1,2,3,6,7,8,9           y 0.5    @10,11

# U+0038 eight glyph ID 556
eight  touch 41,42,43                  y 0.25   @12,13,14
eight  touch 34,35,48                  y -0.25  @12,13,14

then build using

./build-ttf.sh --install-dependencies

[bkmgit]

When using the dev branch, the following works

dnf -y install ttfautohint fonttools pipenv
pip install fontmake
git clone https://github.com/source-foundry/Hack
cd Hack
git checkout dev
./build-ttf.sh --system