[Bug: 21.5-b28] w3 fails on font-spatial-to-canonical

[Aidan Kehoe]

 Ar an séiú lá de mí Lúnasa, scríobh Stephen J. Turnbull: 

 > Aidan Kehoe writes:
 > 
 >  > The size isn’t even that useful; XFT DPI is independent of that for
 >  > server side fonts, though it will often be close. I find myself also
 >  > forgetting to run xrdb -DXEMACS_XFT ~/.Xdefaults before starting an
 >  > XFT XEmacs.
 > 
 > I don't understand what you mean by "independent of that".  I perceive
 > a big difference between
 > -adobe-courier-medium-r-normal--17-120-100-100-m-100-iso8859-1 and
 > -adobe-courier-medium-r-normal--34-240-100-100-m-200-iso8859-1.  If
 > the user has specified a 24pt font in .Xresources, we should respect
 > that.

http://scanline.ca/dpi/ for the details. Basically, the DPI can be set for
XFT applications via an X resource and via the Gnome settings daemon, and
this setting won’t be respected by core fonts. I don’t know how common such
differentiation is on Gnome desktops, but it does mean that the DPIs for the
two are independent.

 > We currently don't have a way to respect that spec on Xft AFAIK, but
 > it's one of the things I work on off and on.  I see no reason why we
 > shouldn't allow any of the various font specs on any platform,
 > although in cases of ambiguity we should prefer different defaults for
 > different platforms.

XLFDs (and X server-side fonts in general) are old and broken (in terms of
size, scalable-or-not, repertoire and other reasons). GNU using them on
Carbon (and even on Windows?) was not a good idea. I am really thankful that
they are not available in XEmacs on Windows.

-- 
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)