unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Emacs antialiasing in X
@ 2005-08-08 14:34 Bill Atkins
  2005-08-09 14:35 ` Jan D.
  0 siblings, 1 reply; 41+ messages in thread
From: Bill Atkins @ 2005-08-08 14:34 UTC (permalink / raw)


Are there currently any plans to support antialiasing in X, even on an
experimental basis?

-- 
Bill Atkins

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2005-08-08 14:34 Emacs antialiasing in X Bill Atkins
@ 2005-08-09 14:35 ` Jan D.
  2005-12-20 20:17   ` David Abrahams
  0 siblings, 1 reply; 41+ messages in thread
From: Jan D. @ 2005-08-09 14:35 UTC (permalink / raw)
  Cc: emacs-devel


> Are there currently any plans to support antialiasing in X, even on an
> experimental basis?

I hope we can have this done in the release after the upcoming  
release.  There is a (highly experimental) branch in CVS.  I know  
there is a unicode-xft branch somewhere also, but I have lost that  
location.

     Jan D.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2005-08-09 14:35 ` Jan D.
@ 2005-12-20 20:17   ` David Abrahams
  2005-12-21  5:30     ` Richard M. Stallman
  0 siblings, 1 reply; 41+ messages in thread
From: David Abrahams @ 2005-12-20 20:17 UTC (permalink / raw)


"Jan D." <jan.h.d@swipnet.se> writes:

>> Are there currently any plans to support antialiasing in X, even on an
>> experimental basis?
>
> I hope we can have this done in the release after the upcoming
> release.  There is a (highly experimental) branch in CVS.  I know
> there is a unicode-xft branch somewhere also, but I have lost that
> location.


I would consider it a worthwhile use of my time to help in that
effort.  Please let me know when you're ready to begin, if you'd like
a hand with it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2005-12-20 20:17   ` David Abrahams
@ 2005-12-21  5:30     ` Richard M. Stallman
  2005-12-21 13:17       ` David Abrahams
  0 siblings, 1 reply; 41+ messages in thread
From: Richard M. Stallman @ 2005-12-21  5:30 UTC (permalink / raw)
  Cc: emacs-devel

    I would consider it a worthwhile use of my time to help in that
    effort.  Please let me know when you're ready to begin, if you'd like
    a hand with it.

If you want to work on this in the branch where it has been started,
that can be done now.  There is no need to wait.

The first step is to talk with the people who were working on it in
that branch.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2005-12-21  5:30     ` Richard M. Stallman
@ 2005-12-21 13:17       ` David Abrahams
  2005-12-22  9:38         ` Jan D.
  0 siblings, 1 reply; 41+ messages in thread
From: David Abrahams @ 2005-12-21 13:17 UTC (permalink / raw)
  Cc: emacs-devel

"Richard M. Stallman" <rms@gnu.org> writes:

>     I would consider it a worthwhile use of my time to help in that
>     effort.  Please let me know when you're ready to begin, if you'd like
>     a hand with it.
>
> If you want to work on this in the branch where it has been started,
> that can be done now.  There is no need to wait.
>
> The first step is to talk with the people who were working on it in
> that branch.

That was the point of my posting.  The post I responded to seemed to
be from the initiator of the branch, and he seemed to have specific
plans.  I'm not volunteering to lead the effort, but I will help with
the programming.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2005-12-21 13:17       ` David Abrahams
@ 2005-12-22  9:38         ` Jan D.
  2006-01-12 22:56           ` David Abrahams
  0 siblings, 1 reply; 41+ messages in thread
From: Jan D. @ 2005-12-22  9:38 UTC (permalink / raw)
  Cc: rms, emacs-devel

> "Richard M. Stallman" <rms@gnu.org> writes:
> 
> >     I would consider it a worthwhile use of my time to help in that
> >     effort.  Please let me know when you're ready to begin, if you'd like
> >     a hand with it.
> >
> > If you want to work on this in the branch where it has been started,
> > that can be done now.  There is no need to wait.
> >
> > The first step is to talk with the people who were working on it in
> > that branch.
> 
> That was the point of my posting.  The post I responded to seemed to
> be from the initiator of the branch, and he seemed to have specific
> plans.  I'm not volunteering to lead the effort, but I will help with
> the programming.

Well, the plan is to not do anything yet :-).  If you feel that you can
contribute time and effort, please go right ahead and check in whatever
changes you find time to do.  The areas in most need of work is font selection,
that is not handeled correctly.  The way Emacs faces specify fonts and how
they map to X fonts needs to be handeled in a way that is appropriate for
antialiased fonts as well.  Currently Emacs faces specify slant, size and
such and then translate to/from XLFD (the -courier-normal-*-12-*-*- notation).
This is not appropriate for antialiased fonts.  The calculation of the size
of the frame (lines => pixels) does not seem to be correct either, I suspect
the calculation uses the wrong font.

People has reported various redrawing problems also.

And then there is the whole i18n problem.  Specifically, Xft wants unicode
characters, but Emacs has its own internal (Mule) representation.  I think
we must integrate XFT and Unicode before this can be sorted out correctly.

	Jan D.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2005-12-22  9:38         ` Jan D.
@ 2006-01-12 22:56           ` David Abrahams
  2006-01-13  8:49             ` Jan D.
  0 siblings, 1 reply; 41+ messages in thread
From: David Abrahams @ 2006-01-12 22:56 UTC (permalink / raw)


"Jan D." <jan.h.d@swipnet.se> writes:

>> That was the point of my posting.  The post I responded to seemed to
>> be from the initiator of the branch, and he seemed to have specific
>> plans.  I'm not volunteering to lead the effort, but I will help with
>> the programming.
>
> Well, the plan is to not do anything yet :-).  

I also thought the plan was to eventually use cairo:

  http://article.gmane.org/gmane.emacs.devel/34434/match=antialiased

> If you feel that you
> can contribute time and effort, please go right ahead and check in
> whatever changes you find time to do.  

I don't believe I've got commit privileges :-)

> The areas in most need of work is font selection, that is not
> handeled correctly.  The way Emacs faces specify fonts and how they
> map to X fonts needs to be handeled in a way that is appropriate for
> antialiased fonts as well.  Currently Emacs faces specify slant,
> size and such and then translate to/from XLFD (the
> -courier-normal-*-12-*-*- notation).  This is not appropriate for
> antialiased fonts.  

How so?

> The calculation of the size of the frame (lines => pixels) does not
> seem to be correct either, I suspect the calculation uses the wrong
> font.

Have any pointers into the code?

> People has reported various redrawing problems also.
>
> And then there is the whole i18n problem.  Specifically, Xft wants
> unicode characters, but Emacs has its own internal (Mule)
> representation.  I think we must integrate XFT and Unicode before
> this can be sorted out correctly.

What do you mean by "integrate XFT and Unicode?"  You just
said Xft already wants unicode characters, so I assume they're as
integrated as they're going to get.  Maybe you mean "integrate Mule
and Unicode?"

Thanks.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-12 22:56           ` David Abrahams
@ 2006-01-13  8:49             ` Jan D.
  2006-01-13 21:32               ` David Abrahams
  0 siblings, 1 reply; 41+ messages in thread
From: Jan D. @ 2006-01-13  8:49 UTC (permalink / raw)
  Cc: emacs-devel


12 jan 2006 kl. 23.56 skrev David Abrahams:

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>>> That was the point of my posting.  The post I responded to seemed to
>>> be from the initiator of the branch, and he seemed to have specific
>>> plans.  I'm not volunteering to lead the effort, but I will help  
>>> with
>>> the programming.
>>
>> Well, the plan is to not do anything yet :-).
>
> I also thought the plan was to eventually use cairo:
>
>   http://article.gmane.org/gmane.emacs.devel/34434/match=antialiased

I don't know about that.  There are still more X platforms without  
cairo than with cairo, so to require cairo just to get antialiased  
text seems a bit much.  Also, I don't know of anybody actually  
working on porting Emacs to cairo.

>
>> The areas in most need of work is font selection, that is not
>> handeled correctly.  The way Emacs faces specify fonts and how they
>> map to X fonts needs to be handeled in a way that is appropriate for
>> antialiased fonts as well.  Currently Emacs faces specify slant,
>> size and such and then translate to/from XLFD (the
>> -courier-normal-*-12-*-*- notation).  This is not appropriate for
>> antialiased fonts.
>
> How so?

The font parameters Emacs has is currently directly derived from the  
different parts of an XLFD.  Then when a font needs to be loaded, an  
XLFD can easily be built.  But most antialiased fonts are not named  
by XLFD.

>
>> The calculation of the size of the frame (lines => pixels) does not
>> seem to be correct either, I suspect the calculation uses the wrong
>> font.
>
> Have any pointers into the code?

The default font is set in realize_default_face(), xfaces.c.
The call to set_lface_from_font_name loads the font, and that function
does the height and width calculations.

>
>> People has reported various redrawing problems also.
>>
>> And then there is the whole i18n problem.  Specifically, Xft wants
>> unicode characters, but Emacs has its own internal (Mule)
>> representation.  I think we must integrate XFT and Unicode before
>> this can be sorted out correctly.
>
> What do you mean by "integrate XFT and Unicode?"  You just
> said Xft already wants unicode characters, so I assume they're as
> integrated as they're going to get.  Maybe you mean "integrate Mule
> and Unicode?"

Unicode refers to the Emacs unicode branch.  So it means integrate  
those two branches.

	Jan D.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-13  8:49             ` Jan D.
@ 2006-01-13 21:32               ` David Abrahams
  2006-01-14 18:15                 ` David Abrahams
  2006-01-15  8:28                 ` Jan Djärv
  0 siblings, 2 replies; 41+ messages in thread
From: David Abrahams @ 2006-01-13 21:32 UTC (permalink / raw)


"Jan D." <jan.h.d@swipnet.se> writes:

>>> People has reported various redrawing problems also.
>>>
>>> And then there is the whole i18n problem.  Specifically, Xft wants
>>> unicode characters, but Emacs has its own internal (Mule)
>>> representation.  I think we must integrate XFT and Unicode before
>>> this can be sorted out correctly.
>>
>> What do you mean by "integrate XFT and Unicode?"  You just
>> said Xft already wants unicode characters, so I assume they're as
>> integrated as they're going to get.  Maybe you mean "integrate Mule
>> and Unicode?"
>
> Unicode refers to the Emacs unicode branch.  So it means integrate
> those two branches.

meaning "emacs-unicode-2" and "XFT_JHD_BRANCH?"

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-13 21:32               ` David Abrahams
@ 2006-01-14 18:15                 ` David Abrahams
  2006-01-15  3:53                   ` Emfox Zhou
  2006-01-15  8:28                 ` Jan Djärv
  1 sibling, 1 reply; 41+ messages in thread
From: David Abrahams @ 2006-01-14 18:15 UTC (permalink / raw)


David Abrahams <dave@boost-consulting.com> writes:

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>>>> People has reported various redrawing problems also.
>>>>
>>>> And then there is the whole i18n problem.  Specifically, Xft wants
>>>> unicode characters, but Emacs has its own internal (Mule)
>>>> representation.  I think we must integrate XFT and Unicode before
>>>> this can be sorted out correctly.
>>>
>>> What do you mean by "integrate XFT and Unicode?"  You just
>>> said Xft already wants unicode characters, so I assume they're as
>>> integrated as they're going to get.  Maybe you mean "integrate Mule
>>> and Unicode?"
>>
>> Unicode refers to the Emacs unicode branch.  So it means integrate
>> those two branches.
>
> meaning "emacs-unicode-2" and "XFT_JHD_BRANCH?"

I've started trying to merge these two, and I have a few questions.
It's pretty tough to figure out what to do about ChangeLog, NEWS, etc.
There are many differences, it isn't clear to me which branch is more
current, and I'm not so involved with emacs development that I can
make judgements about each item.  Certainly XFT_JHD_BRANCH seems to
contain several cleanups and corrections to text present in
emacs-unicode-2.

Any advice on that score?  What about images?

When I see something like

    ("%" . "໌")
    ("'" . "ງ")

in XFT_JHD_BRANCH and

    ("%" . "^[(1l^[(B")
    ("'" . "^[(1'^[(B")

in emacs-unicode-2, do I want to keep the latter, since the
character representation is changing?

Also, would it be better to come up with a patch against
emacs-unicode-2 that adds XFT support, or vice-versa?  I am inclined
towards the former.

Thanks,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-14 18:15                 ` David Abrahams
@ 2006-01-15  3:53                   ` Emfox Zhou
  2006-01-15  8:31                     ` Jan Djärv
  2006-01-16  8:52                     ` YAMAMOTO Mitsuharu
  0 siblings, 2 replies; 41+ messages in thread
From: Emfox Zhou @ 2006-01-15  3:53 UTC (permalink / raw)


David Abrahams <dave@boost-consulting.com> writes:

> I've started trying to merge these two, and I have a few questions.
> It's pretty tough to figure out what to do about ChangeLog, NEWS, etc.
> There are many differences, it isn't clear to me which branch is more
> current, and I'm not so involved with emacs development that I can
> make judgements about each item.  Certainly XFT_JHD_BRANCH seems to
> contain several cleanups and corrections to text present in
> emacs-unicode-2.
>
> Any advice on that score?  What about images?
>
> When I see something like
>
>     ("%" . "໌")
>     ("'" . "ງ")
>
> in XFT_JHD_BRANCH and
>
>     ("%" . "^[(1l^[(B")
>     ("'" . "^[(1'^[(B")
>
> in emacs-unicode-2, do I want to keep the latter, since the
> character representation is changing?
>
> Also, would it be better to come up with a patch against
> emacs-unicode-2 that adds XFT support, or vice-versa?  I am inclined
> towards the former.
>

I think emacs-unicode-2 is more recent, and a patch against emacs-unicode-2
to add XFT support is better. as a notice, I have tested both of the branches,
and find the XFT branch could not deal properly with chinese, while the unicode
one seems ok for everything.

> Thanks,
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-13 21:32               ` David Abrahams
  2006-01-14 18:15                 ` David Abrahams
@ 2006-01-15  8:28                 ` Jan Djärv
  1 sibling, 0 replies; 41+ messages in thread
