English in one field, Hindi in another, lovely!

[mattlight]

If my Mac or Windows PC supports the HINDI character set, will Filemaker?

Namely, could I have a field with English and a field with a Hindi translation of the english - and depending where I'm sending a report, print it out in either of the two languages?

I'm not asking it to translate it for me, I know a human that can do that - just display, store and print either of the two above options.

Will I need a plug-in? a setting changed? or just copy and paste and away you go?

Thanks for your help

[BobWeaver]

Maybe. I discussed in another post doing a similar thing with Japanese.

I have the Japanese language kit installed on my Mac. I can enter Japanese text into a field and print it. But Filemaker seems to get a bit confused about the font metrics. I have had to pad some extra spaces at the end of Kanji text to make sure that it all prints out properly. So, you may have to experiment a bit to make sure that it looks okay.

[mattlight]

Thanks Bob,

What do you reckon the answer is? If I'm making the database for someone else and can't test out what Hindi looks like properly, do I just make the text box massive to account for all weird possibilities or is there more to it?

And, by simply having Hindi/Japanese character set installed/enabled on your machine, does it mean that Filemaker will allow you to drop down into Hindi font and just type? Sorry to be vague on this language, I haven't started on this yet and not sure what I'm getting into on this!

Thanks again!

MAtt

[BobWeaver]

My only experience is with a Macintosh, so I don't know how this would work on a PC.

On a Mac, an application can be language kit savvy or not. This is my own terminology. If it is savvy, then when you switch to a different language, you just continue to type into the text field as before, but your text is formatted according to the current language and in the appropriate font. In a non-savvy application, when you click into a text field, a little floating window pops up and your typing gets entered there until you hit enter or tab etc., at which point the text goes into the original text field in the application. Filemaker is a non-savvy application, so this is how it works. It can be a bit annoying if you are doing a lot of keyboard entry, because it's less intuitive and a bit confusing.

As to the padding of spaces, it's not so much an issue of field sizing as it is Filemaker just forgetting to draw the last little piece of text even if the field is big enough. Adding spaces to the end seems to fix the problem. You could probably automate the space padding issue by displaying calculated fields that append a couple of spaces to the original text:

cDisplayField = OriginalField & "

[BobWeaver]

I should just add that if you are on a Mac, then your system install disk will have the hindi language kit on it. So, you can install it and try it.

If you are on Windows, I expect you can download the Hindi language kit from the MS website. But, I don't know if it's free or not.

[Anatoli]

IMHO -- the field must have the proper font for the language set. Or you have to select the text and then select the font.

This works for me with Central European languages.

[BobWeaver]

Yes that's right. For example, when I installed the Japanese language kit on my computer, it installed several Japanese fonts at the same time. If you format a Filemaker field to use one of the Japanese fonts, then whenever you enter data into that field, it automatically switches to Japanese keyboard entry. I assume Hindi would be the same. It works quite well actually, considering that this all seems to be external to Filemaker itself.

[mattlight]

Thanks for all your help guys - I'm looking forward to trying it out. I am developing the system on a PC and it will be run on a mac with the Hindi character set on it.

Am I right in saying you can assign a character set to a specific field? Namely, the whole record is written in english but one field is using the character set of Hindi? does it simply show up in the font list or what? Sorry, I still haven't got to the point where I can properly test this out so I am trying to do a bit of forward thinking with regard to this.

The calculated field sounds like a cracking idea - thanks. Do you know if the problem exists with most foreign character sets or if it was specific to Japanese as in your case? Also, how many spaces did you add, just the two?

Thanks again

[BobWeaver]

You would simply format the field in which the Hindi will appear to use a Hindi font. Just select the field in layout mode and then select the font. On a Mac, the font will determine which language rules are in effect, so as soon as the user goes to the Hindi field, the text entry should be in Hindi.

As to padding spaces in the field, this is strictly experimental. I have only had problems with Japanese. I don't know whether this will be a problem with Hindi. I think I padded on 2 spaces in my case. Can't remember for sure.

[mattlight]

thanks - an never ending source of knowledge!

[mattlight]

I'm trying to test out how to select Hindi as one of the fields text type! I can select font obviously, and size, etc - I think I'm missing something here - how do I get Hindi?

