Font backend font.c: "name" vs "family"

Font backend font.c: "name" vs "family"

[Adrian Robert]

Hi,

The function: font_open_by_name() gets called by font_load_for_face()
with name=face->lface[LFACE_FONT_INDEX].  However, from 'spec =
Ffont_spec (2, args);', it eventually goes to font_parse_fcname()
which puts the information into the font_spec's 'family' slot.  But
font 'family' and font 'name' are two different things.  E.g.,
"Courier" could be the family, "Courier-Bold" (or "CourierBold") the
'name'.

For example,

nsfont: list for fontspec:
    [ns nil Comic\ Sans\ MS nil iso10646-1 101 101 nil nil ((:name .
"Comic Sans MS"))]
    Returning 1 entities.
nsfont: open size 12 of fontentity:
    [ns apple Comic_Sans_MS Regular iso10646-1 99 100 100 0 nil nil nil]

 ... The returned font has name "ComicSansMS" (no spaces), and gets
used in some faces; later:

nsfont: list for fontspec:
    [ns nil ComicSansMS nil iso10646-1 101 101 nil nil ((:name .
"ComicSansMS"))]

The family "ComicSansMS" (no spaces) does not exist.  Is the driver
supposed to pick up on the '(:name . "ComicSansMS")' part and ignore
the family?  Or should load_font_for_face() or font_open_by_name() be
changed?  It seems strange that loading by font name instead of by
font spec should even be attempted in the font backend.

Finally, a possibly related question: what are the uniqueness rules
for creating new font-entities and opening fonts?  I am seeing
driver->open() called multiple times for font specs with the same
contents (but might be different lisp objects).  Should the driver (a)
never create more than one instance of a given font entity, or (b)
never create more than one 'struct font' object for a given system
font, even if multiple entities exist that specify it?

thanks,
Adrian

Re: Font backend font.c: "name" vs "family"

[Kenichi Handa]

As I wrote, I'm not working of the overhaul of font related
code.  One of the change is to have font-spec in
lface[LFACE_FONT_INDEX] which will solve the problem you
wrote below.

Anyway, could you please give me some time to fix the
current labyrinth caused by the coexistence of legacy and
font-backend codes.

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


In article <55f7df060803072248w9f554afvae9c2f0ec783bfa5@mail.gmail.com>, "Adrian Robert" <adrian.b.robert@gmail.com> writes:

> Hi,
> The function: font_open_by_name() gets called by font_load_for_face()
> with name=face->lface[LFACE_FONT_INDEX].  However, from 'spec =
> Ffont_spec (2, args);', it eventually goes to font_parse_fcname()
> which puts the information into the font_spec's 'family' slot.  But
> font 'family' and font 'name' are two different things.  E.g.,
> "Courier" could be the family, "Courier-Bold" (or "CourierBold") the
> 'name'.

> For example,

> nsfont: list for fontspec:
>     [ns nil Comic\ Sans\ MS nil iso10646-1 101 101 nil nil ((:name .
> "Comic Sans MS"))]
>     Returning 1 entities.
> nsfont: open size 12 of fontentity:
>     [ns apple Comic_Sans_MS Regular iso10646-1 99 100 100 0 nil nil nil]

>  ... The returned font has name "ComicSansMS" (no spaces), and gets
> used in some faces; later:

> nsfont: list for fontspec:
>     [ns nil ComicSansMS nil iso10646-1 101 101 nil nil ((:name .
> "ComicSansMS"))]

> The family "ComicSansMS" (no spaces) does not exist.  Is the driver
> supposed to pick up on the '(:name . "ComicSansMS")' part and ignore
> the family?  Or should load_font_for_face() or font_open_by_name() be
> changed?  It seems strange that loading by font name instead of by
> font spec should even be attempted in the font backend.

> Finally, a possibly related question: what are the uniqueness rules
> for creating new font-entities and opening fonts?  I am seeing
> driver->open() called multiple times for font specs with the same
> contents (but might be different lisp objects).  Should the driver (a)
> never create more than one instance of a given font entity, or (b)
> never create more than one 'struct font' object for a given system
> font, even if multiple entities exist that specify it?

> thanks,
> Adrian