Know I know that DBISAM doesnt currently support unicode and to be honest im
pretty much in the dark regarding unicode, but I may have to modify my
application to support Korean & Japanese...Not sure where to start really,I
a have few of questions for hopefully someone who has done this before.

1. I assume unicode just refers to the use of double byte fonts?.
2. Where do I get these fonts, do I need to purchase a Korean version of
Windows XP?
3. Do the standard delphi controls ie TDBGrid etc support unicode, or do you
need to purchase new controls?
4. Why does DBISAM need to support unicode specifically, is it so that
double byte characters can be stored in char fields? Any other reason?
5. Anything other helpfull hints would be greatly appreciated.!

Cheers
Clive.

BTW, im on D7 Enterprise.

"Clive" <dd@dddd.com> wrote in message
news:FF31CD02-32CB-4173-9B69-C8E805AEF703@news.elevatesoft.com...
> Know I know that DBISAM doesnt currently support unicode and to be honest
> im pretty much in the dark regarding unicode, but I may have to modify my
> application to support Korean & Japanese...Not sure where to start
> really,I a have few of questions for hopefully someone who has done this
> before.
>
> 1. I assume unicode just refers to the use of double byte fonts?.
> 2. Where do I get these fonts, do I need to purchase a Korean version of
> Windows XP?
> 3. Do the standard delphi controls ie TDBGrid etc support unicode, or do
> you need to purchase new controls?
> 4. Why does DBISAM need to support unicode specifically, is it so that
> double byte characters can be stored in char fields? Any other reason?
> 5. Anything other helpfull hints would be greatly appreciated.!
>
> Cheers
> Clive.
>

Clive,

<< I may have to modify my application to support Korean & Japanese >>
Separately, or showing more than one Asian language on the same screen?
One language at a time: you can handle it by using the codepage for that language.
Two or more languages: you have to move to Unicode.

<<  1. I assume unicode just refers to the use of double byte fonts? >>
Not so. Unicode refers to how the data is *stored*. It also affects how data is
processed within your application (as widestrings). Unicode determines the total size
of all the character sets which can be addressed. Unicode can handle all the world's
alphabets with a unique code for each character.

<< 2a. Where do I get these fonts?
Arial Unicode MS is supplied with current versions of Office, but you can't
buy it separately (as far as I know). Arial Unicode MS covers just about
any alphabet you're likely to come across. And there are also freeware fonts
like Code2000: great coverage of alphabets, but draft-like image quality.

<< 2b. Do I need to purchase a Korean version of Windows XP? >>
If you want to go the codepage route, I guess you might have to.
Certainly I test all my stuff on Chinese and Japanese versions of Windows,
but I don't buy. I just borrow my translators' laptops...

<< 3. Do the standard delphi controls ie TDBGrid etc support unicode, or do
> you need to purchase new controls? >>
That's the problem: standard "out-of-the-box" Delphi simply doesn't
handle widestrings in visual controls. The good news is that you don't have to buy.

There is a wonderful set of Unicode controls for free, available from TntWare:
 http://www.tntware.com/delphicontrols/unicode/
but they only display Unicode with Win NT, 2000, XP etc.

If you want Unicode to work on Win9x, then you will have to buy the Elpack
controls from LMD. Here's their webpage:
 http://www.lmd.de/products/

<<4. Why does DBISAM need to support unicode specifically, is it so that
double byte characters can be stored in char fields? Any other reason? >>
We developers need widestring column types, which are not available in
DBISAM versions up to ver 4. And there are plenty more problems which Tim
might answer....

<< 5. Anything other helpfull hints would be greatly appreciated. >>
Whatever else you do, you'll need to have your Asian languages installed in
Windows: Control Panel | Regional & Language Options  |  Languages.

Personally, I think that implementing Unicode without a unicode-enabled
database is a fair old nightmare. We have done it, but it's not an optimal
solution. That's why I'm really looking forward to DBISAM ver 5 / ElevateDB,
so that we can do the job properly - right from the start.

HTH,
Dan

Lexicon Software Ltd, Bath, UK

Clive,

<< 4. Why does DBISAM need to support unicode specifically, is it so that
double byte characters can be stored in char fields? Any other reason? >>

