[Top][All Lists]
[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