[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

[paride]

It seems that the difference is given by the hinting process. If I disable it I end with identical typefaces, the only difference is that with the otf version the lines are a bit more spaced. Screenshots:

otf, no hinting:

ttf, no hinting:

Is it normal that the hinting differs between the font versions? Is the different line spacing expected?

Paride

[chrissimpkins]

Thank you very much for considering this typeface as a Debian package. It's great to hear that you think that this will be a useful resource for the Debian community.

You've definitely hit on problem #1 with screen use of the typeface at small sizes. There are cross-platform differences in rendering and cross-application differences on the same platform. A perfect example of the latter problem is found in the numerous issue reports on this repository for the JetBrains editors (IntelliJ, PyCharm, WebStorm, etc.). These use a Java type renderer that differs from that used by (many/most) other applications on the same platform where the application is executed. This can lead to rendering issues that appear in one application but not another on the same user's system. There are many moving parts involved in type rendering on the screen and it is difficult to optimize a face for all applications on all platforms.

The problem is that we are trying to fit the glyph shapes to the pixel grid displayed on the screen and that grid changes for a given glyph when you change font size (smaller font sizes = smaller height in pixels to create the same glyph shapes). The goal of hinting/TT instruction algorithms is to align the pixels in a legible/visually pleasing/properly aligned/best estimate of the actual design way, but as you might imagine this is not straightforward and the interpretation of these instruction sets can differ by renderer (or be ignored altogether). Antialiasing can further adjust the pixels that are displayed and are another factor that must be considered. This makes screen design difficult and professional type foundries will manually hint their typefaces (i.e. individual instruction sets for each glyph) to achieve the most optimal screen display for their face. This is an involved, time consuming process and it is not (currently) being used for this typeface. Pixel density of the display used to present the glyphs to the viewer plays a role as well and, as use of high pixel density screens becomes more widespread, this rendering issue will become less important. If you haven't seen Hack (or any other typeface) on a high pixel density screen, I highly recommend trying it and you will see what I mean. When you view the face at larger text sizes, there may not be a significant difference. At smaller text sizes, the artificial approaches that we have to use to make type legible on the screen are less apparent and the actual type design emerges again.

In general, I recommend the ttf files for screen use on Linux platforms. I think that for general source code needs at commonly used text sizes (generally smaller than would be used for reading text on the screen) the instructions provided by Werner Lemberg's excellent ttfautohint on the ttf builds will serve your users better. Werner and I have discussed these hints and at the moment, he feels that we are optimized for this typeface. It is possible that we will introduce further changes with his next release of ttfautohint that is due out in the next month or two.

The above recommendation is working under the assumption that you intend to distribute the typeface for that purpose. I suppose it is possible that there are situations where the PostScript files are better suited for your users. Do you know what the rationale was for the use of the otf files as the default in the Debian distro? This could be a distro-specific rendering issue or perhaps an issue with extending the fonts to non-screen applications (like print) that prompted this.

Let's start with that question and then we can attack the rendering issues that you described. It would be helpful to hear from users of other Linux distros (and users on other platforms) whether these same rendering problems are being seen. For every rendering problem that we address in one direction, it is possible to generate a whole new set of consequences for other users (e.g. the point of the i in the bold set begins to render too high on other platforms). Let's see if we can strike a balance that works for you.

[paride]

Dear Christopher,

thank you very much for your for your exhaustive reply. If I get you right, the point is that the particular use case, display (or print) resolution, hinting settings and personal taste varies too much to be able to release a "one format fits it all" font. That's fine, at least until very high resolution displays are not widespread.

The idea now is to distribute all the available versions in separate packages, and let the user chose what it's best for his/her specific use case and taste. A preliminary version of such packages is already in the works (but before a release we will have to elaborate on #85):

https://mentors.debian.net/package/fonts-hack

Still I think there is something to fix. My idea is to recommend the autohinted ttf version for screen usage, that in my experience gives the best results, if not for the bold 'i' letter, where the dot is not defined (visible in the second screenshot I posted). Do you think it is possible to do something to solve or at least mitigate this ugly detail?

Paride

[chrissimpkins]

Definitely.

As a first step, do you mind checking a few other glyphs so that I can gauge the breadth of the rendering issue?

i ì í î ï ĩ ī į à á â ã ä å ā ă ą À Á Â Ã Ä Å Ā Ă Ą j

Let's take a look at these across, say, 8px to 14px sizes with and without hinting. Are you removing the hints from the build files or deactivating them via settings?

[paride]

Here are some screenshots:

https://transfer.sh/16k6yu/hack-tests.tar

I disable the hints via settings (and as you can see the font of the UI is also unhinted, that's DejaVu Sans).

[aleho]

The world of font rendering is a deep, strange pit of lost dreams and hopes. ;)

I'm using the otf version on Debian/unstable here. It does not seem to render substantially differently from the ttf version.

Not using autohinter either. Settings below:

$ xrdb -q
*customization: -color
Xcursor.size:   24
Xft.antialias:  1
Xft.dpi:        96
Xft.hinting:    1
Xft.hintstyle:  hintslight
Xft.rgba:       rgb

[paride]

The rendering you are getting is indeed very good. I'm also using Debian/unstable.

What font size is that?

I'm not sure if the Xresources do apply to the terminal you are using, maybe it's ignoring them and using fontconfig's defaults... It's difficult to say.

[chrissimpkins]

The world of font rendering is a deep, strange pit of lost dreams and hopes. ;)

