emacs-devel
[Top][All Lists]
Advanced

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

macos.texi updated


From: YAMAMOTO Mitsuharu
Subject: macos.texi updated
Date: Wed, 21 Sep 2005 17:21:33 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

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
                                address@hidden




reply via email to

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