From: Jan Djärv @ 2006-01-15  8:28 UTC (permalink / raw)
  Cc: emacs-devel

David Abrahams wrote:
> "Jan D." <jan.h.d@swipnet.se> writes:
> 
> 
>>>>People has reported various redrawing problems also.
>>>>
>>>>And then there is the whole i18n problem.  Specifically, Xft wants
>>>>unicode characters, but Emacs has its own internal (Mule)
>>>>representation.  I think we must integrate XFT and Unicode before
>>>>this can be sorted out correctly.
>>>
>>>What do you mean by "integrate XFT and Unicode?"  You just
>>>said Xft already wants unicode characters, so I assume they're as
>>>integrated as they're going to get.  Maybe you mean "integrate Mule
>>>and Unicode?"
>>
>>Unicode refers to the Emacs unicode branch.  So it means integrate
>>those two branches.
> 
> 
> meaning "emacs-unicode-2" and "XFT_JHD_BRANCH?"
> 

Yes.

	Jan D.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-15  3:53                   ` Emfox Zhou
@ 2006-01-15  8:31                     ` Jan Djärv
  2006-01-15 16:13                       ` David Abrahams
  2006-01-16  8:52                     ` YAMAMOTO Mitsuharu
  1 sibling, 1 reply; 41+ messages in thread
From: Jan Djärv @ 2006-01-15  8:31 UTC (permalink / raw)
  Cc: emacs-devel

Emfox Zhou wrote:
> David Abrahams <dave@boost-consulting.com> writes:

>>in emacs-unicode-2, do I want to keep the latter, since the
>>character representation is changing?
>>
>>Also, would it be better to come up with a patch against
>>emacs-unicode-2 that adds XFT support, or vice-versa?  I am inclined
>>towards the former.
>>
> 
> 
> I think emacs-unicode-2 is more recent, and a patch against emacs-unicode-2
> to add XFT support is better. as a notice, I have tested both of the branches,
> and find the XFT branch could not deal properly with chinese, while the unicode
> one seems ok for everything.

I agree, you would start with emacs-unicode-2 and then add XFT to that, i.e. 
the former as you state above.  W.r.t. characters, this implies that you shall 
keep whatever is in the emacs-unicode-2 branch.

	Jan D.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-15  8:31                     ` Jan Djärv
@ 2006-01-15 16:13                       ` David Abrahams
  2006-01-16  0:58                         ` Kenichi Handa
  0 siblings, 1 reply; 41+ messages in thread
From: David Abrahams @ 2006-01-15 16:13 UTC (permalink / raw)


Jan Djärv <jan.h.d@swipnet.se> writes:

> Emfox Zhou wrote:
>> David Abrahams <dave@boost-consulting.com> writes:
>
>>>in emacs-unicode-2, do I want to keep the latter, since the
>>>character representation is changing?
>>>
>>>Also, would it be better to come up with a patch against
>>>emacs-unicode-2 that adds XFT support, or vice-versa?  I am inclined
>>>towards the former.
>>>
>> I think emacs-unicode-2 is more recent, and a patch against
>> emacs-unicode-2
>> to add XFT support is better. as a notice, I have tested both of the branches,
>> and find the XFT branch could not deal properly with chinese, while the unicode
>> one seems ok for everything.
>
> I agree, you would start with emacs-unicode-2 and then add XFT to that, i.e. 
> the former as you state above.  W.r.t. characters, this implies that you shall 
> keep whatever is in the emacs-unicode-2 branch.

OK, great.  What about Changelog, NEWS, etc.?  I seriously doubt my
ability to reason about what should be kept from each branch.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-15 16:13                       ` David Abrahams
@ 2006-01-16  0:58                         ` Kenichi Handa
  2006-01-16  2:09                           ` David Abrahams
  0 siblings, 1 reply; 41+ messages in thread
From: Kenichi Handa @ 2006-01-16  0:58 UTC (permalink / raw)
  Cc: emacs-devel

In article <ur779cvuq.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> writes:
>>  I agree, you would start with emacs-unicode-2 and then add XFT to that, i.e. 
>>  the former as you state above.  W.r.t. characters, this implies that you shall 
>>  keep whatever is in the emacs-unicode-2 branch.

> OK, great.  What about Changelog, NEWS, etc.?  I seriously doubt my
> ability to reason about what should be kept from each branch.

In emacs-unicode-2, I'm using README.unicode and
ChangeLog.unicode.  NEWS etc. are not yet written.

And, in my .emacs, I have this for convenience.

(eval-after-load "add-log"
  '(defun change-log-name ()
     (if (and (string-match "6.0" mule-version)
	      (string-match "emacs" default-directory ))
	 "ChangeLog.unicode"
       "ChangeLog")))

---
Kenichi Handa
handa@m17n.org

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16  0:58                         ` Kenichi Handa
@ 2006-01-16  2:09                           ` David Abrahams
  2006-01-16  2:35                             ` Kenichi Handa
  2006-01-16  4:28                             ` Stefan Monnier
  0 siblings, 2 replies; 41+ messages in thread
From: David Abrahams @ 2006-01-16  2:09 UTC (permalink / raw)
  Cc: emacs-devel

Kenichi Handa <handa@m17n.org> writes:

> In article <ur779cvuq.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> writes:
>>>  I agree, you would start with emacs-unicode-2 and then add XFT to that, i.e. 
>>>  the former as you state above.  W.r.t. characters, this implies that you shall 
>>>  keep whatever is in the emacs-unicode-2 branch.
>
>> OK, great.  What about Changelog, NEWS, etc.?  I seriously doubt my
>> ability to reason about what should be kept from each branch.
>
> In emacs-unicode-2, I'm using README.unicode and
> ChangeLog.unicode.  NEWS etc. are not yet written.

I appreciate that you're trying to help (really!) but I don't
understand what you're telling me yet.  I'm concerned because there
are merge conflicts in the plain "ChangeLog," etc., files.  If I am
going to merge the branches I have to resolve those, don't I?

> And, in my .emacs, I have this for convenience.
>
> (eval-after-load "add-log"
>   '(defun change-log-name ()
>      (if (and (string-match "6.0" mule-version)
> 	      (string-match "emacs" default-directory ))
> 	 "ChangeLog.unicode"
>        "ChangeLog")))

That looks handy, thanks.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16  2:09                           ` David Abrahams
@ 2006-01-16  2:35                             ` Kenichi Handa
  2006-01-16  3:02                               ` David Abrahams
  2006-01-16  4:28                             ` Stefan Monnier
  1 sibling, 1 reply; 41+ messages in thread
From: Kenichi Handa @ 2006-01-16  2:35 UTC (permalink / raw)
  Cc: emacs-devel

In article <87k6d0exev.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> writes:

>>  In emacs-unicode-2, I'm using README.unicode and
>>  ChangeLog.unicode.  NEWS etc. are not yet written.

> I appreciate that you're trying to help (really!) but I don't
> understand what you're telling me yet.  I'm concerned because there
> are merge conflicts in the plain "ChangeLog," etc., files.  If I am
> going to merge the branches I have to resolve those, don't I?

I thought you are going to make a new branch, say
emacs-unicode-2-xft from the current emacs-unicode-2.  Then,
what I suggest is to use something like ChangeLog.xft for
the changes you are going to made on that new branch.

In the future, emacs-unicode-2-xft branch will be merged
into emacs-unicode-2, and then emacs-unicode-2 branch will
be merged into the main trunk.  Or, we may merge
emacs-unicode-2 to the main trunk at first, create a new
branch emacs-xft from there, merge emacs-unicode-2-xft into
emacs-xft, and when emacs-xft gets stable enough, merge it
into the main trunk.

On those merging, there should be no conflict in ChangeLog
if we are using different file names.  And after the merge,
we can insert ChangeLog.unicode and ChangeLog.xft in
ChangeLog.

---
Kenichi Handa
handa@m17n.org

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16  2:35                             ` Kenichi Handa
@ 2006-01-16  3:02                               ` David Abrahams
  2006-01-16  4:07                                 ` Kenichi Handa
  2006-01-16  8:14                                 ` Jan D.
  0 siblings, 2 replies; 41+ messages in thread
From: David Abrahams @ 2006-01-16  3:02 UTC (permalink / raw)
  Cc: emacs-devel

Kenichi Handa <handa@m17n.org> writes:

> In article <87k6d0exev.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> writes:
>
>>>  In emacs-unicode-2, I'm using README.unicode and
>>>  ChangeLog.unicode.  NEWS etc. are not yet written.
>
>> I appreciate that you're trying to help (really!) but I don't
>> understand what you're telling me yet.  I'm concerned because there
>> are merge conflicts in the plain "ChangeLog," etc., files.  If I am
>> going to merge the branches I have to resolve those, don't I?
>
> I thought you are going to make a new branch, say
> emacs-unicode-2-xft from the current emacs-unicode-2.  Then,
> what I suggest is to use something like ChangeLog.xft for
> the changes you are going to made on that new branch.
>
> In the future, emacs-unicode-2-xft branch will be merged
> into emacs-unicode-2, and then emacs-unicode-2 branch will
> be merged into the main trunk.  Or, we may merge
> emacs-unicode-2 to the main trunk at first, create a new
> branch emacs-xft from there, merge emacs-unicode-2-xft into
> emacs-xft, and when emacs-xft gets stable enough, merge it
> into the main trunk.
>
> On those merging, there should be no conflict in ChangeLog
> if we are using different file names.  And after the merge,
> we can insert ChangeLog.unicode and ChangeLog.xft in
> ChangeLog.

If nobody merges the plain-old "ChangeLog" files from the current XFT
branch into what I'm doing, and my branch is used in lieu of the
current XFT branch everything people have done in those files (in some
cases this amounts substantial work) will be lost.  If nobody cares, I
can start new files and drop the old ones on the floor.

Are you telling me that edits made to ChangeLog, NEWS, etc., in the
XFT branch are expendable?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16  3:02                               ` David Abrahams
@ 2006-01-16  4:07                                 ` Kenichi Handa
  2006-01-16 13:32                                   ` David Abrahams
  2006-01-16  8:14                                 ` Jan D.
  1 sibling, 1 reply; 41+ messages in thread
From: Kenichi Handa @ 2006-01-16  4:07 UTC (permalink / raw)
  Cc: emacs-devel

In article <87fynoeuyg.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> writes:

> If nobody merges the plain-old "ChangeLog" files from the current XFT
> branch into what I'm doing, and my branch is used in lieu of the
> current XFT branch everything people have done in those files (in some
> cases this amounts substantial work) will be lost.  If nobody cares, I
> can start new files and drop the old ones on the floor.

> Are you telling me that edits made to ChangeLog, NEWS, etc., in the
> XFT branch are expendable?

No.  I don't know what is done in XFT branch nor how widely
ChangeLog, etc. are modified.  I've never touched it.
Please discuss with XFT branch maintainers about what to do
with the current modification.

I've just shown you how emacs-unicode-2 branch is maintained
to avoid confliction on future merging, and thought that you
can use the same method.

Please note also that all changes to the main trunk are
periodically (once a week or so) applied also to
emacs-unicode-2 branch by Miles.

---
Kenichi Handa
handa@m17n.org

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16  2:09                           ` David Abrahams
  2006-01-16  2:35                             ` Kenichi Handa
@ 2006-01-16  4:28                             ` Stefan Monnier
  2006-01-16 13:32                               ` David Abrahams
  1 sibling, 1 reply; 41+ messages in thread
From: Stefan Monnier @ 2006-01-16  4:28 UTC (permalink / raw)
  Cc: emacs-devel, Kenichi Handa

> I appreciate that you're trying to help (really!) but I don't
> understand what you're telling me yet.  I'm concerned because there
> are merge conflicts in the plain "ChangeLog," etc., files.  If I am
> going to merge the branches I have to resolve those, don't I?

Actually, for such files, you don't have to resolve the conflicts.
Just make sure that the complete info about the conflict is kept somewhere
so it can be resolved at some point in the future.  Someone else can resolve
those conflicts for you and you can concentrate on the code itself.


        Stefan

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16  3:02                               ` David Abrahams
  2006-01-16  4:07                                 ` Kenichi Handa
@ 2006-01-16  8:14                                 ` Jan D.
  2006-01-16  9:45                                   ` Miles Bader
                                                     ` (2 more replies)
  1 sibling, 3 replies; 41+ messages in thread
From: Jan D. @ 2006-01-16  8:14 UTC (permalink / raw)
  Cc: emacs-devel, Kenichi Handa

> Are you telling me that edits made to ChangeLog, NEWS, etc., in the
> XFT branch are expendable?

Yes, because those files have not been changed.  The changes in the XFT
branch are not that great, so I was going to add change logs later.  I
figured there would be no idea to add changelogs while just trying stuff out.

Kenichi Handa:s suggestion about separate files is a good one.

	Jan D.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-15  3:53                   ` Emfox Zhou
  2006-01-15  8:31                     ` Jan Djärv
@ 2006-01-16  8:52                     ` YAMAMOTO Mitsuharu
  1 sibling, 0 replies; 41+ messages in thread
From: YAMAMOTO Mitsuharu @ 2006-01-16  8:52 UTC (permalink / raw)
  Cc: emacs-devel

>>>>> On Sun, 15 Jan 2006 11:53:06 +0800, Emfox Zhou <EmfoxZhou@gmail.com> said:

> I think emacs-unicode-2 is more recent, and a patch against
> emacs-unicode-2 to add XFT support is better. as a notice, I have
> tested both of the branches, and find the XFT branch could not deal
> properly with chinese, while the unicode one seems ok for
> everything.