well stated...

@legovini & @aleho: Will continue to follow your discussion to see if this is something that I need to correct on my end. The bold 'i' point issue from the OP does not seem to be present in the image that @aleho posted.

[aleho]

Font size is 11, through Gnome Tweak Tool and also manually set in terminal. I get identical results in gnome-terminal and guake, the latter being my default terminal.

Rendering is also identical in Eclipse, by the way.

Regarding the fontconfig setup, here's the output of https://github.com/derat/font-config-info, hope it's useful. Fontconfig's default should actually match the values you're seeing there (at least output changes if I change the setup via tweak tool).

GtkSettings:
gtk-font-name        "Cantarell 11"
gtk-xft-antialias    1 (yes)
gtk-xft-hinting      1 (yes)
gtk-xft-hintstyle    "hintslight"
gtk-xft-rgba         "rgb"
gtk-xft-dpi          98304 (96,00 DPI)

GTK 2.0 styles:
GtkLabel             "Cantarell 11"
GtkMenuItem          "Cantarell 11"
GtkToolbar           "Cantarell 11"

GSettings (org.gnome.desktop.interface):
font-name            "Cantarell 11"
text-scaling-factor  1,00

X11 display info:
screen pixels        3840x1200
screen size          1016x318 mm (96,00x95,85 DPI)

X resources (xrdb):
Xft.antialias        "1"
Xft.hinting          "1"
Xft.hintstyle        "hintslight"
Xft.rgba             "rgb"
Xft.dpi              "96"

Fontconfig (Cantarell 11):
requested size       11 points
family               Cantarell
pixelsize            11,46 pixels
size                 11 points
antialias            [no match]
hinting              1
autohint             0
embeddedbitmap       1
hintstyle            3 (full)
rgba                 1 (rgb)

Fontconfig (default pattern):
antialias            [no match]
hinting              1
autohint             0
embeddedbitmap       1
hintstyle            3 (full)
rgba                 1 (rgb)

Fontconfig (default match):
family               DejaVu Sans
pixelsize            12,50 pixels
size                 12 points
antialias            [no match]
hinting              1
autohint             0
embeddedbitmap       1
hintstyle            3 (full)
rgba                 1 (rgb)

Fontconfig (non-family/size defaults):
antialias            [no match]
hinting              1
autohint             0
embeddedbitmap       1
hintstyle            3 (full)
rgba                 1 (rgb)

[aleho]

Something strange I noticed: Terminals don't seem to use the correct font for bold faces, no matter what setup I try.

I'm also adding a user font config to get correct results for Hack, because default config applies sans-serif before I can apply monospace (I guess they'd be gone once I'm using official packages, but I'm in no way familiar with fc, so excuse my ramblings).

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">

<fontconfig>

    <alias>
        <family>Hack</family>
        <default>
            <family>monospace</family>
        </default>
    </alias>

    <alias>
        <family>monospace</family>
        <prefer>
            <family>Hack</family>
        </prefer>
    </alias>

    <match>
        <test compare="eq" name="family">
            <string>sans-serif</string>
        </test>
        <test compare="eq" name="family">
            <string>monospace</string>
        </test>
        <edit mode="delete" name="family"/>
    </match>

</fontconfig>

Matching seems to be using the correct monospace family.

