[Debian] Linux: otf and ttf render differently on Linux

[paride]

Hi,

I'm working on a Debian package for the Hack font, with the aim to have it included in the main repository. I'm discussing with other people involved in font packages in Debian about which version to package: otf or ttf (or both).

In principle the otf version should be preferred, but when trying it on my system I get some artifacts that I'm not getting with the ttf version. In our understanding the two versions should render identically.

Check the two attached images. In the otf version the rendering is very bad for the capital 'm' letter (in 'games'), and also the '0' and '$' symbols are worse. On the other side, the bold 'i' of the ttf version is bad (the dot touches the body of the letter). The rendering is in general a bit different.

otf version:

ttf version:

The screenshot are done in the same conditions:

1. Same terminal (a VTE-based terminal using GTK3 libraries);
2. Native font hinting (autohinter not enabled);
3. Same font size (11).

Shouldn't the two versions be equal? Why those bad artifacts with the otf version? Why do you suggest the use of the ttf version on Linux systems?

If I completely disable the font hinting the artifacts, but in many cases the result is still not very good, as the resolution of my LCD panel is not high enough. For example, the '~' symbol looks like a blurred '-'.

Cheers,

Paride

[chrissimpkins]

New test build v2.014 is now available. It includes the hinting changes that we worked on here as well as vertical metrics changes to address numerous other issue reports. This tightens the line spacing and I would be interested in your feedback before we push this as the release version. Please let me know if you are seeing any problems on Debian.

The files are available in #111

I am going to give users a few days to provide feedback on these fairly significant changes before we push this as the release.

@legovini Please provide an update on where we stand with any outstanding licensing and build issues with the Debian package. I anticipate that this release will be available by mid- to late week. Does this timeframe work for you?

[aleho]

Looks pretty nice here. Would need an OTF build to be sure, but I guess OTF and TTF will still be rendered differently, right?

[paride]

@chrissimpkins I just tried 2.014, I confirm that the problem with the ij letters is fixed and I welcome all the other changes as positive. This is definitely a better version of Hack, but what I appreciate most is that you listen to the user's feedback and implement improvements. Thanks!

About the Debian packaging: my idea is to start by packaging just the pre-built version of the font. This is simpler, avoids licensing issues, lets us have feedback from the Debian community and, if the package is accepted in the main repositories, will give me the feeling that the packaging work is actually useful. I'll let the definition of a build process (and the associated licensing issues) as a secondary task. I still find it's important, but I think it's better to proceed step by step.

I proposed this on the pkg-fonts-devel mailing list:

https://lists.alioth.debian.org/pipermail/pkg-fonts-devel/2015-September/016292.html

and received some positive feedback. I hope you'll agree.

[chrissimpkins]

@aleho That remains to be seen. I suspect that there will be some platform specific differences, but I am hoping that this will address many of the issues that came up with alignment differences between the two builds. There are likely to still be some PostScript hinting issues on the otf side that have not been addressed yet.

[chrissimpkins]

@legovini That sounds great. You will have to forgive me for my ignorance with the packaging process on Linux. Do you wait for approval at this stage?

[paride]

@chrissimpkins more or less... I need to find a Debian member that has upload privileges for the official package repository and that is willing to "sponsor" my package (that also means checking that everything is fine with it). The whole process is a bit convoluted, as you can guess from the New Maintainers' Guide:

https://www.debian.org/doc/manuals/maint-guide/

but it assures that the quality of the packages is in general rather high. All of this is Debian-specific, other distributions has different guidelines and workflows.

[chrissimpkins]

@legovini That's no problem at all. We are working on a package for Fedora as well and they requested that I release a tar.gz of the builds on my Github releases. Will this work for you? Currently they are released in compressed zip archives.

[paride]

@chrissimpkins It would help a little, as at the moment I use the source .tar.gz and take the ttf/otf/svg/woff files from there, but it's really not a big difference. I also noticed that some of the font files (svg and woff, IIRC) have the execution bit set. I have fix this in the package, but it would be nicer it they came without it. But again, it's no big deal...

[chrissimpkins]

@legovini do you intend to distribute the wen fonts?

[paride]

@chrissimpkins Yes, the idea is to actually build three sub-packages:

fonts-hack-ttf fonts-hack-otf fonts-hack-web

where the -web one includes the svg and woff files. If you have any different recommendation let me know.

[chrissimpkins]

@legovini that sounds great. I will make sure that we have tar.gz archives of each with new releases.

[chrissimpkins]

These changes are now available in the version 2.015 release. Thank you very much for the issue report @legovini . Thanks to all for the testing here and to @lemzwerg for your input on the new Control Instructions File. All of this is greatly appreciated. The releases are now available in compressed zip and tar.gz archives.

https://github.com/chrissimpkins/Hack/releases/tag/v2.015

I am closing this issue as solved. @legovini if you would like to discuss the Debian package further, please feel free to contact me directly or open a new issue report.