bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41645: 27.0.91; Combining Grapheme Joiner (#x34f) gui artifacts


From: Eli Zaretskii
Subject: bug#41645: 27.0.91; Combining Grapheme Joiner (#x34f) gui artifacts
Date: Thu, 04 Jun 2020 16:31:16 +0300

> From: Pip Cet <pipcet@gmail.com>
> Cc: dfussner@googlemail.com,  41645@debbugs.gnu.org
> Date: Thu, 04 Jun 2020 06:58:47 +0000
> 
> > I like this less than your original proposal.
> 
> Okay, so do I. I'd misunderstoond your previous comment, then.

Apologies if I wrote something which caused a misunderstanding.

> Is this any better?

Yes, thanks.  That's what I had in mind.

> I'm not sure what to do about static compositions,
> to be honest, so maybe we shouldn't touch those at all. What do you think?

Yes, let's not alter the static compositions code until we have a
valid reason.

> @@ -30626,6 +30642,11 @@ gui_produce_glyphs (struct it *it)
>        it->pixel_width
>       = composition_gstring_width (gstring, it->cmp_it.from, it->cmp_it.to,
>                                    &metrics);
> +      if (it->pixel_width == 0)
> +     {
> +       it->glyph_not_available_p = true;
> +       it->pixel_width = face->font->space_width;
> +     }
>        if (it->glyph_row
>         && (metrics.lbearing < 0 || metrics.rbearing > metrics.width))
>       it->glyph_row->contains_overlapping_glyphs_p = true;

The IT_CHARACTER case also does this when the pixel width comes out as
zero:

              it->phys_ascent = it->ascent;
              it->phys_descent = it->descent;

That is, it doesn't trust the ascent/descent values from metrics.
Should we do the same for compositions, or did you see any reasons to
believe the metrics in this case?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]