Re: Cygwin fails to utilize Unicode replacement character

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]

On Sep  3 22:42, Thomas Wolff wrote:
> Am 03.09.2018 um 22:27 schrieb Corinna Vinschen:
> > On Sep  3 21:14, Corinna Vinschen wrote:
> > > On Sep  3 20:20, Thomas Wolff wrote:
> > > > Am 03.09.2018 um 19:56 schrieb Thomas Wolff:
> > > > > Am 03.09.2018 um 19:16 schrieb Corinna Vinschen:
> > > > > > On Sep  3 18:34, Thomas Wolff wrote:
> > > > > > > Am 03.09.2018 um 16:59 schrieb Corinna Vinschen:
> > > > > > > > Does anybody have an idea what I'm doing wrong?
> > > > > > > This works in mintty, just uploaded a patch. Maybe somehow the
> > > > > > > GetConsole
> > > > > > > "dc" does not support this usage?
> > > > > > ¯\_(ツ)_/¯
> > > > > Dito; hold on, sorry, your code does *not* work inside mintty.
> > > > > Mine looks a bit different and I thought to have manually verified it's
> > > > > functionally equivalent, but indeed there must be something fishy...
> > > > You still need to
> > > >    SelectObject(cdc, f);
> > > > where f is the HFONT of the font you want to check.
> > > > To compare, you may check out function win_check_glyphs in file wintext.c in
> > > > mintty.
> > > Thanks but I don't know how to get a HFONT for the current console font.
> > > 
> > > In the meantime I figured out why my GetCurrentConsoleFontEx call
> > > failed with error 87:
> > > 
> > > When looking again I realized there's a member called cbSize.  The MSDN
> > > docs neglect to tell that the cbSize member has to be primed with
> > > sizeof(CONSOLE_FONT_INFOEX).  As soon as I tried that, the function
> > > succeeded.
> > > 
> > > Well, it's a start.  I now have the actual font name.  No idea how to
> > > get a HFONT from there, though.  From what I can tell ATM, I'd have to
> > > call CreateFont to get a new HFONT and then destroy it again after
> > > usage.  This looks pretty wasteful.
> > Well, it still doesn't work for me.  I now have the following code:
> > 
> > ===================== SNIP ======================
> > [...]
> > ===================== SNAP ======================
> > 
> > Supposedly none of the fonts support 0xfffd:
> > 
> >    $ gcc -g -o cons cons.c -lgdi32
> >    $ ./cons
> >    font Consolas
> >    gi = 65535 879
> >    rp_idx = 1
> >    $ ./cons
> >    font Lucida Console
> >    gi = 65535 620
> >    rp_idx = 1
> >    $ ./cons
> >    font Courier New
> >    gi = 65535 372
> >    rp_idx = 1
> > 
> > So I'm still doing something wrong, apparently.  Any hint?
> Test with a font that has the glyph; those 3 don't. Try DejaVu.

I can't. I only have a limited set of fonts available in the console.

But yes, you're right.

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.

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.


Thanks a lot for your help,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]