From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Kenichi Handa <handa@m17n.org>
Cc: cyd@stupidchicken.com, 2667@emacsbugs.donarmstrong.com
Subject: bug#2667: Still seeing inconsistent fonts
Date: Wed, 20 May 2009 15:43:00 -0400 [thread overview]
Message-ID: <jwvbppnefy5.fsf-monnier+emacsbugreports@gnu.org> (raw)
In-Reply-To: <E1M3UVt-0000EV-8d@etlken> (Kenichi Handa's message of "Mon, 11 May 2009 21:21:45 +0900")
> ∀ belongs to `symbol' script, but the xfont backend didn't
> support :script font property. That is because I was afraid
> that it made the font listing extremely slow (we must open
> all iso10646-1 fonts to check if it supports the requested
> characters). Actually my trial implementation of :script
> property supports took more than 1 minute to display HELLO
> file.
1 minute would be a problem, indeed.
> But, if we can use this heuristic:
> X fonts that have the same property values except for
> size related properties supports the same set of
> characters on all display. For example, all these fonts
> -adobe-courier-medium-r-normal--8-80-75-75-m-50-iso10646-1
> -adobe-courier-medium-r-normal--10-100-75-75-m-60-iso10646-1
> -adobe-courier-medium-r-normal--11-80-100-100-m-60-iso10646-1
> -adobe-courier-medium-r-normal--12-120-75-75-m-70-iso10646-1
> -adobe-courier-medium-r-normal--14-100-100-100-m-90-iso10646-1
> -adobe-courier-medium-r-normal--14-140-75-75-m-90-iso10646-1
> -adobe-courier-medium-r-normal--17-120-100-100-m-100-iso10646-1
> -adobe-courier-medium-r-normal--18-180-75-75-m-110-iso10646-1
> -adobe-courier-medium-r-normal--20-140-100-100-m-110-iso10646-1
> -adobe-courier-medium-r-normal--24-240-75-75-m-150-iso10646-1
> -adobe-courier-medium-r-normal--25-180-100-100-m-150-iso10646-1
> -adobe-courier-medium-r-normal--34-240-100-100-m-200-iso10646-1
> suports the same set of characters.
That assumption is obviously not guaranteed to hold, and I don't think
it really holds in practice, but it looks like an acceptable tradeoff,
since the cases where it doesn't hold shouldn't be too frequent.
> we can list fonts in a realistic time. Attached is the
> patch to try it. Could you please test it? As the change
> is not simple, I have not yet installed it.
I tried it on my smallest machine, and it seems fast enough: C-h h takes
approximately the same amount of time with it than it did under Emacs-22.3
(around 3s to 4s).
[ And this even though the Emacs-22.3 I used was built with -O2 and
such, whereas my Emacs-CVS is built with -O1, USE_LISP_UNION_TYPE,
ENABLE_CHECKING, and a few additional runtime tests. ]
The machines I used to test it were all running Debian testing, with
a fairly standard set of fonts. I don't know how it would behave for
people with many more fonts installed (most of which would presumably
be scalable and hence wouldn't be affected by the heuristic).
> -static Lisp_Object xfont_list_pattern P_ ((Lisp_Object, Display *, char *));
> +static int xfont_chars_supported P_ ((Lisp_Object, XFontStruct *,
> + struct charset *, struct charset *));
Please just use ANSI-style declarations rather than K&R in new code.
> + /* Two special cases to avoid opening rather big fonts. */
> + if (AREF (props, 2), Qja)
> + return Fcons (intern ("kana"), Fcons (intern ("han"), Qnil));
> + if (AREF (props, 2), Qko)
> + return Fcons (intern ("hangul"), Qnil);
You need EQ (..) around those two tests.
> + if (NILP (val))
> + script = Qnil;
> + else
> + script = XCDR (val);
Aka: script = CDR (val);
> + if (! repertory && NILP (xfont_scripts_cache))
> + {
> + Lisp_Object args[2];
> +
> + args[0] = QCtest;
> + args[1] = Qequal;
> + xfont_scripts_cache = Fmake_hash_table (2, args);
> + }
[...]
> @@ -996,6 +1173,8 @@
> void
> syms_of_xfont ()
> {
> + staticpro (&xfont_scripts_cache);
> + xfont_scripts_cache = Qnil;
> xfont_driver.type = Qx;
> register_font_driver (&xfont_driver, NULL);
> }
Why not just:
@@ -996,6 +1173,8 @@
void
syms_of_xfont ()
{
+ staticpro (&xfont_scripts_cache);
+ {
+ Lisp_Object args[2];
+ args[0] = QCtest;
+ args[1] = Qequal;
+ xfont_scripts_cache = Fmake_hash_table (2, args);
+ }
xfont_driver.type = Qx;
register_font_driver (&xfont_driver, NULL);
}
Stefan
next prev parent reply other threads:[~2009-05-20 19:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-08 3:41 bug#2667: Still seeing inconsistent fonts Chong Yidong
2009-05-08 19:58 ` Stefan Monnier
2009-05-11 12:21 ` Kenichi Handa
2009-05-11 15:56 ` Chong Yidong
2009-05-11 17:23 ` Stefan Monnier
2009-05-20 19:43 ` Stefan Monnier [this message]
2009-05-21 1:15 ` Kenichi Handa
2009-05-21 11:26 ` Kenichi Handa
2009-05-21 14:52 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2009-05-06 4:17 Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvbppnefy5.fsf-monnier+emacsbugreports@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=2667@emacsbugs.donarmstrong.com \
--cc=cyd@stupidchicken.com \
--cc=handa@m17n.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.