[haiku-bugs] Re: [Haiku] #16221: Web+: Garbled text on Github

  • From: "Haiku" <trac@xxxxxxxxxxxx>
  • To: undisclosed-recipients: ;
  • Date: Mon, 28 Jun 2021 19:54:52 -0000

#16221: Web+: Garbled text on Github
---------------------------+----------------------------
  Reporter:  bitigchi      |      Owner:  pulkomandy
      Type:  bug           |     Status:  reopened
  Priority:  normal        |  Milestone:  R1/beta3
 Component:  Kits/Web Kit  |    Version:  R1/Development
Resolution:                |   Keywords:
Blocked By:  16213         |   Blocking:
  Platform:  All           |
---------------------------+----------------------------
Comment (by pulkomandy):

We identity-pair them with the value of the character, the 32 bit
 codepoint, as if they were the same (see ​GlyphPageTreeNodeHaiku or
 ​FontHaiku, for example). So the hand in the "Mentioned" line works, as it
 is 270b. The others: 1f3af, 1f4ac, 1f64c and 1f440, don't work because
 they are in plane 1 and that bit is lost before giving the string to
 Haiku.

 What else could we do? There is no notion of "planes" anywhere in WebKit,
 right? So where should that come from? At which point does webkit remove
 that information, and where does it store it instead?

Then in FontHaiku instead of drawing the glyphs with the given advances,
 as it seems what the WebKit infrastructure expects, we rebuild the string
 to use Haiku API to draw it

 This is not an "instead". We do use the advances, but we put the glyphs
 back into a string. This is because we want to send them to app_server in
 one single call. Drawing character-by-character would be extremely slow.
 In fact, the call to DrawString with offsets/advances was added
 specifically to improve performance in WebKit text drawing.

If I'm right in my previous wall of text, getting the missing glyph char
 back would indeed solve those issues by making BFont::GetHasGlyphs always
 return true, but that's exactly why it was removed

 We want the missing glyph to be drawn if you put a non-existing character
 in a string passed to DrawString. Yet, we want GetHasGlyphs to return
 false in that case, so that applications can check for it and avoid
 calling DrawString with non-existing glyphs if they care.

And that patching the definition of WebKit's Glyph to a 32 bit int,
 dirty hack as it may be, would even show the emojis if we have them. But I
 don't know how bad an idea that is or the consequences it may have in the
 rest of the code.

 I see that in MacOS, GlyphBufferGlyph is defined to be a CGGlyph instead
 of WebKit internal Glyph type. That's also an uint16, however, but
 customizing this type is not unheard of.
-- 
Ticket URL: <https://dev.haiku-os.org/ticket/16221#comment:26>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.

Other related posts: