Link to home
Start Free TrialLog in
Avatar of ccrdude
ccrdude

asked on

Font.CharSet for Farsi

I'm looking for a value for Font.Charset that fits for the Farsi (Persian) language.

I know that ARABIC_CHARSET is 178, but according to a translator who's working on Farsi, Farsi has 4 additional letters which distinguishes it from Arabic. And my apps (Delphi 7) using TMemo and TEdit controls set to Font.Charset=178 won't allow to enter those four special characters.

Does anyone have experience with Farsi & Delphi, and could tell me which charset to use? Or if 178 is the correct one, what trick to use to allow Delphi to let those letters entered?

Thank you!
Avatar of BigRat
BigRat
Flag of France image

Avatar of ccrdude
ccrdude

ASKER

Your first link doesn't mention the license the font comes under, your second link does even explicitely forbid to distribute the font (and is even labeled *web* font - probably not usable for smaller font sizes as common in applications). So what use would they be?

And sorry, I'm not speaking about the font (which doesn't pose any problems), I'm speaking about the CHARSET. Which I would need with any font, even those two.
>>And sorry...

You don't have to be sorry, I thought I didn't understand the question because my googling turned up lots of entries, and I wasn't sure why you rejected them and asked here.

According to MSDN there isn't one for Farsi, I suspect you'll just have to set ARABIC_CHARSET. Obviously setting the face name will force the font chooser to choose that particular font.

TMemo and TEdit are just wrappers for the corresponding Windows controls and are rendered by the API ExTextOut using (effectively) the TFont object. The TFont object when rendered selects or makes a font internally in Windows (LOGFONT).

Now in both controls are 8-bit byte controls so the text rendering is different on different platforms. On Win95 and derivatives the value of the 8-bit character indexes a 256 entry glyph table in the True Type Font. On WinNT and derivatives the 8-bit characters are converted to Unicode using the system locale and the Unicode value is used to find the glyph in the font. This conversion is done my MultiCharToWideChar and the four additional characters might not be mapped to their Unicode equivalents. (Question: do these characters have unicode values?)

Avatar of ccrdude

ASKER

Yes, those additional characters have Unicode equivalents: Peh, Tcheh, Jeh, Gaf.
See http://encyclopedia.laborlawtalk.com/Persian_language

I'm not sure if you ever have used a foreign system, or just installed support for a foreign system. If you did, you would have seen that Microsoft hsa the defaults fonts available in all localizations. Just by installing Arabic support, I can see Arabic letters in Arial, so I don't see the need to install yet another font that supports Arabic. I guess we can try to play around with the default fonts (Arial, MS Sans Serif, etc.)...

Arabic being an example, since Arabic has a separate language code (ar) from Farsi (fa, fa_IR).

I know that MSDN does not list it - of course I searched MSDN before this, I also looked through the SDK file WinGDI.h, where known charsets are defined (because you can't always depend on Borland having translated everything), and I searches koders.com for possibly separate definitions. If this would've been a simple 5-minute-Google question, I surely wouldn't have asked here ;)
>>If this would've been a simple 5-minute-Google question, I surely wouldn't have asked here ;)

You wouldn't believe the sort of questions that get asked here!

>>I'm not sure if you ever have used a foreign system, or just installed support for a foreign system.

I'm located in Germany. Our software is Unicode compliant and I have on my English laptop German, Russian and Hebrew installed.

>>those additional characters have Unicode equivalents:

They're in Unicode standard 2.0 even!

Peh 067E
Tcheh 0686
Jeh 0698
Gaf  06AF

Like I said the problem is the conversion from the 8-bit character set (is your locale set to Arabic?) and Unicode. For this the MultiByteToWideChar API function uses the tables installed by MS corresponding to the local (on WinNT derived systems). The Arabic Charset property implies code page 1256. This code page has the letters at :-

81 = U+067E : ARABIC LETTER PEH
8D = U+0686 : ARABIC LETTER TCHEH
8E = U+0698 : ARABIC LETTER JEH
90 = U+06AF : ARABIC LETTER GAF

Now once again I see that I have not understood the question :-

>>won't allow to enter those four special characters

has not nothing to do with fonts.

Question: How are you trying to enter those characters?

Suggestion: Try using the ALT key method. Hold ALT down and type in the numeric decimal value of the key (HEX 81 = 129) then release ALT.




Avatar of ccrdude

ASKER

Well, it's still set to ARABIC_CHARSET, I've installed Farsi keyboard support on my XP, and entered my application.

Using Alt+ your hex code (0x81 = 129, 0x8D = 141, 0x8E = 142, 0x90 = 133) I get the umlaut ü, two question marks, and an a with accent. Using any other letters a-z gets me Farsi/Arabian characters, so I know keyboard layout and TMemo character setting are working correctly together.

Copying the character from the Screen keyboard (Zeichentabelle in german) and pasting it into the Delphi TMemo works btw. I guess I have to check with the translator how exactly he tries to add them.
>>Copying the character from the Screen keyboard (Zeichentabelle in german) and pasting it into the Delphi TMemo works.

This means that the code page of the systems 8-bit data and the font are correct.

>>Using Alt+ your hex code (0x81 = 129, 0x8D = 141, 0x8E = 142, 0x90 = 133) I get the umlaut ü, two question marks, and an a with accent.

Which means that this feature is not available.

>>Zeichentabelle in german

Character Map in English. BTW I'm not German.
SOLUTION
Avatar of huji
huji
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of ccrdude

ASKER

I'm afraid your easiest way is the most complicated for me, since it would mean redesigning a huge application and probably re-doing translations into 40 languages :-/
Unicode is planed for the future, but it's still a major release away ;)

Regarding the LCID list - I've created a table showing for each language microsoft locale, linux locale, ISO-639-1 und -2, SIL, Dos/Win/Mac Codepages, Web ISO and other standards, and Delphi charset.
IBM (IBM-864) & Windows (Windows-1256) Codepage, ISO-8859 standard (ISO-8859-6) are the same for Farsi and Arabic, just the Mac uses a different codepage (MacFarsi instead of MacArabic)...

Imho the translator has avoided the problem by choosing a font that would display those characters, but I'll have to ask him again...
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of ccrdude

ASKER

I already use one component from the TNT set :)

My problem with exchanging the components is the translation package. Since I don't like the Borland one, which creates files of half a Megabyte per translation and difficulties for the translators, I've written my own, which simple goes through all components and writes/reads them to a file. Would have to make that compatible to the TNT tools. But I couldn't replace everything (got two other special components I can't simply replace, and then there are forms and some other things as well...).

Delphi 2005 can already understand UTF8 source files, but imho not the VCL. And I doubt 2006 (which I already have preordered) will be able to.

But I surely won't switch to .Net. I like backward compatibility to 95, and I would never ask of any user of my software to download a huge .Net framework for a small application. And sorry - I can work in Visual C as well, and I have enough Microsoft stuff on my machine to know that it's sometimes even worse than Delphi (and that means a lot :D ).

In fact, I've nearly switched to FreePascal+Lazarus by now, but: same problems there ;)

I guess I'll simple split the points between you two to close the question, as I guess there won't come any better answer ;)
Well, I just wanted to help. I reached this question by ocasion, and I'm no expert in Delphi programming.
Huji