emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kenichi Handa
Subject: Re: Font backend font.c: "name" vs "family"
Date: Mon, 10 Mar 2008 10:04:55 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

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
address@hidden


In article <address@hidden>, "Adrian Robert" <address@hidden> 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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]