In my understanding (a few months of using dillo; only lately figured this
out), there is a missing flag in the new ebuild (as was in the previous
ebuilds), which causes the fonts, perfectly available on a system, to not be
The issue can be read about in a few threads in dillo-dev, such as:
Fonts not found issue persists in 3.0.5
It finally dawned on me what must the reason be for the eye-hurting miserable
fonts, for all those months when Walter Dnes was kind enough to suggest the
need for xft in fltk:
> You also have to have x11-libs/fltk on
> your system. For fltk, the "xft" USE flag is strongly recommended. I
> wonder if the "opengl" and "threads" USE flags would help fltk+dillo.
Wow! Noone told about that in no tips, and it's not the default. Could
in here below lie some of the reason why my fonts are not found? (just,
I have --ask in my /etc/portage/make.conf):
# emerge flt
These are the packages that would be merged, in order:
Calculating dependencies ... done!
[ebuild R ] x11-libs/fltk-1.3.3-r3:1::gentoo USE="opengl -cairo
-debug -doc -examples -games -pdf -static-libs -threads -xft -xinerama"
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No]
I studied the issue, and I believe that, in the current ebuild, all that is
missing is simply ( I currently don't know to explain this better), I'll
explain using my local overlay ebuild, that installs perfectly scalable
unuicode fonts, after helping the user to fix the /etc/portage/packege.use for
fltk with the xft use flag:
# diff /usr/portage/www-client/dillo/dillo-3.0.5.ebuild \
I don't believe anything more is needed for this bug. But pls. suggest if
emerge --info is really in order. (I'll quickly post it, if I am suggested so
in the next hours that I wait for replies.)
The exceprt from the mail correspondese that I cited is actually from:
What if you want dillo, but not libXft or everything else it pulls in?
I think the best compromise might be to post a warning message after the build process and to /var/log/portage/elog warning that building dillo with fltk[-xft] is not recommended for the following reasons...
1) ***UPSTREAM RECCOMMENDS fltk[xft]*** http://www.dillo.org/FAQ.html#q19
> What libraries does dillo use?
> Dillo itself: Required: libpthread, libiconv, zlib. Optional: openssl, libpng, libjpeg.
> FLTK: At least on Unix, the minimum might be X11, Xext, plus the default
> configuration also requiring Xft and fontconfig. OpenGL, exceptions, and
> rtti can be disabled since dillo does not use them.
It's not recommended just because they feel like it.
2) I've built dillo without xft. If you launch dillo from an xterm, you'll see a slew of error messages as dillo fails to render fonts properly without xft. From upstream again... http://www.dillo.org/FAQ.html#q26
> What does "bad font: variable" mean?
> When FLTK2 (used by Dillo2) is configured with XFT disabled, it expects
> "variable" and "fixed" to be listed somewhere in your fonts.alias files
> (and furthermore to be aliases for fonts that you have :).
This is more detailed than most people's configuration.
3) Yes, dillo still manages to render fonts with fltk[-xft]... but not very pleasantly. Again, from upstream, see http://www.dillo.org/screenshots/ and click on the example that says "FLTK configured without antialiasing (--disable-xft). font_sans_serif=helvetica. 35K 20110916". The direct link is http://www.dillo.org/screenshots/disable_antialiasing.png Do you really want to stare at a screen like that all day long?
(In reply to Walter Dnes from comment #3)
> 1) ***UPSTREAM RECCOMMENDS fltk[xft]*** http://www.dillo.org/FAQ.html#q19
Yes, but you're still barking up the wrong tree. If USE=xft should be enabled by default for x11-libs/fltk, then that's not something we force in every package that uses fltk, but by setting IUSE=+fltk or by enabling it by default in profiles.
(In reply to Jeroen Roovers from comment #4)
> every package that uses fltk, but by setting IUSE=+fltk or by enabling it by
That should read: "but by setting IUSE=+xft [on x11-libs/fltk] or"
I cannot use newlines here, because something on the way changes thoese to something illegible (see my other bug 555180). In reply to Jeroen Roovers from comment #3 and #4) If you respect the Dillo program (which I hope you do), and you respect Gentoo Dillo users (which I also hope you do), please. do the advisory note that Walter Dnes suggested, and all will be fine. An average user like me will otherwise most likely live with miserable, no-unicode supporting fonts, that can not scale, which was my case for (sad to admit, but true:) at least some three months. A torture in itself. There is (I can only speak as user, really) comparison with the Dillo now: configurable, scalable, Unicode-supporting fonts, and before. (And it doesn't matter if you leave the bug invalid or not, only mercy from you towards users, by way of advicory as Walter suggested. matters. Thank you most kindly in advance!
A Tentative at dillo-3.1-dev ebuild (to see the text) https://forums.gentoo.org/viewtopic-t-1021878.html#7783338
(In reply to miro.rovis from comment #6)
Again, FORCING that USE dependency is plain stupid and isn't going to happen.
Pls. somebody tell me, what is the way to try to ask higher-ups in Gentoo, to look into this matter?
Letting you know that I also made a video about this, find all on:
FYI, this problem was basically solved somewhere in July when I set IUSE=+fltk in x11-libs/fltk as perl FLTK upstream's recommendation. Fixing it in www-client/dillo by forcing the USE dependency never was a proper solution.
(In reply to Jeroen Roovers from comment #10)
perl => per
With sincere respect I write. It took me long to figure that solution that I proposed. ...
I currently don't have the time to study and understand your kind suggestiong/explanation. ...
Be it as it may, though, I will only be happy when newbie users will be able to get a fine scalable unicode-supporting fonts, without the non-trivial knowledge currently necessary. ...
I hope you can find some way towards that end. ...