Announcement

Collapse
No announcement yet.

FreeType 2.7 Bringing DirectWrite/ClearType-Like Rendering -- Much Better Looking Fonts On Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • pq1930562
    replied
    How would you enable v40 on Ubuntu 16.04 with this PPA: https://launchpad.net/~no1wantdthisn...ive/ubuntu/ppa ?

    Would installing the PPA be enough?

    Leave a comment:


  • pal666
    replied
    Originally posted by Evil Penguin View Post
    So... Fedora shouldn't have an issue implementing this?
    dnf install freetype-freeworld

    Leave a comment:


  • mudig
    replied
    Qt like Skia and others disable subpixel positioning when normal or full hinting is requested, because pixel-grid hinting doesn't combine with subpixel positioning. So we need to know if face loaded by FreeType is can support subpixel positioning. Note it has to be a runtime because a toolkit might be build against a different version of FreeType than it is run with.
    Ah! Okay. Then a test for hintfull won't do. Basically, you currently don't know unless you're using hintslight. See below.

    I thought hintfull enabled subpixel rendering when available and lcd-filtering. Without subpixel rendering they are identical though.
    Full usually means FT_LOAD_TARGET_NORMAL or FT_LOAD_TARGET_LCD if subpixel rendering is enabled and that means FT renders fonts with the native hinting engine.
    • For .otfs, it is Adobe's contributed CFF engine that exclusively snaps stems vertically, no horizontal hinting and therefore subpixel positioning compatible.
    • For .pfa/bs it is an old homegrown engine that snaps on both axes, not subpixel positioning compatible. Note that .pfbs are still shipping in Linux distros: the Nimbus family in Ghostscript packages. The long term goal is to wire .pfa/bs into the Adobe engine somehow.
    • For .ttfs, it means the homegrown interpreters (v35, v38, v40) and what you get depends almost entirely on the font. If using v40 and in compatibility mode, you always get subpixel positioning compatible output, all other modes of operation and interpreter versions are more or less unpredictable unless you know the typeface. I don't think there is currently a way to get at the compatibility flag thing from the outside or even detect if a font hints to full pixels horizontally. As I understand it, the interpreter itself signals to the typeface that subpixel positioning is desired but the typeface program has to honor the flag. v40 and compatibility mode enforce the flag by subversion.

    Hintslight usually translates to FT_LOAD_TARGET_LIGHT, which triggers the native CFF engine for .otfs (unless the user enforces the old FT CFF engine?) and the autohinter for everything else. It so far guarantees that you get subpixel positioning compatible output because there is never any horizontal hinting.

    I'll have to think about if a CAN_SUBPIXEL_POSITION flag test thing could be implemented.

    Note: Chrome and Chromium doesn't support hintmedium and will fall down to hintslight when it is configured as default.
    Good to know.
    Last edited by mudig; 19 July 2016, 05:24 PM.

    Leave a comment:


  • carewolf
    replied
    Originally posted by mudig View Post

    An artifact from whoever decided to create hintslight, hintmedium and hintfull. It was originally conceived as a sharpness control but never mapped to the reality of how FreeType operates. An unfortunate accident of history. I'd like to get rid of it.
    I thought hintfull enabled subpixel rendering when available and lcd-filtering. Without subpixel rendering they are identical though.

    Note: Chrome and Chromium doesn't support hintmedium and will fall down to hintslight when it is configured as default.

    Leave a comment:


  • carewolf
    replied
    Originally posted by mudig View Post

    Subpixel positioning is done by the toolkit that uses FreeType. Do you mean subpixel hinting? Just test for v40. Note that it might not give you what you expect depending on the font. The compatibility mode and the way it looks depends on the font not being a "native ClearType" font. Fonts like Constantia and Corbel are native CT fonts that are left alone. They will look and behave differently from compatibility fonts. Tricky fonts like DF Kai SB rely on the native hinter to render correctly and are also exempt.
    Let's say I am working on a toolkit, and let's say Qt

    Qt like Skia and others disable subpixel positioning when normal or full hinting is requested, because pixel-grid hinting doesn't combine with subpixel positioning. So we need to know if face loaded by FreeType is can support subpixel positioning. Note it has to be a runtime because a toolkit might be build against a different version of FreeType than it is run with.


    Leave a comment:


  • mudig
    replied
    Thanks for the information. I wonder why there is a medium setting in Xfce then.
    An artifact from whoever decided to create hintslight, hintmedium and hintfull. It was originally conceived as a sharpness control but never mapped to the reality of how FreeType operates. An unfortunate accident of history. I'd like to get rid of it.

    Leave a comment:


  • stqn
    replied
    Originally posted by mudig View Post
    Because they are the same. There is no medium in FT.
    Thanks for the information. I wonder why there is a medium setting in Xfce then.

    Leave a comment:


  • mudig
    replied
    Okay, thanks. Is there a way we can detect at runtime that sub-pixel positioning is possible? Right now we just look at the requested hinting we pass from fontconfig to freetype, but with this, we need to know more about which version of freetype it is, and how it is configured. Please make sure we have such a method in 2.7. It was the same problem with stem darkening.
    Subpixel positioning is done by the toolkit that uses FreeType. Do you mean subpixel hinting? Just test for v40. Note that it might not give you what you expect depending on the font. The compatibility mode and the way it looks depends on the font not being a "native ClearType" font. Fonts like Constantia and Corbel are native CT fonts that are left alone. They will look and behave differently from compatibility fonts. Tricky fonts like DF Kai SB rely on the native hinter to render correctly and are also exempt.

    Medium and full hinting both look the same.
    Because they are the same. There is no medium in FT.

    I thought those patents expired several years ago.
    Bytecode patents, yes. ClearType patents, no. I think they expire 2018 or something.

    Leave a comment:


  • FuturePilot
    replied
    Originally posted by mudig View Post
    The only rendering-related patch that Ubuntu applies is to enable subpixel rendering that FreeType disables by default because it's still patented.
    I thought those patents expired several years ago.

    Leave a comment:


  • stqn
    replied
    Originally posted by smitty3268 View Post

    Windows renders fonts fine now.

    Here's a comparison - your screenshot is on top, windows rendering on bottom.

    http://i.imgur.com/DSVgjYL.png
    The text on the top looks better, it is pixel perfect unlike the bottom that is slightly blurry. But yeah, different fonts anyway…

    When I switched from Windows XP to Linux the fonts looked better on Linux to me (without using infinality). I’m currently using full hinting because the default font (déjà vu sans?) looks bad with slight hinting. Medium and full hinting both look the same.

    Leave a comment:

Working...
X