[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: macos.texi updated

From: Steven Tamm
Subject: Re: macos.texi updated
Date: Wed, 21 Sep 2005 23:12:43 -0700

To correctly use ATSUI, the way that fonts are cached and handled would have to change. The cost of creating an ATSUStyle structure is ridiculously high and a new caching system would have to be added to maintain performance. Furthermore, the calculations of line height and character width are more difficult to perform because of fractional character widths and the rounding errors was leaving artifacts all over the screen. I was also trying to maintain backwards compatibility of old XLFDs, which I'm starting to think was unwise. I've made two attempts at implementing an ATSUI based drawing engine, and I couldn't get it to work right. It would probably be easier to graft on the parts of the Aqua (sic) port into the font/calculation/drawing portions than to convert from QDText to ATSU. Unless someone has the time or the inclination to implement ATSU and pretty much rewrite the font calculation portions of macterm.


On Sep 21, 2005, at 1:21 AM, YAMAMOTO Mitsuharu wrote:

I've updated man/macos.texi.  According to admin/FOR-RELEASE, it is
subject to proofreading by at least two persons before release.
Because this is my first time to edit Texinfo files, there may be some
"texi"cal and grammatical errors.  Corrections of such errors are
also appreciated.

BTW, there seems to be (sometimes loud) complaints about the use of
QuickDraw Text and XLFD for Carbon Emacs here and there.  So let me
say something about their backgrounds.

First, when I started the implementation of Central European and
Cyrillic display support by QuickDraw Text, I already knew that Steven
Tamm was working on ATSUI support and he was planning to add it to the
emacs-unicode-2 branch (actually I suggested that).  As I expected,
the implementation by QuickDraw Text was completed much earlier than
ATSUI support (that's natural because most of the parts could be
reused), and more importantly, displayable characters were increased
without losing stability.  If it had not been implemented, Carbon
Emacs could not display characters other than Mac Roman and CJK ones
still now without installing additional fonts.

Second, I think the evacuation from XLFD for Carbon Emacs is a bad
idea at least for Emacs 22 for the following reason.  In the Emacs 20
era, the face support code was window-system dependent: there were
xfaces.c and w32faces.c, and "Emacs on Aqua" also has nsfaces.m.  The
evacuation from XLFD for non-X11 ports might be meaningful for this
version.  However, the situation has changed in Emacs 21.  The face
support code has been much enhanced (35KB -> 209KB) and become
window-system independent: we only have xfaces.c and the Carbon port
as well as the W32 port is using it.  Since XLFD is used throughout
xfaces.c, introducing another representation for fonts in the Carbon
port not only increases reimplementation work, but also has danger of
losing some functionality that is already implemented in other
systems.  Of course, maintenance of code would also become more
difficult.  So the use of XLFD is not a detour for Carbon Emacs.

                     YAMAMOTO Mitsuharu

Emacs-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]