Something happened to some part of font rendering on 17.09

michalrus commented 6 years ago

Issue description

After updating from 17.03 to 17.09:

Java Swing apps no longer have font anti-aliasing turned on by default (can be turned back on by passing -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true to the java process),
letter spacing of fonts in XTerm is too large (here: XTerm is on the left, Termite with correct rendering on the right, displaying that same GNU Screen buffer, notice the difference in its width),
letter spacing of fonts in Alacritty is crazy (here: Alacritty on the left, Termite on the right)

Everything renders fine back on 17.03.

Alacritty and XTerm configs for the screenshots above:

/cc @volth

Steps to reproduce

Install 17.09.
Lauch some Java app, XTerm, Alacritty.

Technical details

System: 17.09.1989.a86c8599a4 (Hummingbird)
Sandboxing enabled: yes

michalrus commented 6 years ago

~Actually, Termite does weird things, too: https://i.imgur.com/3cAQ5Kc.png~

_{Unrelated: it’s a vte bug w/ ligatures. Using Iosevka Term variant works.}

orivej commented 6 years ago

I've confirmed that XTerm with the given config currently looks as described, with unexpectedly large intervals between letters. Downgrading Iosevka to 1.4.2 (as it was in 17.03) solves this issue.

globin commented 6 years ago

cc @ttuegel who did lots of fontconfig work in 17.03 -> 17.09

orivej commented 6 years ago

N.B. There is no indication that this is caused by freetype or fontconfig changes, although it's interesting how Iosevka managed to become unusable in XTerm but still be usable in e.g. Konsole. One surprising change I've noticed is that they have renamed *.ttf files to *.ttc, an extension I have never seen before.

mkocha2 commented 6 years ago

I am experiencing something similar with urxvt after an "upgrade" of 17.09.

Konsole doesn't seem to be affected. Thunderbird is.

@orivej f and c are adjacent keys. Perhaps it is a typo.

be5invis commented 6 years ago

@orivej I use TTC to share glyphs among multiple subfamilies. Not sure what happened exactly. The way some Linux handle fonts are, well, weird.

be5invis commented 6 years ago

@mkocha2 The TTC is a compressed Font format, that one file can provide multiple sub-fonts with glyph shared. I suspect that the glyph sharing may cause Linux think the Font being non-monospace, since the Iosevka Term now has some glyphs wider than 1sp, which comes from other sub-fonts in the TTC.

orivej commented 6 years ago

Thank you, this is the likely explanation.

Fontconfig knows from the font metadata that the font is monospaced: for instance Konsole has an explicit toggle to show non-monospaced fonts, but Iosevka Term is listed even when it's off. Since Konsole supports variable width fonts, it may render each glyph with its own width, but XTerm must be trying to calculate the maximum width among all the characters and use it for the width of each one. It's interesting that Emacs (GTK3), despite good variable width support, displays Iosevka Term like Alacritty on the screenshot above; maybe it has different logic for monospace and variable fonts.

the Iosevka Term now has some glyphs wider than 1sp

You probably meant to say that Iosevka proper has wide glyphs, while Iosevka Term is still fixed width.

For testing, could you generate one version of Iosevka Term that does not share glyphs with non-Term variants, ~~and another version that is exactly like the current release except it is not marked as monospace in the metadata~~? EDIT: The second variant already exists under the name Iosevka, Emacs renders it perfectly.

be5invis commented 6 years ago

@orivej There are a lot of packages here, and one of them is the Iosevka Term, in TTF: https://github.com/be5invis/Iosevka/releases, without wider glyphs. The TTC files may contain glyphs from other Iosevka variants, which are not accessable from Iosevka Term (unless you provide explicit GlyphID).

berce commented 6 years ago

I had this issue and now have a partial fix. A channel update may have helped, but it was not sufficient.

~/.Xresources had a line setting the font (to "Iosevka Medium"), only after removing it, configuration.nix was in control.
setting the monospace font to "Iosevka Term" in configuration.nix made font rendering fine in xterm, but resulted in very wide character padding in dmenu.
setting the monospace font to "Iosevka" in configuration.nix works fine in the applications I use.

orivej commented 6 years ago

Since #31835 iosevka is built from source which results in .ttf files, they provide only Iosevka, not Iosevka Term. (I'm not sure why not and if they should.) The previous binary package is available as iosevka-bin.

ttuegel commented 6 years ago

Since #31835 iosevka is built from source which results in .ttf files, they provide only Iosevka, not Iosevka Term.

The font build is completely customizable now, so we can add an Iosevka Term derivation, too. It would be a little tricky to build both in the same derivation because that would involve multiple configure -> build -> install cycles.

mfiano commented 6 years ago

Was there any attempt at adding Iosevka Term, either in the same or a separate derivation yet? Just upgraded to unstable from 17.09 and fonts being completely wrong (due to missing the Term variant) led me to this issue.

steveej commented 6 years ago

The Java font rendering issue still exists for me today in 18.03, experienced with umlet and astah-community packages. Extracting the command line from the wrapper and manually inserting -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true works around the issue.

twhitehead commented 5 years ago

Just a note that this seems to be the same issue as in #22719 and #25639. I almost wonder if there is a broken underlying AA library somewhere that Java is using.

Here is a report of the same sort of issue happening on a system level in an earlier version of Ubuntu.

dtzWill commented 5 years ago

Was there any attempt at adding Iosevka Term, either in the same or a separate derivation yet? Just upgraded to unstable from 17.09 and fonts being completely wrong (due to missing the Term variant) led me to this issue.

For possibly similar reasons I ended up making an Iosevka Term specifically, having problems using it with my terminal emulator. It's on my NUR repo: https://github.com/dtzWill/nur-packages , here: https://github.com/dtzWill/nur-packages/blob/master/pkgs/iosevka-term/default.nix .

ttuegel commented 5 years ago

The iosevka expression is overridable. For example, in my packageOverrides I have


    iosevka-term = self.iosevka.override {
      set = "term";
      design = [
        "term" "v-l-italic" "v-i-italic" "v-g-singlestorey" "v-zero-dotted"
        "v-asterisk-high" "v-at-long" "v-brace-straight"
      ];
    };

    iosevka-type = self.iosevka.override {
      set = "type";
      design = [
        "type" "v-l-italic" "v-i-italic" "v-g-singlestorey" "v-zero-dotted"
        "v-asterisk-high" "v-at-long" "v-brace-straight"
      ];
    };

Obviously, I have a lot of variants enabled. :grinning: Should we put an override in Nixpkgs for the plain type and term variants, though?

stale[bot] commented 4 years ago

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

Search for maintainers and people that previously touched the related code and @ mention them in a comment.
Ask on the NixOS Discourse.
Ask on the #nixos channel on irc.freenode.net.

Artturin commented 1 year ago

it's 2023

NixOS / nixpkgs