$ fc-match -s 'Hack'
Hack-Regular.otf: "Hack" "Regular"
Hack-Bold.otf: "Hack" "Bold"
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
DejaVuSansMono-Bold.ttf: "DejaVu Sans Mono" "Bold"
Andale_Mono.ttf: "Andale Mono" "Normal"
Courier_New.ttf: "Courier New" "Normal"
Courier_New_Italic.ttf: "Courier New" "Cursiva"
n022003l.pfb: "Nimbus Mono L" "Regular"
Cousine-Regular.ttf: "Cousine" "Regular"
DroidSansFallbackFull.ttf: "Droid Sans Fallback" "Regular"
opens___.ttf: "OpenSymbol" "Regular"
Arial.ttf: "Arial" "Normal"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSerif.ttf: "DejaVu Serif" "Book"
Carlito-Regular.ttf: "Carlito" "Regular"
DroidNaskhUI-Regular.ttf: "Droid Naskh Shift Alt" "Regular"
GenBasR.ttf: "Gentium Basic" "Regular"
DroidSerif-Regular.ttf: "Droid Serif" "Regular"
DroidSansEthiopic-Regular.ttf: "Droid Sans Ethiopic" "Regular"
GenR102.ttf: "Gentium" "Regular"
s050000l.pfb: "Standard Symbols L" "Regular"
LiberationSansNarrow-Regular.ttf: "Liberation Sans Narrow" "Regular"
DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
DejaVuSerif-Bold.ttf: "DejaVu Serif" "Bold"
DejaVuSerif-Italic.ttf: "DejaVu Serif" "Italic"
LiberationSans-Italic.ttf: "Liberation Sans" "Italic"
LiberationSansNarrow-Italic.ttf: "Liberation Sans Narrow" "Italic"
DejaVuSerif-BoldItalic.ttf: "DejaVu Serif" "Bold Italic"
DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"
DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"

[paride]

I obtained a similar result with the otf version and hintslight, but still it is not as good. I see that you have:

screen pixels 3840x1200

is it a dual monitor setup? Are you sure that nothing is scaled up because you have a HiDPI monitor? Just to rule out some hypotheses...

[aleho]

:D yeah, no HiDPI, just plain old dual monitor setup at 96 DPI.

I just realized it might be helpful to also list my fontconfig includes. At the moment I don't remember whether I ever changed anything important that might influence results that much.

$ ls -1 /etc/fonts/conf.d/
10-scale-bitmap-fonts.conf
10-sub-pixel-rgb.conf
11-lcdfilter-default.conf
20-unhint-small-dejavu-lgc-sans-mono.conf
20-unhint-small-dejavu-lgc-sans.conf
20-unhint-small-dejavu-lgc-serif.conf
20-unhint-small-dejavu-sans-mono.conf
20-unhint-small-dejavu-sans.conf
20-unhint-small-dejavu-serif.conf
20-unhint-small-vera.conf
30-0-google-croscore-arimo-fontconfig.conf
30-0-google-croscore-cousine-fontconfig.conf
30-0-google-croscore-tinos-fontconfig.conf
30-0-google-crosextra-caladea-fontconfig.conf
30-0-google-crosextra-carlito-fontconfig.conf
30-metric-aliases.conf
30-urw-aliases.conf
31-cantarell.conf
40-nonlatin.conf
45-latin.conf
49-sansserif.conf
50-user.conf
51-local.conf
57-dejavu-sans-mono.conf
57-dejavu-sans.conf
57-dejavu-serif.conf
58-dejavu-lgc-sans-mono.conf
58-dejavu-lgc-sans.conf
58-dejavu-lgc-serif.conf
60-latin.conf
62-google-croscore-arimo-fontconfig.conf
62-google-croscore-cousine-fontconfig.conf
62-google-croscore-symbolneu-fontconfig.conf
62-google-croscore-tinos-fontconfig.conf
62-google-crosextra-caladea-fontconfig.conf
62-google-crosextra-carlito-fontconfig.conf
65-fonts-persian.conf
65-nonlatin.conf
69-droid-sans-fallback.conf
69-unifont.conf
70-no-bitmaps.conf
80-delicious.conf
90-synthetic.conf
99pdftoopvp.conf
README

[paride]

@aleho Well, I finally obtained exactly the same rendering you posted. Still I think that the ttf version looks better on screen, and there the problem with the bold 'i' is present. (It would be interesting if you could try the ttf fonts and confirm this.)

