On 2020-02-11 23:25, Marc Lehmann wrote:
First of all, I have askexd you multiple times for a conrete example
case
so I can look at it, but so far you are good at ignoring all my
requests
for more info.
Sorry I missed those, here is a description of the issue.
Using urxvt built with --enable-unicode3 and this font configuration,
U
Try to cat a file containing:
😄😊😉😍😘😚😜😝😳😁😣😢😂😭😪😥😰😩😰🦄
(Hopefully those emojis pass through the email properly)
With an unpatched Xft and unpatched rxvt-unicode ou will get a mono
emoji displayed, and in stderr you will see
urxvt: An X Error occurred, trying to continue after report.
urxvt: + Serial number of failed request: 527
urxvt: + X Error of failed request: BadLength (poly request too large or
internal Xlib length error)
urxvt: + Major opcode of failed request: 138
urxvt: + (which is an unknown extension)
urxvt: + Minor opcode of failed request: 20
This error is triggered by Xft which does not know how to deal with
those emoji glyphs.
If you use a patched Xft with an unpatched rxvt-unicode, the error goes
away but the emoji are still mono ones.
Now if you swap the fonts:
URxvt.font: xft:Noto Color Emoji:pixelsize=11,xft:Terminus:pixelsize=12
Still with patched Xft and unpatched rxvt-unicode, emojis are displayed
in color, but line spacing is huge (I believe it matches the pixel size
of the images stored inside the font, which IIRC is 124x124 for Noto
Color Emoji), and cell width is around double the one we get from the
Terminus font (because the emoji font glyphs are square, and contains
glyphs for digits)
If you try this font configuration with unpatched Xft and rxvt-unicode,
you will get the X error, huge line spacing and huge horizontal spacing
(not double horizontal spacing, much more looks like cells are 124x124,
so it seems it takes the unscaled size of the emoji glyph that will fail
to render anyway).
If you try those configuration with both patches applied, you will get
correct rendering and spacing with the Emoji font as fallback, and
correct rendering, line spacing, but "doubled" width with the Emoji font
as primary (because digits characters from the emoji font are still
square shaped).
I hope this explains the use case and issue clearly enough.
Furthermore, I must admit I get more and more confused - what you write
seems to be contradicting itself: does or does your patch not add
scaling
to xft and thus change font metrics independent of FT?
You seem to now claim that it only avoids an X error?
Or in other words, your patch to add scaling is not required to exhibit
the problem in urxvt - if thats the case, again, it would be nice if
you
gave a concrete example that reproduces the problem.
My patch for Xft adds support for color bitmap fonts and for scaling
their glyphs, those seems to be exclusively used for emoji support.
Scaling is only applied on those fonts, which were not supported
earlier, other kind of fonts do not change behaviour.
This means the only difference between patched and unpatched Xft is that
a set of fonts that were not usable at all are now usable, everything
that was working before still works the same, something that was not
working at all now works.
Under any reasonable definition this is NOT an API break.
UNICODE3 only affects terminal character storage, it has nothing to do
with 32 bit codepoints, which are supported even when the terminal uses
16
bits per cell.
Now I am getting confused as well, do you mean rxvt-unicode can store
codepoints > 0xFFFF when it uses 16bits per cell ? Here if I compile
rxvt-unicode without --enable-unicode3 emojis are always rendered as
squares.
> Cairo is poretty irrelevant as it has its own API.
My point was that cairo sits at the same layer as Xft for font
rendering.
And my point was that it is irrelevant for this discussion, as it has
its
own API.
My decision to add scaling support at the Xft level was informed by the
fact that cairo, a library that provides the same services as Xft (and
more) and hence sits at the same layer in the display stack did it
itself. I believe people working on cairo and freetype interact quite a
lot, and if the decision was taken to do scaling in cairo rather than in
freetype, I assumed that makes it unlikely for me to get scaling added
to freetype.
If the scaling doesn't change the API, then why is there a need to
change
rxvt-unicode?
Scaling does not change the API, but it makes the workaround
rxvt-unicode uses to compute font ascent, descent and height (and only
this, width computation is left untouched except for the addition of an
emoji character in the set of character used) invalid for the fonts
scaling applies to, which again is a set of fonts that were not
supported at all before.
This patch tries to fix that by getting ascent, descent and height from
Xft as they will have scaling applied, but we could also just apply
scaling directy inside rxvt-unicode to fix this. It would be
Scaling is only enabled for fonts that use color bitmaps, those were
plainly
not
supported before.
So does or does the patch enable scaling? You claim both, which
obviously
can't be the case.
I think my sentence was pretty clear, but I'll try to put it another
way, my patch enable scaling for a set of fonts (color bitmap fonts)
that were not supported by Xft previously, it enables scaling only for
this set of fonts, leaving all the previously supported font type (mono
bitmap font, vector font) working exactly as they used to.
The scaling support COULD be used to do things such as auto-slanting of
mono bitmap fonts, but that is NOT enabled in the current patch.
Cheers,
Maxime.
_______________________________________________
rxvt-unicode mailing list
rxvt-unicode@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
