From: Thomas Wolff <towo@towo.net>
To: cygwin@cygwin.com
Subject: Re: mintty overstrokes some fonts unexpectedly
Date: Mon, 26 Apr 2021 20:31:38 +0200 [thread overview]
Message-ID: <19bb84cb-c503-238a-513f-42e8cb3c19de@towo.net> (raw)
In-Reply-To: <20210426081451.EC3F.50F79699@gmail.com>
Am 26.04.2021 um 01:14 schrieb Lemures Lemniscati via Cygwin:
> On Sun, 25 Apr 2021 22:33:57 +0200, Thomas Wolff
>> Am 25.04.2021 um 15:41 schrieb Lemures Lemniscati via Cygwin:
>>> Hi!
>>>
>>> mintty overstrokes some fonts unexpectedly.
>>> https://gitlab.com/test.cases/mintty-test/-/tree/54ae800e695ecd1741851cab57320a9d0e95a6fd
>>>
>>> I got a result mintty-sample-msgothic.png.
>>> https://gitlab.com/test.cases/mintty-test/-/blob/54ae800e695ecd1741851cab57320a9d0e95a6fd/mintty-sample-msgothic.png
>>>
>>> In the 4th line of the output, fonts (of u+25cb) were overstruck
>>> unexpectedly.
>>> And there are other characters also, which are similarly overstruck.
>> This is a Windows bug. Mintty clearly instruct Windows to apply equidistant spacing to achieve fixed-width character cell behaviour. But for certain character ranges, Windows ignores that. Another example for such misbehaviour is the Tibetan block (U+0F00-U+0FFF). Mintty could work around that by rendering characters separately, at a significant penalty for output speed however. Or it could do that only for affected ranges, but criteria to identify them are obscure.
> Thank you, Thomas.
>
> I tried some earlier versions of mintty:
>
> * mintty-3.1.0-1 has the same issue
> * mintty-2.9.6-0 works expectedly in this case.
My previous comment was wrong, sorry. The cause of the issue is that the
Windows CJK fonts are designed for CJK ambiguous-wide layout. If you run
mintty with option Charwidth=ambig-wide, or better in an ambiguous-wide
locale like LC_CTYPE=C.utf8@cjkwide, width handling and font rendering
will match.
Mintty applies auto-narrowing to some characters that would render far
out of their character cell, squeezing them into the cell, in order to
optimise the trade-off between readability and authentic rendering.
Some character ranges were taken out of that mechanism in 2.9.7,
including the Geometric Shapes which you've encountered, in this case
because they are "geometric" and the assumption was that they should not
be tampered for rendering.
Thomas
next prev parent reply other threads:[~2021-04-26 18:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-25 13:41 Lemures Lemniscati
2021-04-25 20:33 ` Thomas Wolff
2021-04-25 23:14 ` Lemures Lemniscati
2021-04-26 18:31 ` Thomas Wolff [this message]
2021-04-26 22:55 ` Lemures Lemniscati
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19bb84cb-c503-238a-513f-42e8cb3c19de@towo.net \
--to=towo@towo.net \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).