From unknown Sat Jun 14 03:54:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17973: Thin space not thin at all Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Jul 2014 20:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 17973 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 17973@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14048506969546 (code B ref -1); Tue, 08 Jul 2014 20:19:02 +0000 Received: (at submit) by debbugs.gnu.org; 8 Jul 2014 20:18:16 +0000 Received: from localhost ([127.0.0.1]:47325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X4bqB-0002Tu-Gs for submit@debbugs.gnu.org; Tue, 08 Jul 2014 16:18:15 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47696) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X4bq9-0002Tf-UX for submit@debbugs.gnu.org; Tue, 08 Jul 2014 16:18:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X4bpu-0005KT-MF for submit@debbugs.gnu.org; Tue, 08 Jul 2014 16:18:08 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:45869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4bpu-0005KP-Jh for submit@debbugs.gnu.org; Tue, 08 Jul 2014 16:17:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4ZoB-0005nS-W4 for bug-gnu-emacs@gnu.org; Tue, 08 Jul 2014 14:08:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X4Zo3-0007YE-2X for bug-gnu-emacs@gnu.org; Tue, 08 Jul 2014 14:08:03 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:7059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4Zo2-0007YA-UV for bug-gnu-emacs@gnu.org; Tue, 08 Jul 2014 14:07:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoIAIDvNVNLd+D9/2dsb2JhbABZgwYBg0mpfwGPA4cwgSEXdIMCXxMhARwNiDCff7IaF48XhCIEqRmBaoNMIQ X-IPAS-Result: AjoIAIDvNVNLd+D9/2dsb2JhbABZgwYBg0mpfwGPA4cwgSEXdIMCXxMhARwNiDCff7IaF48XhCIEqRmBaoNMIQ X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="76888027" Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 08 Jul 2014 14:07:54 -0400 Received: by pastel.home (Postfix, from userid 20848) id E55FD60337; Tue, 8 Jul 2014 14:07:53 -0400 (EDT) From: Stefan Monnier Date: Tue, 08 Jul 2014 14:07:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) Package: Emacs Version: 24.3.92 Severity: important % emacs-24/src/emacs -Q -fn '-misc-fixed-*-r-semicondensed--13-*-*-*-*-*= -*' M-< C-f C-x SPC At this point I should see a thin space before the cursor (highlighted with the region face). Instead I see a full space. C-u C-x =3D indeed shows that there's an overlay at point with an after-string of: #(" " 0 1 (face (region (:height 0.2)))) Now admittedly, ":height 0.2" does not specify a width, but Emacs should be able to find a font that's about 2=BD pixels high but not 6 pixels wide. This is related to bug#16403, in that this is probably a long-standing bug, but the new rectangular region makes it more visible. Maybe it's actually the same bug as bug#9787 as well, which is also more visible since *VC-log* uses such a "thin line" to separate the header from the body. Stefan From unknown Sat Jun 14 03:54:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17973: Thin space not thin at all References: Resent-From: handa@gnu.org (K. Handa) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jul 2014 15:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17973 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 17973@debbugs.gnu.org Received: via spool by 17973-submit@debbugs.gnu.org id=B17973.1404919968872 (code B ref 17973); Wed, 09 Jul 2014 15:33:02 +0000 Received: (at 17973) by debbugs.gnu.org; 9 Jul 2014 15:32:48 +0000 Received: from localhost ([127.0.0.1]:47969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X4trT-0000Dz-AQ for submit@debbugs.gnu.org; Wed, 09 Jul 2014 11:32:47 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:47702 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X4trQ-0000Dq-8L for 17973@debbugs.gnu.org; Wed, 09 Jul 2014 11:32:45 -0400 Received: from fl1-119-240-91-99.iba.mesh.ad.jp ([119.240.91.99]:48698 helo=wanchai) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1X4trP-00033e-BF; Wed, 09 Jul 2014 11:32:43 -0400 Received: from handa by wanchai with local (Exim 4.80) (envelope-from ) id 1X4trF-0007kN-V6; Thu, 10 Jul 2014 00:32:34 +0900 From: handa@gnu.org (K. Handa) In-Reply-To: (message from Stefan Monnier on Tue, 08 Jul 2014 14:07:53 -0400) Date: Thu, 10 Jul 2014 00:32:33 +0900 Message-ID: <87d2deeeem.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.7 (-----) In article , Stefan Monnier writes: > % emacs-24/src/emacs -Q -fn '-misc-fixed-*-r-semicondensed--13-*-*-*-*= -*-*' > M-< C-f C-x SPC > At this point I should see a thin space before the cursor (highlighted > with the region face). Instead I see a full space. > C-u C-x =3D > indeed shows that there's an overlay at point with an after-string of: > #(" " 0 1 (face (region (:height 0.2)))) > Now admittedly, ":height 0.2" does not specify a width, but Emacs should > be able to find a font that's about 2=BD pixels high but not > 6 pixels wide. > This is related to bug#16403, in that this is probably a long-standing > bug, but the new rectangular region makes it more visible. > Maybe it's actually the same bug as bug#9787 as well, which is also more > visible since *VC-log* uses such a "thin line" to separate the header > from the body. Yes, I agree that they are all the same bug. As far as I know, the problem is with the mechanism of face attribute merging. When the control reaches the font selection function font_find_for_lface, font related attributes (family, foundry, weight, ..., height, ...) are already merged. As font_find_for_lface doesn't know which attribute to respect more (except for what specified in face-font-selection-order), it at first tries to get a list of fonts whose family, foundry, registry, adstyle are the same as merged attributes, and selects a font most close to the specified height. To fix this problem, perhaps we must propagate the information about how font related attributes are merged; i.e. which one comes from the specific face directly and which one is inherited from the other faces (including the default face). It's not a trivial work. --- Kenichi Handa handa@gnu.org From unknown Sat Jun 14 03:54:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17973: Thin space not thin at all Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jul 2014 19:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17973 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: handa@gnu.org (K. Handa) Cc: 17973@debbugs.gnu.org Received: via spool by 17973-submit@debbugs.gnu.org id=B17973.140493371327878 (code B ref 17973); Wed, 09 Jul 2014 19:22:01 +0000 Received: (at 17973) by debbugs.gnu.org; 9 Jul 2014 19:21:53 +0000 Received: from localhost ([127.0.0.1]:48094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X4xR6-0007FT-93 for submit@debbugs.gnu.org; Wed, 09 Jul 2014 15:21:52 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:35471) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X4xR0-0007FF-7k; Wed, 09 Jul 2014 15:21:46 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 1E07D84DD2; Wed, 9 Jul 2014 15:21:40 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 84F441E5B74; Wed, 9 Jul 2014 15:21:16 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 65BFDB4167; Wed, 9 Jul 2014 15:21:16 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87d2deeeem.fsf@gnu.org> Date: Wed, 09 Jul 2014 15:21:16 -0400 In-Reply-To: <87d2deeeem.fsf@gnu.org> (K. Handa's message of "Thu, 10 Jul 2014 00:32:33 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) forcemerge 9787 17973 thanks > Yes, I agree that they are all the same bug. As far as I > know, the problem is with the mechanism of face attribute > merging. When the control reaches the font selection > function font_find_for_lface, font related attributes > (family, foundry, weight, ..., height, ...) are already > merged. As font_find_for_lface doesn't know which attribute > to respect more (except for what specified in > face-font-selection-order), it at first tries to get a list > of fonts whose family, foundry, registry, adstyle are the > same as merged attributes, and selects a font most close to > the specified height. So, IIUC you're saying that when we get to selecting a font, we have specifications such as family =3D fixed foundry =3D misc height =3D 2=BD pixels and we end up choosing the 13pixel-high font because it's the only one that matches "misc-fixed"? I do have a 6pixel-high misc-fixed font (tho not semicondensed), so it seems like it's not the whole explanation. Or is the "13pixel high" specification kept somewhere (elsewhere than in the "height", obviously)? I'm beginning to sense that the "13pixel high" specification is indeed kept elsewhere, and it is kept so as to avoid other problems I've had in the past, where the 13pixel spec was turned into a height spec and that this height spec was then used to look for a font and it occasionally found *another* font with the same height in points but not in pixels. Is that right? OTOH, doing a M-x customize-face REt default RET, then setting family to `fixed' and foundry to `misc', and then playing with `height' is pretty scary: height=3D2000 gives me a 9pixel-high font (!) whereas setting it to 200 gives a more reasonable 20pixel-high font. Stefan From unknown Sat Jun 14 03:54:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17973: Thin space not thin at all References: Resent-From: handa@gnu.org (K. Handa) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jul 2014 14:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17973 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 17973@debbugs.gnu.org Received: via spool by 17973-submit@debbugs.gnu.org id=B17973.140500253716891 (code B ref 17973); Thu, 10 Jul 2014 14:29:01 +0000 Received: (at 17973) by debbugs.gnu.org; 10 Jul 2014 14:28:57 +0000 Received: from localhost ([127.0.0.1]:52273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X5FLB-0004OI-GD for submit@debbugs.gnu.org; Thu, 10 Jul 2014 10:28:57 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:45192 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X5FL6-0004O5-5V for 17973@debbugs.gnu.org; Thu, 10 Jul 2014 10:28:52 -0400 Received: from fl1-119-240-91-99.iba.mesh.ad.jp ([119.240.91.99]:48026 helo=wanchai) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1X5FL5-00048Q-AT; Thu, 10 Jul 2014 10:28:47 -0400 Received: from handa by wanchai with local (Exim 4.80) (envelope-from ) id 1X5FL1-0000rd-3l; Thu, 10 Jul 2014 23:28:43 +0900 From: handa@gnu.org (K. Handa) In-Reply-To: (message from Stefan Monnier on Wed, 09 Jul 2014 15:21:16 -0400) Date: Thu, 10 Jul 2014 23:28:42 +0900 Message-ID: <87a98he19h.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.7 (-----) In article , Stefan Monnier writes: > So, IIUC you're saying that when we get to selecting a font, we have > specifications such as > family =3D fixed > foundry =3D misc > height =3D 2=BD pixels > and we end up choosing the 13pixel-high font because it's the only one > that matches "misc-fixed"? Yes. At least that is what I observed in my environment. > I do have a 6pixel-high misc-fixed font Hmmm, then your environment is different from mine. > (tho not semicondensed), so it seems like it's not the > whole explanation. Do you customize face-font-selection-order? It's default value is (:width :height :weight :slant), which means that the function font_select_entity (called from font_find_for_lface) selects a font whose :width is semicondensed even if that font has very different height from what specified. > Or is the "13pixel high" specification kept somewhere (elsewhere than in > the "height", obviously)? I don't think so. > OTOH, doing a M-x customize-face REt default RET, then setting family to > `fixed' and foundry to `misc', and then playing with `height' is pretty > scary: height=3D2000 gives me a 9pixel-high font (!) whereas setting it to > 200 gives a more reasonable 20pixel-high font. Ummm, then perhaps font_score has a bug. As far as I remember, that function treats such a very big font size specially. I'll check the code. --- Kenichi Handa handa@gnu.org From unknown Sat Jun 14 03:54:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17973: Thin space not thin at all Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jul 2014 16:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17973 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: handa@gnu.org (K. Handa) Cc: 17973@debbugs.gnu.org Received: via spool by 17973-submit@debbugs.gnu.org id=B17973.1405010257640 (code B ref 17973); Thu, 10 Jul 2014 16:38:02 +0000 Received: (at 17973) by debbugs.gnu.org; 10 Jul 2014 16:37:37 +0000 Received: from localhost ([127.0.0.1]:52381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X5HLk-0000AD-4h for submit@debbugs.gnu.org; Thu, 10 Jul 2014 12:37:36 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:35619) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X5HLh-0000A0-Q0 for 17973@debbugs.gnu.org; Thu, 10 Jul 2014 12:37:34 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgEnLyMFCws0EhQYDVKHVgjSGReOegeEOASUYpQ3gWqDTCE X-IPAS-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgEnLyMFCws0EhQYDVKHVgjSGReOegeEOASUYpQ3gWqDTCE X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="77079927" Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 10 Jul 2014 12:37:27 -0400 Received: by pastel.home (Postfix, from userid 20848) id 4E584604AF; Thu, 10 Jul 2014 12:37:27 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87a98he19h.fsf@gnu.org> Date: Thu, 10 Jul 2014 12:37:27 -0400 In-Reply-To: <87a98he19h.fsf@gnu.org> (K. Handa's message of "Thu, 10 Jul 2014 23:28:42 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Do you customize face-font-selection-order? It's default > value is (:width :height :weight :slant), which means that > the function font_select_entity (called from > font_find_for_lface) selects a font whose :width is > semicondensed even if that font has very different height > from what specified. Ah, right, that explains it. Hmm... I guess ideally, Emacs should consider a height that's "too far" from the requested one as a failure and then try again ignoring some of the specs. The patch below expresses the first part, but it looks like the second part doesn't exit: Emacs just doesn't find any font to use for the "thin space" of C-x SPC and indicates it to me with one of those big squares that say "0020", which is a lot more intrusive than the problem I'm trying to fix. And (setq scalable-fonts-allowed t) doesn't help either. Maybe a solution/workaround for the specific problem of such "thin lines" is to replace the (:height 0.2) face with another face that specifies "any family". If I use (:height 0.2 :family "Monospace"), indeed, the problem disappears. Is there a better "any family" than "Monospace"? Stefan PS: The patch below also happens to give me assertion failures fontset.c:897: Emacs fatal error: assertion failed: fontset_id_valid_p (face->fontset) I haven't investigated any further, tho (and the line number might be off because of local changes anyway). === modified file 'src/font.c' --- src/font.c 2014-07-09 13:45:53 +0000 +++ src/font.c 2014-07-10 16:11:04 +0000 @@ -2165,10 +2165,14 @@ lowest bit is set if the DPI is different. */ EMACS_INT diff; EMACS_INT pixel_size = XINT (spec_prop[FONT_SIZE_INDEX]); + EMACS_INT entity_size = XINT (AREF (entity, FONT_SIZE_INDEX)); if (CONSP (Vface_font_rescale_alist)) pixel_size *= font_rescale_ratio (entity); - diff = eabs (pixel_size - XINT (AREF (entity, FONT_SIZE_INDEX))) << 1; + if (pixel_size * 2 < entity_size || entity_size * 2 < pixel_size) + /* This size is wrong by more than a factor 2: reject it! */ + return 0xFFFFFFFF; + diff = eabs (pixel_size - entity_size) << 1; if (! NILP (spec_prop[FONT_DPI_INDEX]) && ! EQ (spec_prop[FONT_DPI_INDEX], AREF (entity, FONT_DPI_INDEX))) diff |= 1; From unknown Sat Jun 14 03:54:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17973: Thin space not thin at all References: Resent-From: handa@gnu.org (K. Handa) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jul 2014 15:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17973 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 17973@debbugs.gnu.org Received: via spool by 17973-submit@debbugs.gnu.org id=B17973.140526439619219 (code B ref 17973); Sun, 13 Jul 2014 15:14:02 +0000 Received: (at 17973) by debbugs.gnu.org; 13 Jul 2014 15:13:16 +0000 Received: from localhost ([127.0.0.1]:53823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6LSm-0004zu-3C for submit@debbugs.gnu.org; Sun, 13 Jul 2014 11:13:16 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:48752 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6LSj-0004zm-Oy for 17973@debbugs.gnu.org; Sun, 13 Jul 2014 11:13:14 -0400 Received: from fl1-119-240-91-99.iba.mesh.ad.jp ([119.240.91.99]:46320 helo=wanchai) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1X6LSi-0003Ku-Vt; Sun, 13 Jul 2014 11:13:13 -0400 Received: from handa by wanchai with local (Exim 4.80) (envelope-from ) id 1X6LSU-0001Cr-Qz; Mon, 14 Jul 2014 00:12:58 +0900 From: handa@gnu.org (K. Handa) In-Reply-To: (message from Stefan Monnier on Thu, 10 Jul 2014 12:37:27 -0400) Date: Mon, 14 Jul 2014 00:12:58 +0900 Message-ID: <874myle1hh.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) In article , Stefan Monnier writes: > Ah, right, that explains it. Hmm... I guess ideally, Emacs should > consider a height that's "too far" from the requested one as a failure > and then try again ignoring some of the specs. font_find_for_lface has a code to do that, but I found that it is called with full font properties in SPEC. This function does not try a font of different properties (foundry, family, registry, adstyle). > The patch below expresses the first part, but it looks like the second > part doesn't exit: Emacs just doesn't find any font to use for the "thin > space" of C-x SPC and indicates it to me with one of those big squares > that say "0020", which is a lot more intrusive than the problem I'm > trying to fix. In addition to your patch, could you please try the following patch? === modified file 'src/xfaces.c' --- src/xfaces.c 2014-07-07 23:33:05 +0000 +++ src/xfaces.c 2014-07-13 15:09:21 +0000 @@ -5547,7 +5547,7 @@ } if (! FONT_OBJECT_P (attrs[LFACE_FONT_INDEX])) attrs[LFACE_FONT_INDEX] - = font_load_for_lface (f, attrs, attrs[LFACE_FONT_INDEX]); + = font_load_for_lface (f, attrs, Ffont_spec (0, NULL)); if (FONT_OBJECT_P (attrs[LFACE_FONT_INDEX])) { face->font = XFONT_OBJECT (attrs[LFACE_FONT_INDEX]); > PS: The patch below also happens to give me assertion failures > fontset.c:897: Emacs fatal error: assertion failed: fontset_id_valid_p (face->fontset) > I haven't investigated any further, tho (and the line number might be off > because of local changes anyway). I didn't face with that error, but I'll keep on checking the code. --- Kenichi Handa handa@gnu.org From unknown Sat Jun 14 03:54:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17973: Thin space not thin at all Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Jul 2014 06:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17973 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: handa@gnu.org (K. Handa) Cc: 17973@debbugs.gnu.org Received: via spool by 17973-submit@debbugs.gnu.org id=B17973.140575042420632 (code B ref 17973); Sat, 19 Jul 2014 06:14:02 +0000 Received: (at 17973) by debbugs.gnu.org; 19 Jul 2014 06:13:44 +0000 Received: from localhost ([127.0.0.1]:58862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X8Ntv-0005Mg-9I for submit@debbugs.gnu.org; Sat, 19 Jul 2014 02:13:43 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:13466) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X8Ntt-0005MS-BL for 17973@debbugs.gnu.org; Sat, 19 Jul 2014 02:13:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNiCgI0hkXjnoHhDgBA6kZgWqDTCE X-IPAS-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNiCgI0hkXjnoHhDgBA6kZgWqDTCE X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="78000676" Received: from 75-119-224-253.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2014 02:13:35 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 93859AE661; Sat, 19 Jul 2014 02:13:35 -0400 (EDT) From: Stefan Monnier Message-ID: References: <874myle1hh.fsf@gnu.org> Date: Sat, 19 Jul 2014 02:13:35 -0400 In-Reply-To: <874myle1hh.fsf@gnu.org> (K. Handa's message of "Mon, 14 Jul 2014 00:12:58 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > In addition to your patch, could you please try the following patch? > === modified file 'src/xfaces.c' > --- src/xfaces.c 2014-07-07 23:33:05 +0000 > +++ src/xfaces.c 2014-07-13 15:09:21 +0000 > @@ -5547,7 +5547,7 @@ > } > if (! FONT_OBJECT_P (attrs[LFACE_FONT_INDEX])) > attrs[LFACE_FONT_INDEX] > - = font_load_for_lface (f, attrs, attrs[LFACE_FONT_INDEX]); > + = font_load_for_lface (f, attrs, Ffont_spec (0, NULL)); > if (FONT_OBJECT_P (attrs[LFACE_FONT_INDEX])) > { Looks like this works, indeed! Yay! Stefan From unknown Sat Jun 14 03:54:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17973: Thin space not thin at all References: Resent-From: handa@gnu.org (K. Handa) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Jul 2014 15:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17973 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 17973@debbugs.gnu.org Received: via spool by 17973-submit@debbugs.gnu.org id=B17973.140578547818238 (code B ref 17973); Sat, 19 Jul 2014 15:58:01 +0000 Received: (at 17973) by debbugs.gnu.org; 19 Jul 2014 15:57:58 +0000 Received: from localhost ([127.0.0.1]:59578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X8X1J-0004k6-VA for submit@debbugs.gnu.org; Sat, 19 Jul 2014 11:57:58 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:60785 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X8X1I-0004jy-8A for 17973@debbugs.gnu.org; Sat, 19 Jul 2014 11:57:56 -0400 Received: from fl1-119-240-91-99.iba.mesh.ad.jp ([119.240.91.99]:37780 helo=wanchai) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1X8X1H-0005WB-5J; Sat, 19 Jul 2014 11:57:55 -0400 Received: from handa by wanchai with local (Exim 4.80) (envelope-from ) id 1X8X19-0003TK-Aw; Sun, 20 Jul 2014 00:57:47 +0900 From: handa@gnu.org (K. Handa) In-Reply-To: (message from Stefan Monnier on Sat, 19 Jul 2014 02:13:35 -0400) Date: Sun, 20 Jul 2014 00:57:47 +0900 Message-ID: <87wqb9uyro.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) In article , Stefan Monnier writes: > > In addition to your patch, could you please try the following patch? [...] > Looks like this works, indeed! Yay! I've just committed both changes to the trunk. But, in this part: if (pixel_size * 2 < entity_size || entity_size * 2 < pixel_size) /* This size is wrong by more than a factor 2: reject it! */ return 0xFFFFFFFF; the factor 2 is too arbitrary. Don't we need some user-controllable variable here? --- Kenichi Handa handa@gnu.org From unknown Sat Jun 14 03:54:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17973: Thin space not thin at all Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Jul 2014 17:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17973 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: handa@gnu.org (K. Handa) Cc: 17973@debbugs.gnu.org Received: via spool by 17973-submit@debbugs.gnu.org id=B17973.140579102026826 (code B ref 17973); Sat, 19 Jul 2014 17:31:02 +0000 Received: (at 17973) by debbugs.gnu.org; 19 Jul 2014 17:30:20 +0000 Received: from localhost ([127.0.0.1]:59632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X8YSh-0006ya-Ai for submit@debbugs.gnu.org; Sat, 19 Jul 2014 13:30:20 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:60672) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X8YSf-0006yN-9o for 17973@debbugs.gnu.org; Sat, 19 Jul 2014 13:30:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDYgoCNIZF456B4Q4BKkZgWqDTCE X-IPAS-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDYgoCNIZF456B4Q4BKkZgWqDTCE X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="78110820" Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2014 13:30:10 -0400 Received: by pastel.home (Postfix, from userid 20848) id 8831B60BEC; Sat, 19 Jul 2014 13:30:10 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87wqb9uyro.fsf@gnu.org> Date: Sat, 19 Jul 2014 13:30:10 -0400 In-Reply-To: <87wqb9uyro.fsf@gnu.org> (K. Handa's message of "Sun, 20 Jul 2014 00:57:47 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> > In addition to your patch, could you please try the following patch? > [...] >> Looks like this works, indeed! Yay! > I've just committed both changes to the trunk. But, in this part: > if (pixel_size * 2 < entity_size || entity_size * 2 < pixel_size) > /* This size is wrong by more than a factor 2: reject it! */ > return 0xFFFFFFFF; > the factor 2 is too arbitrary. Don't we need some > user-controllable variable here? It's indeed arbitrary. It might deserve a CPP macro, but I'd rather not add a configurable variable until there's a clear need for it. 2 seems to be large enough that it is hard to imagine a case where it will rule out a font that the user would want to use, yet it's small enough that it should solve the problem in the vast majority of cases where it matters. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 13 23:39:54 2015 Received: (at control) by debbugs.gnu.org; 14 Feb 2015 04:39:54 +0000 Received: from localhost ([127.0.0.1]:42532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YMUWI-0003Uk-Aw for submit@debbugs.gnu.org; Fri, 13 Feb 2015 23:39:54 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:56369) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YMUWG-0003Ub-5I for control@debbugs.gnu.org; Fri, 13 Feb 2015 23:39:52 -0500 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t1E4dnqG009882 for ; Fri, 13 Feb 2015 23:39:49 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 7AC9BAE0CA; Fri, 13 Feb 2015 23:39:49 -0500 (EST) From: Stefan Monnier To: control@debbugs.gnu.org Subject: Re: bug#18413: Inline part displayed in the middle of its button Message-ID: References: Date: Fri, 13 Feb 2015 23:39:49 -0500 In-Reply-To: (Stefan Monnier's message of "Fri, 31 Oct 2014 10:26:33 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV5216=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5216> : inlines <2181> : streams <1389914> : uri <1854855> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) close 4942 close 5037 close 6713 close 9787 close 12823 close 6333 thanks