I am analyzing font file of "data\abc\abc.abc".
However it is not imaginable file format.
I wanna make new font file and replace to "katakana" character.
Do you know file format of abc.abc?

Unfortunately not, but as a complete guess have you tried looking at it as a large bitmap; perhaps Scawen is bliting the text to the screen.

Or, slightly more likely, given the scaling; its vector based? Just some food for thought.

i think the font is rendered in 3D and not just a bitmap.
At least it looks like that.

Thanks,

It seem that bitmap is not included.
What data included in file?
Character code?
I do not have idea.


>Unfortunately not, but as a complete guess have you tried looking at it as a large >bitmap; perhaps Scawen is bliting the text to the screen.
>
>Or, slightly more likely, given the scaling; its vector based? Just some food for thought.

I think two ways.
1. Font is rendered from base font.
2. Font is made by LFS.


>i think the font is rendered in 3D and not just a bitmap.
>At least it looks like that.

Its given a 3d illusion, i believe, by layering 2 items of the same text on top of each other.

I'm still fairly certain its a bitmap or vector based format - although I really cant check it out at work.

Maybe this site could be interesting for you:
http://human-factors.arc.nasa.gov/SLAB/Doc/ref/

That's what I found in another source code that uses this SRAPI:

Quote :

SRChar is the char type used in SRAPI. May change depending on the implementation.

So it seems that this SRAPI library is used to render at least the fonts. Maybe you can find some more detailed information in the reference, which URL I posted at the beginning.

//EDIT: Ok, I now took a more detailed look on the site I posted and now I am unsure, if that was really what you search. But I'll try to find some more infos

Thanks!!!
I'm checking SRAPI.

[QUOTE]

HighBridge
[WHRT] WorkaHolicRacingTeam@JP

Hello.

It's nothing to do with SRAPI... LFS uses its own font system. The special LFS data in the file is used to create the font texture pages in memory. The font data is created in our own font editor.

The font uses the Latin-1 character set, which covers Western Europe very well but doesn't help at all with Russian, Arabic, Chinese, Japanese, Korean, Greek and many more.

I've been researching recently, about the Unicode system which is probably the best way for LFS to support all the world's languages. But it's quite a big deal to implement it. LFS would need to generate a new font texture in memory whenever it encountered a character that it has not yet drawn. It will need to search the Windows fonts, to try to find a font that contains the required character. This is because not all computers contain a single font that covers the whole Unicode character set... and we cannot provide one either because such fonts are over 20 MB and there aren't any available for free download. There are several more complications in creating a font system that can support the Unicode character set, which contains more than 50,000 characters. Anyway, if i do find a way to get past each obstacle, then LFS could be translated using UTF-8 encoded text files, or something similar.

I think that's the only way to do it. I don't think it's really possible to simply substitute the Latin letters for Katakana or Hiragana, or Cyrillic. Because of many problems that would come up, For example the user names, which are in Latin characters, would appear as random incorrect characters. Also, when a Japanese person would meet a European person online, their Latin text would appear in random Katakana characters and wouldn't make sense.

So i think it's Unicode or nothing, really. I would want the correct characters to appear on anyone's screen, no matter where they are from, as long as there is a font on their computer which contains the required character. As i say... i have been looking into it recently, and did manage to make some characters appear on a texture. But it's a big job to to properly, with thousands of lines of code in LFS that use text strings. And i'm also researching and experimenting with other things at the moment. So i can't say if or when the Unicode support will be implemented.

Thank you for the explanation.
Therefore i need know file format of abc.abc.
Maybe impossible...

Eupopean font.


Japanese font.

Scawen:

To take a horrifically simplistic view of this, as much as I understand Direct3D can render TrueType fonts. Couldn't you just replace your font with calls to render your text using TrueType fonts? If that was possible, you could put the name of the true type font into the cfg and then people could substitute whatever Unicode font they have for the default one. The only thing missing then is that the translation files are stored as UTF-8/16/32 instead of ASCII with latin-1.

