Re: Font slants

[Kenichi Handa]

In article <address@hidden>, Stefan Monnier <address@hidden> 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
address@hidden