On 2002-12-02, Eric Auer wrote: This thread was actually a private discussion (between several people involved in the "codepage project"), which accidently made it into the list. It was about possible caveats in altering some of the shapes in fonts in codepage definition files like CPI files.
> who would actually need BIOS character RECOGNITION ? For a /proper/ discussion this is something which /must/ be taken into account. If it is put down eventually as being a marginal issue, then be it so, but then it is put down by /intentional/ (although possible not optimal) decision, whilst if the matter was not brought up at all, it would be mere /sideeffect/. IMHO, it's never a good idea to design anything on the mere assumption that "it won't happen", although, I have to admit, much software is written this way, unfortunately. Well, I know your question is only rhetoric, but to answer it: Anyone who runs (text mode) DOS programs which read characters on the screen using INT 10h BIOS functions, while a graphics mode (not a normal or hi-res text mode) is active. Not a very common scenario, but a possible scenario. If we want to design software that just works, we have to take this into account. > And finally, when you really modify the font to support the > charset of a particular language in TEXT mode, the text video > RAM will still look the same. Yes, text mode is no problem at all. > The character RECOGNITION is only needed for GRAPHICS mode > and probably uses the current font as defined by int 0x43 > for comparison, which should work with any font. Graphics mode is a problem if you change the font/codepage and still leave characters on the screen, which have been drawn with the old font definition. In contrast to text mode, where the shape of all characters on the screen changes when you reload the font, this does not (cannot) happen in graphics mode. Hence, the BIOS will no longer be able to recognize these characters, only the new ones. If your application can perform a clear screen, even graphics mode is no problem. This might be a problem for system using display frontend drivers or for screen reader software, although I am not currently aware of a particular example. It is, however, a problem, for the CopyCursor feature built into our FreeKEYB advanced keyboard driver, when you try to copy & paste characters on the screen into the extended keystroke buffer. To be as compatible and transparent as possible to existing application, FreeKEYB's CopyCursor relies on BIOS functions to work. Of course, it would be only an inconvenience rather than a fatal problem. Greetings, Matthias -- <mailto:[EMAIL PROTECTED]>; <mailto:[EMAIL PROTECTED]> http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org "Programs are poems for computers." ---------- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^================================================================ This email was sent to: [email protected] 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 ==^================================================================