The only way I found to obtain proper 'i', 'j' and similar letters with the ttf version is to completely disable hinting.

@chrissimpkins are you still positive in trying to fix the ttf hinting?

[aleho]

Different machine, still on lastest Debian/unstable. Same terminal, I just replaced the font files in ~/.fonts. As you can see, they're quite different.

OTF:

TTF:

[paride]

And indeed if you check the bold 'i' letters in the ttf version the dot is not well separated from the rest of the letter. It seems that we're getting the same render in the end.

[chrissimpkins]

@aleho Thanks for all of the tests. I appreciate all of these images. This has been very helpful.

@legovini Sure, I would be happy to look at the TrueType instructions. I took a look through the images that you added in the tar archive and it looks like the rendering is fine in the range with the exception of 11px and 12px sizes with hinting and the 13px and 14 px sizes without hinting. In general, all of the diacritic marks (and points) look better on your system with hinting turned off over most of that text size range. This is particularly true for smaller text sizes. This is unexpected.

If the two of you have no other platform-specific rendering thoughts, I will see if Werner Lemberg would be willing to comment on the hinting of these sub-glyph shapes.

[aleho]

@chrissimpkins You're welcome! Just let me know if you need anything else, font-inspector, etc. I'll be glad to contribute just a little bit back at my new favourite source code font. ;)

[paride]

@chrissimpkins Thanks for looking at the images, I agree with you in that the rendering glitches are in those size ranges. At the moment I don't think I have anything else to add, it would be very interesting to read what Werner Lemberg thinks.

In the meantime I'll keep on working on the Debian package.

[chrissimpkins]

@aleho

my new favourite source code font

:+1:

[chrissimpkins]

@legovini will write a note to him this evening. I'd like to summarize this issue in a bit of detail for him.

[chrissimpkins]

Before I pull him back into the conversation let's try one new build that includes a different hinting approach. This separately hints composite glyphs. I'd like to see if this addresses the issue.

Links:

Hack-Regular-DebHC.ttf [SHA1: 1130080f26a773d29926bdf00330bdf7b51fed5e] Hack-Italic-DebHC.ttf [SHA1: e35bac84a5c9fd940284a5ac513961b97f4cae3f] Hack-Bold-DebHC.ttf [SHA1: 4df8f62075f0b6cec0a09de7a608bc3521659418] Hack-BoldItalic-DebHC.ttf [SHA1: 78897729211e91243842bee516f9d68533b3f3c5]

While the filepaths have changed, the font names have not. You still use these as 'Hack' and they will show version 2.013. Let me know if this changes the appearance of the lowercase i or any of the other glyphs that include sub glyph shapes above the main shape.

[paride]

I just gave them a quick try, I find no noticeable improvement...

[chrissimpkins]

the point on the 'i' still seems to join the main stem?

[paride]

@chrissimpkins unfortunately yes:

[chrissimpkins]

@legovini Thanks for giving this a try.

[chrissimpkins]

@lemzwerg Copied from my email today for @legovini and @aleho:

This problem appears in the bold set. We are not seeing it in the regular set.

... The issue is with subglyph rendering on this Linux distro. In the commonly used 10 - 12px range, there is a problem with the points and diacritic marks that became obvious once we looked closely at the point above the lowercase ‘i’. There does not appear to be enough spacing between the point and the main vertical stroke of the glyph. When hinting is turned off, the appearance of these points improves (i.e. the spacing seems appropriate) but the main glyph shape rendering appears worse. I don’t use the —hint-composites flag in the default build so we gave this a try today and it doesn’t appear to address the problem.

Would you happen to have any thoughts?

Builds

Current build (release v2.013) - does not include --hint-composites flag

The test files that we used to examine with the --hint-composites flag on are linked five messages above in this thread.

[lemzwerg]

Unfortunately, the issue with the 'i' and 'j' dots touching the glyph body can't be resolved automatically; this is essentially a feature of FreeType's auto-hinter that ttfautohint has inherited: At small ppem sizes (say, lower than 14ppem), the glyph shapes for 'strong' hinting (this is, vertically snapping the outlines to the pixel grid) must be extremely distorted or shifted sometimes to get decent results.

In the following, I only take care of the case where 'Hack-Bold.ttf' gets displayed with full bytecode hinting.

Using the current git version of ttfautohint, I first apply strong hinting to all three rendering methods (this should be adapted as suitable); this ensures for my tests that I see the problems with the FreeType demo programs also, in particular ftgrid.

