Umlaut dots missing in urxvt

[SammysHP]

I just noticed that the dots above the umlauts Ö and Ü are missing in urxvt with DejaVu Sans Mono.

fontconfig-infinality-ultimate 2.11.1-21 freetype2-infinality-ultimate 2.5.3-13 ttf-dejavu-ib 2.34-10

urxvt.font: xft:DejaVu Sans Mono:pixelsize=12:

urxvt.font: xft:DejaVu Sans Mono:pixelsize=13:

As you can see the dots for Ö and Ü are higher than for Ä, thus they aren't in the bounding box (?) of the character with pixelsize=12 anymore.

[SammysHP]

Oh, I forgot to mention: Infinality config default (preset 2) and ms-fonts (because I don't like most of the substitutions).

PS: Palatino Linotype has a wrong size in Firefox since some months ago.

[bohoomil]

Thanks for the feedback and reporting. Please, insert the following rule to /etc/fonts/conf.d/90-tt-dejavu.conf in the DejaVu Sans Mono subsection (I'll update the DejaVu package later tonight):

  <match target="font">
    <test name="force_autohint">
      <bool>false</bool>
    </test>
    <test name="family">
      <string>DejaVu Sans Mono</string>
    </test>
    <test name="pixelsize" compare="less">
      <double>12.5</double>
    </test>
    <edit name="antialias" mode="assign">
      <bool>true</bool>
    </edit>
    <edit name="hinting" mode="assign">
      <bool>true</bool>
    </edit>
    <edit name="hintstyle" mode="assign">
      <const>hintfull</const>
    </edit>
    <edit name="autohint" mode="assign">
      <bool>false</bool>
    </edit>
  </match>

If possible, please check if the Bold variant is rendered correctly afterwards. If not, I'll restrict the instruction to Book variant only.

Can you please share a link to a site which is using Palatino Linotype? (Edit OK, already found.)

[bohoomil]

Unfortunately, I'm not sure what is wrong with Palatino Linotype… I'm using Linotype's sampler as a reference and it seems that everything is OK. See page 2, size 10pt Palatino Roman.

[SammysHP]

Try my blog http://sammyshp.de/betablog. I forgot to mention that it's only an issue with small caps (see date/time on the left and navigation on the top). You can find reference screenshots in the first blog entry.

I'll test your modification later today.

[SammysHP]

With small-caps:

Without small-caps:

Reference from Windows 7 (with same font file):

Tomorrow I can test Chromium (which is not installed on my laptop). IIRC there are no problems there.

[SammysHP]

I've tested your modification. Now it looks ok with pixelsize=12: But still different height for pixelsize=13.

Here is a screenshot with the bold version (urxvt.font: xft:DejaVu Sans Mono:bold:pixelsize=12):

PS: I can send you my Palatino Linotype collection if you want. PPS: Should I open a new issue for Palatino Linotype?

[SammysHP]

Oopps… I just noticed that Palatino is ok for the characters, but the numbers have the wrong size (they are "small"-caps, too).

[bohoomil]

For DejaVu Sans Mono, increase the pixelsize in 90-tt-dejavu.conf to 13.5: now the transition from 12 to 13 seems smooth.

I'm just playing with Palatino (I have the same version, thanks). With the following snippet in 92-selective-rendering-microsoft.conf:

  <match target="font">
    <test name="family">
      <string>Palatino Linotype</string>
    </test>
    <edit name="hintstyle" mode="assign">
      <const>hintfull</const>
    </edit>
    <edit name="autohint" mode="assign">
      <bool>false</bool>
    </edit>
  </match>

the reference fragment from your blog looks like this:

The thing with numerals being displayed incorrectly has nothing to do with freetype2, though: it's all about web browser's engine being forced to re-size numerals by a HTML/CSS directive (i.e. small-caps). Because we don't have lower case version of numbers, do we? ;-)

[SammysHP]

The thing with numerals being displayed incorrectly has nothing to do with freetype2, though: it's all about web browser's engine being forced to re-size numerals by a HTML/CSS directive (i.e. small-caps). Because we don't have lower case version of numbers, do we? ;-)

Strange, because it is correct with other fonts.

[bohoomil]

The browser should render the date without resizing the digits, just like it does in your 2nd shot (without small-caps). I guess it can be a bug in the browser, at least the Linux version. Maybe it is a good idea to fill a relevant bug report?