How about the following setting with XFT_JHD_BRANCH? :-) 

  (add-to-list 'font-ccl-encoder-alist
  	       '("\\*-\\*$" . ccl-encode-unicode-font))

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16  8:14                                 ` Jan D.
@ 2006-01-16  9:45                                   ` Miles Bader
  2006-01-16 13:38                                   ` David Abrahams
  2006-01-16 15:57                                   ` Emfox Zhou
  2 siblings, 0 replies; 41+ messages in thread
From: Miles Bader @ 2006-01-16  9:45 UTC (permalink / raw)
  Cc: David Abrahams, Kenichi Handa, emacs-devel

2006/1/16, Jan D. <jan.h.d@swipnet.se>:
> > Are you telling me that edits made to ChangeLog, NEWS, etc., in the
> > XFT branch are expendable?
>
> Kenichi Handa:s suggestion about separate files is a good one.

Yes, giving all "high conflict" files like ChangeLog etc.
branch-specific names is a good idea, and neatly avoids the most
common (and annoying) cause of merge conflicts.

I do it on my personal branches too.

-Miles
--
Do not taunt Happy Fun Ball.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16  4:07                                 ` Kenichi Handa
@ 2006-01-16 13:32                                   ` David Abrahams
  2006-01-16 23:45                                     ` Lőrentey Károly
  0 siblings, 1 reply; 41+ messages in thread
From: David Abrahams @ 2006-01-16 13:32 UTC (permalink / raw)
  Cc: emacs-devel

Kenichi Handa <handa@m17n.org> writes:

> In article <87fynoeuyg.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> writes:
>
>> If nobody merges the plain-old "ChangeLog" files from the current XFT
>> branch into what I'm doing, and my branch is used in lieu of the
>> current XFT branch everything people have done in those files (in some
>> cases this amounts substantial work) will be lost.  If nobody cares, I
>> can start new files and drop the old ones on the floor.
>
>> Are you telling me that edits made to ChangeLog, NEWS, etc., in the
>> XFT branch are expendable?
>
> No.  I don't know what is done in XFT branch nor how widely
> ChangeLog, etc. are modified.  I've never touched it.
> Please discuss with XFT branch maintainers about what to do
> with the current modification.
>
> I've just shown you how emacs-unicode-2 branch is maintained
> to avoid confliction on future merging, and thought that you
> can use the same method.

Thanks.

> Please note also that all changes to the main trunk are
> periodically (once a week or so) applied also to
> emacs-unicode-2 branch by Miles.

Does somebody maintain a branchpoint tag that indicates the latest
trunk revisions that have been merged into the branch?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16  4:28                             ` Stefan Monnier
@ 2006-01-16 13:32                               ` David Abrahams
  0 siblings, 0 replies; 41+ messages in thread
From: David Abrahams @ 2006-01-16 13:32 UTC (permalink / raw)
  Cc: emacs-devel, Kenichi Handa

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

>> I appreciate that you're trying to help (really!) but I don't
>> understand what you're telling me yet.  I'm concerned because there
>> are merge conflicts in the plain "ChangeLog," etc., files.  If I am
>> going to merge the branches I have to resolve those, don't I?
>
> Actually, for such files, you don't have to resolve the conflicts.
> Just make sure that the complete info about the conflict is kept somewhere
> so it can be resolved at some point in the future.  Someone else can resolve
> those conflicts for you and you can concentrate on the code itself.

That's a huge relief, thanks.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16  8:14                                 ` Jan D.
  2006-01-16  9:45                                   ` Miles Bader
@ 2006-01-16 13:38                                   ` David Abrahams
  2006-01-16 13:53                                     ` Jan D.
  2006-01-16 16:51                                     ` Stefan Monnier
  2006-01-16 15:57                                   ` Emfox Zhou
  2 siblings, 2 replies; 41+ messages in thread
From: David Abrahams @ 2006-01-16 13:38 UTC (permalink / raw)
  Cc: emacs-devel, Kenichi Handa

"Jan D." <jan.h.d@swipnet.se> writes:

>> Are you telling me that edits made to ChangeLog, NEWS, etc., in the
>> XFT branch are expendable?
>
> Yes, because those files have not been changed.  

I don't mean to be difficult, but I think "CVS merge" disagrees with
you.  If they had not been changed at all, wouldn't it leave them
untouched when I merge the XFT branch into the unicode-2 branch?

> Kenichi Handa:s suggestion about separate files is a good one.

Thanks.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16 13:38                                   ` David Abrahams
@ 2006-01-16 13:53                                     ` Jan D.
  2006-01-16 16:31                                       ` David Abrahams
  2006-01-16 16:51                                     ` Stefan Monnier
  1 sibling, 1 reply; 41+ messages in thread
From: Jan D. @ 2006-01-16 13:53 UTC (permalink / raw)
  Cc: emacs-devel, Kenichi Handa

> "Jan D." <jan.h.d@swipnet.se> writes:
> 
> >> Are you telling me that edits made to ChangeLog, NEWS, etc., in the
> >> XFT branch are expendable?
> >
> > Yes, because those files have not been changed.  
> 
> I don't mean to be difficult, but I think "CVS merge" disagrees with
> you.  If they had not been changed at all, wouldn't it leave them
> untouched when I merge the XFT branch into the unicode-2 branch?

One would think so.  However, when I merge stuff from HEAD to the XFT
branch, I get conflicts in files I know I have not modified.  Probably some
merge expert can explain why that happens.

	Jan D.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16  8:14                                 ` Jan D.
  2006-01-16  9:45                                   ` Miles Bader
  2006-01-16 13:38                                   ` David Abrahams
@ 2006-01-16 15:57                                   ` Emfox Zhou
  2 siblings, 0 replies; 41+ messages in thread
From: Emfox Zhou @ 2006-01-16 15:57 UTC (permalink / raw)


"Jan D." <jan.h.d@swipnet.se> writes:

>> Are you telling me that edits made to ChangeLog, NEWS, etc., in the
>> XFT branch are expendable?
>
> Yes, because those files have not been changed.  The changes in the XFT
> branch are not that great, so I was going to add change logs later.  I
> figured there would be no idea to add changelogs while just trying stuff out.
>
before that, do you think a sync with the CVS head(emacs22) is a good idea?
i see no updates since several monthes ago.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16 13:53                                     ` Jan D.
@ 2006-01-16 16:31                                       ` David Abrahams
  2006-01-16 19:04                                         ` Jan D.
  0 siblings, 1 reply; 41+ messages in thread
From: David Abrahams @ 2006-01-16 16:31 UTC (permalink / raw)
  Cc: emacs-devel, Kenichi Handa

"Jan D." <jan.h.d@swipnet.se> writes:

>> "Jan D." <jan.h.d@swipnet.se> writes:
>> 
>> >> Are you telling me that edits made to ChangeLog, NEWS, etc., in the
>> >> XFT branch are expendable?
>> >
>> > Yes, because those files have not been changed.  
>> 
>> I don't mean to be difficult, but I think "CVS merge" disagrees with
>> you.  If they had not been changed at all, wouldn't it leave them
>> untouched when I merge the XFT branch into the unicode-2 branch?
>
> One would think so.  However, when I merge stuff from HEAD to the XFT
> branch, 

If you've been doing that, it explains everything.

> I get conflicts in files I know I have not modified.  Probably some
> merge expert can explain why that happens.

Are you keeping a tag on the trunk for the last revision you've merged
into your branch?  If so,

     cvs up -jLastMergeTag -jHEAD

should get you an incremental merge with no bogus conflicts.  And then
I could use your LastMergeTag to merge with emacs-unicode-2 with fewer
conflicts as well.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16 13:38                                   ` David Abrahams
  2006-01-16 13:53                                     ` Jan D.
@ 2006-01-16 16:51                                     ` Stefan Monnier
  2006-01-16 18:01                                       ` David Abrahams
  1 sibling, 1 reply; 41+ messages in thread
From: Stefan Monnier @ 2006-01-16 16:51 UTC (permalink / raw)
  Cc: Jan D., Kenichi Handa, emacs-devel

> I don't mean to be difficult, but I think "CVS merge" disagrees with
> you.  If they had not been changed at all, wouldn't it leave them
> untouched when I merge the XFT branch into the unicode-2 branch?

It's probably just spurious conflicts due to repeated merging.  CVS is
notoriously bad at keeping track of what has already been merged.

Better work from the Arch branches managed by Miles when you need to merge.


        Stefan

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16 16:51                                     ` Stefan Monnier
@ 2006-01-16 18:01                                       ` David Abrahams
  0 siblings, 0 replies; 41+ messages in thread
From: David Abrahams @ 2006-01-16 18:01 UTC (permalink / raw)
  Cc: Jan D., Kenichi Handa, emacs-devel

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

>> I don't mean to be difficult, but I think "CVS merge" disagrees with
>> you.  If they had not been changed at all, wouldn't it leave them
>> untouched when I merge the XFT branch into the unicode-2 branch?
>
> It's probably just spurious conflicts due to repeated merging.  CVS is
> notoriously bad at keeping track of what has already been merged.
>
> Better work from the Arch branches managed by Miles when you need to merge.
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Wow, even more confusing.  The above is meaningless to me.  Can you explain?

Thanks,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16 16:31                                       ` David Abrahams
@ 2006-01-16 19:04                                         ` Jan D.
  2006-01-16 20:17                                           ` David Abrahams
  0 siblings, 1 reply; 41+ messages in thread
From: Jan D. @ 2006-01-16 19:04 UTC (permalink / raw)
  Cc: emacs-devel, Kenichi Handa

>
> Are you keeping a tag on the trunk for the last revision you've merged
> into your branch?  If so,
>
>      cvs up -jLastMergeTag -jHEAD
>
> should get you an incremental merge with no bogus conflicts.  And then
> I could use your LastMergeTag to merge with emacs-unicode-2 with fewer
> conflicts as well.

No tag, but you can use the date specifier, the cvs log message gives  
the date.

	Jan D.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16 19:04                                         ` Jan D.
@ 2006-01-16 20:17                                           ` David Abrahams
  2006-01-16 22:48                                             ` Miles Bader
  0 siblings, 1 reply; 41+ messages in thread
From: David Abrahams @ 2006-01-16 20:17 UTC (permalink / raw)
  Cc: emacs-devel, Kenichi Handa

"Jan D." <jan.h.d@swipnet.se> writes:

>>
>> Are you keeping a tag on the trunk for the last revision you've merged
>> into your branch?  If so,
>>
>>      cvs up -jLastMergeTag -jHEAD
>>
>> should get you an incremental merge with no bogus conflicts.  And then
>> I could use your LastMergeTag to merge with emacs-unicode-2 with fewer
>> conflicts as well.
>
> No tag, but you can use the date specifier, the cvs log message gives
> the date.

Thanks, I'll do that.  FWIW, if you do use such tags you can
substantially reduce the number of conflicts you see upon merging.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16 20:17                                           ` David Abrahams
@ 2006-01-16 22:48                                             ` Miles Bader
  2006-01-17  8:34                                               ` Jan D.
  2006-01-17 15:19                                               ` David Abrahams
  0 siblings, 2 replies; 41+ messages in thread
From: Miles Bader @ 2006-01-16 22:48 UTC (permalink / raw)
  Cc: Jan D., Kenichi Handa, emacs-devel

2006/1/17, David Abrahams <dave@boost-consulting.com>:
> > No tag, but you can use the date specifier, the cvs log message gives
> > the date.
>
> Thanks, I'll do that.  FWIW, if you do use such tags you can
> substantially reduce the number of conflicts you see upon merging.

This whole conversation is making me very nervous ....

I also merge into the emacs-unicode-2 branch (using arch), and this is
normally pretty easy.  I'm afraid that a botched merge (all too easy
with CVS) into that same branch will make things very painful for me.

Jan, how many changes are there in the XFT branch, compared to the trunk?

If it's not many, how about instead I update my XFT branch in arch
(it's out of date because it got merged into from the trunk, which
caused lots of problems for my syncing scripts, but I can just
probably just recreate it from scratch), then merge that into the
unicode branch (using arch), and make a new combined branch, and then
make a new CVS branch from that...?

-miles
--
Do not taunt Happy Fun Ball.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16 13:32                                   ` David Abrahams
@ 2006-01-16 23:45                                     ` Lőrentey Károly
  0 siblings, 0 replies; 41+ messages in thread
From: Lőrentey Károly @ 2006-01-16 23:45 UTC (permalink / raw)



[-- Attachment #1.1: Type: text/plain, Size: 576 bytes --]

David Abrahams <dave@boost-consulting.com> writes:
> Kenichi Handa <handa@m17n.org> writes:
>> Please note also that all changes to the main trunk are
>> periodically (once a week or so) applied also to
>> emacs-unicode-2 branch by Miles.
>
> Does somebody maintain a branchpoint tag that indicates the latest
> trunk revisions that have been merged into the branch?

Looking at the current CVS state, Miles seems to use
"emacs-unicode-2-base" to mark the latest mergepoint
on the trunk.

His Arch branches may have more exact snapshots, though.

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16 22:48                                             ` Miles Bader
@ 2006-01-17  8:34                                               ` Jan D.
  2006-01-17 15:20                                                 ` David Abrahams
  2006-01-17 15:19                                               ` David Abrahams
  1 sibling, 1 reply; 41+ messages in thread
From: Jan D. @ 2006-01-17  8:34 UTC (permalink / raw)
  Cc: David Abrahams, emacs-devel, Kenichi Handa

[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]



Miles Bader wrote:
> 2006/1/17, David Abrahams <dave@boost-consulting.com>:
> 
>>>No tag, but you can use the date specifier, the cvs log message gives
>>>the date.
>>
>>Thanks, I'll do that.  FWIW, if you do use such tags you can
>>substantially reduce the number of conflicts you see upon merging.
> 
> 
> This whole conversation is making me very nervous ....
> 
> I also merge into the emacs-unicode-2 branch (using arch), and this is
> normally pretty easy.  I'm afraid that a botched merge (all too easy
> with CVS) into that same branch will make things very painful for me.
> 
> Jan, how many changes are there in the XFT branch, compared to the trunk?

