Hi, (replying to the list again - I've not meant to move this to a private discussion)
the issue for what the original patch fixes came up on IRC recently, and I've remembered that I've sent it here. I think the patch itself (adding the space character to the list of characters to test) makes sense, regardless of if FontAwesome uses codepoints in the private use area. Please consider applying this patch therefore. I'm following up on the discussion about the Unicode PUA below. On 09.11.2016 03:08, Marc Lehmann wrote: >>> rxvt-unicode uses the private use area internally and cannot support fonts >>> (ab-)using it. >> >> How and what for is it used? > > To compress compose sequences. I've not experienced any problems using FontAwesome (with the patch). Can you provide more information about when this would cause a conflict? >> IIRC rxvt-unicode uses different private areas, depending on if >> --enable-unicode3 is used?! >> Is it (only) related to this code: >> https://github.com/exg/rxvt-unicode/blob/b5f4a5a822a6/src/rxvt.h#L768-L783? > > Yep to both :) So it is used only with !UNICODE_3, right? >>> This is not uncommon, the linux kernel and other applications do the >>> same thing for example. >> >> Hmm. >> How does the Linux kernel use them? Is it about >> http://www.lanana.org/docs/unicode/unicode.txt? > > Yes. > >> This sounds like "U+E000 … U+EFFF" could be used freely after all?! > > In that application (the linux kernel), yes. The linux kernel doesn't > mandate any end user area for anything bit itself. ..but they conflict with rxvt-unicode's use, right? #if UNICODE_3 # define COMPOSE_LO 0x40000000UL # define COMPOSE_HI 0x400fffffUL # define IS_COMPOSE(n) ((int32_t)(n) >= COMPOSE_LO) #else # if ENABLE_PERL # define COMPOSE_LO 0xe000UL // our _own_ functions don't like (illegal) surrogates # define COMPOSE_HI 0xf8ffUL // in utf-8, so use private use area only # else # define COMPOSE_LO 0xd800UL # define COMPOSE_HI 0xf8ffUL # endif # define IS_COMPOSE(n) IN_RANGE_INC ((n), COMPOSE_LO, COMPOSE_HI) #endif >>> The only way out here would be to change the font not to use the private >>> use codepoints, as urxvt has no way to deal with it. >> >> Well, my impression is that using the Private Use Area (PUA) is especially >> meant for fonts with glyphs that are not defined in Unicode?! > > And is your impression backed up by any evidence? Have you actually read > what unicode has to say about it? (It doesn't agree with your impression). What does it say? How/where are custom glyhps meant to be positioned then? Cheers, Daniel.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
