Opened 13 years ago

Closed 11 years ago

#947 closed bug (invalid)

Konatu Tohaba isn't recognized as monospaced font

Reported by: jackburton Owned by:
Priority: normal Milestone: R1
Component: - General Version: R1/pre-alpha1
Keywords: Cc: shinta
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

The font Konatu Tohaba isn't recognized as monospaced, as shown in the screenshot. I remember it was recognized before the latest changes on it (before rev. 19210).

Attachments (1)

fonts.PNG (13.8 KB ) - added by jackburton 13 years ago.
Fonts preflet, Konatu Tohaba isn't listed as a monospaced font

Download all attachments as: .zip

Change History (22)

by jackburton, 13 years ago

Attachment: fonts.PNG added

Fonts preflet, Konatu Tohaba isn't listed as a monospaced font

comment:1 by jackburton, 12 years ago

Owner: changed from axeld to jackburton

Maybe koki could talk with the person who created the font ?

comment:2 by jackburton, 12 years ago

Owner: jackburton removed

comment:3 by jackburton, 12 years ago

So, I used FontForge on Ubuntu, read some faqs, and basically, to be monospaced, all glyphs have to have the same advance width. Some glyphs in Konatu Tohaba have an advance width of 1024 instead of 512. I have no idea if this is intended or not. FontForge could fix this, but I don't know which consequences this could bring. Does anyone have more knowledge on this subject ?

comment:4 by shinta, 12 years ago

Japanese monospaced font generally has two kind of width.

Characters like alphabet or number (inluded in western font) have narrow width (512 in your example). They are called "Hankaku".

On the other hand, mainly Japanese caracters like kana or kanji have wide width (1024 in your example). They are called "Zenkaku". Zenkaku's width is exactly twice of Hankaku.

comment:5 by shinta, 12 years ago

Cc: shinta added

comment:6 by koki, 12 years ago

Cc: koki added

According to the definition of "monospaced font" in the FontForge FAQ...

http://fontforge.sourceforge.net/faq.html#monospace

...for a font to be considered monospaced, all glyphs must have the same width. By this definition, Japanese fonts (which include single-width and double-width glyphs) are not monospaced.

FWIW, we actually had a related discussion on this thread of the Pe mailing list here:

http://www.freelists.org/archives/pedevel/04-2008/msg00059.html

It would be really nice if Haiku could, at the OS level, recognize this Japanese fonts as monospaced, so that they can be selected/used in applications.

in reply to:  6 comment:7 by jackburton, 12 years ago

Replying to koki:

According to the definition of "monospaced font" in the FontForge FAQ...

http://fontforge.sourceforge.net/faq.html#monospace

...for a font to be considered monospaced, all glyphs must have the same width. By this definition, Japanese fonts (which include single-width and double-width glyphs) are not monospaced.

Now I understand some of the code I found (and removed) in Terminal (which was originally written by japanese developers).

comment:8 by jackburton, 12 years ago

BTW, haiku has a BFont::IsFullAndHalfFixed() method, which should return true in case the font is one of this kind. Unfortunately it's not implemented server side. So actually it's correct that BFont::IsFixed() returns false.

comment:9 by koki, 12 years ago

So actually it's correct that BFont::IsFixed() returns false.

Yes, but this strict definition of monospace is short-sighted, as it does not seem to contemplate the cases of Japanese fonts that include two sets of characters (one single and one double width).

In practice, this makes it impossible to specify a Japanese typeface as monospace font, which can obviously be a problem in certain situations.

Perhaps the Font preference applet in Haiku can use the BFont::IsFullAndHalfFixed() method to allow the listing of Japanese font sets in the Fixed Font pull down menu?

in reply to:  9 comment:10 by jackburton, 12 years ago

Replying to koki:

So actually it's correct that BFont::IsFixed() returns false.

Yes, but this strict definition of monospace is short-sighted, as it does not seem to contemplate the cases of Japanese fonts that include two sets of characters (one single and one double width).

Of course, but that is a different kind of fixed width. :) IOW: this can make an implementation of text rendering in an application very different.

In practice, this makes it impossible to specify a Japanese typeface as monospace font, which can obviously be a problem in certain situations.

Perhaps the Font preference applet in Haiku can use the BFont::IsFullAndHalfFixed() method to allow the listing of Japanese font sets in the Fixed Font pull down menu?

Yes, although in that case every application should have support for this kind of font. Terminal will handle that. Stephan, do you have an idea on how to implement IsFullAndHalfFixed() ?

comment:11 by koki, 12 years ago

As Axel suggested on the Pe development list...

