From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Newsgroups: gmane.emacs.bugs Subject: bug#15876: 24.3.50; Highly degraded performance between rev 114715 and 115006 Date: Sat, 14 Dec 2013 09:47:11 +0100 Message-ID: References: <867gcdiqji.fsf@somewhere.org> <86fvr09z55.fsf@somewhere.org> <83fvr01du4.fsf@gnu.org> <8638n0nj9p.fsf@somewhere.org> <86bo1eaelv.fsf@somewhere.org> <86r4a2vqbu.fsf@somewhere.org> <867gbqdisp.fsf@somewhere.org> <83haas5y88.fsf@gnu.org> <529C64C5.2040509@yandex.ru> <834n6r5edh.fsf@gnu.org> <529DAAED.9000504@yandex.ru> <83ob4y3wi5.fsf@gnu.org> <529DF416.7070807@yandex.ru> <83txeo33ls.fsf@gnu.org> <52A01D59.7030304@yandex.ru> <83lhzz2oal.fsf@gnu.org> <52A80BA8.3050403@yandex.ru> <83ob4nwdw0.fsf@gnu.org> <52A8A850.8040302@yandex.ru> <83k3fb6yvb.fsf@gnu.org> <837gb86aiq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1387010891 4081 80.91.229.3 (14 Dec 2013 08:48:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Dec 2013 08:48:11 +0000 (UTC) Cc: sva-news@mygooglest.com, 15876@debbugs.gnu.org, Dmitry Antipov To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 14 09:48:16 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VrktT-0002nI-2z for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Dec 2013 09:48:15 +0100 Original-Received: from localhost ([::1]:46513 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrktS-0000d0-Oe for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Dec 2013 03:48:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrktL-0000ck-Cz for bug-gnu-emacs@gnu.org; Sat, 14 Dec 2013 03:48:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrktG-0006I3-Nq for bug-gnu-emacs@gnu.org; Sat, 14 Dec 2013 03:48:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrktG-0006Hw-KJ for bug-gnu-emacs@gnu.org; Sat, 14 Dec 2013 03:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VrktG-00038D-1r for bug-gnu-emacs@gnu.org; Sat, 14 Dec 2013 03:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Dec 2013 08:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15876 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15876-submit@debbugs.gnu.org id=B15876.138701083811918 (code B ref 15876); Sat, 14 Dec 2013 08:48:01 +0000 Original-Received: (at 15876) by debbugs.gnu.org; 14 Dec 2013 08:47:18 +0000 Original-Received: from localhost ([127.0.0.1]:49191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VrksX-000369-Hn for submit@debbugs.gnu.org; Sat, 14 Dec 2013 03:47:17 -0500 Original-Received: from mailfe01.swip.net ([212.247.154.1]:35703 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VrksU-00035z-Cr for 15876@debbugs.gnu.org; Sat, 14 Dec 2013 03:47:15 -0500 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 463934897; Sat, 14 Dec 2013 09:47:12 +0100 In-Reply-To: <837gb86aiq.fsf@gnu.org> X-Mailer: Apple Mail (2.1822) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:81930 Archived-At: Hello. 13 dec 2013 kl. 16:22 skrev Eli Zaretskii : >> From: Jan Dj=E4rv >> Date: Wed, 11 Dec 2013 20:50:12 +0100 >> Cc: Dmitry Antipov , >> Kenichi Handa , >> 15876@debbugs.gnu.org, >> sva-news@mygooglest.com >>=20 >>> Jan, Ken'ichi, would you please comment on this? Are we losing >>> something by reusing already loaded fonts that support a given >>> character, as opposed to looking for the "best-match" font? >>=20 >> See discussion starting here = http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15138#29: >>=20 >> Kenichi Handa wrote: >>=20 >> I agree that this change improves font selection for >> symbols, but it's not good for many scripts for which just >> having a glyph is not enough. For instance, if the default >> font has Hindi glyphs but doesn't have the OTF features for >> Hindi script, we must find another proper font for Hindi. >>=20 >> How about modifying the current fontset mechanism as this? >>=20 >> (1) Allow t for FONT-SPEC of set-fontset-font to tell that >> the default font should be tried. >> (2) Modiyf the default fontset to include `t' as the >> font-spec for scripts/characters for which the default >> font is ok. >=20 > I see. But then why does the NS build still use a variant of that > approach? How is it exempt from what Handa-san wrote above? When this was done, NS only had nsfont.m where OTF features are ignored = (i.e. not implemented) except for script. Since then we have macfont.m but it does the same. There might be a case where the fontset contains two fonts that contains = the same glyph and that we by this code selects the non-preferred one. = But this is highly theoretical, I would like to see a real example where = this choice actually matter.=20 BTW it was said that the font backend should reject fonts that request = OTF features the backend does not support, but if the backend does that = it would end up with no font at all in many cases. There is not first a = font with OTF-features and then one fallback without OTF-feature in the = fontests. There is just the one with OTF-features. So Emacs has made a = second bad choice w.r.t. fonts. The first was using the X11 specific = logical font description as its internal format (still does even if X11 = says it is deprecated). Now we are tied to features specified by Open = Type. Jan D.