Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: "G. Branden Robinson" Newsgroups: gnu.groff.bug Subject: [bug #59031] the \[Im] and \[Re] escapes are wrong Date: Fri, 28 Aug 2020 07:01:26 -0400 (EDT) Lines: 96 Approved: bug-groff@gnu.org Message-ID: References: <20200828-110124.sv108747.42627@savannah.gnu.org> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Trace: usenet.stanford.edu 1598612491 28834 209.51.188.17 (28 Aug 2020 11:01:31 GMT) X-Complaints-To: action@cs.stanford.edu To: "G. Branden Robinson" , bug-groff@gnu.org Envelope-to: bug-groff@gnu.org X-PHP-Originating-Script: 1001:sendmail.php X-Savane-Server: savannah.gnu.org:443 [209.51.188.72] X-Savane-Project: groff X-Savane-Tracker: bugs X-Savane-Item-ID: 59031 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 X-Apparently-From: 1.129.104.20 (Savane authenticated user gbranden) In-Reply-To: X-BeenThere: bug-groff@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Bug reports for the GNU version of nroff, troff et al" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <20200828-110124.sv108747.42627@savannah.gnu.org> Xref: csiph.com gnu.groff.bug:2003 URL: Summary: the \[Im] and \[Re] escapes are wrong Project: GNU troff Submitted by: gbranden Submitted on: Fri 28 Aug 2020 11:01:24 AM UTC Category: Core Severity: 3 - Normal Item Group: Incorrect behaviour Status: Need Info Privacy: Public Assigned to: gbranden Open/Closed: Open Discussion Lock: Any Planned Release: None _______________________________________________________ Details: Blackletter/fraktur fonts are NOT generally used for the names of standard number sets (naturals, integers, rationals, reals, complex numbers). Instead, double-struck letters are typically used for this purpose. And in turn, double-struck and blackletter faces are not the same. See . Given that: I submit that at least one of the following is true. 1. The descriptions of these glyph names in groff_char(7) is wrong. \[Im] \e[Im] Ifraktur u2111 Gothic I, imaginary \[Re] \e[Re] Rfraktur u211C Gothic R, real 2. Their association with the Ifraktur and Rfraktur names in the Adobe Glyph List (AGL) is incorrect. 3. The glyph names themselves are wrong to imply idiomatic usage as indicators for the sets of real and imaginary numbers. (The complex field ℂ is more commonly referred to than the set of imaginaries, which, being a 1-space anyway, can be represented by simply by iℝ (where i is the imaginary unit). Unfortunately, this problem goes all the way back to the beginning. ^351da0dc doc/chars.tr (James Clark 1991-06-02 04:20:34 -0500 564) .C2 Im Ifraktur "Fraktur I, imaginary" ^351da0dc doc/chars.tr (James Clark 1991-06-02 04:20:34 -0500 565) .C2 Re Rfraktur "Fraktur R, real" A variety of solutions suggest themselves. A. Retire (delete, unsupport) the glyph names and let the user use Unicode-form special character escapes if they need these symbols. As they already do if they want the correct glyph for the reals. B. Retain the mnemonics of the glyph name, remapping \[Im] and \[Re] to U+1D540 and U+221D, respectively. Note that the former is outside the Basic Multilingual Plane. This means dropping the AGL associations and the "Gothic" part of the glyph descriptions. C. Retain the mappings but rename them to be less misleading. We could go ahead and use long glyph names for this purpose. I share the general consensus expressed on the groff list in recent years that the groff glyph list should be frozen, but this is an outright error and should be corrected. D. Continue to be wrong and further cede the field of mathematical typography to TeX. Solutions A, B, and C would merit NEWS items. Solution D requires only an admission of error in the groff_char(7) man page. And perhaps a suggestion for .char remappings that one can add to one's documents. groff mavens--what say you? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.gnu.org/