I've attached a diff from HEAD 2006-01-12 10:24 to the XFT branch (the latest 
sync with head occurred then).  It is not that much.

> 
> If it's not many, how about instead I update my XFT branch in arch
> (it's out of date because it got merged into from the trunk, which
> caused lots of problems for my syncing scripts, but I can just
> probably just recreate it from scratch), then merge that into the
> unicode branch (using arch), and make a new combined branch, and then
> make a new CVS branch from that...?

Sounds like a bit of work, but if it is easy for you, please do, that would 
help a lot.

	Jan D.

[-- Attachment #2: xft.diff-060112-1024 --]
[-- Type: text/plain, Size: 44787 bytes --]

--- emacs-060112-102400/configure.in	2006-01-17 08:53:17.000000000 +0100
+++ emacs.xft/configure.in	2006-01-17 08:59:18.000000000 +0100
@@ -109,10 +109,12 @@
 [  --with-gif              use -lungif for displaying GIF images])
 AC_ARG_WITH(png,
 [  --with-png              use -lpng for displaying PNG images])
+AC_ARG_WITH(xft,
+[  --with-xft              use -lXft for anti aliased fonts])
 AC_ARG_WITH(gtk,
 [  --with-gtk              use GTK (same as --with-x-toolkit=gtk)])
 AC_ARG_WITH(pkg-config-prog,
-[  --with-pkg-config-prog  Path to pkg-config to use for finding GTK])
+[  --with-pkg-config-prog  Path to pkg-config to use for finding GTK and Xft])
 AC_ARG_WITH(toolkit-scroll-bars,
 [  --without-toolkit-scroll-bars
                           don't use Motif or Xaw3d scroll bars])
@@ -2267,6 +2269,42 @@
   CFLAGS=$late_CFLAGS
 fi
 
+
+### Use -lXft if available, unless `--with-xft=no'.
+HAVE_XFT=maybe
+if test "${HAVE_X11}" = "yes"; then
+  if test "${with_xft}" != "no"; then
+
+    dnl Check if --with-pkg-config-prog has been given.
+    if test "X${with_pkg_config_prog}" != X; then
+      PKG_CONFIG="${with_pkg_config_prog}"
+    fi
+
+    PKG_CHECK_MODULES(XFT, xft >= 0.13.0, , HAVE_XFT=no)
+    if test "$HAVE_XFT" != no; then
+      OLD_CFLAGS="$CPPFLAGS"
+      OLD_CFLAGS="$CFLAGS"
+      OLD_LIBS="$LIBS"
+      CPPFLAGS="$CPPFLAGS $XFT_CFLAGS"
+      CFLAGS="$CFLAGS $XFT_CFLAGS"
+      LIBS="$XFT_LIBS $LIBS"
+      AC_CHECK_HEADER(X11/Xft/Xft.h,
+        AC_CHECK_LIB(Xft, XftFontOpen, HAVE_XFT=yes, , $XFT_LIBS))
+
+      if test "${HAVE_XFT}" = "yes"; then
+        AC_DEFINE(HAVE_XFT, 1, [Define to 1 if you have the Xft library.])
+ 	AC_SUBST(XFT_LIBS)
+        C_SWITCH_X_SITE="$C_SWITCH_X_SITE $XFT_CFLAGS"
+      else
+        CFLAGS="$OLD_CPPFLAGS"
+        CFLAGS="$OLD_CFLAGS"
+        LIBS="$OLD_LIBS"
+      fi
+    fi
+  fi
+fi
+
+
 ### Use -lXpm if available, unless `--with-xpm=no'.
 HAVE_XPM=no
 if test "${HAVE_X11}" = "yes"; then
@@ -2291,7 +2329,7 @@
   fi
 
   if test "${HAVE_XPM}" = "yes"; then
-    AC_DEFINE(HAVE_XPM, 1, [Define to 1 if you have the Xpm libary (-lXpm).])
+    AC_DEFINE(HAVE_XPM, 1, [Define to 1 if you have the Xpm library (-lXpm).])
   fi
 fi
 
--- emacs-060112-102400/src/Makefile.in	2005-12-26 23:10:18.000000000 +0100
+++ emacs.xft/src/Makefile.in	2006-01-12 11:25:42.000000000 +0100
@@ -401,6 +401,11 @@
 #endif
 #endif /* not USE_X_TOOLKIT */
 
+#if HAVE_XFT
+#undef LIB_X11_LIB
+#define LIB_X11_LIB @XFT_LIBS@
+#endif /* HAVE_XFT */
+
 #if HAVE_XPM
 #ifndef LIBXPM
 #define LIBXPM -lXpm
--- emacs-060112-102400/src/config.in	2005-09-10 13:36:24.000000000 +0200
+++ emacs.xft/src/config.in	2006-01-12 11:25:42.000000000 +0100
@@ -700,13 +700,16 @@
 /* Define to 1 if you're using XFree386. */
 #undef HAVE_XFREE386
 
+/* Define to 1 if you have the Xft library. */
+#undef HAVE_XFT
+
 /* Define to 1 if XIM is available */
 #undef HAVE_XIM
 
 /* Define to 1 if you have the XkbGetKeyboard function. */
 #undef HAVE_XKBGETKEYBOARD
 
-/* Define to 1 if you have the Xpm libary (-lXpm). */
+/* Define to 1 if you have the Xpm library (-lXpm). */
 #undef HAVE_XPM
 
 /* Define to 1 if you have the `XrmSetDatabase' function. */
--- emacs-060112-102400/src/dispextern.h	2005-11-11 16:33:34.000000000 +0100
+++ emacs.xft/src/dispextern.h	2006-01-12 11:25:42.000000000 +0100
@@ -27,6 +27,17 @@
 #ifdef HAVE_X_WINDOWS
 
 #include <X11/Xlib.h>
+
+#ifndef X_FONT_TYPE_DECL
+#define X_FONT_TYPE_DECL
+#ifdef HAVE_XFT
+#include <X11/Xft/Xft.h>
+typedef XftFont x_font_type;
+#else
+typedef XFontStruct x_font_type;
+#endif
+#endif /* not X_FONT_TYPE_DECL */
+
 #ifdef USE_X_TOOLKIT
 #include <X11/Intrinsic.h>
 #endif /* USE_X_TOOLKIT */
@@ -1149,7 +1160,7 @@
   struct face *face;
 
   /* Font in which this string is to be drawn.  */
-  XFontStruct *font;
+  x_font_type *font;
 
   /* Font info for this string.  */
   struct font_info *font_info;
@@ -1428,6 +1439,11 @@
 
 #ifdef HAVE_WINDOW_SYSTEM
 
+#ifdef HAVE_XFT
+  XftColor xft_fg;
+  XftColor xft_bg;
+  XftDraw *xft_draw;
+#endif
   /* If non-zero, this is a GC that we can use without modification for
      drawing the characters in this face.  */
   GC gc;
@@ -1436,7 +1452,7 @@
      for some reason.  This points to a `font' slot of a struct
      font_info, and we should not call XFreeFont on it because the
      font may still be used somewhere else.  */
-  XFontStruct *font;
+  x_font_type *font;
 
   /* Background stipple or bitmap used for this face.  This is
      an id as returned from load_pixmap.  */
@@ -1633,11 +1649,19 @@
 /* Prepare face FACE for use on frame F.  This must be called before
    using X resources of FACE.  */
 
+#ifdef HAVE_XFT
+#define PREPARE_FACE_FOR_DISPLAY(F, FACE)               \
+     if ((FACE)->xft_draw == 0 || (FACE)->gc == 0)      \
+       prepare_face_for_display ((F), (FACE));          \
+     else                                               \
+       (void) 0
+#else
 #define PREPARE_FACE_FOR_DISPLAY(F, FACE)	\
      if ((FACE)->gc == 0)			\
        prepare_face_for_display ((F), (FACE));	\
      else					\
        (void) 0
+#endif /* not HAVE_XFT */
 
 /* Return a pointer to the face with ID on frame F, or null if such a
    face doesn't exist.  */
@@ -2293,7 +2317,9 @@
 
 /* Get metrics of character CHAR2B in FONT of type FONT_TYPE.
    Value is null if CHAR2B is not contained in the font.  */
-  XCharStruct * (*per_char_metric) P_ ((XFontStruct *font, XChar2b *char2b,
+  XCharStruct * (*per_char_metric) P_ ((struct frame *f,
+                                        x_font_type *font,
+                                        XChar2b *char2b,
 					int font_type));
 
 /* Encode CHAR2B using encoding information from FONT_INFO.  CHAR2B is
@@ -2658,7 +2684,7 @@
 extern void reseat_at_previous_visible_line_start P_ ((struct it *));
 
 extern int calc_pixel_width_or_height P_ ((double *, struct it *, Lisp_Object,
-					   /* XFontStruct */ void *, int, int *));
+					   /* x_font_type */ void *, int, int *));
 
 #ifdef HAVE_WINDOW_SYSTEM
 
--- emacs-060112-102400/src/fontset.h	2005-12-19 07:59:10.000000000 +0100
+++ emacs.xft/src/fontset.h	2006-01-12 11:25:43.000000000 +0100
@@ -30,7 +30,7 @@
 struct font_info
 {
   /* Pointer to window system dependent font structure.  On X window,
-     this value should be coerced to (XFontStruct *).  */
+     this value should be coerced to (x_font_type *).  */
   void *font;
 
   /* Index number of the font.  */
--- emacs-060112-102400/src/image.c	2005-12-24 03:50:00.000000000 +0100
+++ emacs.xft/src/image.c	2006-01-12 11:25:43.000000000 +0100
@@ -28,6 +28,15 @@
 #include <unistd.h>
 #endif
 
+#ifdef HAVE_PNG
+
+#if defined HAVE_LIBPNG_PNG_H
+# include <libpng/png.h>
+#else
+# include <png.h>
+#endif
+#endif
+
 /* This makes the fields of a Display accessible, in Xlib header files.  */
 
 #define XLIB_ILLEGAL_ACCESS
--- emacs-060112-102400/src/macterm.c	2006-01-12 09:14:58.000000000 +0100
+++ emacs.xft/src/macterm.c	2006-01-12 11:25:44.000000000 +0100
@@ -258,7 +258,8 @@
 					    unsigned long *));
 
 static int is_emacs_window P_ ((WindowPtr));
-static XCharStruct *mac_per_char_metric P_ ((XFontStruct *, XChar2b *, int));
+static XCharStruct *mac_per_char_metric P_ ((FRAME_PTR,
+                                             XFontStruct *, XChar2b *, int));
 static void XSetFont P_ ((Display *, GC, XFontStruct *));
 
 /* Defined in macmenu.h.  */
@@ -1000,7 +1001,7 @@
 
   for (i = 0; i < nchars; i++)
     {
-      pcm = mac_per_char_metric (font_struct, string, 0);
+      pcm = mac_per_char_metric (0, font_struct, string, 0);
       if (pcm == NULL)
 	width += FONT_WIDTH (font_struct);
       else
@@ -1060,7 +1061,7 @@
   advances = xmalloc (sizeof (CGSize) * nchars);
   for (i = 0; i < nchars; i++)
     {
-      XCharStruct *pcm = mac_per_char_metric (GC_FONT (gc), buf, 0);
+      XCharStruct *pcm = mac_per_char_metric (f, GC_FONT (gc), buf, 0);
 
       advances[i].width = pcm->width;
       advances[i].height = 0;
@@ -1966,7 +1967,8 @@
  */
 
 static XCharStruct *
-mac_per_char_metric (font, char2b, font_type)
+mac_per_char_metric (f, font, char2b, font_type)
+     FRAME_PTR f;
      XFontStruct *font;
      XChar2b *char2b;
      int font_type;
@@ -7964,7 +7966,7 @@
 	XCharStruct *pcm;
 
 	char2b.byte1 = 0x00, char2b.byte2 = 0x20;
-	pcm = mac_per_char_metric (font, &char2b, 0);
+	pcm = mac_per_char_metric (0, font, &char2b, 0);
 	if (pcm)
 	  fontp->space_width = pcm->width;
 	else
@@ -7974,7 +7976,7 @@
 	  {
 	    int width = pcm->width;
 	    for (char2b.byte2 = 33; char2b.byte2 <= 126; char2b.byte2++)
-	      if ((pcm = mac_per_char_metric (font, &char2b, 0)) != NULL)
+	      if ((pcm = mac_per_char_metric (0, font, &char2b, 0)) != NULL)
 		width += pcm->width;
 	    fontp->average_width = width / 95;
 	  }
--- emacs-060112-102400/src/w32fns.c	2005-12-14 21:58:33.000000000 +0100
+++ emacs.xft/src/w32fns.c	2006-01-12 11:25:46.000000000 +0100
@@ -64,7 +64,8 @@
 extern int w32_console_toggle_lock_key P_ ((int, Lisp_Object));
 extern void w32_menu_display_help P_ ((HWND, HMENU, UINT, UINT));
 extern void w32_free_menu_strings P_ ((HWND));
-extern XCharStruct *w32_per_char_metric P_ ((XFontStruct *, wchar_t *, int));
+extern XCharStruct *w32_per_char_metric P_ ((FRAME_PTR f,
+                                             XFontStruct *, wchar_t *, int));
 
 extern int quit_char;
 
@@ -4602,7 +4603,7 @@
       {
 	wchar_t space = 32;
 	XCharStruct* pcm;
-	pcm = w32_per_char_metric (font, &space, ANSI_FONT);
+	pcm = w32_per_char_metric (f, font, &space, ANSI_FONT);
 	if (pcm)
 	  fontp->space_width = pcm->width;
 	else
--- emacs-060112-102400/src/w32term.c	2005-12-19 09:31:23.000000000 +0100
+++ emacs.xft/src/w32term.c	2006-01-12 11:25:46.000000000 +0100
@@ -841,7 +841,8 @@
 
 /* Function prototypes of this page.  */
 
-XCharStruct *w32_per_char_metric P_ ((XFontStruct *, wchar_t *, int));
+XCharStruct *w32_per_char_metric P_ ((FRAME_PTR f,
+                                      XFontStruct *, wchar_t *, int));
 static int w32_encode_char P_ ((int, wchar_t *, struct font_info *, int *));
 
 
@@ -989,7 +990,8 @@
 
 
 XCharStruct *
-w32_per_char_metric (font, char2b, font_type)
+w32_per_char_metric (f, font, char2b, font_type)
+     FRAME_PTR f;
      XFontStruct *font;
      wchar_t *char2b;
      int /* enum w32_char_font_type */ font_type;
--- emacs-060112-102400/src/xdisp.c	2005-12-11 16:37:00.000000000 +0100
+++ emacs.xft/src/xdisp.c	2006-01-12 11:25:47.000000000 +0100
@@ -18038,9 +18038,9 @@
 
 #ifdef HAVE_WINDOW_SYSTEM
       if (EQ (prop, Qheight))
-	return OK_PIXELS (font ? FONT_HEIGHT ((XFontStruct *)font) : FRAME_LINE_HEIGHT (it->f));
+	return OK_PIXELS (font ? FONT_HEIGHT ((x_font_type *)font) : FRAME_LINE_HEIGHT (it->f));
       if (EQ (prop, Qwidth))
-	return OK_PIXELS (font ? FONT_WIDTH ((XFontStruct *)font) : FRAME_COLUMN_WIDTH (it->f));
+	return OK_PIXELS (font ? FONT_WIDTH ((x_font_type *)font) : FRAME_COLUMN_WIDTH (it->f));
 #else
       if (EQ (prop, Qheight) || EQ (prop, Qwidth))
 	return OK_PIXELS (1);
@@ -18578,7 +18578,7 @@
 
   if (glyph->type == CHAR_GLYPH)
     {
-      XFontStruct *font;
+      x_font_type *font;
       struct face *face;
       struct font_info *font_info;
       XChar2b char2b;
@@ -18588,7 +18588,7 @@
       font = face->font;
       font_info = FONT_INFO_FROM_ID (f, face->font_info_id);
       if (font  /* ++KFS: Should this be font_info ?  */
-	  && (pcm = rif->per_char_metric (font, &char2b, glyph->font_type)))
+	  && (pcm = rif->per_char_metric (f, font, &char2b, glyph->font_type)))
 	{
 	  if (pcm->rbearing > pcm->width)
 	    *right = pcm->rbearing - pcm->width;
@@ -19584,7 +19584,7 @@
   int ascent = 0;
   double tem;
   struct face *face = FACE_FROM_ID (it->f, it->face_id);
-  XFontStruct *font = face->font ? face->font : FRAME_FONT (it->f);
+  x_font_type *font = face->font ? face->font : FRAME_FONT (it->f);
 
   PREPARE_FACE_FOR_DISPLAY (it->f, face);
 
@@ -19735,7 +19735,7 @@
 calc_line_height_property (it, val, font, boff, override)
      struct it *it;
      Lisp_Object val;
-     XFontStruct *font;
+     x_font_type *font;
      int boff, override;
 {
   Lisp_Object face_name = Qnil;
@@ -19825,7 +19825,7 @@
   if (it->what == IT_CHARACTER)
     {
       XChar2b char2b;
-      XFontStruct *font;
+      x_font_type *font;
       struct face *face = FACE_FROM_ID (it->f, it->face_id);
       XCharStruct *pcm;
       int font_not_found_p;
@@ -19895,8 +19895,9 @@
 
 	  it->nglyphs = 1;
 
-	  pcm = rif->per_char_metric (font, &char2b,
-				      FONT_TYPE_FOR_UNIBYTE (font, it->char_to_display));
+	  pcm = rif->per_char_metric (it->f, font, &char2b,
+				      FONT_TYPE_FOR_UNIBYTE (font,
+                                                             it->char_to_display));
 
 	  if (it->override_ascent >= 0)
 	    {
@@ -20126,7 +20127,7 @@
 	     from the charset width; this is what old redisplay code
 	     did.  */
 
-	  pcm = rif->per_char_metric (font, &char2b,
+	  pcm = rif->per_char_metric (it->f, font, &char2b,
 				      FONT_TYPE_FOR_MULTIBYTE (font, it->c));
 
 	  if (font_not_found_p || !pcm)
@@ -20187,7 +20188,7 @@
       /* Note: A composition is represented as one glyph in the
 	 glyph matrix.  There are no padding glyphs.  */
       XChar2b char2b;
-      XFontStruct *font;
+      x_font_type *font;
       struct face *face = FACE_FROM_ID (it->f, it->face_id);
       XCharStruct *pcm;
       int font_not_found_p;
@@ -20258,8 +20259,9 @@
 
 	  /* Initialize the bounding box.  */
 	  if (font_info
-	      && (pcm = rif->per_char_metric (font, &char2b,
-					      FONT_TYPE_FOR_MULTIBYTE (font, it->c))))
+	      && (pcm = rif->per_char_metric (it->f, font, &char2b,
+					      FONT_TYPE_FOR_MULTIBYTE (font,
+                                                                       it->c))))
 	    {
 	      width = pcm->width;
 	      ascent = pcm->ascent;
@@ -20317,7 +20319,7 @@
 		}
 
 	      if (font_info
-		  && (pcm = rif->per_char_metric (font, &char2b,
+		  && (pcm = rif->per_char_metric (it->f, font, &char2b,
 						  FONT_TYPE_FOR_MULTIBYTE (font, ch))))
 		{
 		  width = pcm->width;
--- emacs-060112-102400/src/xfaces.c	2005-11-26 12:06:53.000000000 +0100
+++ emacs.xft/src/xfaces.c	2006-01-12 11:25:47.000000000 +0100
@@ -5246,7 +5246,6 @@
 	      x_free_gc (f, face->gc);
 	      face->gc = 0;
 	    }
-
 	  free_face_colors (f, face);
 	  x_destroy_bitmap (f, face->stipple);
 	}
@@ -5269,6 +5268,30 @@
 #ifdef HAVE_WINDOW_SYSTEM
   xassert (FRAME_WINDOW_P (f));
 
+#ifdef HAVE_XFT
+  if (face->xft_draw == 0)
+    {
+      BLOCK_INPUT;
+      XColor colors[2];
+      face->xft_draw = XftDrawCreate (FRAME_X_DISPLAY (f),
+                                      FRAME_X_WINDOW (f),
+                                      FRAME_X_DISPLAY_INFO (f)->visual,
+                                      FRAME_X_DISPLAY_INFO (f)->cmap);
+      colors[0].pixel = face->xft_fg.pixel = face->foreground;
+      colors[1].pixel = face->xft_bg.pixel = face->background;
+      
+      XQueryColors (FRAME_X_DISPLAY (f), FRAME_X_DISPLAY_INFO (f)->cmap,
+                    colors, 2);
+      face->xft_fg.color.alpha = face->xft_fg.color.alpha = 0xffff;
+      face->xft_fg.color.red = colors[0].red;
+      face->xft_fg.color.green = colors[0].green;
+      face->xft_fg.color.blue = colors[0].blue;
+      face->xft_bg.color.red = colors[1].red;
+      face->xft_bg.color.green = colors[1].green;
+      face->xft_bg.color.blue = colors[1].blue;
+      UNBLOCK_INPUT;
+    }
+#endif
   if (face->gc == 0)
     {
       XGCValues xgcv;
@@ -5280,18 +5303,24 @@
       xgcv.graphics_exposures = False;
 #endif
       /* The font of FACE may be null if we couldn't load it.  */
+      if (!face->font)
+        fprintf (stderr, "%s: font is NULL\n", __func__);
       if (face->font)
 	{
 #ifdef HAVE_X_WINDOWS
+#ifndef HAVE_XFT
 	  xgcv.font = face->font->fid;
 #endif
+#endif
 #ifdef WINDOWSNT
 	  xgcv.font = face->font;
 #endif
 #ifdef MAC_OS
 	  xgcv.font = face->font;
 #endif
+#ifndef HAVE_XFT
 	  mask |= GCFont;
+#endif
 	}
 
       BLOCK_INPUT;
@@ -5408,6 +5437,15 @@
       for (i = BASIC_FACE_ID_SENTINEL; i < c->used; ++i)
 	{
 	  struct face *face = c->faces_by_id[i];
+#ifdef HAVE_XFT
+          if (face && face->xft_draw)
+            {
+              BLOCK_INPUT;
+              XftDrawDestroy (face->xft_draw);
+              UNBLOCK_INPUT;
+              face->xft_draw = 0;
+            }
+#endif
 	  if (face && face->gc)
 	    {
 	      x_free_gc (c->f, face->gc);
@@ -6681,6 +6719,9 @@
 	      }
 	  }
 
+#ifndef HAVE_XFT
+      /* KOKO: overstrike only works with non-aliased fonts.  How to figure
+         out if a font is aliased?  It is in the XFT properties.  */
       if (needs_overstrike)
 	{
 	  enum xlfd_weight want_weight = specified[XLFD_WEIGHT];
@@ -6698,6 +6739,7 @@
 		*needs_overstrike = 1;
 	    }
 	}
+#endif
     }
 
   if (font_scalable_p (best))
@@ -6978,6 +7020,7 @@
   Lisp_Object attrs[LFACE_VECTOR_SIZE];
   Lisp_Object frame_font;
   struct face *face;
+  int do_font = 0;
 
   /* If the `default' face is not yet known, create it.  */
   lface = lface_from_face_name (f, Qdefault, 0);
@@ -6999,6 +7042,7 @@
       set_lface_from_font_name (f, lface, frame_font,
                                 f->default_face_done_p, 1);
       f->default_face_done_p = 1;
+      do_font = 1;
     }
 #endif /* HAVE_WINDOW_SYSTEM */
 
@@ -7068,6 +7112,11 @@
   check_lface (lface);
   bcopy (XVECTOR (lface)->contents, attrs, sizeof attrs);
   face = realize_face (c, attrs, 0, NULL, DEFAULT_FACE_ID);
+#ifdef HAVE_WINDOW_SYSTEM
+#warning "Must get face parameters and font cache right"
+  if (do_font)
+    face->font = FRAME_FONT (f);
+#endif
   return 1;
 }
 
