X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=puLqKJREBilfgTF+n2SPS7lOj3x3wB3EvjVIBQJiC0H9uOWz9tb/h
	0AtDOgDt1GRHI62LYjyK5zIQ/L3RmdNJob93Sl6H1IQETbyVKZp1nW5LCFcxEQXB
	pWa8uRU+Zr1WJY2XsR0vAPfoYTPDTjW2y8+YrUt0gOj4ZZrXLvJrzY=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=vvmkxRde6MwIUnufcXEfTJmvYro=; b=ymYZZJyDYneJt6wwbukGhlkpE369
	rglWi7RPvVB5VelDweAs6FYXKwsTNdc7OV5bcbRmfq8ZWqPTFXC1jPjWyTWPDGiD
	siWJ3+BSUYotk/8Mi6ldfbdXrMS7b8ha3a4JQoROxSp2Kc8/wOKXm1tZ4yYIyf1O
	E/EI58Rqe5BtRCA=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-101.2 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=shade, WORD, theory
X-HELO:	mout.kundenserver.de
Date:	Mon, 3 Sep 2018 16:59:19 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Cygwin fails to utilize Unicode replacement character
Message-ID:	<20180903145919.GU6350@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<7942b18e-96bf-a824-4dac-82715d87af55 AT towo DOT net> <5b8bdcc4 DOT 1c69fb81 DOT 84d1a DOT e6b9 AT mx DOT google DOT com> <20180903124616 DOT GT6350 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<20180903124616.GT6350@calimero.vinschen.de>
User-Agent:	Mutt/1.9.2 (2017-12-15)

--ubBGeysJ7fFOU9Y9
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sep  3 14:46, Corinna Vinschen wrote:
> On Sep  2 05:51, Steven Penny wrote:
> > On Sun, 2 Sep 2018 10:07:10, Thomas Wolff wrote:
> > > Actually, the width problem I suggested in my other response (and even
> > > referring to the wrong character) does not apply as mintty enforces
> > > proper width in that case.
> > > Also, even with fonts that do not provide the glyph, you will usually
> > > still see it by the Windows font fallback mechanism.
> > > Shall I make it configurable?
> >=20
> > your call - here are the possible resolutions - in order of my preferen=
ce:
> >=20
> > 1. Change the default to U+FFFD with no option
> > 2. Change the default to U+FFFD with option to change
> > 3. Leave default as is with option to change
>=20
> Ideally we could check if the current font supports a visual
> representation of 0xfffd and if not, fall back to 0x2592.
>=20
> Not sure how feasible that is, but it doesn't seem to be overly
> complicated.  I'm just looking into a solution for the Cygwin
> console.

Only, I can't get this working.  In theory the GDI function
GetGlyphIndicesW is supposed to allow checking if a certain character
exists.  But I'm getting a weird result.  This code:

  static const wchar_t replacement_char[2] =3D
    {
      0xfffd, /* REPLACEMENT CHARACTER */
      0x2592  /* MEDIUM SHADE */
    };
  HWND cwnd =3D GetConsoleWindow ();
  HDC cdc =3D GetDC (cwnd);
  int rp_idx =3D 0;
  WORD gi =3D 0;
  DWORD ret =3D GetGlyphIndicesW (cdc, replacement_char, 1, &gi,
                                GGI_MARK_NONEXISTING_GLYPHS);
  if (ret !=3D GDI_ERROR && gi =3D=3D 0xffff)
    rp_idx =3D 1;

always sets rp_idx to 1 when called from inside the Cygwin DLL,
independently of the actual console font.  And, here's the really weird
thing, it always sets rp_idx to 0 when called directly from an
application, likewise independently of the actual console font.

Does anybody have an idea what I'm doing wrong?

Just as side-note:

- GetTextFaceW always returns font number 7 called "System", independently
  of the actual current font set in the console.
- GetCurrentConsoleFont always returns a font number of 0, independently
  of the actual current font set in the console.
  GetCurrentConsoleFontEx always returns with error 87, "invalid
  parameter"

Something's very fishy.  Thanks for any actual help.


Corinna

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

--ubBGeysJ7fFOU9Y9
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAluNTEcACgkQ9TYGna5E
T6CgQQ/+KbF+3NncIUjTFblbXRUagGLDSwxCyt7cebHWnrMeZj6z6oecXSmFM7O7
o43dJuj0FjNBSZ0EV4weTC6jSysuk5W74m3Fu7AksQMIRhfaHgNciF0eb0p4lg/Y
kV+ceJO1KDIhvPJ4SdOOJ2syqWgc+AIVq6yE5fQC44LXK4ntmXHjVPXH5TfPmVu0
oTZiUhbuDa2jgBHMS84ehcawO2BZoiQUDK2DZjS5iezOwDAYenGGcOb1R/kpPrSm
R6kUHjOKxGRTiuAPxazFO6O1zGEMMK8y3IuWaZogQ1qCbujtv2NpjwbUwZA/n9AK
5hxoGoT7JA3u7tQ7UhucOzydZ7TwwnzarmL/4zpkhUEiMbmDV7N8wHYb99QDYO9i
3w1Gb0B3NR7OAwaxXLdOiXyFsA0cWOeM+2Xy5dLR0uBbyJC0UMqjvuYjE9ymknOf
WVyMa5JB+n6uyd79eBf7aaM26JYoa3fJ9U/0aQA4z+hbk0ytFWj2FgNnQcfTqxn4
GWudb5kunKeRP8KpaB0I4tlV+0ED4sOt4PKqZxUeJTxfiqQkH6R5O9sJw5M2P1T8
nwjghWZ4TDA60uc9bDhl/K4Q+B0yL1qqoUMQgG6FINKyxdEPk2nCiY0D7Czi8omb
TJG/MRZ3uP3YJNLy2McsWkfd4Il0FLmJkD+o/YYrl0PfDJg8P7k=
=SE1f
-----END PGP SIGNATURE-----

--ubBGeysJ7fFOU9Y9--

- Raw text -