On Mon, Nov 07, 2016 at 01:49:49AM +0100, Daniel Hahler
<[email protected]> wrote:
> A simple fix for this is to use the glyph's width instead of WCWIDTH in
> rxvt_font_xft::has_char. Then rxvt-unicode does not assume the glyph to
> not be there at all in the font, but it will be displayed in a single cell.
> Would you accept a patch in this regard?
It's not a fix if the character width suddenly is wrong. If wcwidth
returns the "wrong" result on your system then you need to change wcwidth
(i.e. the locale info). Just changing it in urxvt doesn't magically tell
anybody else that this characte rfis now displayxed double-width.
> That's not optimal, since it will be displayed using its height (for 2
It's actually a bug.
> btw: what about using another indicator for "no font provides this
> char", and "char exists, but we cannot display it"?
Nothing like this is planned at the moment, although it is an interesting
idea.
> > To get this whole topic back on track: you do NOT start with a bug (a
> > broken or unsuitable font) and then modify your editor, your text files
> > and the terminal - you'd fix the font first. if you use a unicode locale,
> > you get a font that follows the unicode standard w.r.t. glyph size,
> > problem solved, no hacks needed at all.
>
> You keep on insisting that the font is broken, but it is about the Unicode
> standard, and the wcwidth(3) function after all. With Unicode 9 emojis
> have now a defined size of 2 ("Emoji style standardized variation
> sequences behave as though they were East Asian Wide, regardless of
> their assigned East_Asian_Width property value."), but libc's (glibc and
> musl) have not been updated in that regard.
Well, if the font is to be used in unicode applications based on unicode 8
systems such as yours, then it is broken. Upgrading your system to unicode
9 would then fix it, no?
> So, given an updated or patched wcwidth, urxvt actually considers the
> Snake to be two cells wide, and everything is nice (assuming that
> programs use wcwidth(3) also - which is not the case for Vim by default).
Yup.
> However, then there is the Private Use Area (see my other mail, "Re:
> [PATCH] Add space to extent_test_chars to recognize Font Awesome"),
Yes, the private use area is not for fonts to extent their character
repertoire and expect them to work.
> (I am assuming my interpretation of "Private Use Area" here, which
> allows to use codepoints from there for things like FontAwesome and
> Powerline)
fonts can have whatever glyphs they want for whatever codepoint (or even
codepoint combination) but that doesn't mean that everything works as the
fotn designer intended. Certainly the private use codepoints are not meant
for fonts to extend unicode - they are defined for use in cooperating
applications that know about the specific codepoints, so you would need to
not only teach your font about new glyphs, but also your libc, terminal
emulators, text editors and so on.
In the case of urxvt, the private use area is used, well, privately inside
urxvt, which is a valid application for the concept.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