It starts there and continues on with partial-length index key comparisons,
etc.  This is one of the main reasons that we're doing ElevateDB.  It is
designed from the ground up to support both ANSI and Unicode through and
through from the SQL to the data storage.  To "modify" DBISAM to support
things in such a manner would have been more work than just doing ElevateDB.
Plus, we were able to add all sorts of nicer things like per-column
collation specifications so that you can have multiple collations in the
same table, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks for all the Info Dan.

No it just needs to support either , not both at the same time.
I found a free Korean Unicode font and managed to get Korean showing in with
the TNT controls from your link below, they look great!.

Im not going to add  myself onto the list of people asking for a ElevateDB
release date, but I wait patiently !

Cheers
Clive

"Dan Rootham" <roothamd@yahoo.co.uk> wrote in message
news:2BD81B27-0E40-4844-82DD-55825266721F@news.elevatesoft.com...
> Clive,
>
> << I may have to modify my application to support Korean & Japanese >>
> Separately, or showing more than one Asian language on the same screen?
> One language at a time: you can handle it by using the codepage for that
> language.
> Two or more languages: you have to move to Unicode.
>
> <<  1. I assume unicode just refers to the use of double byte fonts? >>
> Not so. Unicode refers to how the data is *stored*. It also affects how
> data is
> processed within your application (as widestrings). Unicode determines the
> total size
> of all the character sets which can be addressed. Unicode can handle all
> the world's
> alphabets with a unique code for each character.
>
> << 2a. Where do I get these fonts?
> Arial Unicode MS is supplied with current versions of Office, but you
> can't
> buy it separately (as far as I know). Arial Unicode MS covers just about
> any alphabet you're likely to come across. And there are also freeware
> fonts
> like Code2000: great coverage of alphabets, but draft-like image quality.
>
> << 2b. Do I need to purchase a Korean version of Windows XP? >>
> If you want to go the codepage route, I guess you might have to.
> Certainly I test all my stuff on Chinese and Japanese versions of Windows,
> but I don't buy. I just borrow my translators' laptops...
>
> << 3. Do the standard delphi controls ie TDBGrid etc support unicode, or
> do
>> you need to purchase new controls? >>
> That's the problem: standard "out-of-the-box" Delphi simply doesn't
> handle widestrings in visual controls. The good news is that you don't
> have to buy.
>
> There is a wonderful set of Unicode controls for free, available from
> TntWare:
>  http://www.tntware.com/delphicontrols/unicode/
> but they only display Unicode with Win NT, 2000, XP etc.
>
> If you want Unicode to work on Win9x, then you will have to buy the Elpack
> controls from LMD. Here's their webpage:
>  http://www.lmd.de/products/
>
> <<4. Why does DBISAM need to support unicode specifically, is it so that
> double byte characters can be stored in char fields? Any other reason? >>
> We developers need widestring column types, which are not available in
> DBISAM versions up to ver 4. And there are plenty more problems which Tim
> might answer....
>
> << 5. Anything other helpfull hints would be greatly appreciated. >>
> Whatever else you do, you'll need to have your Asian languages installed
> in
> Windows: Control Panel | Regional & Language Options  |  Languages.
>
> Personally, I think that implementing Unicode without a unicode-enabled
> database is a fair old nightmare. We have done it, but it's not an optimal
> solution. That's why I'm really looking forward to DBISAM ver 5 /
> ElevateDB,
> so that we can do the job properly - right from the start.
>
> HTH,
> Dan
>
> Lexicon Software Ltd, Bath, UK
>

One more question.

Where do you store the transalations?, as String Resources, hardcoded or in
the DB?

"Dan Rootham" <roothamd@yahoo.co.uk> wrote in message
news:2BD81B27-0E40-4844-82DD-55825266721F@news.elevatesoft.com...
> Clive,
>
> << I may have to modify my application to support Korean & Japanese >>
> Separately, or showing more than one Asian language on the same screen?
> One language at a time: you can handle it by using the codepage for that
> language.
> Two or more languages: you have to move to Unicode.
>
> <<  1. I assume unicode just refers to the use of double byte fonts? >>
> Not so. Unicode refers to how the data is *stored*. It also affects how
> data is
> processed within your application (as widestrings). Unicode determines the
> total size
> of all the character sets which can be addressed. Unicode can handle all
> the world's
> alphabets with a unique code for each character.
>
> << 2a. Where do I get these fonts?
> Arial Unicode MS is supplied with current versions of Office, but you
> can't
> buy it separately (as far as I know). Arial Unicode MS covers just about
> any alphabet you're likely to come across. And there are also freeware
> fonts
> like Code2000: great coverage of alphabets, but draft-like image quality.
>
> << 2b. Do I need to purchase a Korean version of Windows XP? >>
> If you want to go the codepage route, I guess you might have to.
> Certainly I test all my stuff on Chinese and Japanese versions of Windows,
> but I don't buy. I just borrow my translators' laptops...
>
> << 3. Do the standard delphi controls ie TDBGrid etc support unicode, or
> do
>> you need to purchase new controls? >>
> That's the problem: standard "out-of-the-box" Delphi simply doesn't
> handle widestrings in visual controls. The good news is that you don't
> have to buy.
>
> There is a wonderful set of Unicode controls for free, available from
> TntWare:
>  http://www.tntware.com/delphicontrols/unicode/
> but they only display Unicode with Win NT, 2000, XP etc.
>
> If you want Unicode to work on Win9x, then you will have to buy the Elpack
> controls from LMD. Here's their webpage:
>  http://www.lmd.de/products/
>
> <<4. Why does DBISAM need to support unicode specifically, is it so that
> double byte characters can be stored in char fields? Any other reason? >>
> We developers need widestring column types, which are not available in
> DBISAM versions up to ver 4. And there are plenty more problems which Tim
> might answer....
>
> << 5. Anything other helpfull hints would be greatly appreciated. >>
> Whatever else you do, you'll need to have your Asian languages installed
> in
> Windows: Control Panel | Regional & Language Options  |  Languages.
>
> Personally, I think that implementing Unicode without a unicode-enabled
> database is a fair old nightmare. We have done it, but it's not an optimal
> solution. That's why I'm really looking forward to DBISAM ver 5 /
> ElevateDB,
> so that we can do the job properly - right from the start.
>
> HTH,
> Dan
>
> Lexicon Software Ltd, Bath, UK
>

Clive,

<< One more question. Where do you store the translations?, as String Resources, hardcoded
or in the DB? >>

Our product is a big multilingual dictionary, so for that purpose we obviously store  
the translations in a DBISAM database - one table per language. For West European
languages we store the data in string fields, and for Asian languages we store
Unicode data in blob fields. When ElevateDB arrives, we'll use widestring fields
to hold all languages as Unicode.

When we produce a user application which needs a multilingual interface,
we also store translations for the GUI captions and hints in a DBISAM table.
This is used by our own "Translate" function which takes a LangID parameter.
We looked at various localisation tools, but decided to do our own "on-the-fly"
translating of the UI. This way, the user can swap from one interface language
to another just with a menu choice. The downside is that you have to assign
all the captions and hints on start-up and every time the user changes the
interface language. And that includes everything: the Options screen, the About
screen and every dialogue message.

Regards,
Dan

Lexicon Software Ltd, Bath, UK

Thanks, Thats what I thought I would do also.

"Dan Rootham" <roothamd@yahoo.co.uk> wrote in message
news:B72D6401-CF28-4AC4-9804-F39555725F44@news.elevatesoft.com...
> Clive,
>
> << One more question. Where do you store the translations?, as String
> Resources, hardcoded
> or in the DB? >>
>
> Our product is a big multilingual dictionary, so for that purpose we
> obviously store
> the translations in a DBISAM database - one table per language. For West
> European
> languages we store the data in string fields, and for Asian languages we
> store
> Unicode data in blob fields. When ElevateDB arrives, we'll use widestring
> fields
> to hold all languages as Unicode.
>
> When we produce a user application which needs a multilingual interface,
> we also store translations for the GUI captions and hints in a DBISAM
> table.
> This is used by our own "Translate" function which takes a LangID
> parameter.
> We looked at various localisation tools, but decided to do our own
> "on-the-fly"
> translating of the UI. This way, the user can swap from one interface
> language
> to another just with a menu choice. The downside is that you have to
> assign
> all the captions and hints on start-up and every time the user changes the
> interface language. And that includes everything: the Options screen, the
> About
> screen and every dialogue message.
>
> Regards,
> Dan
>
> Lexicon Software Ltd, Bath, UK
>