7:49 p.m.
I'm trying to figure out what is going on with
https://bugzilla.redhat.com/show_bug.cgi?id=512623. I mention in that
bug report that I cannot reproduce. That's because I was using
21.5.28. With 21.5.29, I can reproduce this. The function
fc-name-parse is being called, even though XEmacs was configured
without Xft. Does anyone know what changed between 21.5.28 and
21.5.29 to cause this, and what we need to do about it? Thanks,
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:17 p.m.
On Mon, Aug 24, 2009 at 12:49 PM, Jerry James<james(a)xemacs.org> wrote:
I'm trying to figure out what is going on with
https://bugzilla.redhat.com/show_bug.cgi?id=512623. I mention in that
bug report that I cannot reproduce. That's because I was using
21.5.28. With 21.5.29, I can reproduce this. The function
fc-name-parse is being called, even though XEmacs was configured
without Xft. Does anyone know what changed between 21.5.28 and
21.5.29 to cause this, and what we need to do about it? Thanks,
I think I found the problem. I'm looking at the function
x-font-create-object, in lisp/font.el. In the second conditional from
the top of the function, it checks
(if (and (stringp fontname)
(string-match font-xft-font-regexp fontname))
;; Return an XFT font.
(xft-font-create-object fontname)
But that's not right, is it? Shouldn't we also check that Xft is even
available? What about something like this:
(if (and (stringp fontname)
(featurep 'xft-fonts)
(string-match font-xft-font-regexp fontname))
;; Return an XFT font.
(xft-font-create-object fontname)
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:29 a.m.
Jerry James writes:
I think I found the problem. I'm looking at the function
x-font-create-object, in lisp/font.el. In the second conditional from
the top of the function, it checks
(if (and (stringp fontname)
(string-match font-xft-font-regexp fontname))
;; Return an XFT font.
(xft-font-create-object fontname)
But that's not right, is it?
Shouldn't we also check that Xft is even available?
Actually, it is right, and the check is counterproductive. A basic
problem is that Emacs, and especially our Xft support, confound font
specification with implementation of font objects.
But all of the standard font naming systems encapsulate similar sets
of font properties. There is no reason why an X font shouldn't be
returned on X11 for a MSFT font spec, or vice versa. Of course to
"really get it right", you'd need some auxiliary stuff like mapping
Arial to Helvetica, etc. But even without that it is at least
possible to parse out stuff like the size and often properties like
weight or slant.
That's what the currently unused lisp/font-mgr.el is aimed at.
AFAICS, fontconfig can handle anything that any other font
specification system can handle, so I plan to emulate its API.
What about something like this:
(if (and (stringp fontname)
(featurep 'xft-fonts)
(string-match font-xft-font-regexp fontname))
;; Return an XFT font.
(xft-font-create-object fontname)
This is a hangover from the original patch. The comment is wrong;
what is returned is a font.el-internal font object (NOT an XEmacs font
instance!) whose properties correspond to parsing the name as a
fontconfig name.
I would prefer the patch below (untested, and actually needs work on
the documentation but I don't have time to regenerate now).
What actually addresses the bug report is the change to
font-xft-font-regexp.
diff -r 891381effa11 lisp/font-mgr.el
--- a/lisp/font-mgr.el Tue Aug 18 12:34:34 2009 +0100
+++ b/lisp/font-mgr.el Tue Aug 25 17:04:44 2009 +0900
＠＠ -39,7 +39,8 ＠＠
;; #### should we wrap the world in `(unless (featurep 'font-mgr) ... )'?
-(provide 'font-mgr)
+;; #### implementation is incomplete
+;; (provide 'font-mgr)
(defvar xft-xlfd-font-regexp
(concat
diff -r 891381effa11 lisp/font.el
--- a/lisp/font.el Tue Aug 18 12:34:34 2009 +0100
+++ b/lisp/font.el Tue Aug 25 17:04:44 2009 +0900
＠＠ -753,14 +753,22 ＠＠
(defvar font-xft-font-regexp
(concat "\\`"
- #r"\(\\-\|\\:\|\\,\|[^:-]\)*" ; optional foundry and family
+ #r"\(\\[-,]|[^-:,*]\)*" ; optional foundry and family
; (allows for escaped colons,
- ; dashes, commas)
+ ; dashes, commas, asterisks)
"\\(-[0-9]*\\(\\.[0-9]*\\)?\\)?" ; optional size (points)
"\\(:[^:]*\\)*" ; optional properties
; not necessarily key=value!!
"\\'"
- ))
+ )
+ "Regexp matching fontconfig font names.
+Unfortunately, there is no explicit standard specifying these. We disallow
+hyphen and comma in family names unless escaped, because they have a syntactic
+role in fontconfig names. We disallow colon because it is part of fontconfig
+name syntax, and asterisk because of the potential for confusion with an XLFD.
+We do not allow escapes for colon and asterisk because the fontconfig
+documentation doesn't specify whether they can be escaped, or how a redundant
+escape character is treated.
+#### The name of this variable is subject to change.")
(defvar font-xft-family-mappings
;; #### FIXME this shouldn't be needed or used for Xft
＠＠ -799,6 +807,8 ＠＠
"Return a font descriptor object for FONTNAME, appropriate for Xft.
Optional DEVICE defaults to `default-x-device'."
+ (unless (featurep 'font-mgr)
+ (error 'unimplemented 'font-mgr "fontconfig-style font names"))
(let* ((name fontname)
(device (or device (default-x-device)))
(pattern (fc-font-match device (fc-name-parse name)))
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5 p.m.
On Tue, Aug 25, 2009 at 2:29 AM, Stephen J. Turnbull<stephen(a)xemacs.org> wrote:
I would prefer the patch below (untested, and actually needs work on
the documentation but I don't have time to regenerate now).
What actually addresses the bug report is the change to
font-xft-font-regexp.
Wonderful. Thanks for looking at this. I'll give that a try and see
if it fixes Horst's problem.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:13 p.m.
On Tue, Aug 25, 2009 at 2:29 AM, Stephen J. Turnbull<stephen(a)xemacs.org> wrote:
I would prefer the patch below (untested, and actually needs work on
the documentation but I don't have time to regenerate now).
What actually addresses the bug report is the change to
font-xft-font-regexp.
That leads to a build failure [1], because fontconfig.el does a
(require 'font-mgr) that is now unsatisfiable. How do I handle that?
Sorry to be helpless, but I don't know this code at all. Thanks,
References:
[1] http://koji.fedoraproject.org/koji/getfile?taskID=1636608&name=build.log
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:34 a.m.
Jerry James writes:
On Tue, Aug 25, 2009 at 2:29 AM, Stephen J.
Turnbull<stephen(a)xemacs.org> wrote:
> I would prefer the patch below (untested, and actually needs work on
> the documentation but I don't have time to regenerate now).
>
> What actually addresses the bug report is the change to
> font-xft-font-regexp.
That leads to a build failure [1],
Ow! that's scary ... oh, I see what you mean ("that" == patch, not
"that" == change to regexp :-). You had me going for a second.
because fontconfig.el does a (require 'font-mgr) that is now
unsatisfiable. How do I handle that?
Mmm. Try just wrapping it:
(ignore-errors (require 'font-mgr)) ; FIXME!
In a --without-xft build you should get some compile warnings that
xft-* functions are not known to be defined, and at runtime if
something falls through to an xft-* function you'll get an undefined
function error for some fc-whatever. Presumably that's an error
anyway if Xft isn't linked, but it might be marginally more confusing.
If that doesn't work, make the change you proposed and flag it
;; #### stephen doesn't like this but it's up to him to do better!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:36 p.m.
On Thu, Aug 27, 2009 at 3:34 AM, Stephen J. Turnbull<stephen(a)xemacs.org> wrote:
Ow! that's scary ... oh, I see what you mean ("that" ==
patch, not
"that" == change to regexp :-). You had me going for a second.
Oops. Dang ambiguous references.
Mmm. Try just wrapping it:
(ignore-errors (require 'font-mgr)) ; FIXME!
In a --without-xft build you should get some compile warnings that
xft-* functions are not known to be defined, and at runtime if
something falls through to an xft-* function you'll get an undefined
function error for some fc-whatever. Presumably that's an error
anyway if Xft isn't linked, but it might be marginally more confusing.
If that doesn't work, make the change you proposed and flag it
;; #### stephen doesn't like this but it's up to him to do better!
I don't like the direction this is going. The existing rpm includes
an option (unused in Fedora) to build with xft support. The idea is
that once it looks like xft is ready (I'm just waiting for the
"display turds" to go away, actually), I can flip the default from off
to on. The approach we're taking here is going to make that
impossible.
Also, I don't understand how the regexp change helps with the bug
report. Isn't the problem that font-x-font-regexp matches too little?
My predecessor configured Fedora XEmacs to have this in Emacs.ad:
XEmacs*FontSet: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso10646-1, \
-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*, \
*
I believe that the third spec, the fallback, is what is getting us into trouble:
(string-match font-x-font-regexp "*")
nil
In fact, every single position has to be satisfied. As far as I can
tell, this is the shortest matching string:
(string-match font-x-font-regexp "-*-*-*-*-*--*-*-*-*-*-*-*-*")
0
Shouldn't font-x-font-regexp match strings with some of the positions
left off? That works with xfontsel. Otherwise, perhaps I should
change Emacs.ad to read:
XEmacs*FontSet: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso10646-1, \
-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*, \
-*-*-*-*-*--*-*-*-*-*-*-*-*
but then the fallback doesn't match "10x20", "fixed", etc.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:04 a.m.
Jerry James writes:
> ;; #### stephen doesn't like this but it's up to him to
do better!
I don't like the direction this is going. The existing rpm includes
an option (unused in Fedora) to build with xft support. The idea is
that once it looks like xft is ready (I'm just waiting for the
"display turds" to go away, actually), I can flip the default from off
to on. The approach we're taking here is going to make that
impossible.
No, it already is impossible as far as I am concerned. I am not
willing to say that Xft is near releasable state. A lot of work
remains to be done, on font.el, font-mgr.el, objects-x.c, menus,
custom, lwlib, etc etc.
The display turds are way low on my list of things to do. If you're
serious that you don't care if the menus and custom fail in many
circumstances, you don't care if font-selection for charset-crossing
texts really sucks, then just flip the switch and let the users fix it
for us. That's the kind of thing that somebody who's willing to face
a couple crashes before they get the code right can improve by just
poking around in redisplay-x.c.
Also, I don't understand how the regexp change helps with the
bug
report. Isn't the problem that font-x-font-regexp matches too
little?
No. The current design is that you use XLFDs for legacy X fonts or
it's not supported. Sorry, but that is what you all voted for when
you voted to have Xft merged. You will recall I opposed it then. I
was right then, and I'm still right.
Now, I intend to change that assumption, but the whole infrastructure
needs to change, and there's nothing in the current design that is
easily adaptable to making it work.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
12:11 p.m.
Stephen J. Turnbull writes:
The display turds are way low on my list of things to do.
That's the kind of thing that somebody who's willing to face
a
couple crashes before they get the code right can improve by just
poking around in redisplay-x.c.
N.B. By "that" I mean the display turds.
AFAICT, the problem is that in the nature of things the extent of
redisplay of text displayed in an antialiased font is necessarily a
bit fuzzy. Xft seems to report optimistically (ie, the smallest
extent that could be needed).
I think that blanking an extra pixel around the extent reported by Xft
is what we need to do, but that can effectively clip the surrounding
text (and I have in fact observed such artifacts in Mozilla and
OpenOffice, so apparently that is what they do). The amount of code
in XEmacs that deals with it is pretty small and well-marked by #ifdef
XFT or similar. This would be a good project for somebody who wants a
useful task that is limited in scope.
I don't understand why the cursor is so likely to leave turds. There
may be an off-by-one error in the calculation of its size. Why that
doesn't matter for legacy X fonts I don't know, though.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5364
days inactive
5368
days old
8 comments
2 participants
participants (2)
-
Jerry James -
Stephen J. Turnbull