Re: [fd-dev] codepage IDs
Rösberg, Tue 26.11.02 Hi Arkady, On Tue, 26 Nov 2002 18:54:43 +0300 (MSK), Arkady V.Belousov wrote: AB 26-îÏÑ-2002 16:25 [EMAIL PROTECTED] (tom ehlert) wrote to [EMAIL PROTECTED]: AF Maybe I've gone too AF far with 'nightmare', but it's still handy to save address space. AB This is matter of taste, how call such desicions: silly, nightmare, AB etc. TE trouble to save 4 bits isn't 'silly'. it's outright 'dull' ;-) Tom, why so polite? Why not slightly saying 'crack-brained'? After all, you always omit infinitive truth and wisdom, so you do need to take care of other people's opinion AB Please, don't make such silly suggestions and implementations. Making AF Really, I would not call this suggestion 'silly'. AB AB But results of such decisions often are silly. B-\ Probably, AB most clear example of such decisions is an BIOS limits for disk AB sizes: first 512M, then 2Gb, then 4Gb, then 8Gb, then 32Gb, then AB 127Gb... Hmmm... the number of codepage IDs does not grow with the same speed than hard disks do. But I go for that. And I want to repeat: my previous statement is more a wish than a demand. I would likely have the number of existing codepages limited to 4096 or 16384. But if there would be new codepages introduced with higher ID's, I would not ignore them. Of course, because of the possibility of such high codepage IDs my idea is somewhat questionable. AB full featured lookup table may be _slightly_ more complicated, but then AB later this will not crash your (and our) head when limits will be exhausted. AF Yes, but whenever new codepages are introduced, such lookup tables AF must be maintained, this can become a cumbersome work. AB Why? Actually, I starting to ask this question to myself. At meanwhile, it seems to be less effort for me to implement lookup tables than constisting on my idea. ;-) Regards, Axel. -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^^=== This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^^===
Re: [fd-dev] codepage IDs
Rösberg, Thu 21.11.02 Hi Arkady, On Thu, 21 Nov 2002 02:37:51 +0300 (MSK), Arkady V.Belousov wrote: RQ ( my wish: below 4000 RQ my second wish: below 8000 RQ my last wish: below 16000 :-((() AF I agree completely! AF Let me express it more precisely: it would be handy to have all AF codepage number below 4098. AB As stated by Matthias, DR-DOS assigns for code pages with euro sign AB some very big values. I think I heard about this, too. But is there an official DR-DOS release with such codepages? AF Codepage numbers above 16383 would be nightmare! AB Why? Well, with the assumption that all codepage IDs would not take more than 10 bits, there would be 6 remaining bits to denote variations of the existing codepages. If I remember correct, the DR-DOS method denotes codepage 858 as 20850. For automatted processing it is much easier to subtract 2 than looking up in an additional lookup table for variants of codepages. With 'regular' codepage IDs above 16383, there would only one bit remain for variations - this could become painful for system programmers. AF lot of codepages without any official IDs. The most important of them AF is KOI8-R, which should be supported as well. (Arkady, do you agree?) AB No. What a pity. AB See the difference: under Windows you have one system codepage (to be AB precise: two with so called OEM) and may use any fonts simultaneously. AB This is how was added support for KOI8-R in Netscape Navigator before it AB begins a _real_ internationalized program. Well, as it goes for me, I would likely have support for ISO-Latin-1 under DOS, this would spare me much conversion work for my emails. I thought you would feel similar. AB Under DOS you have one system codepage and you _can't_ have other AB simultaneous fonts [for different code pages]. This is nature of text modes, AB only some _applications_ may support in graphics mode some different fonts. I don't understand this. Can't you use CHCP to switch between codepages? AB On the other side, KOI8-R never used in DOS as base codepage, although This is no reason against. You know, there was a time where Internet was never used before. Nowadays many people use it in spite. ;-) AB beside ALT (CP866) codepage there was three other - MAIN, BULGAR and GOST. AB KOI8-R used only as commincation base, so under DOS you should only have AB translation tables in communication programs. Well, I don't know whether these codepages contain important characters which are not contained in KOI8-R. AB Conclusion: under DOS may/should used only CP866. Adding support for AB other codepages (even for Windows CP1251) have no sense - at least, because AB they not contain pseudographic characters. Well, I confess: you have more knowledge about this topic as I have. AB BTW, to complicate case the more, there is another KOI8 - KOI8-U AB (Ukrainian KOI8). You may see the differences with KOI8-R in RFC2319. I will take a look at it by chance. Thanks. Regards, Axel. -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^^=== This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^^===
