Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#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)

FontDemo.png (175.5 KB ) - added by nephele 5 years ago.

Download all attachments as: .zip

Change History (5)

by nephele, 5 years ago

Attachment: FontDemo.png added

comment:1 by nephele, 4 years ago

Did a bit more investigation.

  • drawing mode is irrelevant for this bug
  • only happens if the set font does not include the to be-to-fallbacked codepoints
  • happens with thai aswell as cjk chars (only two non-latin derived languages in the fallback)
  • never happens when falling back to latin/latin-derived (also ö, etc.) from other fonts
  • this Never happens when noto sans cjk display is set as primary font (although the bounding box of thai looks suspicious, but still properly placed)

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

Last edited 4 years ago by nephele (previous) (diff)

comment:2 by madmax, 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.

Last edited 4 years ago by madmax (previous) (diff)

comment:3 by pulkomandy, 4 years ago

Milestone: UnscheduledR1/beta3
Resolution: fixed
Status: newclosed

comment:4 by pulkomandy, 4 years ago

Blocking: 16221 added
Note: See TracTickets for help on using tickets.