More antialiasing work

More antialiasing work

[Chris Gray]

Well the winter holidays have come and gone, and I got to do a little
more hacking on antialiasing fonts for emacs on X.  For those who want
to follow the development, I have an arch archive located at
http://www.cs.ubc.ca/~cmg/{archive} .  You might need to register
Miles Bader's archive as well.  It is at
http://arch.linuxguru.net/~miles/miles@gnu.org--gnu-2003 .  

The latest version is much more stable than the patch I had previously
announced, though not as feature complete.  It is certainly not
something you would want to give up your regular emacs for.  

Please let me know what you think.

Cheers,
Chris

P.S.:  For those uninitiated with arch, the following commands might
work to download this version:

# apt-get install tla
$ tla register-archive http://www.cs.ubc.ca/~cmg/{archive}
$ tla register-archive http://arch.linuxguru.net/~miles/miles@gnu.org--gnu-2003
$ tla get christopher.gray@mail.mcgill.ca--archive-ubc/emacs--xft--0

After that, you are on your own.

-- 
foo

Re: More antialiasing work

[Stefan Monnier]

> Well the winter holidays have come and gone, and I got to do a little
> more hacking on antialiasing fonts for emacs on X.  For those who want
> to follow the development, I have an arch archive located at
> http://www.cs.ubc.ca/~cmg/{archive} .  You might need to register
> Miles Bader's archive as well.  It is at
> http://arch.linuxguru.net/~miles/miles@gnu.org--gnu-2003 .  

> The latest version is much more stable than the patch I had previously
> announced, though not as feature complete.  It is certainly not
> something you would want to give up your regular emacs for.  

- I had to turn off PNG support to get it to compile (might just be bad luck
  and merging recent changes to Emacs trunk might fix it).

- Otherwise, it built fine.

- I had to disable my font setting to get it to work, otherwise it just said

   emacs/xft% src/emacs -q
   Font `-misc-fixed-medium-r-semicondensed--13-*-*-*-*-*-iso8859-1' is not defined

  I guess it's just because your code is XFT-only and doesn't try to be
  backward compatible yet.

- The font it chose is some kind of helvetica thingy.  Looks really nice,
  but the proportional fonts aren't well supported in elisp, so it's
  probably not a good choice for the default.  Of course that might be due
  to the fact that helvetica is the only font it could find, I don't know.
  This is on a machine using the redhat-9 version of GNU/Linux.
  Actually, describe-font says it's adobe-courier, which it clearly isn't,
  so maybe my MacOSX display is messed up (although I thought with Xft the
  fonts are not provided by the server but by the client, in which case
  it can't be it because the problem appears both with Emacs running locally
  on the MacOSX machine and remotely on the GNU/Linux system).

- The scrollbar tends to be layed on top of the left-fringe and
  leftmost chars.  I used the default toolkit (i.e. Lucid).

- Too bad Lucid isn't using XFT.

- The cursor tends to be moved to the lower left corner of the modeline
  when I try to go to the end of the buffer.  There were a few other
  strange transient display glitches, but it might just be due to the slow
  display here (using a remote machine through X over SSH over DSL).
  Nothing very easily reproducible or even describable for now.

- On my MacOSX, freetype/freetype.h was actually in
  freetype2/freetype/freetype.h contrary to what X11/Xft/Xft.h assumed.
  And ft2build.h is actually in freetype2/ft2build.h contrary to what
  freetype/freetype.h assumed.  This looks like a messed up installation
  of freetype (which is part of the X distrib that comes with MacOSX).

- (x-list-fonts "*") only returned two elements ("fixed"
  "-adobe-helvetica-...") where the second seems to be the font actually
  displayed (contrary to what describe-font claims).  set-default-font
  refuses "fixed".

I noticed that you use xftdisp.c, xftterm.c, and xftfns.c rather than
xdisp.c, xterm.c, and xfns.c.  Unless your changes are really major, I'd
recommend you don't do that because it makes it more difficult to track
changes in Emacs code.  It also kind of defeats the purpose of revision
control software like Arch.


        Stefan

Re: More antialiasing work

[Jason Rumney]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I noticed that you use xftdisp.c, xftterm.c, and xftfns.c rather than
> xdisp.c, xterm.c, and xfns.c.

xdisp.c contains only platform independant code, so that should not
need changing just to support xft. I would have expected only font
selection and drawing functions to need replacing.