unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Kenichi Handa <handa@m17n.org>
To: Adrian Robert <adrian.b.robert@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Font back end font selection process
Date: Wed, 10 Jun 2009 20:04:33 +0900	[thread overview]
Message-ID: <E1MELbd-0001Fg-5T@etlken> (raw)
In-Reply-To: <E11A11F8-6256-4C97-A8FC-C8CA036E5002@gmail.com> (message from Adrian Robert on Wed, 10 Jun 2009 14:27:34 +0700)

In article <E11A11F8-6256-4C97-A8FC-C8CA036E5002@gmail.com>, Adrian Robert <adrian.b.robert@gmail.com> writes:

> Currently I'm just responding to the 'thai' in :otf with a Thai font  
> and it seems to work reasonably.  None of the otf functions are  
> implemented in the NS font driver and I'm unsure whether they can be,  
> but emacs' text layout must fall back to stacking automatically.  If  
> it would be better to refuse the :otf list() request at this stage  
> then adding the :script 'thai entry would be good.  The same goes for  
> other entries in the default fontset that use :otf in the same way.

If NS backend doesn't support OTF, it is better that `list'
method returns nil for that request.  So, I'll add

	    ,(font-spec :registry "iso10646-1" :script 'thai)

for Thai.  By the way, for lao, the default fontset already
has this entry after the entry specifying :otf property.

	  ,(font-spec :registry "iso10646-1" :script 'lao)

But, for the other scripts that request OTF, it is
impossible to implement a falling back method.  Simple
stacking doesn't work for them.

>>> Also, often I have noticed that when given a Chinese text file
>>> (encoded in UTF-8), the only request that comes through is :lang=ja.
> >
> > ?? For han script, the default fontset has this entry:
> >
> >      (han (nil . "GB2312.1980-0")
> > 	  (nil . "JISX0208*")
> > 	  (nil . "JISX0212*")
> > 	  (nil . "big5*")
> > ...
> > 	  ,(font-spec :registry "iso10646-1" :lang 'ja)
> > 	  ,(font-spec :registry "iso10646-1" :lang 'zh))

> Why not have

> (font-spec :registry "iso10646-1" :script 'han)

> before the lang entries?

Just to reduce the number of font-specs to try.  Here I
assume that a font that supports han script supports ja
and/or zh, and thus adding the entry of :script 'han is
redundant.

> > So, not only `ja', emacs should try `zh' if `ja' is not
> > available.  Doesn't it happen on Cocoa?

>>> How should the font driver know to return a kanji font instead of
>>> hiragana / katakana?.
> >
> > A font driver can return any 'ja' iso10646-1 fonts for this
> > request (even if the font support only kana):
> >
> > 	  ,(font-spec :registry "iso10646-1" :lang 'ja)
> >
> > If the first font in the returned list doesn't support a
> > specific han character, Emacs tries another font in the
> > returned list.

> Ah, OK so for purposes of list() the driver should treat :lang='ja as  
> "kana | kanji" instead of "kana & kanji", and treat kanji itself as  
> "kanji | hanzi".

Yes.

---
Kenichi Handa
handa@m17n.org




      reply	other threads:[~2009-06-10 11:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-07  3:54 Font back end font selection process Adrian Robert
2009-06-07  5:59 ` Stephen J. Turnbull
2009-06-08  2:49 ` Kenichi Handa
2009-06-10  7:27   ` Adrian Robert
2009-06-10 11:04     ` Kenichi Handa [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1MELbd-0001Fg-5T@etlken \
    --to=handa@m17n.org \
    --cc=adrian.b.robert@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).