2:23 p.m.
================================================================
Dear Bug Team!
The font resulting from doing `M-x customize-face RET default RET',
activating "Font Family", inserting "helvetica" (without quotation
marks) and clicking "State -> Set for Current Session" is _much_
larger than the default font. This doesn't look quite right.
In ~/.Xdefaults I set
Emacs.Font: -*-terminal-medium-r-*-*-18-*-*-*-*-*-iso8859-*
which gets picked up by XEmacs as well in case this is relevant.
BTW, customizing the default face in XEmacs 21.5 like described above
has no effect at all.
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: Linux penell 2.6.10 #1 Fri Feb 4 22:08:22 JST 2005 i686 GNU/Linux
./configure '--with-sound=none,native' '--with-x11'
'--extra-verbose' '--with-site-lisp' '--with-database=berkdb'
'--statedir=/var/lib' '--infodir=/usr/share/info/xemacs-21.4.17'
'--prefix=/usr' '--dynamic' '--error-checking=none'
'--debug=no' '--with-pop' '--with-gpm=no'
'--with-file-coding' '--pdump' '--with_menubars=lucid'
'--with_scrollbars=lucid' '--with_dialogs=athena'
'--docdir=/usr/lib/xemacs-21.4.17/i386-debian-linux/mule/' '--with-mule'
'--with-canna=no' '--with-wnn=no' '--with-xim=xlib'
'--with-xfs'
'--package-path=~/.xemacs:~/.xemacs/packages:~/.xemacs/xemacs-packages::/usr/share/xemacs21/xemacs-packages:/usr/share/xemacs21/mule-packages:/usr/share/xemacs21/site-packages'
'i386-debian-linux'
XEmacs 21.4.17 "Jumbo Shrimp" configured for `i386-debian-linux'.
Compilation / Installation:
Source code location: /home/mohura/packages/build-area/xemacs21-21.4.17
Installation prefix: /usr
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -g -O3 -Wall -Wno-switch -Winline
-Wmissing-prototypes -Wsign-compare -fno-strict-aliasing -Wshadow
Compiler version: gcc (GCC) 3.3.5 (Debian 1:3.3.5-8)
Compiler specs file: /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Need to guess glibc1/2/etc here
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw
- Athena library to link: Xaw
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Compiling in support for X-Face message headers.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for file coding.
Compiling in support for XIM (X11R5+ I18N input method).
- Using raw Xlib to provide XIM support.
- Using XFontSet to provide bilingual menubar.
Mail:
Compiling in support for POP mail retrieval.
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the new portable dumper.
Load-Path Lisp Shadows:
----------------------
(/usr/share/xemacs21/xemacs-packages/lisp/build/build-report
/usr/lib/xemacs-21.4.17/lisp/build-report)
Installed XEmacs Packages:
-------------------------
(skk ver: 1.23 upstream: 10.62a)
(mule-ucs ver: 1.11 upstream: 0.84)
(mule-base ver: 1.46 upstream: No-Upstream-Ver)
(lookup ver: 1.14 upstream: 1.0)
(locale ver: 1.22 upstream: No-Upstream-Ver)
(leim ver: 1.22 upstream: No-Upstream-Ver)
(latin-unity ver: 1.14 upstream: 1.14)
(latin-euro-standards ver: 1.0 upstream: 1.0)
(egg-its ver: 1.27 upstream: No-Upstream-Ver)
(edict ver: 1.16 upstream: 0.9.9)
(zenirc ver: 1.15 upstream: 2.112)
(xwem ver: 1.19 upstream: lg(a)xwem.org--2004/xwem--main--2.0--version-0)
(xslt-process ver: 1.11 upstream: 1.2.1)
(xslide ver: 1.09 upstream: 0.2.2)
(xlib ver: 1.13 upstream: lg(a)xwem.org--2004/xlib--main--2.0--version-0)
(xemacs-devel ver: 1.7 upstream: No-Upstream-Ver)
(xemacs-base ver: 1.96 upstream: No-Upstream-Ver)
(x-symbol ver: 1.1 upstream: 4.5.1)
(w3 ver: 1.3 upstream: 4.0pre47)
(vm ver: 7.18 upstream: 7.17)
(viper ver: 1.38 upstream: 3.09)
(view-process ver: 1.13 upstream: 2.4)
(vhdl ver: 1.2 upstream: 3.33.2)
(vc-cc ver: 1.22 upstream: No-Upstream-Ver)
(vc ver: 1.4 upstream: No-Upstream-Ver)
(tramp ver: 1.22 upstream: 2.0.47)
(tpu ver: 1.14 upstream: 4.2X)
(tooltalk ver: 1.15 upstream: No-Upstream-Ver)
(tm ver: 1.37 upstream: No-Upstream-Ver)
(time ver: 1.14 upstream: 1.17)
(textools ver: 1.15 upstream: No-Upstream-Ver)
(text-modes ver: 1.84 upstream: No-Upstream-Ver)
(texinfo ver: 1.28 upstream: No-Upstream-Ver)
(supercite ver: 1.2 upstream: 3.55x3)
(strokes ver: 1.1 upstream: No-Upstream-Ver)
(speedbar ver: 1.27 upstream: 0.14beta4)
(sounds-wav ver: 1.12 upstream: No-Upstream-Ver)
(sounds-au ver: 1.12 upstream: No-Upstream-Ver)
(sml-mode ver: 0.11 upstream: 3.9.5)
(slider ver: 1.15 upstream: 0.3x1)
(sieve ver: 1.17 upstream: No-Upstream-Ver)
(sh-script ver: 1.18 upstream: 2.0e)
(sgml ver: 1.11 upstream: No-Upstream-Ver)
(semantic ver: 1.19 upstream: 1.4.2)
(scheme ver: 1.14 upstream: No-Upstream-Ver)
(sasl ver: 1.15 upstream: 1.14.4)
(ruby-modes ver: 1.02 upstream: 1.6.8)
(rmail ver: 1.14 upstream: No-Upstream-Ver)
(riece ver: 1.17 upstream: 1.0.6)
(reftex ver: 1.34 upstream: 4.21)
(python-modes ver: 1.06 upstream: No-Upstream-Ver)
(psgml-dtds ver: 1.03 upstream: No-Upstream-Ver)
(psgml ver: 1.43 upstream: 1.3.1)
(ps-print ver: 1.11 upstream: 6.5.6)
(prog-modes ver: 2.02 upstream: No-Upstream-Ver)
(pgg ver: 1.05 upstream: 0.1)
(perl-modes ver: 1.07 upstream: No-Upstream-Ver)
(pcomplete ver: 1.04 upstream: 1.1.6)
(pcl-cvs ver: 1.66 upstream: R-2_9_9)
(pc ver: 1.27 upstream: No-Upstream-Ver)
(os-utils ver: 1.36 upstream: No-Upstream-Ver)
(oo-browser ver: 1.04 upstream: 4.08)
(ocaml ver: 0.05 upstream: 3.06)
(net-utils ver: 1.44 upstream: N/A)
(mmm-mode ver: 1.02 upstream: 0.4.7)
(misc-games ver: 1.18 upstream: No-Upstream-Ver)
(mine ver: 1.16 upstream: 1.9)
(mh-e ver: 1.28 upstream: 7.4.2)
(mew ver: 1.18 upstream: 1.94.2)
(mailcrypt ver: 2.14 upstream: 3.5.8)
(mail-lib ver: 1.71 upstream: No-Upstream-Ver)
(liece ver: 1.13 upstream: 1.4.9)
(jde ver: 1.46 upstream: 2.3.2)
(ispell ver: 1.31 upstream: 3.6)
(ilisp ver: 1.33 upstream: 5.12.0)
(igrep ver: 1.13 upstream: 2.111)
(idlwave ver: 1.31 upstream: 5.1)
(ibuffer ver: 1.09 upstream: No-Upstream-Ver)
(hyperbole ver: 1.16 upstream: 4.18)
(hm--html-menus ver: 1.23 upstream: 5.9)
(haskell-mode ver: 1.07 upstream: 1.45)
(gnus ver: 1.82 upstream: 5.10.6)
(gnats ver: 1.16 upstream: 3.101)
(general-docs ver: 1.03 upstream: No-Upstream-Ver)
(games ver: 1.15 upstream: 1.04)
(fsf-compat ver: 1.15 upstream: No-Upstream-Ver)
(frame-icon ver: 1.11 upstream: No-Upstream-Ver)
(fortran-modes ver: 1.04 upstream: No-Upstream-Ver)
(forms ver: 1.15 upstream: 2.37)
(footnote ver: 1.16 upstream: 0.18x)
(eudc ver: 1.39 upstream: 1.32)
(eterm ver: 1.15 upstream: No-Upstream-Ver)
(ess ver: 1.12 upstream: 5.2.3)
(eshell ver: 1.08 upstream: 2.4.1)
(escreen ver: 1.01 upstream: 1.16)
(erc ver: 0.12 upstream: Version 4.0 Revision: 1.675)
(emerge ver: 1.11 upstream: No-Upstream-Ver)
(elib ver: 1.11 upstream: 1.0)
(eieio ver: 1.05 upstream: 0.17)
(efs ver: 1.33 upstream: 1.23)
(edt ver: 1.13 upstream: No-Upstream-Ver)
(edit-utils ver: 2.22 upstream: No-Upstream-Ver)
(ediff ver: 1.51 upstream: 2.75)
(edebug ver: 1.21 upstream: No-Upstream-Ver)
(ecrypto ver: 0.19 upstream: 2.0)
(ecb ver: 1.22 upstream: 2.31)
(docbookide ver: 0.07000000000000001 upstream: 0.1)
(dired ver: 1.16 upstream: 7.12)
(dictionary ver: 1.15 upstream: 1.8)
(debug ver: 1.17 upstream: No-Upstream-Ver)
(crisp ver: 1.14 upstream: 1.34)
(cookie ver: 1.15 upstream: No-Upstream-Ver)
(clearcase ver: 1.09 upstream: /main/laptop/156)
(cc-mode ver: 1.43 upstream: 5.30.9)
(calendar ver: 1.23 upstream: No-Upstream-Ver)
(calc ver: 1.26 upstream: 2.02fX3)
(c-support ver: 1.2 upstream: No-Upstream-Ver)
(build ver: 1.14 upstream: 2.02)
(bbdb ver: 1.25 upstream: 2.34)
(auctex ver: 1.46 upstream: 11.55)
(apel ver: 1.27 upstream: 10.2)
(ada ver: 1.14 upstream: 2.27)
(Sun ver: 1.16 upstream: No-Upstream-Ver)
Installed Modules:
-----------------
Features:
--------
(mail-abbrevs xemacsbug shadow sendmail rfc822 skk-autoloads
mule-ucs-autoloads mule-base-autoloads lookup-autoloads
locale-autoloads leim-autoloads latin-unity-autoloads
latin-euro-standards-autoloads egg-its-autoloads edict-autoloads
zenirc-autoloads xwem-autoloads xslt-process-autoloads
xslide-autoloads xlib-autoloads xemacs-devel-autoloads
xemacs-base-autoloads x-symbol-autoloads w3-autoloads vm-autoloads
viper-autoloads view-process-autoloads vhdl-autoloads vc-cc-autoloads
vc-autoloads tramp-autoloads tpu-autoloads tooltalk-autoloads
tm-autoloads time-autoloads textools-autoloads text-modes-autoloads
texinfo-autoloads supercite-autoloads strokes-autoloads
speedbar-autoloads sounds-wav-autoloads sounds-au-autoloads
sml-mode-autoloads slider-autoloads sieve-autoloads
sh-script-autoloads sgml-autoloads semantic-autoloads scheme-autoloads
sasl-autoloads ruby-modes-autoloads rmail-autoloads riece-autoloads
reftex-autoloads python-modes-autoloads psgml-dtds-autoloads
psgml-autoloads ps-print-autoloads prog-modes-autoloads pgg-autoloads
perl-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads
pc-autoloads os-utils-autoloads oo-browser-autoloads ocaml-autoloads
net-utils-autoloads mmm-mode-autoloads misc-games-autoloads
mine-autoloads mh-e-autoloads mew-autoloads mailcrypt-autoloads
mail-lib-autoloads liece-autoloads jde-autoloads ispell-autoloads
ilisp-autoloads igrep-autoloads idlwave-autoloads ibuffer-autoloads
hyperbole-autoloads hm--html-menus-autoloads haskell-mode-autoloads
gnus-autoloads gnats-autoloads general-docs-autoloads games-autoloads
fsf-compat-autoloads frame-icon-autoloads fortran-modes-autoloads
forms-autoloads footnote-autoloads eudc-autoloads eterm-autoloads
ess-autoloads eshell-autoloads escreen-autoloads erc-autoloads
emerge-autoloads elib-autoloads eieio-autoloads efs-autoloads
edt-autoloads edit-utils-autoloads ediff-autoloads edebug-autoloads
ecrypto-autoloads ecb-autoloads docbookide-autoloads dired-autoloads
dictionary-autoloads debug-autoloads crisp-autoloads cookie-autoloads
clearcase-autoloads cc-mode-autoloads calendar-autoloads
calc-autoloads c-support-autoloads build-autoloads bbdb-autoloads
auctex-autoloads apel-autoloads ada-autoloads Sun-autoloads
lisp-autoloads loadhist auto-show fontl-hooks x-iso8859-1 slovenian
czech romanian ccl mule-help code-cmds gutter-items menubar-items
x-menubar mode-motion mouse itimer auto-save lisp-mode easymenu
iso8859-1 page buff-menu lib-complete cus-file derived frame
text-props obsolete cus-start custom widget cl-extra mini-cl cl cl-19
packages backquote very-early-lisp file-coding mule lucid-scrollbars
cut-buffer lucid-menubars athena-dialogs x c-balloon-help tty-frames
tty toolbar native-sound scrollbar unix-processes multicast
network-streams subprocesses modules menu-accelerator-support menubar
berkeley-db md5 xemacs xim gutter tiff png gif jpeg xface xpm xbm
lisp-float-type linux dialog devices window-system base64)
Recent keystrokes:
-----------------
M-x r e p o r t - x e m TAB RET
Recent messages (most recent first):
-----------------------------------
Loading xemacsbug...done
Loading xemacsbug...
--
Ralf
2:43 p.m.
Ar an seachtú lá déag de mí Márta, scríobh Ralf Angeli:
The font resulting from doing `M-x customize-face RET default
RET',
activating "Font Family", inserting "helvetica" (without quotation
marks) and clicking "State -> Set for Current Session" is _much_
larger than the default font. This doesn't look quite right.
In ~/.Xdefaults I set
Emacs.Font: -*-terminal-medium-r-*-*-18-*-*-*-*-*-iso8859-*
which gets picked up by XEmacs as well in case this is relevant.
I don’t see that. When I start an xemacs -vanilla with that resource in my
xrdb, and nothing else, I get a horrible, huge, font; when I do what you
describe, I get a slightly bigger, slightly better-looking Helvetica.
What exact font does that pattern resolve to for you? For me,
xfd -fn '-*-terminal-medium-r-*-*-18-*-*-*-*-*-iso8859-*' gives an xfd
window describing
-Bitstream-Terminal-Medium-R-Normal--18-140-100-100-C-110-ISO8859-1 . After
making your change,
(font-truename (face-font (get-face 'default)))
within XEmacs gives
"-Adobe-Helvetica-Medium-R-Normal--25-180-100-100-P-130-ISO8859-1"
I _suspect_ this is a peculiarity of your local X11 installation, but give
us more details and we can try to work that out.
BTW, customizing the default face in XEmacs 21.5 like described
above
has no effect at all.
There’s been massive breakage in X11 server-side fonts in 21.5 for ages :-(
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien
3:18 p.m.
* Aidan Kehoe (2005-03-17) writes:
Ar an seachtú lá déag de mí Márta, scríobh Ralf Angeli:
> The font resulting from doing `M-x customize-face RET default RET',
> activating "Font Family", inserting "helvetica" (without
quotation
> marks) and clicking "State -> Set for Current Session" is _much_
> larger than the default font. This doesn't look quite right.
>
> In ~/.Xdefaults I set
> Emacs.Font: -*-terminal-medium-r-*-*-18-*-*-*-*-*-iso8859-*
> which gets picked up by XEmacs as well in case this is relevant.
I don’t see that. When I start an xemacs -vanilla with that resource in my
xrdb, and nothing else, I get a horrible, huge, font;
If that's the same font I am using, try to imagine how it looks on a
120dpi display.
when I do what you
describe, I get a slightly bigger, slightly better-looking Helvetica.
What exact font does that pattern resolve to for you? For me,
xfd -fn '-*-terminal-medium-r-*-*-18-*-*-*-*-*-iso8859-*' gives an xfd
window describing
-Bitstream-Terminal-Medium-R-Normal--18-140-100-100-C-110-ISO8859-1 .
Same here.
After
making your change,
(font-truename (face-font (get-face 'default)))
within XEmacs gives
"-Adobe-Helvetica-Medium-R-Normal--25-180-100-100-P-130-ISO8859-1"
Here this returns
"-urw-nimbus sans l-regular-r-condensed--42-300-100-100-p-194-iso8859-1"
$ find /usr/X11R6/lib/X11/fonts/ -name fonts.dir | xargs grep "nimbus sans
l-regular-r-condensed"
/usr/X11R6/lib/X11/fonts/Type1/fonts.dir:n019043l.pfb -urw-nimbus sans
l-regular-r-condensed--0-0-0-0-p-0-iso8859-1
/usr/X11R6/lib/X11/fonts/Type1/fonts.dir:n019043l.pfb -urw-nimbus sans
l-regular-r-condensed--0-0-0-0-p-0-iso8859-2
/usr/X11R6/lib/X11/fonts/Type1/fonts.dir:n019043l.pfb -urw-nimbus sans
l-regular-r-condensed--0-0-0-0-p-0-iso8859-15
n019043l.pfb is part of the gsfonts-x11 package in Debian/sid.
I _suspect_ this is a peculiarity of your local X11 installation, but
give
us more details and we can try to work that out.
$ xdpyinfo
name of display: :0.0
version number: 11.0
vendor string: The XFree86 Project, Inc
vendor release number: 40300001
XFree86 version: 4.3.0.1
[...]
This is the version distributed with Debian/sid, so not really a
vanilla XFree86 4.3.0.
--
Ralf
3:44 p.m.
Ar an seachtú lá déag de mí Márta, scríobh Ralf Angeli:
If that's the same font I am using, try to imagine how it looks
on a
120dpi display.
:-) 112 locally.
>
"-Adobe-Helvetica-Medium-R-Normal--25-180-100-100-P-130-ISO8859-1"
Here this returns
"-urw-nimbus sans l-regular-r-condensed--42-300-100-100-p-194-iso8859-1"
$ find /usr/X11R6/lib/X11/fonts/ -name fonts.dir | xargs grep "nimbus sans
l-regular-r-condensed"
/usr/X11R6/lib/X11/fonts/Type1/fonts.dir:n019043l.pfb -urw-nimbus sans
l-regular-r-condensed--0-0-0-0-p-0-iso8859-1
/usr/X11R6/lib/X11/fonts/Type1/fonts.dir:n019043l.pfb -urw-nimbus sans
l-regular-r-condensed--0-0-0-0-p-0-iso8859-2
/usr/X11R6/lib/X11/fonts/Type1/fonts.dir:n019043l.pfb -urw-nimbus sans
l-regular-r-condensed--0-0-0-0-p-0-iso8859-15
n019043l.pfb is part of the gsfonts-x11 package in Debian/sid.
> I _suspect_ this is a peculiarity of your local X11 installation, but give
> us more details and we can try to work that out.
$ xdpyinfo
name of display: :0.0
version number: 11.0
vendor string: The XFree86 Project, Inc
vendor release number: 40300001
XFree86 version: 4.3.0.1
[...]
This is the version distributed with Debian/sid, so not really a
vanilla XFree86 4.3.0.
Okay, if you move the 100dpi directory befor the Type1 directory in either
the font path of your X server or of your font server, as appropriate, you
should get a much better looking font. (You may need to install some package
to make it available.) There’s nothing wrong with the URW font, it’s just
that the XFree86 Type1 font renderer is unfinished, and as such the bitmap
(.pcf) fonts are much better when they’re available.
Strangely, I get
"-urw-nimbus sans l-medium-r-condensed--19-180-75-75-p-85-iso8859-1"
when I repeat your steps but with nimbus sans l instead of helvetica; if you
are using a font server, there’s a default DPI setting there that may
explain our differences.
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien
4:23 p.m.
* Aidan Kehoe (2005-03-17) writes:
Ar an seachtú lá déag de mí Márta, scríobh Ralf Angeli:
> If that's the same font I am using, try to imagine how it looks on a
> 120dpi display.
:-) 112 locally.
Hm, that's not much difference. And you consider the font to be huge?
Either you have a magnifying glass in front of your display or eagle
eyes. (c:
> >
"-Adobe-Helvetica-Medium-R-Normal--25-180-100-100-P-130-ISO8859-1"
>
> Here this returns
>
> "-urw-nimbus sans l-regular-r-condensed--42-300-100-100-p-194-iso8859-1"
[...]
Okay, if you move the 100dpi directory befor the Type1 directory in
either
the font path of your X server or of your font server, as appropriate, you
should get a much better looking font. (You may need to install some package
to make it available.) There’s nothing wrong with the URW font, it’s just
that the XFree86 Type1 font renderer is unfinished, and as such the bitmap
(.pcf) fonts are much better when they’re available.
There is no font server running here.
I moved the Type1 directory to the last position of the list of font
paths and restarted the X server. After this the font looked even
worse, i.e. it was as large as the URW font but with rough edges.
Here is what (font-truename ...) returned:
"-adobe-helvetica-medium-r-normal--42-300-100-100-p-223-iso8859-1"
This is probably aliased to the URW font but I don't know which font
package to install in order to get the real Adobe Helvetica; at least
xfonts-100dpi-transcoded and xfonts-75dpi-transcoded did not do the
trick.
Strangely, I get
"-urw-nimbus sans l-medium-r-condensed--19-180-75-75-p-85-iso8859-1"
when I repeat your steps but with nimbus sans l instead of helvetica; if you
are using a font server, there’s a default DPI setting there that may
explain our differences.
Hm, I have a DisplaySize statement in my XF86Config-4 file, maybe this
has some influence.
Anyway, the reason I am asking is that AUCTeX uses a proportional font
for displaying section headings. Now if other people have a similar
setup like me, the section headings will come out in the totally wrong
size. That means playing around with the X server configuration is
not really a solution. It would be better if XEmacs could
display/choose the font in the right size.
I found that I can help XEmacs a bit if I explicitely specify the size
of the face. That means when customizing the face it does not come
out as big as before if I activate the "Size" specifier and insert
"18pt" besides the "helvetica" for the font family. But it still is
noticably larger than the 18-pixel default font.
--
Ralf
4:43 p.m.
Ar an seachtú lá déag de mí Márta, scríobh Ralf Angeli:
I moved the Type1 directory to the last position of the list of font
paths and restarted the X server. After this the font looked even
worse, i.e. it was as large as the URW font but with rough edges.
Hmm, I could have sworn that the XFree86 people turned off the scaling of
bitmap fonts by default before 4.3.0. I think it is the bitmap Adobe
font--if it _had_ been aliased to the URW font, the font-truename would have
returned “nimbus sans l” as its name. Perhaps Debian have re-enabled bitmap
font scaling on your system.
This is probably aliased to the URW font but I don't know which
font
package to install in order to get the real Adobe Helvetica; at least
xfonts-100dpi-transcoded and xfonts-75dpi-transcoded did not do the
trick.
[...] Hm, I have a DisplaySize statement in my XF86Config-4 file,
maybe
this has some influence.
Could do.
Anyway, the reason I am asking is that AUCTeX uses a proportional
font
for displaying section headings. Now if other people have a similar
setup like me, the section headings will come out in the totally wrong
size. That means playing around with the X server configuration is
not really a solution. It would be better if XEmacs could
display/choose the font in the right size.
It would be even better if XEmacs were using another window system :-)
There’s always a certain amount of gambling when choosing a default font as
an application in X11; the most important thing, and it can be surprisingly
easy to have that fail, is to not have the app crash[1]. After that, well,
if someone has an atypical setup, and their fonts look horrible, that’s not
sometyhing you can avoid.
I found that I can help XEmacs a bit if I explicitely specify the
size
of the face. That means when customizing the face it does not come
out as big as before if I activate the "Size" specifier and insert
"18pt" besides the "helvetica" for the font family. But it still is
noticably larger than the 18-pixel default font.
Oww! When I do that on my machine, it’s even huger and more surprising.
Though perhaps just about acceptable for section
headings. “-Adobe-Helvetica-Medium-R-Normal--25-180-100-100-P-130-ISO8859-1”
is the full xlfd.
[1] http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-02/msg00190.html
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien
4:58 p.m.
* Aidan Kehoe (2005-03-17) writes:
Ar an seachtú lá déag de mí Márta, scríobh Ralf Angeli:
> I moved the Type1 directory to the last position of the list of font
> paths and restarted the X server. After this the font looked even
> worse, i.e. it was as large as the URW font but with rough edges.
Hmm, I could have sworn that the XFree86 people turned off the scaling of
bitmap fonts by default before 4.3.0. I think it is the bitmap Adobe
font--if it _had_ been aliased to the URW font, the font-truename would have
returned “nimbus sans l” as its name. Perhaps Debian have re-enabled bitmap
font scaling on your system.
This could well be because AFAIK they patched it up with many things
done during development of 4.4.0 until the point the licence was
changed.
There’s always a certain amount of gambling when choosing a default
font as
an application in X11; the most important thing, and it can be surprisingly
easy to have that fail, is to not have the app crash[1]. After that, well,
if someone has an atypical setup, and their fonts look horrible, that’s not
sometyhing you can avoid.
As you are referring to GNU Emacs with the crash you are mentioning, I
am tempted to refer to it as well when I say that there are
applications which actually are able to avoid horribly looking
fonts. (c;
> I found that I can help XEmacs a bit if I explicitely specify
the size
> of the face. That means when customizing the face it does not come
> out as big as before if I activate the "Size" specifier and insert
> "18pt" besides the "helvetica" for the font family. But it
still is
> noticably larger than the 18-pixel default font.
Oww! When I do that on my machine, it’s even huger and more surprising.
Though perhaps just about acceptable for section
headings. “-Adobe-Helvetica-Medium-R-Normal--25-180-100-100-P-130-ISO8859-1”
is the full xlfd.
That's actually what I am getting as well. So XEmacs seems to have a
problem only if there is no size specified.
--
Ralf
5:14 p.m.
Ar an seachtú lá déag de mí Márta, scríobh Ralf Angeli:
[...] As you are referring to GNU Emacs with the crash you are
mentioning, I am tempted to refer to it as well when I say that there are
applications which actually are able to avoid horribly looking fonts. (c;
Eh, that’s a subjective call. And we do have a whisper of a decent redisplay
infrastructure on X11 in the pipeline;
http://www.parhasard.net/aidan-gnus-sjt-xft-2005-03-02.png .
> > I found that I can help XEmacs a bit if I explicitely
specify the size
> > of the face. That means when customizing the face it does not come
> > out as big as before if I activate the "Size" specifier and insert
> > "18pt" besides the "helvetica" for the font family. But
it still is
> > noticably larger than the 18-pixel default font.
>
> Oww! When I do that on my machine, it’s even huger and more surprising.
> Though perhaps just about acceptable for section
> headings. “-Adobe-Helvetica-Medium-R-Normal--25-180-100-100-P-130-ISO8859-1”
> is the full xlfd.
That's actually what I am getting as well. So XEmacs seems to have a
problem only if there is no size specified.
Let me re-iterate that, but more concisely; I see a problem when the size is
specified, and not otherwise. In your place, I would consult with more
people before specifying a size by default, because your setup seems strange
enough that what works there may look horrible with more widespread
defaults.
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien
5:44 p.m.
* Aidan Kehoe (2005-03-17) writes:
Ar an seachtú lá déag de mí Márta, scríobh Ralf Angeli:
> [...] As you are referring to GNU Emacs with the crash you are
> mentioning, I am tempted to refer to it as well when I say that there are
> applications which actually are able to avoid horribly looking fonts. (c;
Eh, that’s a subjective call.
I was mainly referring to the problem with font size because that's
what we are talking about.
And we do have a whisper of a decent redisplay
infrastructure on X11 in the pipeline;
http://www.parhasard.net/aidan-gnus-sjt-xft-2005-03-02.png .
Hm, I am still not sure if I like anti-aliased fonts inside of an
editor. Currently I tend to favor a good "plain" font. So /this/
certainly is subjective.
> So XEmacs seems to have a
> problem only if there is no size specified.
Let me re-iterate that, but more concisely; I see a problem when the size is
specified, and not otherwise. In your place, I would consult with more
people before specifying a size by default, because your setup seems strange
enough that what works there may look horrible with more widespread
defaults.
Okay, I played a bit more and I could persuade XEmacs to pick the
correct font size by specifying the full font name for the X resource,
i.e.
Emacs.Font: -bitstream-terminal-medium-r-normal--18-140-100-100-c-110-iso8859-1
Shouldn't it be able to resolve this itself?
--
Ralf
2:36 a.m.
>>>> "Ralf" == Ralf Angeli
<angeli(a)iwi.uni-sb.de> writes:
Ralf> Emacs.Font:
Ralf> -bitstream-terminal-medium-r-normal--18-140-100-100-c-110-iso8859-1
Ralf> Shouldn't it be able to resolve this itself?
Yes, "it" should, but "it" refers to the X server or X font server,
not to the application. Specifying less than a fully-specified XLFD
is asking for trouble, as there is no X11 standard for what font from
a given available list will be picked, except for the fontpath. Even
then you can get hosed if the distro does things like alias 75dpi
fonts into the 100dpi path, because the internal font data (which
XEmacs actually uses, isn't that horrible!) will be different from
that specified in the XLFD.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
9:40 a.m.
* Stephen J. Turnbull (2005-03-18) writes:
>>>>> "Ralf" == Ralf Angeli
<angeli(a)iwi.uni-sb.de> writes:
Ralf> Emacs.Font:
Ralf> -bitstream-terminal-medium-r-normal--18-140-100-100-c-110-iso8859-1
Ralf> Shouldn't it be able to resolve this itself?
Yes, "it" should, but "it" refers to the X server or X font server,
not to the application.
I don't know if this is possible, but wouldn't it be a good idea for
XEmacs to ask the X server to resolve the value? I dug a bit in the
code and what it actually does is simply exchanging certain parts in
the XLFD string of the default font when a face is altered. This
fails on my computer when it tries to compute the canonical size (in
points) for the new XLFD.
I used the following code snippet for debugging (extracted from
`make-face-family' and `frob-face-property'):
(let* ((f (face-property-instance 'default 'font))
(d (car (device-list)))
(fo (font-create-object (font-instance-name f) d)))
(set-font-family fo "helvetica")
(font-create-name fo d))
In case the X resource of the default font includes both the size in
pixels and decipoints (in my setup 18 pixels and 140 decipoints) the
snippet returns
"-*-helvetica-medium-r-*-*-*-140-*-*-*-*-iso8859-1"
This looks reasonable.
If the XLFD includes only the size in pixels XEmacs tries to convert
it into points and this is where it fails on my computer. The
result of executing the snippet above is this:
"-*-helvetica-medium-r-*-*-*-300-*-*-*-*-iso8859-*"
What happens is that `font-size' for the default font returns "18px"
(instead of 14 for the fully specified one). This value gets fed into
`font-spatial-to-canonical' which returns 30.97. This can be checked
easily with
(font-spatial-to-canonical "18px" (car (device-list)))
(The car of `device-list' on my computer is the X device.)
The return value is computed from
(setq retval (* num (/ pix-width mm-width) (/ 25.4 72.0))))
with num=18, pix-width=1400 and mm-width=287 on my setup.
This formula is not correct. You can deduct that by looking at the
units:
(* px (/ px mm) (/ mm pt)) will result in px²/pt
The correct formula would look like this:
(* num (/ mm-width pix-width) (/ 72 25.4))
On my computer this will result in 10.46pt which is a _much_ saner
value than the one computed before. The resulting font is a bit too
small because the 18 pixels of the default font correspond to 14
points and not 10 points, but I guess one cannot do much about that.
So this indeed is a bug in XEmacs and not a broken setup.
Do you want a patch with that? (c;
--
Ralf
1:30 p.m.
Ar an t-ochtú lá déag de mí Márta, scríobh Ralf Angeli:
Do you want a patch with that? (c;
If you’re offering :-) Excuse the general slow turnaround on your patches;
you tend to make good arguments on things people don’t have huge experience
with. We’ll get to them, though.
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien
9:14 a.m.
* Aidan Kehoe (2005-03-20) writes:
Ar an t-ochtú lá déag de mí Márta, scríobh Ralf Angeli:
> Do you want a patch with that? (c;
If you’re offering :-) Excuse the general slow turnaround on your patches;
you tend to make good arguments on things people don’t have huge experience
with. We’ll get to them, though.
Here you are:
2005-03-21 Ralf Angeli <angeli(a)iwi.uni-sb.de>
* font.el (font-spatial-to-canonical): Correct calculation of
return value for pixel-based input value.
The patch is against the release-21-4 branch. The trunk will need the
same change. I also adapted the doc string because edebug had
problems with the unescaped parenthesis at the start of the line.
--
Ralf
4:30 a.m.
>>>> "Ralf" == Ralf Angeli
<angeli(a)iwi.uni-sb.de> writes:
Ralf> I don't know if this is possible, but wouldn't it be a good
Ralf> idea for XEmacs to ask the X server to resolve the value?
No. That's a roundtrip query, very expensive (it only takes a few
roundtrips to result in a noticable delay even on 10 Mbps LAN).
Unfortunately, the people who designed X assumed it was going to run
with sophisticated clients over a network, while "modern" Linux
distros typically optimize it to run with very naive clients on the
same workstation as the server. XEmacs has a _lot_ of users who
depend on reasonable behavior over a reasonable connection (eg, ADSL).
If the server is running on the same workstation as the client, the
right way to go is Xrender.
Ralf> So this indeed is a bug in XEmacs and not a broken setup.
Ralf> Do you want a patch with that? (c;
Sure, but I wouldn't bet on it fixing everything. :-(
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:31 a.m.
* Stephen J. Turnbull (2005-03-22) writes:
>>>>> "Ralf" == Ralf Angeli
<angeli(a)iwi.uni-sb.de> writes:
Ralf> Do you want a patch with that? (c;
Sure, but I wouldn't bet on it fixing everything. :-(
Well, if it at least fixes _something_ and does not break anything
else, it should be okay, shouldn't it?
--
Ralf
11:15 a.m.
>>>> "Ralf" == Ralf Angeli
<angeli(a)iwi.uni-sb.de> writes:
Ralf> Well, if it at least fixes _something_ and does not break
Ralf> anything else, it should be okay, shouldn't it?
For sure!
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7532
days inactive
7537
days old
15 comments
3 participants
participants (3)
-
Aidan Kehoe -
Ralf Angeli -
Stephen J. Turnbull