--- emacs-060112-102400/src/xfns.c	2005-12-27 11:39:51.000000000 +0100
+++ emacs.xft/src/xfns.c	2006-01-12 11:25:47.000000000 +0100
@@ -2851,21 +2851,25 @@
      struct frame *f;
 {
   XGCValues gc_values;
-
+  unsigned mask;
   BLOCK_INPUT;
 
   /* Create the GCs of this frame.
      Note that many default values are used.  */
 
   /* Normal video */
+  mask = GCLineWidth | GCForeground | GCBackground;
+#ifndef HAVE_XFT
   gc_values.font = FRAME_FONT (f)->fid;
+  mask |= GCFont;
+#endif
   gc_values.foreground = f->output_data.x->foreground_pixel;
   gc_values.background = f->output_data.x->background_pixel;
   gc_values.line_width = 0;	/* Means 1 using fast algorithm.  */
   f->output_data.x->normal_gc
     = XCreateGC (FRAME_X_DISPLAY (f),
 		 FRAME_X_WINDOW (f),
-		 GCLineWidth | GCFont | GCForeground | GCBackground,
+		 mask,
 		 &gc_values);
 
   /* Reverse video style.  */
@@ -2874,7 +2878,7 @@
   f->output_data.x->reverse_gc
     = XCreateGC (FRAME_X_DISPLAY (f),
 		 FRAME_X_WINDOW (f),
-		 GCFont | GCForeground | GCBackground | GCLineWidth,
+		 mask,
 		 &gc_values);
 
   /* Cursor has cursor-color background, background-color foreground.  */
@@ -2885,10 +2889,14 @@
     = XCreateBitmapFromData (FRAME_X_DISPLAY (f),
 			     FRAME_X_DISPLAY_INFO (f)->root_window,
 			     cursor_bits, 16, 16);
+  mask = GCForeground | GCBackground
+    | GCFillStyle /* | GCStipple */ | GCLineWidth;
+#ifndef HAVE_XFT
+    mask |= GCFont;
+#endif
   f->output_data.x->cursor_gc
     = XCreateGC (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
-		 (GCFont | GCForeground | GCBackground
-		  | GCFillStyle /* | GCStipple */ | GCLineWidth),
+		 mask,
 		 &gc_values);
 
   /* Reliefs.  */
@@ -3194,8 +3202,11 @@
 #ifdef USE_LUCID
   /* Prevent lwlib/xlwmenu.c from crashing because of a bug
      whereby it fails to get any font.  */
+#warning "xlwmenu_default_font??"
+#if 0
   xlwmenu_default_font = FRAME_FONT (f);
 #endif
+#endif
 
   x_default_parameter (f, parms, Qborder_width, make_number (2),
 		       "borderWidth", "BorderWidth", RES_TYPE_NUMBER);
--- emacs-060112-102400/src/xmenu.c	2005-12-23 00:30:36.000000000 +0100
+++ emacs.xft/src/xmenu.c	2006-01-12 11:25:47.000000000 +0100
@@ -1238,6 +1238,10 @@
       if (event.type == ButtonRelease
           && dpyinfo->display == event.xbutton.display)
         {
+	  /* If the click is not on the menu, deactivate the menu.  */
+	  if (x_any_window_to_frame (dpyinfo, event.xexpose.window))
+	    popup_activated_flag = 0;
+	    
           dpyinfo->grabbed &= ~(1 << event.xbutton.button);
 #ifdef USE_MOTIF /* Pretending that the event came from a
                     Btn1Down seems the only way to convince Motif to
--- emacs-060112-102400/src/xterm.c	2005-11-16 17:38:48.000000000 +0100
+++ emacs.xft/src/xterm.c	2006-01-12 11:25:47.000000000 +0100
@@ -336,7 +336,7 @@
 void x_wm_set_window_state P_ ((struct frame *, int));
 void x_wm_set_icon_pixmap P_ ((struct frame *, int));
 void x_initialize P_ ((void));
-static void x_font_min_bounds P_ ((XFontStruct *, int *, int *));
+static void x_font_min_bounds P_ ((x_font_type *, int *, int *));
 static int x_compute_min_glyph_bounds P_ ((struct frame *));
 static void x_update_end P_ ((struct frame *));
 static void XTframe_up_to_date P_ ((struct frame *));
@@ -822,8 +822,9 @@
    is not contained in the font.  */
 
 static XCharStruct *
-x_per_char_metric (font, char2b, font_type)
-     XFontStruct *font;
+x_per_char_metric (f, font, char2b, font_type)
+     FRAME_PTR f;
+     x_font_type *font;
      XChar2b *char2b;
      int font_type;  /* unused on X */
 {
@@ -832,6 +833,7 @@
 
   xassert (font && char2b);
 
+#ifndef HAVE_XFT
   if (font->per_char != NULL)
     {
       if (font->min_byte1 == 0 && font->max_byte1 == 0)
@@ -883,6 +885,23 @@
 	  && char2b->byte2 <= font->max_char_or_byte2)
 	pcm = &font->max_bounds;
     }
+#else /* HAVE_XFT */
+  {
+    static XCharStruct xch;
+    XGlyphInfo xgl;
+    XftChar16 ch = char2b->byte2 | (char2b->byte1 << 8);
+    BLOCK_INPUT;
+    XftTextExtents16 (FRAME_X_DISPLAY (f), font, &ch, 1, &xgl);
+    UNBLOCK_INPUT;
+    xch.lbearing = -xgl.x;
+    xch.rbearing = xgl.width - xgl.x;
+    xch.width = xgl.xOff;
+    xch.ascent = xgl.y;
+    xch.descent = xgl.height - xgl.y;
+
+    pcm = &xch;
+  }
+#endif /* HAVE_XFT */
 
   return ((pcm == NULL
 	   || (pcm->width == 0 && (pcm->rbearing - pcm->lbearing) == 0))
@@ -901,7 +920,7 @@
      int *two_byte_p;
 {
   int charset = CHAR_CHARSET (c);
-  XFontStruct *font = font_info->font;
+  x_font_type *font = font_info->font;
 
   /* FONT_INFO may define a scheme by which to encode byte1 and byte2.
      This may be either a program in a special encoder language or a
@@ -927,12 +946,16 @@
 
       ccl_driver (ccl, NULL, NULL, 0, 0, NULL);
 
+#ifdef HAVE_XFT
+      char2b->byte1 = ccl->reg[1], char2b->byte2 = ccl->reg[2];
+#else
       /* We assume that MSBs are appropriately set/reset by CCL
 	 program.  */
       if (font->max_byte1 == 0)	/* 1-byte font */
 	char2b->byte1 = 0, char2b->byte2 = ccl->reg[1];
       else
 	char2b->byte1 = ccl->reg[1], char2b->byte2 = ccl->reg[2];
+#endif
     }
   else if (font_info->encoding[charset])
     {
@@ -949,8 +972,12 @@
     }
 
   if (two_byte_p)
-    *two_byte_p = ((XFontStruct *) (font_info->font))->max_byte1 > 0;
-
+#ifdef HAVE_XFT
+    *two_byte_p = FcCharSetCount
+      (((x_font_type *) font_info->font)->charset) > 256;
+#else
+    *two_byte_p = ((x_font_type *) (font_info->font))->max_byte1 > 0;
+#endif
   return FONT_TYPE_UNKNOWN;
 }
 
@@ -992,7 +1019,7 @@
 				 int, int, int, XRectangle *));
 
 #if GLYPH_DEBUG
-static void x_check_font P_ ((struct frame *, XFontStruct *));
+static void x_check_font P_ ((struct frame *, x_font_type *));
 #endif
 
 
@@ -1034,9 +1061,12 @@
 	}
 
       IF_DEBUG (x_check_font (s->f, s->font));
+      mask = GCForeground | GCBackground | GCGraphicsExposures;
+#ifndef HAVE_XFT
+      mask |= GCFont;
       xgcv.font = s->font->fid;
+#endif
       xgcv.graphics_exposures = False;
-      mask = GCForeground | GCBackground | GCFont | GCGraphicsExposures;
 
       if (FRAME_X_DISPLAY_INFO (s->f)->scratch_cursor_gc)
 	XChangeGC (s->display, FRAME_X_DISPLAY_INFO (s->f)->scratch_cursor_gc,
@@ -1085,9 +1115,12 @@
       xgcv.background = s->face->background;
       xgcv.foreground = s->face->foreground;
       IF_DEBUG (x_check_font (s->f, s->font));
+      mask = GCForeground | GCBackground | GCGraphicsExposures;
+#ifndef HAVE_XFT
+      mask |= GCFont;
       xgcv.font = s->font->fid;
+#endif
       xgcv.graphics_exposures = False;
-      mask = GCForeground | GCBackground | GCFont | GCGraphicsExposures;
 
       if (FRAME_X_DISPLAY_INFO (s->f)->scratch_cursor_gc)
 	XChangeGC (s->display, FRAME_X_DISPLAY_INFO (s->f)->scratch_cursor_gc,
@@ -1175,6 +1208,208 @@
 }
 
 
+#if HAVE_XFT
+/* XXX kludge - use the same font everywhere */
+static char *
+xft_pattern_name (char *pattern)
+{
+  static char *xft_pattern;
+
+  if (!xft_pattern)
+    {
+      if (*pattern == '-') return pattern;
+      xft_pattern = malloc (strlen (pattern) + 1);
+      strcpy (xft_pattern, pattern);
+    }
+  return xft_pattern;
+}
+
+static x_font_type *
+xft_font_open_name (Display *dpy, int screen, char *name)
+{
+    x_font_type *font;
+
+    /* name = xft_pattern_name (name); */
+    if (*name == '-') {
+	font = XftFontOpenXlfd (dpy, screen, name);
+	if (font)
+	    return font;
+    }
+    return XftFontOpenName (dpy, screen, name);
+}
+
+static int
+xft_ndashes (char *pattern)
+{
+  int ndashes = 0;
+  while (*pattern)
+    if (*pattern++ == '-')
+      ++ndashes;
+  return ndashes;
+}
+
+static char *
+xft_pad_fields (char *pattern)
+{
+  int ndashes = xft_ndashes (pattern);
+  int add = 14 - ndashes;
+  char *new, *ret;
+
+  ret = new = malloc (strlen (pattern) + add * 2 + 1);
+  if (!new)
+    return NULL;
+  if (*pattern != '-') {
+    *new++ = '-';
+    add--;
+    ndashes++;
+  }
+  if (ndashes < 4) 
+    {
+      strcpy (new, pattern);
+      while (add--)
+	strcat (new, "-*");
+    }
+  else
+    {
+      char *third = pattern;
+      int n;
+
+      for (n = 0; n < 3; n++)
+	third = index (third, '-') + 1;
+
+      bcopy (pattern, new, third - pattern);
+      new[third - pattern] = '\0';
+      while (add--)
+	strcat (new, "*-");
+      strcat (new, third);
+    }
+  return new;
+}
+
+static char *
+xft_fillout_xlfd (char *pattern)
+{
+  char *fourteen = xft_pad_fields (pattern);
+  char *dash = fourteen;
+  int n;
+  static char numeric[14] = {
+    0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0
+  };
+
+
+  for (n = 0; n < 14; n++) {
+    dash = index (dash, '-') + 1;
+    if (numeric[n] && *dash == '*')
+      *dash = '0';
+  }
+  return fourteen;
+}
+
+static FcPattern *
+xft_name_parse (char *name)
+{
+    FcPattern	*pattern;
+    
+    if (*name == '-') {
+	char *full_xlfd = xft_fillout_xlfd (name);
+	pattern = XftXlfdParse (full_xlfd, FcFalse, FcFalse);
+	free (full_xlfd);
+	if (pattern)
+	    return pattern;
+    }
+    return FcNameParse (name);
+}
+
+static char *
+xft_xlfd_weight_name (int weight)
+{
+    if (weight < (FC_WEIGHT_LIGHT + FC_WEIGHT_MEDIUM) / 2)
+	return "light";
+    if (weight < (FC_WEIGHT_MEDIUM + FC_WEIGHT_DEMIBOLD) / 2)
+	return "regular";
+    if (weight < (FC_WEIGHT_DEMIBOLD + FC_WEIGHT_BOLD) / 2)
+	return "demibold";
+    if (weight < (FC_WEIGHT_BOLD + FC_WEIGHT_BLACK) / 2)
+	return "demibold";
+    return "black";
+}
+
+static char *
+xft_xlfd_slant_name (int slant)
+{
+    if (slant < (FC_SLANT_ROMAN + FC_SLANT_ITALIC) / 2)
+	return "r";
+    if (slant < (FC_SLANT_ITALIC + FC_SLANT_OBLIQUE) / 2)
+	return "i";
+    return "o";
+}
+
+static char *
+xft_xlfd_unparse (FcPattern *pattern)
+{
+    char    *foundry;
+    char    *family;
+    int	    weight;
+    char    *weight_name;
+    int	    slant;
+    char    *slant_name;
+    double  pixel;
+    int	    len;
+    char    *xlfd;
+
+    if (FcPatternGetString (pattern, FC_FOUNDRY, 0, (FcChar8 *) &foundry)
+        != FcResultMatch)
+	foundry = "*";
+    if (FcPatternGetString (pattern, FC_FAMILY, 0, (FcChar8 *) &family)
+        != FcResultMatch)
+	family = "*";
+    if (FcPatternGetInteger (pattern, FC_WEIGHT, 0, &weight) != FcResultMatch)
+	weight_name = "*";
+    else
+	weight_name = xft_xlfd_weight_name (weight);
+    if (FcPatternGetInteger (pattern, FC_SLANT, 0, &slant) != FcResultMatch)
+	slant_name = "*";
+    else
+	slant_name = xft_xlfd_slant_name (slant);
+    if (FcPatternGetDouble (pattern, FC_PIXEL_SIZE, 0, &pixel) != FcResultMatch)
+	pixel = 0.0;
+    if (pixel < 0.0)
+	pixel = 0;
+    if (pixel >= 10000)
+	pixel = 9999;
+    len = (strlen (foundry) + 
+	   strlen (family) + 
+	   strlen (weight_name) +
+	   strlen (slant_name) + 
+	   5 +			    /* pixel */
+	   9 +			    /* stars */
+	   14 +			    /* dashes */
+	   1);			    /* null */
+    xlfd = malloc (len);
+    sprintf(xlfd, "-%s-%s-%s-%s-*-*-%d-*-*-*-*-0-*-*",
+	    foundry, family, weight_name, slant_name,
+	    (int) (pixel + 0.5));
+    return xlfd;
+}
+
+static char *
+xft_match_font (Display *dpy, int screen, char *name)
+{
+    FcPattern *pattern;
+    FcResult result;
+    FcPattern *match;
+    char      *xlfd;
+
+    pattern = xft_name_parse (name);
+    match = XftFontMatch (dpy, screen, pattern, &result);
+    FcPatternDestroy (pattern);
+    xlfd = xft_xlfd_unparse (match);
+    FcPatternDestroy (match);
+    return xlfd;
+}
+
+#endif
+
 /* RIF:
    Compute left and right overhang of glyph string S.  If S is a glyph
    string for a composition, assume overhangs don't exist.  */
@@ -1188,8 +1423,23 @@
     {
       XCharStruct cs;
       int direction, font_ascent, font_descent;
+#ifdef HAVE_XFT
+      XGlyphInfo xgl;
+      XftChar16 ch = s->char2b->byte2 | (s->char2b->byte1 << 8);
+      Display *dpy = s->display;
+      BLOCK_INPUT;
+      XftTextExtents16 (dpy, s->font, &ch, 1, &xgl);
+      UNBLOCK_INPUT;
+      cs.lbearing = -xgl.x;
+      cs.rbearing = xgl.width - xgl.x;
+      cs.width = xgl.xOff;
+      cs.ascent = xgl.y;
+      cs.descent = xgl.height - xgl.y;
+      
+#else
       XTextExtents16 (s->font, s->char2b, s->nchars, &direction,
 		      &font_ascent, &font_descent, &cs);
+#endif
       s->right_overhang = cs.rbearing > cs.width ? cs.rbearing - cs.width : 0;
       s->left_overhang = cs.lbearing < 0 ? -cs.lbearing : 0;
     }
@@ -1300,6 +1550,41 @@
 	 XDrawImageString is usually faster than XDrawString.)  Always
 	 use XDrawImageString when drawing the cursor so that there is
 	 no chance that characters under a box cursor are invisible.  */
+#ifdef HAVE_XFT
+      /* KOKO: Always clear background for now, there are some redraw problems
+         otherwise.  */
+      if (1 || ! (s->for_overlaps
+                  || (s->background_filled_p && s->hl != DRAW_CURSOR)))
+        XftDrawRect (s->face->xft_draw,
+                     s->hl == DRAW_CURSOR ? &s->face->xft_fg : &s->face->xft_bg,
+                     s->x,
+                     s->y,
+                     s->width + s->right_overhang,
+                     s->height);
+
+      if (s->two_byte_p)
+        {
+          XftChar16 ch[s->nchars];
+          int i;
+          for (i = 0; i < s->nchars; ++i)
+            ch[i] = s->char2b[i].byte2 | (s->char2b[i].byte1 << 8);
+          XftDrawString16 (s->face->xft_draw,
+                           &s->face->xft_fg,
+                           s->face->font,
+                           x,
+                           s->ybase - boff,
+                           ch,
+                           s->nchars);
+        }
+      else
+        XftDrawString8 (s->face->xft_draw,
+                        &s->face->xft_fg,
+                        s->face->font,
+                        x,
+                        s->ybase - boff,
+                        char1b,
+                        s->nchars);
+#else
       if (s->for_overlaps
 	  || (s->background_filled_p && s->hl != DRAW_CURSOR))
 	{
@@ -1320,7 +1605,9 @@
 	    XDrawImageString (s->display, s->window, s->gc, x,
 			      s->ybase - boff, char1b, s->nchars);
 	}