I am testing it out on a PC and have downloaded the indic language set which supports Hindi.

Thanks

[mattlight]

Just to add something to what I've said

I am able to select Hindi as my chosen character set and then type in Microsoft Word in Hindi with no problem what-so-ever. It must be a setting within Filemaker to accept the use of the operating system character sets.

Please help! Thanks

[BobWeaver]

I don't know how that would work in Windows. On a Mac, every font has a corresponding text encoding. So, when you format a field to a specific font, then it automatically assigns the corresponding text encoding, and also the keyboard entry method. Since your end user will be using a Mac, then it should work with no additional setup.

[mattlight]

Still haven't solved this problem!

In every other application, I can write in Hindi - even though I don't speak it, I bash around on the keyboard and it uses the hindi character set in all MS applications regardless of the chosen font - it is all in the chosen language on the toolbar at the bottom of the screen.

In Filemaker it does not work! comes out with a series of ::? - I have been into the add Fonts thing and added every single one of them and tried every one of them - no go.

Doesn't filemaker support the fonts and character sets which are imbedded in the OS or does it require a Filemaker download update to do different languages on the PC? Also, tried it out on a Mac - got the Asian character set loaded up but can't even get it to work in MS apps neither mind Filemaker!

The only thing that is really annoying now is that on my Outlook and on my mates Mac, all dates of emails and files are now written in Hindi! Bloody great, can't get it to work where we want and can't get rid of it from where we don't want it - PLEASE HELP!

Thanks

[BobWeaver]

Unfortunately, Filemaker has never officially supported any text encoding other than Roman (unless you buy the Hindi version of Filemaker). Maybe it's just lucky that there is something in the Mac OS routines that FM uses to render text and that recognizes the encoding and does it correctly. The Windows version no doubt does things entirely differently. But, if the end user is going to be on a Mac, you may still be okay though. Doesn't help you as a developer though.

[mattlight]

But,

How come all other Windows applications support any fonts that your keyboard layout is set to do? Same on a mac as well - in fact, now I can't stop the date and time in Outlook from being in Hindi - also, my collegue is on Entourage and he's now showing date in Hindi - All Microsoft products support chinese, japanese, Papa New Guinean even - so why does Filemaker have such a hard time?

Bob - I'm not really asking you - just anyone with the answer will do.

I haven't had a chance to look at this forum for a while because of an office fire in the front of our building which has completely gutted out the adjasent office to me. Staggeringly, the fire stopped at the 2 inch partition between my office and theirs. Unfortunately, our servers were installed in there cabinet and everything made of plastic was melted - cables, keyboards, mice, fronts of server hardware and imploded monitors with what looks like melted cheese dripped and set over the floor.

The amazing thing is though - once the cables were replaced, the servers happily booted up and the hard drives span and gave us all our data back!!!

The moral of the story however

**** Always take your DLT, DAT, CD and DVD backups OFF SITE in case of FIRE ****

Hard Drives really don't seem to mind 300 degrees of blazing heat as long as licks of flames didn't savage their circuitary. Also, make sure you use DUST BUSTER to get rid of any unwanted conducting carbon particles.

[BobWeaver]

Glad your mishap had a happy ending.

[BobWeaver]

Matt, I was playing around with my own project this weekend, and came up with an idea that may be of some use to you. I was trying to make my Japanese database independent of fonts and platform and came up with the idea of converting the text into graphics and storing it in a container field. I tested it on my file with 6000 records, and found that using graphics had surprisingly little effect on the file size. Of course we are talking about a relatively small black and white image in this case.

I generated the graphics automatically by script. Since I have been able to get the text to display properly on my machine, I ran a script which switched to a layout which displayed only the Japanese text field, switched to preview mode, copied the image, switched back to browse and then pasted the image into a container field. Then on to the next record and repeat ad infinitum. For 6000 records it only took about 5 minutes and now the database will run on any computer whether the language kit and font are present or not. Of course this only works if you can actually get the text to display properly on your own machine in the first place, and your user may not like the way he had to create new messages and convert to graphics, but it's an idea.

In fact this same technique can be used to automatically generate thumbnails of stored or referenced images without the use of plug-ins. I will post an example in the samples forum when I get it working.