#16213 closed bug (fixed)
app_server: Glyphs render above each other
Reported by: | nephele | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta3 |
Component: | Servers/app_server | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #16221 | |
Platform: | All |
Description
To reproduce copy "Haiku へようこそ!" into fontdemo, select noto sans regular and play around a bit with the size slider, the japanese glyphs of the string will render above each other.
Attachments (1)
Change History (5)
by , 5 years ago
Attachment: | FontDemo.png added |
---|
comment:2 by , 4 years ago
Fallbacks.
A lot of printfs and recompiling (thank you for test_app_server) shows that when the kanas render above each other, their escapements are retrieved as 0 because their glyphs are not found, and rendered anyway because the glyphs are found!
The escapements are retrieved using the whole string. I'm guessing for some sizes Noto Sans Regular does not return any glyph, Noto Sans Display is selected as fallback with the first "H" and, as only one fallback is used for the whole string, the kanas are missing.
The rendering, on the other hand, is done a character at a time, so when rendering latin letters Noto Sans Display is used if needed and when rendering tha kanas Noto Sans CJK JP is chosen.
The thing is https://git.haiku-os.org/haiku/tree/src/servers/app/font/GlyphLayoutEngine.h#n249 only looks for a fallback font once in a whole layout string, so when one needs two or more fallback fonts for different characters in the same hunk, we are out of luck.
I've played a bit with the call and the locks but as expected I only got deadlocks. Time for someone who knows to try.
comment:3 by , 4 years ago
Milestone: | Unscheduled → R1/beta3 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:4 by , 4 years ago
Blocking: | 16221 added |
---|
Did a bit more investigation.
example
if thai is set cjk glyphs sometimes have no size
if cjk is set thai glyphs sometimes have no size
in both cases ascii renders fine, if noto sans regular is set both thai and cjk have problems
edit: interestingly enough, in webpositive latin derived glyphs have a problem falling back, i have yet to reproduce this in fontdemo