Mr.Kim.Sanders

Further to my post #7 above, I suggest that TMG hires someone with Microsoft who has experience with both Visual FoxPro and Unicode-enabled database software. There ought to be a way for that someone to upgrade the proprietary capabilities to full Unicode operability, perhaps by offering a download which allows the user the ability of converting the file extensions away from those used by Visual FoxPro. /Mr.Kim.Sanders@shaw.ca A true master isn't content with an outmoded system.

• I suggest that my feelings and expectations have been shaped by my life-long experience — my interest in people, my attention to details such as language and culture, and my exposure to the increasingly-Unicode Internet context. I find myself increasingly interested in the world outside of my own experience and the cultures that have limited my perspective, so that these shared challenges now in mind may yet be overcome. • If I could know which program(s) would be able to import my TMG 6.12 project of over 32900 names fully intact, that would be awesome, as would having the know-how to write such a program. But, alas, as a mere mortal, I too have my limitations. Even rocket scientists are vapourised in space every so often because they rely on the rest of the team which has remained on the ground. I am no rocket scientist. But neither am I willing to be vapourised. • That having been said, I still feel that the goal of Unicode-compatibility is very much a worthy project. Perhaps there are yet those without monetary ambitions, whether connected to Microsoft or the Unicode Consortium or some other relevant enterprise who would gladly share their expertise. The Internet itself suggests as much, as the remainder of this post seems to indicate. • Looking at http://www.west-wind.com/presentations/fox.../foxunicode.asp, Rick Strahl tells us (near the end of his article »The VFP user interface basically allows you to display a single code page at a time. This means that if you want to display output from multiple different locales with differing character sets you're pretty much out of luck with the native Visual FoxPro user interface. »However, there is a workaround: You can skip using VFP controls and use ActiveX controls instead. Figure 5 shows a very simple Visual FoxPro form of the multi-language data I've been working with in this article. Figure 5 – Displaying Unicode in Visual FoxPro applications requires that you use ActiveX controls. Other than the default Locale, Visual FoxPro’s native controls cannot display Unicode. This form uses the DataDynamics SharpGrid and the Microsoft Forms Editbox to display the Unicode text.« • If Strahl is right, then the rest may become just a matter of the design team tackling one part at a time, so that TMG users who are not so tech-savvy might just be able to download upgrades from the WhollyGenes sites as they can be made available.

It is a reality that I personally would have names in my tree that are from all over the world, in languages as diverse as Czech, Vietnamese, Persian, Turkish, and Chinese. The reality is that the Web and even family tree programs are increasingly a Unicode world. I feel that it is, thus, not unreasonable to expect to see them in TMG in an orthographically correct manner, according to the country of origin, just as I can in my e-mail (now that I've switched from Outlook Express to Mozilla Thunderbird 2). And, from the postings I have seen on the various boards here, I know that others face the same Web reality and have similar family tree expectations. It is also a reality is that my Character Map shows up in Unicode even in my TMG (while the given edit screen is still open), so I see no "eternal" reason prohibiting TMG and all its component parts from being able to move with the times (at some point in time) to full Unicode-compatibility. The reality is that each .COM file (Visual FoxPro) can surely have its .NET counterpart. It will just a matter of knowing what the .COM extensions are for the version in question, what the conversion requires, and writing a program that implements the changes for Unicode compliancy without changing the format of the data in question. Reality (and the future) is my perspective.

So, what options are there then to make TMG Unicode-compatible? After all, what else is there to TMG besides a database? /Mr.Kim.Sanders

It may now be possible to convert our .dbf files (based on Visual FoxPro) to SQL script (which I understand is Unicode compatible) through a DBF to SQL Converter. This is mentioned at http://www.whitetown.com/order.php3. Does anyone have experience with it? I'm especially interested in knowing if the other files which TMG uses (http://www.tmgtips.com/dbnames2.htm refers to ACC, BKP, CDX, COL, DBT, DNA, DOC, EMF, FLC, FLE, FLK, FLL, FLN, FLP, FLR, FLS, FLW, FLW, FPT, INI, LO, LOG, MEM, PJC, RPT, TBR, TMG, TXT; and there may even be others) are then (made) Unicode-compatible. Can anyone comment on this matter? /Mr.Kim.Sanders.

There's a free utility download called Quick Unicode Input (QUI). It's downloadable from http://www.cardbox.com/quick/download.htm, which puts quick100.exe on the user's system. You can see what any Unicode value would look like by holding down the alt-key and pressing . (i.e. dot from the numeric keypad) followed by its 4 hex numbers. This QUI method could be referred to as the alt.xxxx method. Another QUI method, using alt., allows the user to access the Character Map. (That's by holding down the alt-key and pressing just the numpad dot [alt.].) From there, the user can choose some characters from a variety of character sets (including Unicode) just by pointing the mouse and clicking on the desired characters. Unfortunately, until further whollygenes.com-side action, the user is just tantalized on TMG with all of this, at least so far. Alas, by the time the user presses OK to close the input window, it's converted the Γ (Alt.393) to a G, changed the Θ (Alt.0398) to a ?, and dumbed down the Ệ to Ê, which just isn't what the user wants or is prepared to accept. It's "not what was ordered". As far as I understand, the user's contract regarding TMG 6.0 and TMG 7.0 is with the operators of whollygenes.com. The user could care less what its platform is (Visual FoxPro 7.0, VFP 9.0, etc. are quite beside the point) or the history to any of the various "issues", as long as the latest Unicode data is available for display and use (throughout TMG after the input windows close) from now onwards. A consultant of mine advises me that MySQL is a possibility for those (in this case, on the whollygenes.com side of the user's TMG contract) who know how to rewrite the utilities which are still not in sync with Unicode. Perhaps there are other options as well, useful input available on the Internet, for the creative thinkers onboard, which would allow the creative thinking users to input family tree data in an æsthetically pleasing format, giving full respect to the way family members actual write and have written their story, in whatever language. Mr.Kim.Sanders shaw.ca.

Rather than contending anything, we just need to move to a Microsoft umbrella that does support Unicode. If only somebody in TMG still had our Visual Foxpro license numbers. Then, this wouldn't have to hit us like a Hurricane Katrina that they knew for 50 years that New Orleans was vulnerable, but did nothing to dike it up, or move the people inland. » I have in my Tree a cousin who was born in England, but died in Turkey during the first world war. » I also have a Vietnamese acquaintance who moved to the Czech Republic, married a Czech lady, before coming to Canada. He's important enough for me to put in my Tree. » I have a Turkish acquaintance who came to Canada and married a lady in Ontario who came from China. » A number of ancestors on my mother's side moved to Kansas, where there is a colony of people who appear on the US census with their Czech names fully accented in Czech style because the census taker was a Czech-American. » And I'm only one example. We live in a cosmopolitan world, in a time of modern technology and communication. Many of us are interested in recording the details that appear on the records, in all their glorious detail, inconsistencies and accents and all the rest. » Surely Microsoft can help us to move from the dead-end backwaters of Visual FoxPro, which is known to be heading for extinction, to something where complaints are no longer required. » Are there any creative thinkers amongst us? Anyone?

You'll find some ideas you may find useable at http://www.whollygenes.com/forums201/index...?showtopic=9809. I wish you and everyone else all the best as we do our best to put things accurately into our Tree for ourselves and those we may teach.

A fairly comprehensive list of ASCII equivalents for "Characters with diacritical marks absent in the codepage ISO 8859-1" is at http://www.eki.ee/knab/kbdiakr.htm. Although most of it is written in the Estonian language, it does show the English (ingl) translation for the various accents (diacritics), and examples of each "foreign" letter used in each of the 41 languages shown from around the world. Down the left side of the table under the heading Kood ja märk (code and symbol) are the Alt-numbers without the necessary lead zeros and the symbol used to represent each accent/diacritic, except in the case of 187 [i.e. Alt-0187] (which is used for letters that don't fit the norm, such as the dotless i in Turkish and the long ö in Hungarian, etc.). The languages covered are as follows, using accented English alphabetical order (with the Estonian names to search), with Romanized usage marked with an asterisk [i.e. *] in each case: Arabic (araabia)*, Azerbaijani (aserbaidz^aani), Bengali (bengali)*, Bulgarian (bulgaaria)*, Catalan (katalaani), Croatian (horvaadi), Czech (ts^ehhi), Estonian (eesti), Farsi (pärsia)*, French (prantsuse), Guaraní (guaranii), Hawaiian (havai), Hebrew (heebrea)*, Hindi (hindi)*, Hungarian (ungari), Japanese (jaapani)*, Khmer (khmeeri)*, Korean (korea)*, Latvian (läti), Lithuanian (leedu), Livonian (liivi), Macedonian (makedoonia)*, Malagasy (malagassi), Maltese (malta), Maōri (maoori), Nepali (nepali)*, Polish (poola), Pushtu (pus^tu)*, Romanian (rumeenia), Sámi (saami), Serbian (serbia)*, Slovak (slovaki), Slovenian (sloveeni), Sorbian (sorbi), Tagalog (tagali), Tamil (tamili)*, Turkish (türgi), Urdu (urdu)*, Vietnamese (vietnami)*, Welsh (kõmri), Yoruba (joruba).

For a more-comprehensive solution that can "apparently" only be used on TMG in the Notes field, one can refer to http://www.geocities.com/Athens/Parthenon/9860/asr22.html [a solution known as ASR 2.2]. I say "apparently" because it requires on strikethroughs and underlines. An interesting side-note is found there, which indicates to me that the system I call KBD was actually devised by Peeter Päll peeter@eki.ee], and is referred to as ASR 2.0. At the time of the update (1997-10-24), the link went to , which is now , I see.

A quick look at http://en.wikipedia.org/wiki/Visual_FoxPro shows us the real problem. Visual FoxPro is COM-based and Microsoft has stated that they do not intend to create a Microsoft .NET version. Unless… maybe we helped them? We must not hide our head in the sand here. So the "handwriting is on the wall" for both Visual FoxPro and its extensions like TMG. The terminal diagnosis has already been given, even if its vegetative state will be ensured for a few years of life support. What kind of life and hope is that?! Surely there is an up-and-coming programmer (or several) who is/are also interested in genealogy. Let them come on board so the ship we're on doesn't sink. There clearly needs to be a shift from COM-based to .NET based. And the sooner the better.

The Mekasseh method for the Turkish modifications (of the Roman/Latin alphabet) is as follows: C¸[using ALT-0184]c¸ G¢[using ALT-0162]g¢ I¤[using ALT-0164]i¤ I•[using ALT-0149]i• O¨[using ALT-0168]o¨ S¸s¸ and U¨u¨. The circumflexed versions (used by some) each use ˆ[ALT-0136] following its standard Latin/Roman base, thus: Aˆaˆ, Iˆiˆ, and Uˆuˆ. The Cappy Singer method for the Turkish modifications (of the Latin/Roman alphabet) is as follows: Ç[ALT-0199]ç[ALT-0231], G¥[using ALT-0165]g¥, I¤i¤, I•i•, Ö[ALT-0214]ö[ALT-0246], Š[ALT-0138]š[ALT-0154], and Ü[ALT-0220]ü[ALT-0252]. The circumflexed versions for the Cappy Singer method are the same as described for the Mekasseh method, i.e. Aˆaˆ, Iˆiˆ, and Uˆuˆ.

The Mekasseh method for Czech gives the Latin/Roman additions as follows: A´[using ALT-0180]a´, C¥[using ALT-0165]c¥, D¥d¥, E´e´, E¥e¥, Chch, I´i´, N¥n¥, O´o´, R¥r¥, S¥s¥, T¥t¥, U´u´, U°[using ALT-0176]u°, Y´y´, and Z¥z¥. In summary, the tšárkas are represented using ALT-0180 after the unaccented Latin/Roman letter it's based on, the hátšeks are represented by the Yen sign [ALT-0165] following the unaccented letter, and the kroužeks are represent by the Degree sign [ALT-0176] following the base U/u. For the Czech Roman/Latin additions, the Cappy Singer method is as follows: Á[ALT-0193]á[ALT-0225], C¥[using ALT-0165]c¥, D¥d¥, É[ALT-0201]é[ALT-0233], E¥e¥, Chch, Í[ALT-0205]í[ALT-0237], N¥n¥, Ó[ALT-0211]ó[ALT-0243], R¥r¥, Š[ALT-0138]š[ALT-0154], T¥t¥, Ú[ALT-0218]ú[ALT-0250], U°[using ALT-0176]u°, Ý[ALT-0221]ý[ALT-0253], and Ž[ALT-0142]ž[ALT-0158]. In summary, in the Cappy Singer method, all Czech letters which look like those found in Windows-1252 are represented that way, which includes Áá, Éé, Chch, Íí, Óó, Šš, Úú, Ýý, and Žž. The Czech-specific hátšeks and kroužeks are entered as in the Mekasseh method: C¥c¥, D¥d¥, E¥e¥, N¥n¥, R¥r¥, T¥t¥, and U°u°.

There are several work-arounds for entering Vietnamese so the user can know the accurate spelling, even using Windows-1252. It will depend on what look and/entry speed you are willing to accept. If you go with standards used by the Vietnamese themselves, there are 3 ways that come to mind: Telex (IME) (http://en.wikipedia.org/wiki/Telex_%28IME%29), Vietnamese Quoted-Readable [a.k.a. Vietnet](http://en.wikipedia.org/wiki/Vietnamese_Quoted-Readable), and the VNI Input Method (http://en.wikipedia.org/wiki/VNI). Then there are 2 others that I've seen online: the "KBDiakr" method (http://www.eki.ee/knab/kbdiakr.htm) and the RFC 1345 mnemonics method (http://www.ietf.org/rfc/rfc1345.txt). I must add that if I were to use the RFC method, I would use \ [i.e. ALT-0092] as a delimiter where required, instead of _. And, finally, I've come up with 2 myself: the Mekasseh method and the Cappy Singer method. The Mekasseh method gives the modern Vietnamese Latin/Roman alphabet extensions as follows: A¢a¢ [using ALT-0162], Aˆaˆ[using ALT-0136], Eˆeˆ, Oˆoˆ, O’o’ [using ALT-0146], Uˆuˆ], and U’u’. Tones follow thus: ´ [using ALT-0180], ` [using ALT-0096], ² [using ALT-0178], ˜ [using ALT-0152], and · [using ALT-0183]. The Cappy Singer method gives the modern Vietnamese Roman/Latin alphabet extensions as follows: Ä[ALT-0196]ä[ALT-0228], Â[ALT-0194]â[ALT-0226], Ê[ALT-0202]ê[ALT-0234], Ô[ALT-0212]ô[ALT-0244], Ö[ALT-0214]ö[ALT-0246], Û[ALT-0219]û[ALT-0251], and Ü[ALT-0220]ü[ALT-0252]. Tones follow as seen in the Mekasseh method just mentioned.

Actually, technically, the latest non-Unicode ANSEL (used with GEDCOM 5.5) is known as ANSI Z39.47-1985. So, ANSEL characters are actually all ANSI, by definition. I wonder how to enable ANSEL-encoding on my computer. I am using a Windows XP. That would allow me to change the Windows-1252 (Latin-1) display to ANSEL. Then the only issue would be whether the Data Entry screen would show the Croatian soft c as ć or, sensibly for easy-editing, as ´c.

I understand that GEDCOM 5.5 was specifically released in 1995 to handle even languages with unusual accents/diacritics (such as Czech, Turkish, and Vietnamese) with just an 8-bit ASCII. It relies on ANSEL fonts, which use a special set of characters in the ALT-128 to ALT-255 section. Can you tell me how I can set the native TMG font to a GEDCOM 5.5 ANSEL layout, such as is described at http://www.ces.clemson.edu/~simms/genealogy/ll/gedcom55.pdf in Appendix D? I've set everything in the Preference fields to display using an ANSEL-type font (AlaBas is the one I found online), but some screens display only in Tahoma. How can I fix this?

For those using TMG who are OK with just ASCII characters, there are often informal systems developed to represent accented names accurately. It means using a table found online, presently. Perhaps a better way might be to have a set of transliteration tables built into TMG, in a .pdf-type format. I would gladly volunteer my time in this regard. A user-friendly one for Vietnamese, as one example, is called Vietnamese Quoted-Readable, usually abbreviated VIQR and also known as Vietnet. It is described (with supplementary references) at http://en.wikipedia.org/wiki/Vietnamese_Quoted-Readable.

There appear to me to be 2 possible solutions at present. The first is to emulate the accents/diacritics of Unicode using a font such as AlaBas for either Windows or Macintosh. That can be downloaded at http://quod.lib.umich.edu/b/bas/help/dowfon.htm. The downside is that various screens do not recognize the AlaBas ALT-0128 to ALT-0255 range since it is not a Windows-x type codepage. The second method is to upgrade from Visual FoxPro 9.0 to Visual Studio , since .NET does support Unicode, whereas .COM does not . The satisfactory implementation of either method requires having a license for VFP 9.0, since Microsoft will not deal with end users, especially ones like myself who do not live in the USA.