From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Display of undisplayable characters: \U01F3A8 instead of diamond Date: Fri, 2 Sep 2022 15:38:32 +0000 Message-ID: References: <83y1v7w6eu.fsf@gnu.org> <2f302d1c3966849477b3@heytings.org> <2f302d1c3933a5091b66@heytings.org> <2f302d1c39d838732c24@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17830"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , eliz@gnu.org, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 02 17:40:03 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oU8m2-0004SE-Fq for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Sep 2022 17:40:02 +0200 Original-Received: from localhost ([::1]:33616 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oU8m0-0003pv-Tz for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Sep 2022 11:40:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46410) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU8kh-00039Y-Uf for emacs-devel@gnu.org; Fri, 02 Sep 2022 11:38:42 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:28837) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU8kd-0002xd-TY for emacs-devel@gnu.org; Fri, 02 Sep 2022 11:38:38 -0400 Original-Received: (qmail 55305 invoked by uid 3782); 2 Sep 2022 17:38:33 +0200 Original-Received: from acm.muc.de (p2e5d5e67.dip0.t-ipconnect.de [46.93.94.103]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 02 Sep 2022 17:38:32 +0200 Original-Received: (qmail 9184 invoked by uid 1000); 2 Sep 2022 15:38:32 -0000 Content-Disposition: inline In-Reply-To: <2f302d1c39d838732c24@heytings.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:294565 Archived-At: Hello, Gregory. On Fri, Sep 02, 2022 at 13:41:14 +0000, Gregory Heytings wrote: > > In my experience, they work less well than the fonts for the Linux > > console. > Your experience is rather short, isn't it? You objected to that solution > as soon as it was suggested. Please try again with a better font. Suggest one to me, please. I'm not an expert on X-Windows fonts. > What you see under fbterm is exactly (with respect to fonts) what you > would see in a terminal emulator under X, including anti-aliasing. I detest anti-aliasing. It makes everything go blurred for me. Maybe that's a reason why I don't like these fonts. > > That was the first one I tried this morning. I didn't like it. It's a > > "spidery" font like all the other ones I have available. > Can you provide a screenshot of Emacs under fbterm with that font and one > of Emacs in the raw Linux console? I'm not sure I understand what you > mean by "spidery". No, I don't know how to take a screen shot of a console. But the utility psf2txt displays the bitmaps of all characters in a console font. The image for C in lat1-16.psfu looks like: // Character 67 Bitmap: -------- \ -------- \ --####-- \ -##--##- \ ##----#- \ ##------ \ ##------ \ ##------ \ ##------ \ ##----#- \ -##--##- \ --####-- \ -------- \ -------- \ -------- \ -------- Unicode: [00000043]; % Note that the main body of the character is two pixels thick. This doesn't appear to be the case for any of the fonts I've tried in fbterm, which appear to be just one pixel thick; or to use anti-aliasing or other tricks. That one pixel thickness is what I mean by "spidery", in the sense of "as thin as a spider's web". > > I just came across another problem. The GPM mouse utility won't > > transfer text between an fbterm console and another console, not even a > > second fbterm. > I don't know. In any case, that seems to be a very minor problem. It's not minor to me. Without GPM, I'd have to alter my workflow considerably. > > I think you were being too positive about the topic, and felt I should > > express the other side of the argument. > I don't think you are expressing the other side of the argument. You are > listing very minor problems (and non-problems, such as when you said that > "you have to configure faces"). I think you said earlier on in the thread that there were "no known inconveniences" with fbterm. I have listed some inconveniences, even if I've called them problems. I think you were mistaken on this point. > By the way, if you don't want 256 colors and want to use only 8 colors as > you did before, just don't set TERM=fbterm, or set TERM=linux. Well, it's not just as before - as I said earlier, hi-green comes out as brown. That's the sort of thing I meant when I said that you had to configure faces. -- Alan Mackenzie (Nuremberg, Germany).