Re: [PATCH] Xft patch reloaded, #3

>>>>> "ms" == Michael Sperber <[email protected]> writes:

    ms> No, I don't think you should.  I've said so about five times.
    ms> I also don't see the responses you're referring to.

I'm confused (obviously).  What is the discussion that is going on,
then?

My position is

1.  Xft Reloaded, #3 is not ready for prime time yet.  [It seems you
    agree.]

2.  The technical issues are listed concisely in
<a href="http://list-archive.xemacs.org/xemacs-patches/200311/msg00087.html">
    [email protected]</a>
    [The immediate responses by you and Matthias indicate that you
    thought this was satisfactorily dealt with by #ifdef'ing, and
    defaulting to off.  I don't know what you think now.]

3.  Of those, I consider the issues related to lwlib valid, but
    concede that they probably are best "solved" for now by removing
    the menubar part of the patch as in Xft Reloaded, #3.  However,
    some attention should be given to the design issue of not making
    life difficult for future programmers who want to work on lwlib.

    In particular, this is a good time to factor out those parts of
    the face cache code that are used by both lwlib and the frame
    widget into a consistent API.  Ditto the color stuff, which is
    really ad hoc, as is the handling of the graphics context cache.

4.  Mule and Customization support are policy as far as I know, and
    providing that support is the responsibility of the contributor.
    That includes design.

5.  There are two ways to go about providing Mule font support with
    Xft.  One is to fix the broken 16-bit code in Xft Reloaded (I
    tried this on top of #2); the other is to use UTF-8 APIs as in the
    "Russian patch".  Neither currently works, and neither I nor the
    Eric/Matthias team currently knows how to do it AFAIK.

6.  The issue of integrating fontconfig specs with Windows specs is
    more important than you might think because it turns out that the
    issue of what characters are provided by a font is buried in
    there.  This is not a problem with core fonts because the font
    spec contains the charset registry, but this is not so for Xft.
    This is especially crucial for non-Latin-1 Latin charsets under
    Mule, because they often get mixed into a Latin-1 buffer and a
    naive treatment typically ends up assigning them different fonts.

I conclude that the patch is less than 50% done, and nobody currently
expert in Mule or Customization (the majority of the missing part) is
committed to working on it.  Thus I want to

1.  Veto this patch so that it doesn't bitrot in the trunk.  Cf. the
    comment below about "framework" for one example of the kind of
    thing I think very likely to bitrot as bugfixes are applied by
    third parties (ie, reviewers who haven't worked on the Xft code
    before) to the code itself but such comments fail to be updated.

2.  Wait for a patch that

    o factors out face cache, color, and GC access into defined APIs,
    o provides a framework for Mule menu and Customization support,
    o a working implementation of extended character display, and
    o working charset coverage querying, preferably dealing with the
      comment in objects-msw.c that such querying probably should be
      done when displaying the character rather than when loading the
      font (I'm not sure that comment is entirely correct).

    Also, provide comments detailing the work that needs to be done,
    and any conjectures about the implementation that are available.

I can't define "framework."  I'll know it when I see it, but it's
definitely less than "full support".  It may not even require any
implementation: it might simply be a matter of a sufficiently explicit
comment that "this code will need to be modified in the following ways
when the ability to select fonts by character set is implemented: ...".

*****

A trivial issue that _must_ be fixed before committing: copyright
notices in the new files.

Minor issues (don't prevent committing, but should promise to discuss
and fix where needed quickly) that I mention here because I just
reviewed the patch again and noticed them:

there's still a lot of unnecessary code duplication in xft-fonts.c
    (wouldn't defsubsts in xft.el be just as good?)
we probably already have a MINL macro if we can substitute EMACS_INT
    for long in Xft-related usage,
we should require Xft2 + fontconfig and get rid of references to Xft1,
texi documentation for users and programmers.

-- 
Institute of Policy and Planning Sciences     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.