Font slants

Font slants

[Chong Yidong]

When I do M-x customize-face RET default RET, the value of the `default'
face is given as a Lisp expression instead of the usual value menus.
This occurs because the slant of the face, as supplied by the new font
engine, is "roman".

I just committed the following patch to fix this.  However, I'm not sure
these are the only values of the slant parameter.  Does anyone know if
other possible values could be generated?


*** trunk/lisp/cus-face.el.~1.53.~	2008-03-14 13:42:17.000000000 -0400
--- trunk/lisp/cus-face.el	2008-04-05 10:42:06.000000000 -0400
***************
*** 120,126 ****
  	     :value normal		; default
  	     (const :tag "italic" italic)
  	     (const :tag "oblique" oblique)
! 	     (const :tag "normal" normal)))
  
      (:underline
       (choice :tag "Underline"
--- 120,127 ----
  	     :value normal		; default
  	     (const :tag "italic" italic)
  	     (const :tag "oblique" oblique)
! 	     (const :tag "normal" normal)
! 	     (const :tag "roman" roman)))
  
      (:underline
       (choice :tag "Underline"

Re: Font slants

[Stefan Monnier]

> When I do M-x customize-face RET default RET, the value of the `default'
> face is given as a Lisp expression instead of the usual value menus.
> This occurs because the slant of the face, as supplied by the new font
> engine, is "roman".

> I just committed the following patch to fix this.  However, I'm not sure
> these are the only values of the slant parameter.  Does anyone know if
> other possible values could be generated?

Why not use font-slant-table, font-weight-table, and font-swidth-table?


        Stefan

Re: Font slants

[Chong Yidong]

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

>> When I do M-x customize-face RET default RET, the value of the `default'
>> face is given as a Lisp expression instead of the usual value menus.
>> This occurs because the slant of the face, as supplied by the new font
>> engine, is "roman".
>
>> I just committed the following patch to fix this.  However, I'm not sure
>> these are the only values of the slant parameter.  Does anyone know if
>> other possible values could be generated?
>
> Why not use font-slant-table, font-weight-table, and font-swidth-table?

There is one problem with that: font-slant-table etc. are defcustoms,
while custom-face-attributes is a defconst.  So if you want to use them
to initialize custom-face-attributes, one possibility is to change
font-slant-table etc into defconsts and move them from faces.el into
cus-face.el.  Is it even useful to customize these alists?

On a related note, what's the story behind these settings?

(defcustom font-swidth-table
  '((ultracondensed . 50) (ultra-condensed . 51)
  ...

Why do we have a practically indistinguishable difference between
ultracondensed and ultra-condensed?  Similarly with several other
symbols in these alists.

Re: Font slants

[Stefan Monnier]

>>> When I do M-x customize-face RET default RET, the value of the `default'
>>> face is given as a Lisp expression instead of the usual value menus.
>>> This occurs because the slant of the face, as supplied by the new font
>>> engine, is "roman".
>> 
>>> I just committed the following patch to fix this.  However, I'm not sure
>>> these are the only values of the slant parameter.  Does anyone know if
>>> other possible values could be generated?
>> 
>> Why not use font-slant-table, font-weight-table, and font-swidth-table?

> There is one problem with that: font-slant-table etc. are defcustoms,
> while custom-face-attributes is a defconst.  So if you want to use them
> to initialize custom-face-attributes, one possibility is to change
> font-slant-table etc into defconsts and move them from faces.el into
> cus-face.el.  Is it even useful to customize these alists?

As long as cus-face is loaded after faces.el, that won't be
a serious problem, since it's probably not very useful to customize
those lists.  I wouldn't have made them customizable, but maybe Handa
had good reasons to do that?

> On a related note, what's the story behind these settings?

> (defcustom font-swidth-table
>   '((ultracondensed . 50) (ultra-condensed . 51)
>   ...

> Why do we have a practically indistinguishable difference between
> ultracondensed and ultra-condensed?  Similarly with several other
> symbols in these alists.

Try to change it (or check vc-annotate) to see why: it needs to be
bijective (ie. reversible).


        Stefan

Re: Font slants

[Chong Yidong]

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

>> On a related note, what's the story behind these settings?
>
>> (defcustom font-swidth-table
>>   '((ultracondensed . 50) (ultra-condensed . 51)
>>   ...
>
>> Why do we have a practically indistinguishable difference between
>> ultracondensed and ultra-condensed?  Similarly with several other
>> symbols in these alists.
>
> Try to change it (or check vc-annotate) to see why: it needs to be
> bijective (ie. reversible).

Would it be possible for Emacs to change all occurrences of
`ultracondensed' to `ultra-condensed' internally?  That would also
eliminate the annoyance of having a value menu within Customize that
gives separate choices for `ultracondensed' and `ultra-condensed'.

Re: Font slants

[Chong Yidong]

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

>> one possibility is to change font-slant-table etc into defconsts and
>> move them from faces.el into cus-face.el.  Is it even useful to
>> customize these alists?
>
> ...
>
>> (defcustom font-swidth-table
>>   '((ultracondensed . 50) (ultra-condensed . 51)
>>   ...
>
>> Why do we have a practically indistinguishable difference between
>> ultracondensed and ultra-condensed?  Similarly with several other
>> symbols in these alists.
>
> Try to change it (or check vc-annotate) to see why: it needs to be
> bijective (ie. reversible).

This is another reason why these alists should be constants instead of
customizable, IMO.  As defcustoms, it would seem reasonable for the user
to provide arbitrary values for these alists.

Re: Font slants

[Stefan Monnier]

>>> On a related note, what's the story behind these settings?
>> 
>>> (defcustom font-swidth-table
>>> '((ultracondensed . 50) (ultra-condensed . 51)
>>> ...
>> 
>>> Why do we have a practically indistinguishable difference between
>>> ultracondensed and ultra-condensed?  Similarly with several other
>>> symbols in these alists.
>> 
>> Try to change it (or check vc-annotate) to see why: it needs to be
>> bijective (ie. reversible).

> Would it be possible for Emacs to change all occurrences of
> `ultracondensed' to `ultra-condensed' internally?  That would also
> eliminate the annoyance of having a value menu within Customize that
> gives separate choices for `ultracondensed' and `ultra-condensed'.

What we could do is to keep (in the new internal vector format) the
original names along side the numbers.  This way the conversion
back can recover the original name without forcing the numbers to
be unique.

What do you think, Handa san?


        Stefan

Re: Font slants

[Stefan Monnier]

>>> one possibility is to change font-slant-table etc into defconsts and
>>> move them from faces.el into cus-face.el.  Is it even useful to
>>> customize these alists?
>> 
>> ...
>> 
>>> (defcustom font-swidth-table
>>> '((ultracondensed . 50) (ultra-condensed . 51)
>>> ...
>> 
>>> Why do we have a practically indistinguishable difference between
>>> ultracondensed and ultra-condensed?  Similarly with several other
>>> symbols in these alists.
>> 
>> Try to change it (or check vc-annotate) to see why: it needs to be
>> bijective (ie. reversible).

> This is another reason why these alists should be constants instead of
> customizable, IMO.  As defcustoms, it would seem reasonable for the user
> to provide arbitrary values for these alists.

That's OK: the bijectivity is enforced, so if the user tries to change
it wrong, she'll immediately get an error,


        Stefan

Re: Font slants

[Kenichi Handa]

In article <jwv8wzrvjx0.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> What we could do is to keep (in the new internal vector format) the
> original names along side the numbers.  This way the conversion
> back can recover the original name without forcing the numbers to
> be unique.

> What do you think, Handa san?

In the version I'm working on locally, I cancelled your
change for assuring bijection of numeric and symbol style
values.  And, to recover the original X fontname, I changed
the xfont driver to store proper information in the slot of
FONT_EXTRA_INDEX in each font-entity.

enum font_property_index
  {
[...]
    /* In a font-spec, the value is an alist of extra information of a
       font such as name, OpenType features, and language coverage.
       In addition, in a font-entity, the value may contain a pair
       (font-entity . INFO) where INFO is an extra infomation to
       identify a font (font-driver dependent).  */
    FONT_EXTRA_INDEX,		/* alist		alist */
[...]

That way, we can treat, for instance, font-weight-table as a
table that provides symbolic representation of numeric
weight values just for user convenience.  The font selection
routine and each font-backend always work on numeric values.
So, if a user specifies the weight `light' and it's mapped
to 50 in the table, each font-backend finds a font of weight
50 (not `light').  And, as names in font-weight-table are
just for user convenience, we can delete, for instance, one
of extra-bold and extrabold.

The numeric values must have constant meaning; for instance,
100 is normal, 0 is the mininum weight/slant/width, 255 is
the maximum weight/slant/width.  Each font-backend must
convert information of font's weight/slant/width to those
values.  The conversion algorithm is upto font-backend.

For instance, in font-weight-table, all of medium, normal,
regular are mapped to 100 (as the pre-unicode-merge emacs).
If X font-backend finds two fonts whose XLFD-WEIGHT are
`regular' and `medium' and thinks that their weight must be
treated as the same `normal' value, it maps both values to
100.  If it thinks they are different, `regular' may be
mapped to 95.  In any case, it keeps the information of the
original weight name in FONT_EXTRA_INDEX slot.

I need some more time to test the current code.  When I
think it gets stable, I'll make a new branch and commit the
code in it.

---
Kenichi Handa
handa@ni.aist.go.jp