You are not logged in.
Or (assuming this is indeed limited to pango) use a different TE…
https://bbs.archlinux.org/viewtopic.php?id=93865&p=20
Edit, linked wrong thread
Last edited by seth (2019-04-03 07:13:59)
Offline
Although that issue from that #360 disappears when I run:
$ sudo fc-cache -rs
And it replaces itself with another set of issues.
Does font-config call pango when regenerating cache? It seems so, and then it seems more likely that it's pango issue. On the other hand, it's clear that what triggers the issue is freetype2 update.
Also all screenshots that I saw from people complaining about this issue is from tiling window manager users (i3wm mostly). Does i3wm use pango and more popular wm's use something else?
Offline
xmobar and xterm can not use Dina font atm.
With xterm I get:
xterm: Selected font has no non-zero height for ISO-8859-1 encoding
Offline
ISO-8859-1 ?
locale
locale -a
Offline
You do have a point regarding ISO-8859-1
$ locale -a
C
en_US.utf8
POSIX
Normal xterm fails:
$ xterm
xterm: Selected font has no non-zero height for ISO-8859-1 encoding
Using uxterm works.
I'm pretty sure that normal xterm used to work, but I might be wrong.
EDIT: Nope. Uxterm fails as well. With ISO-8859-1 error.
Last edited by arch-ed (2019-04-03 13:30:59)
Offline
"locale" and "locale -a" produce different outputs. The latter one describes your locale config.
(This could be a simplification in the error message or a configuration problem)
@crem,
pango uses fontconfig uses freetype
The freetype change likely affected both dependent libs in different ways.
xterm uses fontconfig but not pango
Offline
seth, does Dina work with xterm for you? If you are willing to try.
Offline
"xterm -fa Dina" works for me, so does "xterm -fa 'Gohu GohuFont'"
% fc-list| grep gohu
/usr/share/fonts/misc/gohufont-uni-14.pcf.gz: Gohu GohuFont:style=Regular
/usr/share/fonts/misc/gohufont-11.pcf.gz: Gohu GohuFont:style=Regular
/usr/share/fonts/misc/gohufont-uni-11.pcf.gz: Gohu GohuFont:style=Regular
/usr/share/fonts/misc/gohufont-14.pcf.gz: Gohu GohuFont:style=Regular
/usr/share/fonts/misc/gohufont-uni-14b.pcf.gz: Gohu GohuFont:style=Bold
/usr/share/fonts/misc/gohufont-14b.pcf.gz: Gohu GohuFont:style=Bold
/usr/share/fonts/misc/gohufont-uni-11b.pcf.gz: Gohu GohuFont:style=Bold
/usr/share/fonts/misc/gohufont-11b.pcf.gz: Gohu GohuFont:style=Bold
I've some trouble selecting a pixel size for gohu ("-fs" selects a point size and idk at hand how to make xterm select pixel fonts. Bypassing fontconfig using xfontsel is rather pointless…)
Offline
xterm with Dina doesn't work for me either. And polybar also doesn't
use pango. Thus, this is obviously not limited to pango programs.
xterm uses freetype + fontconfig. But other fontconfig-based programs
do work.
I hacked xterm a bit, and managed to get it to start with Dina by
removing a call that verifies glyphs exists in the font. But it still
didn't render correctly.
I'm also fairly sure I've had some bitmap fonts that has worked, but
stopped when I installed other fonts (and thus rebuilt the font
cache).
So, looks like the problem is in fontconfig, or in how programs use
fontconfig. It also seems to be related to font fallback; programs
that doesn't bother with that works. Maybe there's an issue with how
fontconfig generates the font cache.
I guess it also could be a freetype bug, even though they say it
isn't.
Offline
I ran "sudo fc-cache -rs" and then "fc-match -v Dina" with a clean freetype-2.9 and a clean freetype-2.10, and here's the difference. Notice the charset differences, and that "lang" is empty in the 2.10 version.
--- /tmp/ft-2.9 2019-04-03 19:04:56.661331718 +0200
+++ /tmp/ft-2.10 2019-04-03 19:05:10.057988215 +0200
@@ -23,9 +23,9 @@ Pattern has 38 elts (size 48)
rgba: 1(i)(w)
scale: 1(f)(s)
charset:
- 0000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
+ 0000: 7fffffff 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(w)
- lang: aa|ay|bi|br|ch|da|de|en|es|eu|fj|fo|fur|fy|gd|gl|gv|ho|ia|id|ie|io|is|it|lb|mg|nb|nds|nl|nn|no|nr|oc|om|pt|rm|sma|smj|so|sq|ss|st|sv|sw|tl|ts|uz|vo|wa|xh|yap|zu|an|fil|ht|jv|kj|kwm|li|ms|ng|pap-an|pap-aw|rn|rw|sc|sg|sn|su|za(s)
+ lang: (s)
fontversion: 0(i)(s)
fontformat: "PCF"(w)
embeddedbitmap: True(s)
Last edited by dnkl (2019-04-03 17:16:23)
Offline
might be relevant https://github.com/stark/siji/issues/28 … -475917552
Offline
might be relevant https://github.com/stark/siji/issues/28 … -475917552
Possibly
https://git.savannah.gnu.org/cgit/freet … 45d4ebc51e
Offline
liara wrote:might be relevant https://github.com/stark/siji/issues/28 … -475917552
Possibly
https://git.savannah.gnu.org/cgit/freet … 45d4ebc51e
I did a local build of freetype-2.10 with that patch reverted, and then re-ran "sudo fc-cache -rs". Still no go.
Offline
dnkl could you locally bisect freetype2 see if you can find the causal commit so upstream knows what calls are affected?
Offline
Offline
After rebuilding the cache I lost gohu-14 and dina yells the same error.
As pointed out, there're actually more patches around the default char.
https://git.savannah.gnu.org/cgit/freet … VER-2-10-0
The entire block from 2018-07-17 to 2018-07-29 should be suspicious.
Offline
@seth I bisected it; it's in the freetype bug report linked in the post just before yours. Anyways, the commit that broke fontconfig is:
cba72a0b0f0256e61af8dc6cb1924b143b127dde is the first bad commit
commit cba72a0b0f0256e61af8dc6cb1924b143b127dde
Author: Werner Lemberg <wl@gnu.org>
Date: Sat Jul 21 23:45:32 2018 +0200
[pcf] Fix handling of the undefined glyph.
This change makes the driver use the `defaultChar' property of PCF
files.
* src/pcf/pcf.h (PCF_FaceRec): Change type of `defaultChar' to
unsigned.
* src/pcf/pcfread.c (pcf_get_encodings): Read `defaultChar' as
unsigned.
Validate `defaultChar'.
If `defaultChar' doesn't point to glyph index zero, swap glyphs with
index zero and index `defaultChar' and adjust the encodings
accordingly.
* src/pcf/pcfdrivr.c (pcf_cmap_char_index, pcf_cmap_char_next,
PCF_Glyph_Load): Undo change from 2002-06-16 which always enforced
the first character in the font to be the default character.
Offline
If you know how to compile from source, https://savannah.nongnu.org/bugs/index.php?56067 links to a (freetype) patch that fixes fontconfig's enumeration of bitmap fonts. It hasn't been accepted for merging yet, but the freetype devs asked for testers.
I have tested it, and it does solve most of the problems, if not all. But there are still caveats, see details in URL above. Dina should work. I haven't tested gohu.
Don't forget to run "sudo fc-cache -rs" after installing your self-compiled freetype lib.
Offline
@dnkl thanks, the patch works. However, it seems that Dina does not respect Xft.dpi settings, and I am unsure if it ever has - this my first computer using a hidpi screen.
Offline
Dina is a bitmap font, ie. it's not vector based, ie. the raster has a fixed display. Ie. it cannot "respect" dpi.
Offline
Ok. Thanks seth. I should have researched that part better I guess.
The Dina ttf port found in the following link is not really looking all that great either: http://www.geenat.com/?p=66
Dina must go on this laptop then.
Offline
Although it might not be a perfect solution either, other pcf fonts such as siji have solved this by simply not using the pcf format anymore, but the bdf format instead, which is unaffected. Since the dina upstream sources are in this bdf format, but are converted to pcf in the package, it's fairly straight forward to change this.
For the time being, with it unsure if its a freetype2 bug or not, I've suggested this as a possible solution in this bug report and put up a dina-font-bdf aur package that does just that. From what I can tell the font still looks and functions exactly the same everywhere as the pcf formatted one.
Cheers
Offline
It has now been confirmed to be a freetype bug, and it is being worked on.
Offline
A fix has now been committed to the freetype2 master branch and will be included in the 2.10.1 release. I've posted a bug on the arch freetype2 package, asking them to consider backporting the patch (https://bugs.archlinux.org/task/62395).
Offline
It seems that that patch was cherrypicked into latest arch package: https://bugs.archlinux.org/task/62395
Now probably just upgrade the package and issue is gone.
I'm travelling now, will only be able to check on Sunday.
Offline