* 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-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 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 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 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-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 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 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 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 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-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
* 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-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 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 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 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-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-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
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).