+#endif
 
+#ifndef HAVE_XFT
       if (s->face->overstrike)
 	{
 	  /* For overstriking (to simulate bold-face), draw the
@@ -1332,6 +1619,7 @@
 	    XDrawString (s->display, s->window, s->gc, x + 1,
 			 s->ybase - boff, char1b, s->nchars);
 	}
+#endif
     }
 }
 
@@ -1368,6 +1656,7 @@
     {
       for (i = 0; i < s->nchars; i++, ++s->gidx)
 	{
+#ifndef HAVE_XFT
 	  XDrawString16 (s->display, s->window, s->gc,
 			 x + s->cmp->offsets[s->gidx * 2],
 			 s->ybase - s->cmp->offsets[s->gidx * 2 + 1],
@@ -1377,6 +1666,7 @@
 			   x + s->cmp->offsets[s->gidx * 2] + 1,
 			   s->ybase - s->cmp->offsets[s->gidx * 2 + 1],
 			   s->char2b + i, 1);
+#endif
 	}
     }
 }
@@ -2672,7 +2962,9 @@
 	  int y;
 
 	  /* Get the underline thickness.  Default is 1 pixel.  */
+#ifndef HAVE_XFT
 	  if (!XGetFontProperty (s->font, XA_UNDERLINE_THICKNESS, &h))
+#endif
 	    h = 1;
 
 	  /* Get the underline position.  This is the recommended
@@ -2683,11 +2975,23 @@
 	     ROUND ((maximum descent) / 2), with
 	     ROUND(x) = floor (x + 0.5)  */
 
+#ifndef HAVE_XFT
 	  if (x_use_underline_position_properties
 	      && XGetFontProperty (s->font, XA_UNDERLINE_POSITION, &tem))
 	    y = s->ybase + (long) tem;
+#else
+          if (x_use_underline_position_properties)
+            {
+              tem = (float)s->font->descent/2.0+0.5;
+              y = s->ybase + (long) tem;
+            }
+#endif
 	  else if (s->face->font)
+#ifdef HAVE_XFT
+	    y = s->ybase + (s->face->font->descent + 1) / 2;
+#else
 	    y = s->ybase + (s->face->font->max_bounds.descent + 1) / 2;
+#endif
 	  else
 	    y = s->y + s->height - h;
 
@@ -7809,7 +8113,7 @@
   if (!fontp)
     return Qnil;
 
-  FRAME_FONT (f) = (XFontStruct *) (fontp->font);
+  FRAME_FONT (f) = (x_font_type *) (fontp->font);
   FRAME_BASELINE_OFFSET (f) = fontp->baseline_offset;
   FRAME_FONTSET (f) = -1;
 
@@ -7835,13 +8139,14 @@
   /* Now make the frame display the given font.  */
   if (FRAME_X_WINDOW (f) != 0)
     {
+#ifndef HAVE_XFT
       XSetFont (FRAME_X_DISPLAY (f), f->output_data.x->normal_gc,
 		FRAME_FONT (f)->fid);
       XSetFont (FRAME_X_DISPLAY (f), f->output_data.x->reverse_gc,
 		FRAME_FONT (f)->fid);
       XSetFont (FRAME_X_DISPLAY (f), f->output_data.x->cursor_gc,
 		FRAME_FONT (f)->fid);
-
+#endif
       /* Don't change the size of a tip frame; there's no point in
 	 doing it because it's done in Fx_show_tip, and it leads to
 	 problems because the tip frame has no widget.  */
@@ -9307,6 +9612,10 @@
   int try_XLoadQueryFont = 0;
   int count;
   int allow_auto_scaled_font = 0;
+  int font_scalable_p = 0;
+#ifdef HAVE_XFT
+  int font_width = 0;
+#endif
 
   if (size < 0)
     {
@@ -9318,14 +9627,17 @@
   if (NILP (patterns))
     patterns = Fcons (pattern, Qnil);
 
+#ifndef HAVE_XFT
   if (maxnames == 1 && !size)
     /* We can return any single font matching PATTERN.  */
     try_XLoadQueryFont = 1;
+#endif
 
   for (; CONSP (patterns); patterns = XCDR (patterns))
     {
       int num_fonts;
       char **names = NULL;
+      char *name = NULL;
 
       pattern = XCAR (patterns);
       /* See if we cached the result for this particular query.
@@ -9347,10 +9659,12 @@
       BLOCK_INPUT;
       count = x_catch_errors (dpy);
 
+#ifndef HAVE_XFT
       if (try_XLoadQueryFont)
 	{
-	  XFontStruct *font;
+	  x_font_type *font;
 	  unsigned long value;
+	  int len;
 
 	  font = XLoadQueryFont (dpy, SDATA (pattern));
 	  if (x_had_errors_p (dpy))
@@ -9365,16 +9679,21 @@
 	      && XGetFontProperty (font, XA_FONT, &value))
 	    {
 	      char *name = (char *) XGetAtomName (dpy, (Atom) value);
-	      int len = strlen (name);
-	      char *tmp;
 
 	      /* If DXPC (a Differential X Protocol Compressor)
                  Ver.3.7 is running, XGetAtomName will return null
                  string.  We must avoid such a name.  */
 	      if (len == 0)
 		try_XLoadQueryFont = 0;
+	    }
 	      else
+	    try_XLoadQueryFont = 0;
+	  if (font)
+            XFreeFont (dpy, font);
+          if (name)
 		{
+	      int len = strlen (name);
+	      char *tmp;
 		  num_fonts = 1;
 		  names = (char **) alloca (sizeof (char *));
 		  /* Some systems only allow alloca assigned to a
@@ -9384,15 +9703,22 @@
 		  XFree (name);
 		}
 	    }
-	  else
-	    try_XLoadQueryFont = 0;
-
-	  if (font)
-	    XFreeFont (dpy, font);
-	}
+#endif
 
       if (!try_XLoadQueryFont)
 	{
+#if HAVE_XFT
+	  char *full = xft_match_font (dpy, DefaultScreen (dpy), SDATA(pattern));
+	  int len = strlen (full);
+	  char *tmp;
+	  num_fonts = 1;
+	  names = (char **) alloca (sizeof (char *));
+	  /* Some systems only allow alloca assigned to a
+	     simple var.  */
+	  tmp = (char *) alloca (len + 1);  names[0] = tmp;
+	  bcopy (full, names[0], len + 1);
+	  free (full);
+#else
 	  /* We try at least 10 fonts because XListFonts will return
 	     auto-scaled fonts at the head.  */
           if (maxnames < 0)
@@ -9424,6 +9750,7 @@
 	      names = NULL;
 	      x_clear_errors (dpy);
 	    }
+#endif
 	}
 
       x_uncatch_errors (dpy, count);
@@ -9458,9 +9785,15 @@
 		    else if (dashes == 12) /* AVERAGE_WIDTH field */
 		      average_width = atoi (p);
 		  }
+              font_scalable_p = dashes == 14 && average_width == 0 && resx != 0;
 
-	      if (allow_auto_scaled_font
-		  || dashes < 14 || average_width != 0 || resx == 0)
+#ifdef HAVE_XFT
+              if (width == 0)
+                width = font_width;
+              if (dashes != 14)
+                allow_auto_scaled_font = 1;
+#endif
+	      if (allow_auto_scaled_font || ! font_scalable_p)                
 		{
 		  tem = build_string (names[i]);
 		  if (NILP (Fassoc (tem, list)))
@@ -9479,12 +9812,14 @@
 		}
 	    }
 
+#ifndef HAVE_XFT
 	  if (!try_XLoadQueryFont)
 	    {
 	      BLOCK_INPUT;
 	      XFreeFontNames (names);
 	      UNBLOCK_INPUT;
 	    }
+#endif
 	}
 
       /* Now store the result in the cache.  */
