[Debian] Linux: otf and ttf render differently on Linux #84
Comments
|
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? Paride |
|
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. |
|
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 |
|
Definitely. As a first step, do you mind checking a few other glyphs so that I can gauge the breadth of the rendering issue? 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? |
chrissimpkins
changed the title
|
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). |
|
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. Not using autohinter either. Settings below: |
|
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. |
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. |
|
Font size is 11, through Gnome Tweak Tool and also manually set in 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). |
|
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.
|
|
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? |
|
: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. |
|
@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? |
|
Different machine, still on lastest Debian/unstable. Same terminal, I just replaced the font files in OTF: TTF: |
|
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. |
|
@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. |
|
@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. ;) |
|
@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. |
👍 |
|
@legovini will write a note to him this evening. I'd like to summarize this issue in a bit of detail for him. |
|
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] 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. |
|
I just gave them a quick try, I find no noticeable improvement... |
|
the point on the 'i' still seems to join the main stem? |
|
@chrissimpkins unfortunately yes:
|
|
@legovini Thanks for giving this a try. |
|
@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.
Builds Current build (release v2.013) - does not include The test files that we used to examine with the |
|
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 [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 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
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 I get the desired result if I now call ttfautohint with |
|
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. SHA1: 6b2c60bac8cd443ff27efc9f5d7b079a7566ec3e @lemzwerg when I viewed this in Here are the 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] |
|
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 |
|
Hack, OTF at 11 (for comparison): Hack, OTF at 11, your TTF version from above: OTF bold: TTF build from above: |
|
@lemzwerg Thank you very much Werner.
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. |
|
@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. |
|
For some reason I don't see bold baselines being offset in Eclipse the way they are in (GTK) terminals. OTF: |
|
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? — On Mon, Sep 14, 2015 at 7:55 AM, Alexander Hofbauer
|
|
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: |
|
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. |
|
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: |
|
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. |
|
@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. |
|
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. |
|
@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. |
|
@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. |
|
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: |
|
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? |
|
Looks pretty nice here. |
|
@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. |
|
@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. |
|
@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? |
|
@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. |
|
@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. |
|
@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... |
|
@legovini do you intend to distribute the wen fonts? |
|
@chrissimpkins Yes, the idea is to actually build three sub-packages: fonts-hack-ttf where the -web one includes the svg and woff files. If you have any different recommendation let me know. |
|
@legovini that sounds great. I will make sure that we have tar.gz archives of each with new releases. |
|
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. |
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:
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
The text was updated successfully, but these errors were encountered: