[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: