X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SARE_SUB_ENC_UTF8,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <2BF01EB27B56CC478AD6E5A0A28931F202DE9FEA@A1DAL1SWPES19MB.ams.acs-inc.net> References: <2BF01EB27B56CC478AD6E5A0A28931F202DE9FEA AT A1DAL1SWPES19MB DOT ams DOT acs-inc DOT net> Date: Thu, 14 Jul 2011 19:40:10 +0100 Message-ID: Subject: Re: man UTF-8 rendering problem From: Andy Koppe To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 13 July 2011 15:07, Nellis, Kenneth wrote: > I wrote back in January about a UTF-8 rendering error with > "man size", but got no satisfaction. > > http://cygwin.com/ml/cygwin/2011-01/msg00057.html > > I encountered the same issue today with "man addr2line". > > Running mintty with the Lucinda Console font and configured > for the UTF-8 character set and LANG set to C.UTF-8, these > two man commands render an undefined box symbol where a > vertical bar would appear. It appears that man is > attempting to display U+23AA (CURLY BRACKET EXTENSION) > where it would display "|" (0x7C) were I configured > for ISO8859-1. > > In a separate issue regarding hyphens and dashes, I recall > that mintty added exception logic to work around an issue > where Lucinda Console did not support the Unicode HYPHEN > character as man presented, and so mintty instead rendered > an Ascii HYPHEN-MINUS (0x2D) instead (or something like that... > I forget the details). > > I wonder in this case whether mintty would be an appropriate > place for a similar workaround. > > Or what would the proper fix be? It seems CURLY BRACKET > EXTENSION to be an odd choice for this character, but where > is this choice being made? Looks like this has been fixed in the man pages for binutils 2.21, whereas Cygwin still uses 2.20. I noticed that when trying it on an install with binutils 2.21 from Cygwin Ports, but you can also see plain old pipe characters being used in 'man i686-pc-mingw32-addr2line' (assuming you've got the mingw-binutils package installed, which also uses 2.21). I don't know exactly what is wrong with those pages, but unlike with HYPHEN vs HYPHEN-MINUS, the CURLY BRACKET EXTENSION certainly is the wrong character to be used there, which is why I don't think this merits a specific workaround in the terminal. Having said that, mintty issue 264 is about dealing with missing line drawing glyphs by either rendering them using graphics primitives or replacing them with approximations, so this one would be a candidate for that. Low priority though. The DejaVu Sans Mono actually does have a glyph for the CURLY BRACKET EXTENSION. Looks rather odd though where those characters are lined up on top of each other in 'man addr2line', because they're as high as the character cell thus forming a continuous line, whereas the pipe character leaves gaps. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple