Ticket #5775 (new defect)

Opened 18 months ago

Last modified 18 months ago

It is basically impossible to install bitmapped fonts.

Reported by: karmaflux Owned by: bernie
Priority: normal Milestone: Future Release
Component: x window system Version:
Keywords: Cc: mwolson@…
Action Needed: Verified: yes
Deployments affected: Blocked By:
Blocking:

Description

X.org, as started by olpc-dm, uses -fp built-ins. The only font built-in is an unreadably small instance of "fixed." Attempting to add a fontpath with xset results in the following error message:

xset: bad font path element (#61), possible causes are:
Directory does not exist or has wrong permissions
Directory missing fonts.dir
Incorrect font server address or syntax 

regardless of the directory permissions, the presence of fonts.dir, or whether you start X from olpc-dm, or boot into runlevel 4 and manually initiate X. Adding a FontPath in a "Files" section in /etc/X11/xorg.conf results in a

Could not init font path element /usr/share/X11/fonts/100dpi/, removing from list!

line in /var/log/Xorg.0.log.

I know that bitmapped fonts are not a priority. However, lots of legacy x11 software is essentially unavailable to XO users with the current configuration. Is there a compelling reason to break font handling? What is being gained from this? May we not at least look at having built-in fonts which are more appropriately sized for the XO's resolution?

Change History

Changed 18 months ago by frankprindle

I agree, xset fs seems to be broken. See ticket #864 where it recommends doing exactly this for the dejavu font aliases posted therein. I've asked the question there, but I'm repeating it here because this ticket is current.

Changed 18 months ago by frankprindle

Whoops, I meant "xset fp" (or "xset +fp").

Changed 18 months ago by jg

  • keywords font, xfs, xorg removed
  • milestone changed from Never Assigned to Future Release

We will never support xfs.

There was a mistake that caused font aliases that cause most legacy X applications to evaporate in the Ship.2 release. These will be in update.1.

I'd expect xset fp to work.... I presume you have a properly set up font directory????

I suggest, however, that font aliases to the existing outline fonts are a better solution for almost all applications.

Bernie?

Changed 18 months ago by frankprindle

My point (and karmaflux's point) is that "xset +fp" does not work when used EXACTLY as detailed in #864, i.e. after adding the 3 fonts.* files to the dejavu fonts directory as recommended. Nor does it work if I simply yum-up the old xorg "misc" fonts directory, and try to use "xset +fp" with that. The font aliases idea is great, but only if we can tell the X server to make them available to the legacy apps that don't know beans about how to access the new fonts directly. Adobe flash is one of those, but I have a half dozen of my own (all at least 5-10 years old). Sure, I can change all the fallbacks to "fixed", but who with my 61-year-old eyes can read it?

Changed 18 months ago by karmaflux

All the fonts.alias in the world won't help without a font server. xset +fp will not work, because the only font server available is x.org itself, which has been instructed to use builtins.

I have a properly set-up font directory. Not only did I try making one manually with mkfontscale and mkfontdir, I copied an entire font directory from an existing FC7 install and ensured the permissions remained the same.

Changed 18 months ago by frankprindle

I understand all that, but exactly how is it that X "has been instructed" to use ONLY builtins, i.e. to ignore all "xset fp" requests?

Even if I run an instance of xfs and get it hooked to a fonts.dir, the client isn't going to ask xfs for fonts, it's going to ask the X server, which would need to be configured to pass the query along to xfs, which would need an "xset +fp tcp/:...." (or unix/:..., depending on how xfs is set up), which presumably doesn't work either.

I'm not disagreeing with karmaflux... there is indeed a bit of a disconnect here. That is not to say OLPC needs to include any server-side fonts on the XO, it just shouldn't preclude installing them as needed. I'm hoping that when Update.1 comes out, we'll be able to sniff out exactly how the dejavu aliases get utilized, and use the same method to add any additional. The method detailed in #864 simply doesn't work.

Changed 18 months ago by mwolson

  • cc mwolson@… added
  • verified set

This bug is annoying me as well -- I'm having to use Emacs from the Terminal instead of the X/GTK version, and that limits me from viewing images and seeing bold/italic text. I hope to see this assigned to a particular milestone soon.

Changed 18 months ago by cjb

mwolson: Aside from this bug, if you install an Emacs that's built from the Emacs "unicode-2" branch, you'll get Xft font support and can use the GTK version. I've done this on my XO before.

Note: See TracTickets for help on using tickets.