ttfautohint -t -w gGD Hack-Bold.ttf Hack-Bold-TA.ttf

[Note that I'm still missing the build instructions in Hack's git repository what parameters for ttfautohint you are using – since you no longer use ttfautohint's -t option I can only guess...]

Using the above ttfautohint command, the problematic ppem values where the dots are touching the body are 10, 11, and 21ppem. However, it is possible to fix this problem with some instructions added to a Control Instructions File used as an additional input to ttfautohint.

The image below shows the 'i' glyph at 20ppem, using the current git version of the ftgrid program (pressing key D enables display of point numbers).

In case the dot is touching the body, we have to move up (parts of) the dot. For simplicity, I move up the points of both the upper and lower segment of the dot by one full pixel at all problematic sizes (the points in-between are automatically interpolated to the correct positions) – this should be fine-tuned if necessary. Putting the following line into a plain text file Hack-Bold-TA.txt

i  touch 0,1, 4,5, 6,7, 10,11  y 1  @  10, 11, 21
j  touch 0,1, 4,5, 6,7, 10,11  y 1  @  10, 11, 21

I get the desired result if I now call ttfautohint with

ttfautohint -t -w gGD -m Hack-Bold-TA.txt Hack-Bold.ttf Hack-Bold-TA.ttf 

[chrissimpkins]

Original Issue

@lemzwerg Thank you very much for all of this information Werner. I apologize that I didn't include the original hinting set. I will convert the post-build ttfautohint settings into a script and add it to the repository. To date, I have been using your ttfautohint GUI tool. For the Hack-Bold.ttf build, the post-build ttfautohint settings are as follows:

I change the fallback stem widths to 181 (Hack-Regular.ttf), 145 (Hack-Italic.ttf), and 265 (Hack-BoldItalic.ttf). There are otherwise no modifications in the hinting for the four build files.

In the *-DebHC.ttf files that I linked above, I added the --hint-composites flag and this did not influence the appearance of these subglyphs at the text size ranges where @legovini and @aleho noted problems.

I have not been using strong stem width / positioning for the greyscale or DirectWrite options as you did in these tests.

@legovini and @aleho : I will build new files with the Control Instructions File that Werner recommended above so that you can test these on Debian. Hopefully this is the solution.

FreeType Tools for Diagnostic Testing of ttf Hinting

@lemzwerg As an aside, I tried to build the git release version of FreeType git://git.sv.nongnu.org/freetype/freetype2.git (on OS X 10.10.5 , zsh shell v5.1) yesterday so that I can install the FreeType demo tools. I was hoping to preempt some of this diagnostic work that I have been asking you to complete on the project in order to have more informed conversations with you. I'm receiving an error during the build at the ./configure stage:

Looking at the configure file it looks like there have been problems in zsh in the past and I gather that the error is coming from this block:

# call make

CFG=
# work around zsh bug which doesn't like `${1+"$@"}'
case $# in
0) ;;
*) for x in "$@"; do
     case x"$x" in
     x--srcdir=* ) CFG="$CFG '$x'/builds/unix" ;;
     *) CFG="$CFG '$x'" ;;
     esac
   done ;;
esac
CFG=$CFG $MAKE setup unix

# eof

I have FreeType2 installed via homebrew; however, my understanding is that the FT demo tools are set to identify the freetype2 directory at the same directory level. Thoughts? Also, I am having a difficult time finding documentation on these tools. Is this available? They appear to be extremely useful.

[lemzwerg]

I suggest that you compile FreeType and the demo programs statically in developer mode – this is what I do. It should also help you to really use the current git version of FreeType since it might be easy to link with a wrong version of FreeType otherwise.

Starting from a clean git repository (git clean -fdx), you should say make devel; make to build the library. Then follow the instructions in the ft2demos git repository, including the creation of the directory link.

This developer mode, however, simply expects that you have already set up all the necessary paths to the include and library directories – if you want to use homebrew libraries (which I recommend) this is not fully trivial. It might be thus simplest if you write a small shell script to do the compilation so that you don't have to type everything again and again in case of errors :-)

BTW, the problem you've encountered by simply calling configure can be fixed by calling autogen.sh in advance – today, generated files are usually not part of a git repository. For compilation in developer mode, however, this is not necessary.

The documentation of the demo tools are man pages, e.g. ftview.1, in the ft2demos bundle.

[chrissimpkins]

