bug#31702: 26.1; Effective font height is different from set value

bug#31702: 26.1; Effective font height is different from set value

[Carlos Piat]

I'm setting the Hack Mono font for the default face with size 110:

  (set-face-attribute 'default nil :font "Hack" :height 110)

but I noticed that the result is slightly different from what
gnome-terminal renders for "Hack 11". Namely, in emacs the font looks
bigger. So I checked the attribute value in the customize-face
screen for the default face, which showed a height of 113.

Playing a bit with different heights I realized that the number I set is
never exactly the setting that ends up being effective, as if a rounding
error or something was happening somewhere.

Even if I set the font as "Hack 10" or set it from the standard dialog
that is available in the menu bar the result is the same.

Some relevant libraries in my system are:

  local/freetype2 2.9.1-1
    Font rasterization library
    
  local/libxft 2.3.2-1
    FreeType-based font drawing library for X

In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2018-05-29 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description:	Manjaro Linux

Recent messages:
nil
Creating customization items...
Creating customization items ...done
Resetting customization items...done
Creating customization setup...done
nil
Entering debugger...
previous-line: Beginning of buffer
nil
Auto-saving...

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 MODULES THREADS LIBSYSTEMD LCMS2

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  show-paren-mode: t
  diff-auto-refine-mode: t
  pyvenv-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils cl-print debug crm vc-git base16-default-dark-theme
base16-theme paren cl-extra yasnippet elec-pair highlight-indentation
flymake-proc flymake warnings company edmacro kmacro pcase help-fns
radix-tree help-mode elpy find-file-in-project ivy delsel ivy-overlay
ffap thingatpt windmove diff-mode easy-mmode elpy-shell pyvenv esh-var
esh-io esh-cmd esh-opt esh-ext esh-proc esh-arg esh-groups eshell
esh-module esh-mode esh-util elpy-profile elpy-django s elpy-refactor
subr-x python tramp-sh tramp tramp-compat tramp-loaddefs trampver
ucs-normalize shell pcomplete parse-time format-spec advice json map ido
grep compile comint ansi-color files-x etags xref project ring cus-edit
cus-start cus-load wid-edit finder-inf info package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 364347 15038)
 (symbols 48 32967 1)
 (miscs 40 772 758)
 (strings 32 72107 1797)
 (string-bytes 1 2082553)
 (vectors 16 52862)
 (vector-slots 8 929416 10894)
 (floats 8 121 290)
 (intervals 56 576 99)
 (buffers 992 15))

bug#31702:

[Carlos Pita]

Ok, I think I now understand the problem a bit better:

1. Changing the height from 102 to 109 sets the effective height to
105. This size is the same of that of the font which both the font
select dialog and gnome-terminal show for "Hack 11" (I have counted
pixel by pixel in comparative xmag shots).

2. From 110 to 116 the effective size is 113 as stated above. This is
the size corresponding to "Hack 12" in the font selector and in
gnome-terminal.

3. 117 rounds up to 120, etc.

So I guess it's just a different way of rounding up to the next
available size (I don't know which is the precision of the underlying
font renderer but I assume it's not a tenth of a point... from the
numbers above it seems to be about 6 or 7 tenths of a point).

But:

* The fact that setting the font from the font dialog offered in the
menu bar of emacs itself doesn't set a font with the height that was
previewed in the dialog is a bit disturbing.

* Besides, since the height attribute documentation explicitly states
that the it is measured in tenths of a point, the rendering of a font
with height P * 10 in emacs should exactly match the rendering of the
same font with size P in the system. There is no "rounding up" excuse
for the mismatch between 110 and 11, for example.

bug#31702:

[Carlos Pita]

A further inconsistency is that setting "Hack 11" from the resources
file makes the face height 105, in a manner that matches the system
behavior but not emacs own behavior when setting "Hack 11" from the
font dialog or the init file (which makes the height 113, as described
above).

bug#31702:

[Carlos Pita]

Sorry, forget about this last comment, my mistake, just got confused
with the font descriptor, emacs is indeed consistent in its
inconsistency with the desktop :)

All in all I'm not sure how to feel about this issue. Despite the
external inconsistency emacs is internally coherent and, according to
what I described in my second comment, I would say it's selecting a
more accurate effective height than the desktop. But, anyway, the
inconsistency is annoying and it's not even possible to get the same
font from the resources file since the size/height granularity is less
than the one offered by emacs face specification.

bug#31702:

[Eli Zaretskii]

> From: Carlos Pita <carlosjosepita@gmail.com>
> Date: Mon, 4 Jun 2018 15:25:28 -0300
> 
> All in all I'm not sure how to feel about this issue. Despite the
> external inconsistency emacs is internally coherent and, according to
> what I described in my second comment, I would say it's selecting a
> more accurate effective height than the desktop. But, anyway, the
> inconsistency is annoying and it's not even possible to get the same
> font from the resources file since the size/height granularity is less
> than the one offered by emacs face specification.

Then maybe you can convince the developers of the desktop to follow
Emacs's example ;-)

bug#31702:

[Carlos Pita]

I noticed another weird behavior (but it's not emacs fault as explained below).

Hack:size=11 looks very different of "Hack 11" or Hack-11. In fact
"Hack 11" is more like Hack:size=15.

The fontconfig documentation states that the size property is a double
which specifies the size in points, but then it's ambiguous when
stating how the size is encoded in a descriptor. The general
descriptor format is:

<families>-<point sizes>:<name1>=<values1>:<name2>=<values2>...

where <nameX> can be "size". So there seems to be two equivalent ways
of specifying a size in points: Hack-11 and Hack:size=11.

But by trial and error I found out that when part of the name-value
list, the size property is synonymous with the pixelsize property.

So the right way to specify a point size is, in my example, Hack-11.

Now, I was concerned about missing some font sizes, since emacs is
rounding sizes in a different way than gtk or whatever is the desktop
using. But my concern was unfounded. To be sure, emacs' Hack-10 is
desktop's Hack-10 and emacs' Hack-11 is desktop's Hack-12, so there is
a gap there. Of course, this is no big deal when setting the font from
inside emacs, since I'm able to set the size with tenth-of-point
precision: instead of 110 I just set 109 to get desktop's Hack-11. But
TIL that from resources file I'm able to set double valued sizes, so
Hack-10.9 also does the trick.

:)

From my very limited experiments, it seems to be that emacs is
rounding sizes to the nearest available one while the desktop is
always rounding them down. Perhaps is a bit impolite from the part of
emacs to behave like that in a desktop environment but its behavior is
both internally consistent and more accurate. I feel inclined to close
this issue (and maybe to add an entry to the wiki explaining this font
sizing border case).

bug#31702:

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Carlos Pita <carlosjosepita@gmail.com>
>> Date: Mon, 4 Jun 2018 15:25:28 -0300
>> 
>> All in all I'm not sure how to feel about this issue. Despite the
>> external inconsistency emacs is internally coherent and, according to
>> what I described in my second comment, I would say it's selecting a
>> more accurate effective height than the desktop. But, anyway, the
>> inconsistency is annoying and it's not even possible to get the same
>> font from the resources file since the size/height granularity is less
>> than the one offered by emacs face specification.
>
> Then maybe you can convince the developers of the desktop to follow
> Emacs's example ;-)

So I take that to mean that we don't want to change anything in Emacs,
and I'm therefore closing this bug report now.

If that's incorrect, please reopen the bug report.

Best regards,
Stefan Kangas