http://www.freelists.org/archives/pedevel/04-2008/msg00059.html

...it seems as if it would be better to handle this at the system level, so that applications can rely on the OS to be able to see all monospaced fonts (including non-compliant Japanese typefaces) without having to resort to hacks at the application level.

in reply to:  11 ; comment:12 by jackburton, 12 years ago

Replying to koki:

As Axel suggested on the Pe development list...

http://www.freelists.org/archives/pedevel/04-2008/msg00059.html

...it seems as if it would be better to handle this at the system level, so that applications can rely on the OS to be able to see all monospaced fonts (including non-compliant Japanese typefaces) without having to resort to hacks at the application level.

Yeah, I read that thread too. But this is just not possible in a transparent way: an application has to know that the fonts can have two different sizes and not just one. If we change the meaning of IsFixedWidth(), most applications will not handle that case correctly.

in reply to:  12 comment:13 by jackburton, 12 years ago

Replying to jackburton:

Replying to koki:

As Axel suggested on the Pe development list...

http://www.freelists.org/archives/pedevel/04-2008/msg00059.html

...it seems as if it would be better to handle this at the system level, so that applications can rely on the OS to be able to see all monospaced fonts (including non-compliant Japanese typefaces) without having to resort to hacks at the application level.

Yeah, I read that thread too. But this is just not possible in a transparent way: an application has to know that the fonts can have two different sizes and not just one. If we change the meaning of IsFixedWidth(), most applications will not handle that case correctly.

In other words: the "fix at os level" is, in my opinion, the fact that there is a BFont::IsFullAndHalfFixed() function. Just like applications can "filter" fonts using BFont::IsFixed(), they can use that function if they can handle those kind of fonts.

comment:14 by stippi, 12 years ago

Exactly. It won't work to simply advertise these fonts as fixed width, because they aren't. The application will need to know what to do when encountering a double width character. And those applications should look for IsFullAndHalfFixed() fonts in addition to IsFixed(), because they know how to support them. My personal opinion is that this should be resolved by a Japanese developer who knows the requirements and what he is doing and can actually check the results for correctness.

comment:15 by koki, 12 years ago

@stippi

There is a fundamental problem IMO: if the user cannot specify a Japanese font in the Font preferences Fixed font setting, then applications that rely on the OS font settings will not be able to display Japanese. So, yes, apps will have to deal with those non-compliant monospaced fonts, but the OS has to advertise these fonts so that the applications can see them.

So, I would start by allowing the Fonts preference application to select Japanese typefaces for the Fixed width font setting. That will expose the problem at the application level that you point out, and hopefully a Japanese developer will come along and take care of it.

Of course, all IMHO and FWIW applies. :)

in reply to:  15 comment:16 by jackburton, 12 years ago

Replying to koki:

There is a fundamental problem IMO: if the user cannot specify a Japanese font in the Font preferences Fixed font setting, then applications that rely on the OS font settings will not be able to display Japanese.

That is true, indeed :)

comment:17 by axeld, 12 years ago

That's not really the way to go. There is a reason for fixed width fonts, and it doesn't help to incorrectly advertise "full and half" fixed fonts as such - it simply makes no sense to do so. You cannot force applications to support these fonts either when it doesn't make any sense for them; we cannot and should not change the meaning of be_fixed_font. If an application asks for a fixed font, it must get one, period.

We could introduce a new default half/full fixed font which specifically allows this feature, and could even only expose this in the "Fonts" preferences app. But this cannot hide the fact that applications need to be changed to support these fonts; you don't deliberately break them just to make your point.

in reply to:  17 comment:18 by shinta, 12 years ago

Replying to axeld:

we cannot and should not change the meaning of be_fixed_font.

I think so, too.

IsFullAndHalfFixed() seems nice. I think that in most case, half fixed font can be used instead of completely fixed font. So, I want many applications to use IsFullAndHalfFixed() in addition to IsFixed().

comment:19 by koki, 12 years ago

@axeld

You confuse me. :)

What did you then mean by "if this problem is really thorough, it should be tried to fix it at the OS level, not in every application that might solely want to use monospaced fonts" on the Pe developmet list? Please see:

http://www.freelists.org/archives/pedevel/04-2008/msg00053.html

comment:20 by axeld, 12 years ago

That was obviously before I knew about the double width characters. This problem is not solvable on OS level as I first thought, at least not differently as outlined above.

comment:21 by jackburton, 11 years ago

Resolution: invalid
Status: newclosed

Let's close this, since it's not really a bug.

Note: See TracTickets for help on using tickets.