@@ -9514,12 +9849,17 @@
 	    {
 	      /* Since we have not yet known the size of this font, we
 		 must try slow function call XLoadQueryFont.  */
-	      XFontStruct *thisinfo;
+	      x_font_type *thisinfo;
 
 	      BLOCK_INPUT;
 	      count = x_catch_errors (dpy);
+#ifdef HAVE_XFT
+              thisinfo = xft_font_open_name (dpy, DefaultScreen (dpy),
+					     SDATA (XCAR (tem)));
+#else
 	      thisinfo = XLoadQueryFont (dpy,
 					 SDATA (XCAR (tem)));
+#endif
 	      if (x_had_errors_p (dpy))
 		{
 		  /* This error is perhaps due to insufficient memory on X
@@ -9532,12 +9872,21 @@
 
 	      if (thisinfo)
 		{
+#ifdef HAVE_XFT
+		  XSETCDR (tem,
+                           make_number (thisinfo->max_advance_width));
+#else
 		  XSETCDR (tem,
 			   (thisinfo->min_bounds.width == 0
 			    ? make_number (0)
 			    : make_number (thisinfo->max_bounds.width)));
+#endif
 		  BLOCK_INPUT;
+#ifdef HAVE_XFT
+                  XftFontClose (dpy, thisinfo);
+#else
 		  XFreeFont (dpy, thisinfo);
+#endif
 		  UNBLOCK_INPUT;
 		}
 	      else
@@ -9589,7 +9938,7 @@
 static void
 x_check_font (f, font)
      struct frame *f;
-     XFontStruct *font;
+     x_font_type *font;
 {
   int i;
   struct x_display_info *dpyinfo = FRAME_X_DISPLAY_INFO (f);
@@ -9614,17 +9963,20 @@
 
 static INLINE void
 x_font_min_bounds (font, w, h)
-     XFontStruct *font;
+     x_font_type *font;
      int *w, *h;
 {
   *h = FONT_HEIGHT (font);
+#ifdef HAVE_XFT
+  *w = 0;
+#else
   *w = font->min_bounds.width;
-
+#endif
   /* Try to handle the case where FONT->min_bounds has invalid
      contents.  Since the only font known to have invalid min_bounds
      is fixed-width, use max_bounds if min_bounds seems to be invalid.  */
   if (*w <= 0)
-    *w = font->max_bounds.width;
+    *w = FONT_WIDTH(font);
 }
 
 
@@ -9640,7 +9992,7 @@
 {
   int i;
   struct x_display_info *dpyinfo = FRAME_X_DISPLAY_INFO (f);
-  XFontStruct *font;
+  x_font_type *font;
   int old_width = dpyinfo->smallest_char_width;
   int old_height = dpyinfo->smallest_font_height;
 
@@ -9653,8 +10005,8 @@
 	struct font_info *fontp = dpyinfo->font_table + i;
 	int w, h;
 
-	font = (XFontStruct *) fontp->font;
-	xassert (font != (XFontStruct *) ~0);
+	font = (x_font_type *) fontp->font;
+	xassert (font != (x_font_type *) ~0);
 	x_font_min_bounds (font, &w, &h);
 
 	dpyinfo->smallest_font_height = min (dpyinfo->smallest_font_height, h);
@@ -9708,10 +10060,11 @@
   /* Load the font and add it to the table.  */
   {
     char *full_name;
-    XFontStruct *font;
+    x_font_type *font;
     struct font_info *fontp;
     unsigned long value;
     int i;
+    Display *dpy = FRAME_X_DISPLAY (f);
 
     /* If we have found fonts by x_list_font, load one of them.  If
        not, we still try to load a font by the name given as FONTNAME
@@ -9723,7 +10076,11 @@
 
     BLOCK_INPUT;
     count = x_catch_errors (FRAME_X_DISPLAY (f));
+#ifdef HAVE_XFT
+    font = xft_font_open_name (dpy, DefaultScreen (dpy), fontname);
+#else
     font = (XFontStruct *) XLoadQueryFont (FRAME_X_DISPLAY (f), fontname);
+#endif
     if (x_had_errors_p (FRAME_X_DISPLAY (f)))
       {
 	/* This error is perhaps due to insufficient memory on X
@@ -9764,26 +10121,32 @@
     fontp->name = (char *) xmalloc (strlen (fontname) + 1);
     bcopy (fontname, fontp->name, strlen (fontname) + 1);
 
+#ifndef HAVE_XFT
     if (font->min_bounds.width == font->max_bounds.width)
       {
 	/* Fixed width font.  */
 	fontp->average_width = fontp->space_width = font->min_bounds.width;
       }
     else
+#endif
       {
 	XChar2b char2b;
 	XCharStruct *pcm;
 
 	char2b.byte1 = 0x00, char2b.byte2 = 0x20;
-	pcm = x_per_char_metric (font, &char2b, 0);
+	pcm = x_per_char_metric (f, font, &char2b, 0);
 	if (pcm)
 	  fontp->space_width = pcm->width;
 	else
 	  fontp->space_width = FONT_WIDTH (font);
 
+#ifdef HAVE_XFT
+        fontp->average_width = 0;
+#else
 	fontp->average_width
 	  = (XGetFontProperty (font, dpyinfo->Xatom_AVERAGE_WIDTH, &value)
 	     ? (long) value / 10 : 0);
+#endif
 	if (fontp->average_width < 0)
 	  fontp->average_width = - fontp->average_width;
 	if (fontp->average_width == 0)
@@ -9792,7 +10155,7 @@
 	      {
 		int width = pcm->width;
 		for (char2b.byte2 = 33; char2b.byte2 <= 126; char2b.byte2++)
-		  if ((pcm = x_per_char_metric (font, &char2b, 0)) != NULL)
+		  if ((pcm = x_per_char_metric (f, font, &char2b, 0)) != NULL)
 		    width += pcm->width;
 		fontp->average_width = width / 95;
 	      }
@@ -9803,6 +10166,7 @@
 
     /* Try to get the full name of FONT.  Put it in FULL_NAME.  */
     full_name = 0;
+#ifndef HAVE_XFT
     if (XGetFontProperty (font, XA_FONT, &value))
       {
 	char *name = (char *) XGetAtomName (FRAME_X_DISPLAY (f), (Atom) value);
@@ -9829,13 +10193,13 @@
 
 	XFree (name);
       }
-
+#endif
     if (full_name != 0)
       fontp->full_name = full_name;
     else
       fontp->full_name = fontp->name;
 
-    fontp->size = font->max_bounds.width;
+    fontp->size = FONT_WIDTH (font);
     fontp->height = FONT_HEIGHT (font);
 
     if (NILP (font_names))
@@ -9875,6 +10239,12 @@
        uses this font.  So, we set information in fontp->encoding[1]
        which is never used by any charset.  If mapping can't be
        decided, set FONT_ENCODING_NOT_DECIDED.  */
+#ifdef HAVE_XFT
+    fontp->encoding[1] = FONT_ENCODING_NOT_DECIDED;
+    fontp->baseline_offset = 0;
+    fontp->relative_compose = 0;
+    fontp->default_ascent = font->ascent;
+#else
     fontp->encoding[1]
       = (font->max_byte1 == 0
 	 /* 1-byte font */
@@ -9907,7 +10277,7 @@
     fontp->default_ascent
       = (XGetFontProperty (font, dpyinfo->Xatom_MULE_DEFAULT_ASCENT, &value)
 	 ? (long) value : 0);
-
+#endif
     /* Set global flag fonts_changed_p to non-zero if the font loaded
        has a character with a smaller width than any other character
        before, or if the font loaded has a smaller height than any
--- emacs-060112-102400/src/xterm.h	2005-12-02 15:57:10.000000000 +0100
+++ emacs.xft/src/xterm.h	2006-01-12 11:25:47.000000000 +0100
@@ -31,6 +31,16 @@
 #include <X11/Xatom.h>
 #include <X11/Xresource.h>
 
+#ifndef X_FONT_TYPE_DECL
+#define X_FONT_TYPE_DECL
+#ifdef HAVE_XFT
+#include <X11/Xft/Xft.h>
+typedef XftFont x_font_type;
+#else
+typedef XFontStruct x_font_type;
+#endif
+#endif /* not X_FONT_TYPE_DECL */
+
 #ifdef USE_X_TOOLKIT
 #include <X11/StringDefs.h>
 #include <X11/IntrinsicP.h>	/* CoreP.h needs this */
@@ -106,7 +116,11 @@
 #define WHITE_PIX_DEFAULT(f) WhitePixel (FRAME_X_DISPLAY (f), \
 					 XScreenNumberOfScreen (FRAME_X_SCREEN (f)))
 
+#ifdef HAVE_XFT
+#define FONT_WIDTH(f)	((f)->max_advance_width)
+#else
 #define FONT_WIDTH(f)	((f)->max_bounds.width)
+#endif
 #define FONT_HEIGHT(f)	((f)->ascent + (f)->descent)
 #define FONT_BASE(f)    ((f)->ascent)
 #define FONT_DESCENT(f) ((f)->descent)
@@ -512,7 +526,7 @@
   int icon_bitmap;
 
   /* Default ASCII font of this frame.  */
-  XFontStruct *font;
+  x_font_type *font;
 
   /* The baseline offset of the default ASCII font.  */
   int baseline_offset;

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-16 22:48                                             ` Miles Bader
  2006-01-17  8:34                                               ` Jan D.
@ 2006-01-17 15:19                                               ` David Abrahams
  1 sibling, 0 replies; 41+ messages in thread
From: David Abrahams @ 2006-01-17 15:19 UTC (permalink / raw)
  Cc: Jan D., emacs-devel, Kenichi Handa, miles

Miles Bader <snogglethorpe@gmail.com> writes:

> 2006/1/17, David Abrahams <dave@boost-consulting.com>:
>> > No tag, but you can use the date specifier, the cvs log message gives
>> > the date.
>>
>> Thanks, I'll do that.  FWIW, if you do use such tags you can
>> substantially reduce the number of conflicts you see upon merging.
>
> This whole conversation is making me very nervous ....

Me too.  If I have to learn and install a whole new version control
system just to contribute to a project that's actually officially
stored in CVS, it raises the barrier to entry considerably.

> I also merge into the emacs-unicode-2 branch (using arch), and this is
> normally pretty easy.  I'm afraid that a botched merge (all too easy
> with CVS) into that same branch will make things very painful for me.
>
> Jan, how many changes are there in the XFT branch, compared to the trunk?
>
> If it's not many, how about instead I update my XFT branch in arch
> (it's out of date because it got merged into from the trunk, which
> caused lots of problems for my syncing scripts, but I can just
> probably just recreate it from scratch), then merge that into the
> unicode branch (using arch), and make a new combined branch, and then
> make a new CVS branch from that...?

Well :)

That's certainly an attractive idea from my point of view!  Please do
it; I'll be very glad not to have to worry about that step.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-17  8:34                                               ` Jan D.
@ 2006-01-17 15:20                                                 ` David Abrahams
  2006-01-18  0:41                                                   ` Miles Bader
  0 siblings, 1 reply; 41+ messages in thread
From: David Abrahams @ 2006-01-17 15:20 UTC (permalink / raw)
  Cc: snogglethorpe, emacs-devel, Kenichi Handa, miles

"Jan D." <jan.h.d@swipnet.se> writes:

> I've attached a diff from HEAD 2006-01-12 10:24 to the XFT branch (the
> latest sync with head occurred then).  It is not that much.

I could easily(?) apply this patch to emacs-unicode-2 myself, but I
don't want to duplicate work if Miles is going to do it too.  So,
Miles, what'll it be?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-17 15:20                                                 ` David Abrahams
@ 2006-01-18  0:41                                                   ` Miles Bader
  2006-01-20  1:51                                                     ` David Abrahams
  0 siblings, 1 reply; 41+ messages in thread
From: Miles Bader @ 2006-01-18  0:41 UTC (permalink / raw)
  Cc: Jan D., emacs-devel, Kenichi Handa, miles

2006/1/18, David Abrahams <dave@boost-consulting.com>:
> > I've attached a diff from HEAD 2006-01-12 10:24 to the XFT branch (the
> > latest sync with head occurred then).  It is not that much.
>
> I could easily(?) apply this patch to emacs-unicode-2 myself, but I
> don't want to duplicate work if Miles is going to do it too.  So,
> Miles, what'll it be?

My only concern is if any branch merging is done.

If you want to apply this patch directly on the emacs-unicode-2
branch, and work there, then I've no reason to be involved (I dunno
whether that's acceptable to Kenichi et al though).

If you want to work on a new branch (derived from emacs-unicode-2),
and later merge it into emacs-unicode-2, then I'd like to be the one
that creates the new branch (and later merges it back into
emacs-unicode-2).

So if it's the latter, give me the word, and I'll make a new branch. 
[Actually, probably the simplest thing to do is for me to make it a
clone of emacs-unicode-2, and let you apply Jan's patch.]

Thanks,

-Miles

--
Do not taunt Happy Fun Ball.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-18  0:41                                                   ` Miles Bader
@ 2006-01-20  1:51                                                     ` David Abrahams
  2006-01-28 13:23                                                       ` David Abrahams
  0 siblings, 1 reply; 41+ messages in thread
From: David Abrahams @ 2006-01-20  1:51 UTC (permalink / raw)
  Cc: Miles Bader

Miles Bader <snogglethorpe@gmail.com> writes:

> 2006/1/18, David Abrahams <dave@boost-consulting.com>:
>> > I've attached a diff from HEAD 2006-01-12 10:24 to the XFT branch (the
>> > latest sync with head occurred then).  It is not that much.
>>
>> I could easily(?) apply this patch to emacs-unicode-2 myself, but I
>> don't want to duplicate work if Miles is going to do it too.  So,
>> Miles, what'll it be?
>
> My only concern is if any branch merging is done.
>
> If you want to apply this patch directly on the emacs-unicode-2
> branch, and work there, then I've no reason to be involved (I dunno
> whether that's acceptable to Kenichi et al though).

I guess I would be slightly more comfortable if someone with more
experience with the emacs codebase (like you) wanted to merge the two
branches together.  It seems like a lot to ask, but you did volunteer
:).  However, it sounds like it's a small thing so if you want to back
out, I can probably manage.

> If you want to work on a new branch (derived from emacs-unicode-2),
> and later merge it into emacs-unicode-2, then I'd like to be the one
> that creates the new branch (and later merges it back into
> emacs-unicode-2).
>
> So if it's the latter, give me the word, and I'll make a new
> branch. 

Well, that would keep me out of everyone's hair -- if someone will
give me commit privileges, that is.  Who do I ask?  Otherwise I'll
have to ask somebody to keep committing my intermediate work.

> [Actually, probably the simplest thing to do is for me to make it a
> clone of emacs-unicode-2, and let you apply Jan's patch.]

Won't that make *more* work when things are integrated?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Emacs antialiasing in X
  2006-01-20  1:51                                                     ` David Abrahams
@ 2006-01-28 13:23                                                       ` David Abrahams
  0 siblings, 0 replies; 41+ messages in thread
From: David Abrahams @ 2006-01-28 13:23 UTC (permalink / raw)
  Cc: Miles Bader

David Abrahams <dave@boost-consulting.com> writes:

> Miles Bader <snogglethorpe@gmail.com> writes:
>
>> 2006/1/18, David Abrahams <dave@boost-consulting.com>:
>>> > I've attached a diff from HEAD 2006-01-12 10:24 to the XFT branch (the
>>> > latest sync with head occurred then).  It is not that much.
>>>
>>> I could easily(?) apply this patch to emacs-unicode-2 myself, but I
>>> don't want to duplicate work if Miles is going to do it too.  So,
>>> Miles, what'll it be?
>>
>> My only concern is if any branch merging is done.
>>
>> If you want to apply this patch directly on the emacs-unicode-2
>> branch, and work there, then I've no reason to be involved (I dunno
>> whether that's acceptable to Kenichi et al though).
>
> I guess I would be slightly more comfortable if someone with more
> experience with the emacs codebase (like you) wanted to merge the two
> branches together.  It seems like a lot to ask, but you did volunteer
> :).  However, it sounds like it's a small thing so if you want to back
> out, I can probably manage.

So, Miles, I'm waiting on word from you about what you're going to do
here.

>> If you want to work on a new branch (derived from emacs-unicode-2),
>> and later merge it into emacs-unicode-2, then I'd like to be the one
>> that creates the new branch (and later merges it back into
>> emacs-unicode-2).
>>
>> So if it's the latter, give me the word, and I'll make a new
>> branch. 
>
> Well, that would keep me out of everyone's hair -- if someone will
> give me commit privileges, that is.  Who do I ask?  Otherwise I'll
> have to ask somebody to keep committing my intermediate work.

Also, I'd appreciate it if someone could tell me how to get commit
privileges (for a branch at least, if you have fine-grained control).

>> [Actually, probably the simplest thing to do is for me to make it a
>> clone of emacs-unicode-2, and let you apply Jan's patch.]
>
> Won't that make *more* work when things are integrated?

...not that I mind applying Jan's patch.

Thanks,

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

^ permalink raw reply	[flat|nested] 41+ messages in thread

end of thread, other threads:[~2006-01-28 13:23 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-08-08 14:34 Emacs antialiasing in X Bill Atkins
2005-08-09 14:35 ` Jan D.
2005-12-20 20:17   ` David Abrahams
2005-12-21  5:30     ` Richard M. Stallman
2005-12-21 13:17       ` David Abrahams
2005-12-22  9:38         ` Jan D.
2006-01-12 22:56           ` David Abrahams
2006-01-13  8:49             ` Jan D.
2006-01-13 21:32               ` David Abrahams
2006-01-14 18:15                 ` David Abrahams
2006-01-15  3:53                   ` Emfox Zhou
2006-01-15  8:31                     ` Jan Djärv
2006-01-15 16:13                       ` David Abrahams
2006-01-16  0:58                         ` Kenichi Handa
2006-01-16  2:09                           ` David Abrahams
2006-01-16  2:35                             ` Kenichi Handa
2006-01-16  3:02                               ` David Abrahams
2006-01-16  4:07                                 ` Kenichi Handa
2006-01-16 13:32                                   ` David Abrahams
2006-01-16 23:45                                     ` Lőrentey Károly
2006-01-16  8:14                                 ` Jan D.
2006-01-16  9:45                                   ` Miles Bader
2006-01-16 13:38                                   ` David Abrahams
2006-01-16 13:53                                     ` Jan D.
2006-01-16 16:31                                       ` David Abrahams
2006-01-16 19:04                                         ` Jan D.
2006-01-16 20:17                                           ` David Abrahams
2006-01-16 22:48                                             ` Miles Bader
2006-01-17  8:34                                               ` Jan D.
2006-01-17 15:20                                                 ` David Abrahams
2006-01-18  0:41                                                   ` Miles Bader
2006-01-20  1:51                                                     ` David Abrahams
2006-01-28 13:23                                                       ` David Abrahams
2006-01-17 15:19                                               ` David Abrahams
2006-01-16 16:51                                     ` Stefan Monnier
2006-01-16 18:01                                       ` David Abrahams
2006-01-16 15:57                                   ` Emfox Zhou
2006-01-16  4:28                             ` Stefan Monnier
2006-01-16 13:32                               ` David Abrahams
2006-01-16  8:52                     ` YAMAMOTO Mitsuharu
2006-01-15  8:28                 ` Jan Djärv

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).