Re: macos.texi updated

[Steven Tamm <steventamm@mac.com>]

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.

-Steven

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
>                 mituharu@math.s.chiba-u.ac.jp
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>