Opened 14 years ago

Closed 11 years ago

#6967 closed bug (duplicate)

haiku needs a better font overlay or fallback mechanism

Reported by: khallebal Owned by: pulkomandy
Priority: normal Milestone: R1
Component: - General Version: R1/Development
Keywords: Cc: linlongzhou@…
Blocked By: #7961 Blocking: #5320
Platform: All

Description (last modified by korli)

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.

Change History (15)

comment:1 by korli, 14 years ago

Description: modified (diff)

comment:2 by korli, 14 years ago

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

in reply to:  2 comment:3 by khallebal, 14 years ago

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.

comment:4 by khallebal, 14 years ago

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.

Version 0, edited 14 years ago by khallebal (next)

comment:5 by khallebal, 14 years ago

and typing in the terminal works fine as well!

comment:6 by khallebal, 14 years ago

ئثلتبتيمﻻنب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.

comment:7 by korli, 14 years ago

Owner: changed from nobody to pulkomandy
Status: newassigned

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

comment:8 by pulkomandy, 14 years ago

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.

comment:9 by mmlr, 14 years ago

Resolution: invalid
Status: assignedclosed

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

comment:10 by khallebal, 14 years ago

Resolution: invalid
Status: closedreopened
Summary: haiku does not display Arabic characters anymorehaiku needs a better font overlay or fallback mechanism

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.

comment:11 by leavengood, 13 years ago

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...

comment:12 by axeld, 13 years ago

Blocking: 5320 added

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

comment:13 by axeld, 13 years ago

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.

comment:14 by mshlyn, 11 years ago

Cc: linlongzhou@… added

comment:15 by pulkomandy, 11 years ago

Blocked By: 7961 added
Resolution: duplicate
Status: reopenedclosed
Note: See TracTickets for help on using tickets.