haiku needs a better font overlay or fallback mechanism

[khallebal]

hi devs. since hrev39695 haiku displays only blanc spaces if you type arabic characters,either in the Tracker,Stylededite or in the keymap preflet,if you choose the arabic keymap in the preflet the chracters diseppear. the last revision that worked was the hrev39683. cheers. khaled.

[korli]

Nothing in the in between revisions would explain the behavior you describe. Did you build the image yourself ?

[khallebal]

Replying to korli:

Nothing in the in between revisions would explain the behavior you describe. Did you build the image yourself ?

no this is a nightly image. i'll try the rev from last night to see if the prob is gone.

[khallebal]

changing the settings in the Local app seems to trigger this behavior after the next reboot,as long as you do not "touch" the Local preflet everything is ok,and the revision that started this was actually 39719 from december 3rd,and not 39695 as mentioned earlier,and i found that it affects the hebrew characters as well.

update: it seems happening even with the revisions prior to 39719,but curiously writing in some qt text editor works just fine.

[khallebal]

and typing in the terminal works fine as well!

[khallebal]

ئثلتبتيمﻻنبwell,it took me a while to find the problem.it's a fonts issue,i found that choosing fonts other than the "dejavu sans" family makes the characters "invisible",but curiously this affects only the arabic & hebrew characters,so it's not a "local app" issue as stated above. this should help you track down the problem.

[korli]

It could be related to font overlay then. Let's see whether Adrien has an idea.

[pulkomandy]

Yes, the font overlay currently always falls back to VLGothic, which has japanese chars, but not hebrew nor arabic ones. So if your main font doesn't have these characters, the current fallback will not work.

The two options are :

• Make a more complete font overlay that select the most appropriate font for the missing chars (but evaluating similarity between two fonts is not easy);
• Include a font with a complete unicode coverage as the fallback font in Haiku. Such a font would be really big and may not look nice.
• Make the fallback font locale dependant. Mapping a locale to a font may not be easy, either.

[mmlr]

Basically this one is invalid. As stated by the reporter choosing a font other than dejavu triggers this, which is expected behaviour when the chosen font doesn't contain glyphs for the characters at hand. The only thing that changed with the font fallback was that those characters weren't rendered at all instead of being rendered as "missing glyph boxes". This has been corrected by now (see #7077), but now, same as before the font fallback introduction, if both the chosen font and the fallback font (currently always vl gothic) are missing the glyph, they will simply be rendered as the "missing glyph box".

Conclusion being: The ticket as is (i.e. "doesn't display anymore") is invalid, as it never did when selecting the wrong fonts (it just went from rendering boxes to rendering nothing, which is no fixed). The issue that the font fallback mechanism should be more clever and try to find more suitable fallback fonts still stands of course, but belongs to a separate ticket that I'm going to create (if there isn't one already).

[khallebal]

hi all
i took the liberty to reopen this ticket coz it has detailed info on the subject, so changing the title of the ticket seemed more apropriate than closing it as invalid, i didn't come across a similair ticket while i was searching the trac. so i thought this problem could be forgotten & may never get solved.

[leavengood]

I was thinking of the best way to fix this, and did a search here for other tickets and found #5320, which has a screenshot of Dano's font overlay configuration.

This was pretty much what I was thinking for how to fix this properly. We can have a default font, then can configure fonts to cover the Unicode glyph ranges not covered by the default font. VLGothic can cover Japanese, khallebal can configure his favorite font for Arabic, and we can set up WQY-MicroHei as the overlay font for Chinese and properly fix #6194 (and of course Chinese users can change this for another font if they wish.) Win, win, win!

Is anyone in the mood to implement this? I could probably pull it off, but my bug list is getting pretty long at this point...

[axeld]

(In #5320) Closing this as a duplicate of #6967; we already have an overlay mechanism, it just isn't good :-)

[axeld]

I don't think Dano's solution is appropriate; this is nothing a normal user should ever need to tackle with, so I don't think it should be placed in the Font preferences.

Furthermore, since this is language depending to some degree (see CJK fonts), the mechanism should be beware of that, too. However, since the app_server can only know the current user preferences, it cannot know which language is printed on screen if that one differs (think something like ReadOnlyBootPrompt), so it cannot really be made perfect, anyway, with the current API.