Adrian Aichner <adrian(a)xemacs.org&gt; writes: Heh, that's pretty bad. Thanks for trying it, anyway.

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Thanks for researching that, but doing that kind of thing is outside the scope of htmlize. I don't even use Windows, and it would be nearly impossible to debug the code that attempted all that. It really sucks that Lisp code has to resort to parsing font descriptions. GNU Emacs 21 has completely surpassed us with simple yet powerful face properties that they support.

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Maybe so, but they define an interface which I can use to query face properties. If that interface doesn't work, it's their bug which I can report and they can fix (but it does work in my tests.) For example, `face-bold-p' and `face-italic-p' and, in newer incarnations, (face-attribute FACE :weight) and (face-attribute FACE :slant) -- you get the idea. And that's all I'm asking for. I really don't care how they do it behind the scenes -- the interface is what matters. When they port Emacs to a new GUI platform, they'll take care to parse font names and/or whatever else is necessary, and htmlize will "just work". XEmacs doesn't support that. Also note that `M-x apropos' only lists interactive commands under FSF. Try `C-u M-x apropos'.

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: I don't use those in htmlize, partly because I don't consider `custom-face-*' part of the public face API, and partly because I don't trust that code. And I'm the one who put it in! Note the comment above those illustrious functions: ;; Really, we should get rid of these font.el dependencies... They ;; are still presenting a problem with dumping the faces (font.el is ;; too bloated for us to dump). I am thinking about hacking up ;; font-like functionality myself for the sake of this file. It will ;; probably be to-the-point and more efficient. Because when they were added, they were internal functions in a state of flux. I didn't want to make them "official" by naming them `face-bold-p', etc. That was a good decision. An even better one would have been not to add them in the first place, but then our custom would have been too incomplete. :-( I don't use Custom with faces because it just sucks. I set my fonts using X resources. I guess I didn't realize what you meant by supported. For example, a user cannot type `M-x make-extent', or `M-x make-face' yet both interfaces are supported for my definitions of the word.

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Note that, when I referred to font.el as "bloat", I was referring not to its size, but to the fact that we needed only a small subset of its functionality. I now know that part of it is already available in `x-face.el', and that the other part could have been obtained through the `font-instance-properties' alist. I wish I'd known it then. The harder problem was that querying for font properties is not very useful if you cannot also set them, which really had nothing to do with font.el. For example, why doesn't make-face-bold use font.el? Why does make-face-font have to be so hairy? Why does it have to even exist? There should IMHO be a set-face-bold-p, which should do exactly what set-face-underline-p and friends do: change a specifier's value. It should be up to the display code to use the value when choosing the font to draw the face with. The horror that is make-face-bold, make-face-family (who the hell invented *that* name? **set**-face-family, anyone?) must go away if we're to have a sane face API. For example, it should be possible to do this: (let ((face (make-face (gensym) nil t))) (set-face-bold-p face t) (put (make-extent (point-min) (point-max)) 'face face)) and end up with a buffer whose characters are drawn in bold versions of their respective fonts. (On a TTY, it should draw highlighted characters.) And that should, of course, be exactly equivalent to: (put (make-extent (point-min) (point-max)) 'face 'bold) because the `bold' face should be nothing other than a face with the `bold' property set to t, such as the temporary I generated with `make-face' in the above example. Of course, the second form works even now, but with subtly different semantics: it draws all characters in the buffer with *the same* font: that of the `bold' face. Bad. The same should be possible with all font properties, e.g. family, size, slant, and possibly even "antialiasing"! I can easily imagine that I'd want antialiasing for one buffer or face, and not want for others. The power behind specifiers might for once actually be put to good use. If it sounds hairy for the display code to merge fonts on the fly, it may be true. But implementing that hairiness is time well-spent because it would allow the interface to be simple. And it's not like our display code doesn't look for fonts at redisplay time anyway, e.g. for Mule. FSF Emacs 21 does it like that, and so should we. All this was discussed several years ago, and there was consensus that the approach I advocated was a Good Thing. But I didn't have enough knowledge to implement it then, and I'm far from convinced that I could do it now. Also, I wasn't sure at the time if it's a good idea to introduce font properties as face properties, or whether we should use a "font" abstract type and allow the user to change its attributes. After having seen how it works in Emacs 21, I don't have a problem with "faces" equally treating font properties (size, weight, slant) and non-font ones (color, underline, antialiasing). Note that those functions were originally written by Per Abrahamsen for Custom, hence the custom- prefix. I simply didn't want to drop the prefix without also fixing them. I never did fix them, so the prefix stayed. Ouch. Have you tried talking to Mr. Handa and Stallman about it?