Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jam]

Hi there,

Thank you for creating MediaCenter for Linux.  

I noticed CJK fonts problem like others.  It looks like there is no thread about it.  Therefore, I made one.

It appears like this.
http://yabb.jriver.com/interact/index.php?topic=85770.msg611970#msg611970

There are several threads discussed about this issue:
http://yabb.jriver.com/interact/index.php?topic=85770.msg611939#msg611939
http://yabb.jriver.com/interact/index.php?topic=84651.msg607310#msg607310
http://yabb.jriver.com/interact/index.php?topic=92168.msg634347#msg634347

Hope CJK fonts issue will be fixed somehow soon.  Thanks.

Edit:  I separated problem and suggestion.

[jam]

I can specify one of Japanese font, "-jis-fixed-medium-r-normal--16-110-100-100-c-160-jisx0208.1983-0", in Tools -> Option -> Tree & View -> Select Font -> User Defined.  The result is this white screen.

[jam]

I could manage to show CJK fonts somehow.   

I think there are two problems in MediaCenter 20.

• Loading single font by using XLoadQueryFont
• Encoding conversion is not taken

I guess MediaCenter is using XLoadQueryFont, so we need to use single font contains all character sets which we want to show.  Therefore, it is required to use iso10646 encoding.  I see.  In above trial, I didn't understand it.  Once I use "-misc-fixed-medium-r-normal-ja-18-120-100-100-c-180-iso10646-1", Chinese fonts appears well like first attachment.  However, as you see, using unicode-font decrease the quality of appearance badly.  I don't know any well designed singe font with alphabet and CJK characters.   

Second problem appears like second attachment.  Track information of this CD is written in Japanese with cp932 encoding (Windows Japanese encoding).  If it was written in UTF-8, there is no problem like first attachment.  So, it means MC for Linux doesn't support encoding conversion at the current version (20.0.31).  Please support encoding conversion in future as MediaCenter for Windows does.  Thanks.

[bob]

If you use unifont from the font selection and you install
-gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1
you'll get the best behavior.
There is no encoding conversion in MC linux (or Mac) at this time.

[jam]

If you use unifont from the font selection and you install
-gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1
you'll get the best behavior.
There is no encoding conversion in MC linux (or Mac) at this time.

Thanks.  It is much better to use -gnu-unifont-medium-r-normal-sans-16-160-75-75-c-80-iso10646-1.  I will attach its image.  MC20 chopped bottom several lines of each Japanese characters though.

[bob]

Thanks.  It is much better to use -gnu-unifont-medium-r-normal-sans-16-160-75-75-c-80-iso10646-1.  I will attach its image.  MC20 chopped bottom several lines of each Japanese characters though.

You can try adjusting the chopping with the intraline pixel trim. Try 0 or a negative integer.

[jam]

You can try adjusting the chopping with the intraline pixel trim. Try 0 or a negative integer.

Thanks.  It doesn't work what we expected.  It enlarges each character little, but it doesn't change chopping pixels.  Attached images are with -2 and -4 pixel trim.  Previous one was zero by default.  I'm using MC20.0.31.

[bob]

Thanks.  It doesn't work what we expected.  It enlarges each character little, but it doesn't change chopping pixels.  Attached images are with -2 and -4 pixel trim.  Previous one was zero by default.  I'm using MC20.0.31.

Unifont has a bug in the specification of its matrix height.

There is a constant in the program to take that into account but it seems like it needs to be somewhat larger.

It will be changed in the next linux build.

[jam]

Unifont has a bug in the specification of its matrix height.

There is a constant in the program to take that into account but it seems like it needs to be somewhat larger.

It will be changed in the next linux build.

Thank you for trying to fix the problem.  I tried 20.0.33.  But, sorry for saying this, 20.0.33 chopps bottom pixels even if they are English characters.  I tried -4, -2, 0, 2, and 4 as IntraLine Pixel Trim, but not only Japanese but also English characters appear wrongly.  I attach IntraLine pixel trim 0 configuration as an example.

BTW, is it difficult to support fontset?  These days, many X applications use a fontset to show multiple character sets.  A fontset is a set of multiple fonts in oreder to display multiple character sets.  It uses different fonts to display different character sets.  I think it is opposite idea to use single font with iso10464 encoding to display multiple character sets.  Check
http://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#Creating_and_Freeing_a_Font_Set
if it is possible.  Thanks.

[bob]

Thank you for trying to fix the problem.  I tried 20.0.33.  But, sorry for saying this, 20.0.33 chopps bottom pixels even if they are English characters.  I tried -4, -2, 0, 2, and 4 as IntraLine Pixel Trim, but not only Japanese but also English characters appear wrongly.  I attach IntraLine pixel trim 0 configuration as an example.

BTW, is it difficult to support fontset?  These days, many X applications use a fontset to show multiple character sets.  A fontset is a set of multiple fonts in oreder to display multiple character sets.  It uses different fonts to display different character sets.  I think it is opposite idea to use single font with iso10464 encoding to display multiple character sets.  Check
http://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#Creating_and_Freeing_a_Font_Set
if it is possible.  Thanks.

I'll take a look when possible. The way we do fonts in MC is very specific to the way the App is constructed and it's possible that this won't fit into that method.

In the meantime, I think your particular desktop is interfering with the height specification. I did notice this on one test machine here where the others all worked as expected.