As far as I am aware sdether, the code for using TrueType fonts is still slower than blitting your own to the screen. Seeing as we need to save as many cycles as possible, this seems to be a logical optimisation point.

Quote from highbridge :

Thank you for the explanation.
Therefore i need know file format of abc.abc.
Maybe impossible...

Eupopean font.
...

Japanese font.
...

Thanks for showing me the code pages. Until now, i did not know there was a single-byte code page which could support Japanese.

So now i'm having a look at the single-byte code pages... this may be an easier way to support some more languages, including Japanese (Katakana only), Cyrillic, Greek... but it would not support Kanji or Chinese Characters. I still have some more investigation to do.

Quote from sdether :

Scawen:

To take a horrifically simplistic view of this, as much as I understand Direct3D can render TrueType fonts. Couldn't you just replace your font with calls to render your text using TrueType fonts? If that was possible, you could put the name of the true type font into the cfg and then people could substitute whatever Unicode font they have for the default one. The only thing missing then is that the translation files are stored as UTF-8/16/32 instead of ASCII with latin-1.

You are right that is horrifically simplistic.

It's a bit like saying...

"How to build a house - just get some bricks and put them on some land. Job done!"

In fact the full Unicode support is a major task. It can be broken down into 3 sections - display / internal processing / input. Display is complicated by the support of over 50,000 characters instead of 255, which means they must be generated and discarded on the fly, storing characters on dynamically rendered textures instead of simply storing a pregenerated version of all available characters, so that LFS can run smoothly and do specialised things like coloured text. Internal processing is complicated because text processing is handled in over 1000 places in the LFS code, and each one would need to be updated manually to handle multibyte characters - it's not possible in LFS to just flick a switch to suddenly support multibyte characters - many things including several file formats and multiplayer packets and memory allocations, depend on the size of the characters. Input is complicated by the fact that it's only XP that can handle Unicode input. If i simply set the UNICODE define and compile LFS to accept Unicode input to its windows, it just doesn't run on Win98 / WinME.

I'm not saying it's impossible, i'm just pointing out that even what i can see, is several weeks of work. And that's not taking account of all the grey areas where i don't know what is going to happen.

It's possible that the full Unicode support would be best left until some future version of LFS (some years from now) which is DX9 based and only works on XP or later versions of Windows.

For now, i'm looking into the single character code pages...

Quote from Scawen :

Thanks for showing me the code pages. Until now, i did not know there was a single-byte code page which could support Japanese.

So now i'm having a look at the single-byte code pages... this may be an easier way to support some more languages, including Japanese (Katakana only), Cyrillic, Greek... but it would not support Kanji or Chinese Characters. I still have some more investigation to do.

Yes, this is 8bits character.
calling JIS X 0201. (not ISO)
JIS is Japanese Industrial Standards.
I found English page
http://www.cs.mcgill.ca/~aelias4/encodings.html

I want to be replacing the font data from 0xa0 to 0xdf with the katakana.
A lot of Japanese might not think the Kanji character to be necessary.

Hello highbridge.

For testing, i have made a modified abc.abc with Half Width Katakana (attached) - like Windows Codepage 932 or JIS X 201

I think you must set your keyboard input mode to "Half Width Katakana" but i don't know about keyboard modes... so i don't really know if that is a normal thing to do. On my computer, i can enter the Katakana characters by pasting these Latin characters :

¡¢£¤¥¦§¨©ª«¬*®¯
°±²³´µ¶·¸¹º»¼½¾¿
ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏ
ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß

Please can you test the abc.abc and tell me :

1) Does it work ok - can you enter the Katakana characters with your keyboard?

2) Are my characters readable - or do some of them look wrong?

