Re: FontDlg sample text
On Sun, 30 Nov 2003 03:43:04 +0200, you wrote:
+ {'C','c','D','d',0}, /* Symbol */
With native win98, ME and win2k the example string for symbol I get is spelled 'S','y','m','b','o','l' BTW, I have a patch for this and other fontdlg enhancements as well. Do you plan to submit any more patches soon? Rein. -- Rein Klazes rklazes(a)xs4all.nl
Rein Klazes wrote:
On Sun, 30 Nov 2003 03:43:04 +0200, you wrote:
+ {'C','c','D','d',0}, /* Symbol */
With native win98, ME and win2k the example string for symbol I get is spelled 'S','y','m','b','o','l'
BTW, I have a patch for this and other fontdlg enhancements as well. Do you plan to submit any more patches soon?
Rein.
Well aware of that. However, doing that would require me to introduce a significant change into the code, and I don't see the reward. It's not as if you can read the resulting string anyways. Likewise, the Japanese sample text only has Aa (and not AaBb) of Romanji (latin characters). For similar reasons, I left AaBb in place (why remove it?). Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
Shachar Shemesh <wine-devel(a)shemesh.biz> writes:
Likewise, the Japanese sample text only has Aa (and not AaBb) of Romanji (latin characters). For similar reasons, I left AaBb in place (why remove it?).
The question should be why do we go to the trouble of having parts of the string handled in two different places, when we could simply store the full string in the sample text array. It would make the code simpler, more flexible, and more compatible. Is there a good reason for doing it the way it is now? -- Alexandre Julliard julliard(a)winehq.com
On Sun, 30 Nov 2003 11:45:55 -0800, you wrote:
Shachar Shemesh <wine-devel(a)shemesh.biz> writes:
Likewise, the Japanese sample text only has Aa (and not AaBb) of Romanji (latin characters). For similar reasons, I left AaBb in place (why remove it?).
The question should be why do we go to the trouble of having parts of the string handled in two different places, when we could simply store the full string in the sample text array. It would make the code simpler, more flexible, and more compatible. Is there a good reason for doing it the way it is now?
This is what my patch is doing, I will submit it when I have put a few more sample strings in. And may be Shachar thinks it is not important: symbol files are sometimes scarcely populated, a diffferent sample string may look completely different, for instance not at all. Rein. -- Rein Klazes rklazes(a)xs4all.nl
Alexandre Julliard wrote:
Shachar Shemesh <wine-devel(a)shemesh.biz> writes:
Likewise, the Japanese sample text only has Aa (and not AaBb) of Romanji (latin characters). For similar reasons, I left AaBb in place (why remove it?).
The question should be why do we go to the trouble of having parts of the string handled in two different places, when we could simply store the full string in the sample text array. It would make the code simpler, more flexible, and more compatible. Is there a good reason for doing it the way it is now?
The reason is the unicode version of the dialog. In Unicode, you may need to display several "character sets" simultaniously. When that happens, you don't want to repeat the AaBb string over and over. As for the strings themselves - they are 100% language independant, as far as I can tell. After all, they don't spell a word in any language that I actually speak (Arabic may be an exception here, as may Japanese). Even when they, do, it's a word in that language. I failed to understand how you wanted to make it into a resource. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
participants (3)
-
Alexandre Julliard -
Rein Klazes -
Shachar Shemesh