DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:to:subject:references
	:content-type; q=dns; s=default; b=S0JMrtHE5ga8v0gTkgELQeXylgYRc
	Db05YnT9rT13X7j+53IsXCJ9N/b/GiZmnI+6d2MJOwl625QOl30b9owQAxAZFP5M
	uJXFGecEAzDGAN1litmPVWw06o4eqGfHfB0cZVWBjJA1oQzezatqvKpHd10bGUoP
	mi/YHA83dX8Cq0=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <5b8db27e.1c69fb81.e3b47.6cd8@mx.google.com>
Date: Mon, 03 Sep 2018 15:15:26 -0700 (PDT)
From: Steven Penny <svnpenn@gmail.com>
To: cygwin@cygwin.com
Subject: Re: Cygwin fails to utilize Unicode replacement character
References: <20180903210258.GC6350@calimero.vinschen.de>
Content-Type: text/plain; charset=utf8; format=flowed
User-Agent: Tryst/2.8.0 (cup.github.io/tryst)

On Mon, 3 Sep 2018 23:02:58, Corinna Vinschen wrote:
> I can't. I only have a limited set of fonts available in the console.

http://superuser.com/questions/390933/add-font-cmd-window-choices/956818

> What I just did was calling the GetFontUnicodeRanges function
> for each font, and it turns out that none of the fonts support
> 0xfffd "REPLACEMENT CHARACTER", but all three support 0xfffc
> "OBJECT REPLACEMENT CHARACTER".  I expanded the testcase to check
> for this with GetGlyphIndicesW and, lo and behold, the result
> makes sense.

Here is my code if it helps:

    #include <stdio.h>
    #include <windows.h>
    int main()
    {
      CONSOLE_FONT_INFOEX ta;
      ta.cbSize = sizeof ta;
      GetCurrentConsoleFontEx(GetStdHandle(STD_OUTPUT_HANDLE), 0, &ta);
      HDC wh = GetDC(0);
      SelectObject(wh,
        CreateFontW(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ta.FaceName));
      WCHAR xr = 0xFFFD;
      WORD zu[1];
      GetGlyphIndicesW(wh, &xr, 1, zu, 1);
      printf("%ls: %s\n", ta.FaceName, *zu == 0xFFFF ? "FAILURE" : "SUCCESS");
    }

Result:

    DejaVu Sans Mono: SUCCESS
    Consolas: FAILURE

> On the other hand, during testing I saw a 0xfffd character printed for
> these fonts.  None of them actually supports 0xfffd, so apparently the
> Windows console already uses replacement fonts if possible.
>
> I guess I just stop here and always print 0xfffd.  I seriously doubt
> it makes sense to add so much code just to print a single char in a
> border case.

this is not possible; most likely you were seeing the ".notdef glyph":

http://docs.microsoft.com/typography/opentype/spec/recom

for Consolas which is simlar in appearance to U+FFFD REPLACEMENT CHARACTER. The
differnce is that if you copy the ".notdef glyph" and paste it into "Notepad" or
similar, it will paste the proper character that couldnt be seen in the console,
while pasting U+FFFD into "Notepad" will just paste itself.

Expanding on the "Notepad" example, "Notepad" default font is "Lucida Console",
which doesnt have U+FFFD either. However pasting into "Notepad" will still show
U+FFFD properly because "Tahoma" has U+FFFD and "Notepad" can utilize composite
font, while it appears "cmd.exe" and similar cannot.


--
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