[ note : this is just a test - there is more to do for proper international support - i would like the correct characters to appear on all screens, but of course that would not happen with this test version - on a European's computer the Latin characters would appear ]

Quote from Scawen :

Hello highbridge.

For testing, i have made a modified abc.abc with Half Width Katakana (attached) - like Windows Codepage 932 or JIS X 201

I think you must set your keyboard input mode to "Half Width Katakana" but i don't know about keyboard modes... so i don't really know if that is a normal thing to do. On my computer, i can enter the Katakana characters by pasting these Latin characters :

¡¢£¤¥¦§¨©ª«¬*®¯
°±²³´µ¶·¸¹º»¼½¾¿
ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏ
ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß

Please can you test the abc.abc and tell me :

1) Does it work ok - can you enter the Katakana characters with your keyboard?

2) Are my characters readable - or do some of them look wrong?

[ note : this is just a test - there is more to do for proper international support - i would like the correct characters to appear on all screens, but of course that would not happen with this test version - on a European's computer the Latin characters would appear ]

Thanks Scawen

We have checked it.
It is nice font
That's Great!!
It is very useful for Japanese racer.

1) Does it work ok - can you enter the Katakana characters with your keyboard?

Yes,
How to input Katakana.
1. Input T and enter message box.
2. Input kanji convert key.
http://whrt.web.infoseek.co.jp/img/Capu0046.jpg
3. Input F8 of shortcut key.
http://whrt.web.infoseek.co.jp/img/Capu0047.jpg
4. Input Enter.
http://whrt.web.infoseek.co.jp/img/Capu0048.jpg

http://whrt.web.infoseek.co.jp/img/Capu0050.jpg

2) Are my characters readable - or do some of them look wrong?

Perfect!!
Thank you very much.

HighBridge

very cool and important. mostly for asian market is gonna be great. keep it up.

This could also be used for the language file, no?

Quote from xaotik :

This could also be used for the language file, no?

http://image.space.rakuten.co. ... 76/img6c0abdf636oe1o.jpeg

Quote from highbridge :

http://image.space.rakuten.co. ... 76/img6c0abdf636oe1o.jpeg

Yay, excellent news.
Needless to say that a greek version of abc.abc would be nice... and I'm sure the request for a cyrillic one won't be too far away.

(first one that asks for a Klingon version gets a kick in the head)

Quote from highbridge :

http://image.space.rakuten.co. ... 76/img6c0abdf636oe1o.jpeg

WOW! That looks great!

I'm pleased it's working well. I'm continuing this work now, leading to a compatible patch in which we all have the same font file, and can see other people's characters on our own screen, regardless of which input mode we are using. So the Latin users can see Katakana characters, and Japanese users can see Finnish characters or whatever.

Quote from xaotik :

Needless to say that a greek version of abc.abc would be nice... and I'm sure the request for a cyrillic one won't be too far away.

Yes and no...

Yes, i would like to support Cyrillic, Czech and Greek in this new version (as far as possible in the time available - i don't want to make any promises about exactly which languages will be supported in the first version). But i won't do any more single-code-page test versions of abc.abc, like i did for the Katakana. I'll just continue with this universal abc.abc system now.

Unfortunately i can't support Arabic or Hebrew yet, because they go from right to left. And Chinese characters can't be done either, because they would need too big a change of system... there are several thousands of them - so they can't fit onto static font textures, and can't be supplied with LFS.

Quote from Scawen :

But i won't do any more single-code-page test versions of abc.abc, like i did for the Katakana. I'll just continue with this universal abc.abc system now.

Sounds good to me. I don't think anyone is in a hurry for that anyhow, this is a racing simulator after all, not an instant messenger.

wow! great work again Scawen!

Highbridge, please can you run this attached exe and then paste a screenshot of the results? English example is attached...

You can see on the forum main page i'm asking for more info about some other languages. But, because we've already tested Japanese, this is the only extra info we need.

Quote from Scawen :

Highbridge, please can you run this attached exe and then paste a screenshot of the results? English example is attached...

You can see on the forum main page i'm asking for more info about some other languages. But, because we've already tested Japanese, this is the only extra info we need.

Here is result.
http://whrt.web.infoseek.co.jp/data/00000.jpg

HighBridge