@lemzwerg thank you very much Werner. I will try this tonight.

[chrissimpkins]

@lemzwerg The make devel command worked without issues from the clean git repository. With make, I receive the following error:

gcc -ansi -pedantic -I/Users/ces/Desktop/code/freetype2/src/autofit -I/Users/ces/Desktop/code/freetype2/objs -I/Users/ces/Desktop/code/freetype2/devel -I/Users/ces/Desktop/code/freetype2/include   -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="<ftmodule.h>"  -o /Users/ces/Desktop/code/freetype2/objs/autofit.o /Users/ces/Desktop/code/freetype2/src/autofit/autofit.c
In file included from /Users/ces/Desktop/code/freetype2/src/autofit/autofit.c:21:
In file included from /Users/ces/Desktop/code/freetype2/src/autofit/afpic.c:23:
In file included from /Users/ces/Desktop/code/freetype2/src/autofit/afglobal.h:26:
/Users/ces/Desktop/code/freetype2/src/autofit/hbshim.h:29:10: fatal error:
      'hb.h' file not found
#include <hb.h>
         ^
1 error generated.
make: *** [/Users/ces/Desktop/code/freetype2/objs/autofit.o] Error 1

[lemzwerg]

This means that the harfbuzz library can't be found. Install it with homebrew and check that

pkg-config --cflags harfbuzz

produces correct output. [Obviously, this means that you have to install 'pkg-config' also in case it wasn't yet, and that you have set up a valid path to homebrew's pkg-config binary.]

The same is true for libpng, BTW.

[chrissimpkins]

Still having troubles with this @lemzwerg. I think it will be easiest to just carry the entire build over to Linux (hopefully). Working on this today and will let you know if there are any other issues.

@legovini & @aleho : I am trying to get a new build out for you to try later today. This will include the new instruction sets that @lemzwerg recommended.

[chrissimpkins]

@legovini so here is what Werner is referring to above. At different text sizes, the point above the i is being aligned at different areas of the pixel grid. At some sizes, this is properly aligned so that you notice the point properly above the vertical stem of the i. At other sizes, they are adjacent to each other and this gives the appearance that the point is part of the stem:

16 pt

18 pt

20 pt

22 pt

We're going to attempt to nudge the points on the improperly aligned text sizes up so that they have the correct appearance.

[chrissimpkins]

Here is a test file that addresses the i and j point issue. It carries the current release version number 2.013. I included the SHA1 hash below.

Hack-Bold-DebTA.ttf

SHA1: 6b2c60bac8cd443ff27efc9f5d7b079a7566ec3e

@lemzwerg when I viewed this in ftgrid I came up with 6, 7, 15, 16, 21, & 22 pt for the adjustments. I suspect that this is due to a difference in the settings that I used for autohinting relative to what you applied?

Here are the ftgrid images for the 16 and 22 pt sizes in the new autohinted build. The alignment was incorrect above before we used the new Control Instructions File. This appears to be corrected as seen in the new images. I verified that this is the case for the lowercase j as well. Please give this file a shot and let me know if this addresses the issues for these characters.

16 pt

22 pt

If this fixes the issue, then we will include this in the next release.

For my future reference, the ftgrid command that I used was:

$ ./ftgrid -f 157 20 [font-path]

[lemzwerg]

Yes, the different ppem values are due to different settings. The 'i' and 'j' glyphs in the resulting TTF file look OK to me.

BTW, I still suggest that you use ttfautohint's -t option (which is equivalent to the 'Add TTFA info table' checkbox in ttfautohintGUI)...

[aleho]

Hack, OTF at 11 (for comparison):

Hack, OTF at 11, your TTF version from above:

OTF bold:

TTF build from above:

[chrissimpkins]

@lemzwerg Thank you very much Werner.

BTW, I still suggest that you use ttfautohint's -t option (which is equivalent to the 'Add TTFA info table' checkbox in ttfautohintGUI)

Sorry, I thought that was the flag for the strong stem width / positioning. I will definitely add it. This will make it easier to discuss these issues.

[chrissimpkins]

@aleho now it looks like we have the issue with the bold vs. regular baseline alignment that has been reported in other issue reports. The bottom of the bold glyphs look like they are displaying a pixel above the level of the regular set. I'm not sure what is leading to this. Let me look into it.

[aleho]

For some reason I don't see bold baselines being offset in Eclipse the way they are in (GTK) terminals.

OTF:

[chrissimpkins]

Alexander can you confirm that this is happening in the ttf builds as well?  My read of the comparison post above is that the bottom image is the ttf build that we just created with the Control Instructions File.  Is that correct?  

Would it be possible to try the ttf files in Eclipse and include strings in bold that have a stroke that extends below the baseline like the lowercase g, q, or j, or p?

— Chris

On Mon, Sep 14, 2015 at 7:55 AM, Alexander Hofbauer notifications@github.com wrote:

For some reason I don't see bold baselines being offset in Eclipse the way they are in (GTK) terminals. OTF:

Reply to this email directly or view it on GitHub: https://github.com/chrissimpkins/Hack/issues/84#issuecomment-140048261

[aleho]

Yes, the bottom image was OTF-files with only the bold being replaced with the build from above.

Eclipse samples are quite strange. I double checked, to make sure I didn't mix them up. The second sample is OTF with bold variant replaced with the TTF version from above.

Eclipse, OTF:

Eclipse, OTF + TTF bold:

[chrissimpkins]

Do you mind trying all ttf files to see if those align? I wonder if some of these alignment issues are coming from a mix of otf and ttf builds on systems.

[aleho]

For me the alignment problems are with OTF only (no mixing).

Next round of samples. OTF versions are with version 013, TTF versions with 013 and the bold font replaced by the test build above.

OTF:

TTF:

[chrissimpkins]

Looks to me like we are good on the TTF side of things. Do you see any issues there?

For the OTF files there is still a bold vs. regular vertical alignment problem that I will need to look into. Is there a reason that you prefer the OTF files at this stage? Do they render better on the Debian platform? I don't appreciate a difference from the images that you posted.

@legovini I think that we are ready on the TTF build side for your Debian package. It seems that we have the bold i and j point issues sorted out. Please let me know if you spot any other issues when you test these files and if there is anything that I can do.

[chrissimpkins]

@lemzwerg thanks again for all of your help with this issue. I really appreciate it. The Control Instructions File looks like it will be very useful to address other issues that come up down the road. I am going to take a look through all of the diacritics to see if they are problematic at any text sizes.

[aleho]

OFT don't render particularly better. For some reason OFT is smaller than TTF in terminals, as you can see above, but in Eclipse the glyphs appear larger for whatever reason at the same font size (so exactly the other way round). In terminals and gedit I use size 11, in Eclipse 10.

Well, maybe Eclipse specific.

[paride]

@chrissimpkins sorry for the late reply, busy days. The TTF versions renders perfectly to me now, I think the font is ready for distribution. Thank you very much for dealing with the issue! Do you plan to release a version that includes this fix any soon? In this case I'll wait before working on an upgraded Debian package.

[chrissimpkins]

@legovini absolutely no rush. I just wanted you to be aware that this (I hope) addresses your concerns. I am happy to push a new release with these changes this week. There may be a few other issues that we can address in this release so I will plan for this to happen towards the end of the week.

Have you sorted out how you would like to release this in the Debian package? I think that there is another open issue report with some concerns that you expressed about licensing and the possibility of generating and hinting your own builds on users' systems. I had to change the name of the SIL license and modify some of the wording so that I could incorporate the Bitstream Vera license and the reserved font names included in that license. SIL asks that, with any modification of the license, the preamble is removed and the name changes so that it does not represent SIL as the organization that released the license. I don't foresee any issues for you if you intend to use the builds released on the main repository though I can't claim any expertise/experience with Debian-specific licensing and I would ask that your team confirm this. Most of the restrictions in the license pertain to modifications that are made and the inability to use "Bitstream", "Vera", and "Hack" in the new font name (These are "Reserved Font Names" in font legal speak). There are restrictions against the sale of the original fonts and any derivative fonts created from these font builds or the source that is used to build them. The goal there is for the font and any derivatives to remain libre, open source fonts as originally intended from the time of the Bitstream Vera release.

If you intend to build and hint yourself as part of the packaging process, let's discuss the build chain further.

If you have any interest, I've created a Slack account for the typeface and we could hold further conversations in a channel there. It may be an easier platform to discuss these issues than in Github issue reports.

[manuel-uberti]

This is the latest TTF font on Emacs and Debian unstable. I am talking about the latest release, not the test files available here.

This is how Hack is setup in my configuration:

(set-face-attribute 'default nil
                                :family "Hack"
                                :height 150
                                :weight 'regular)