Hi Jim Michaels, > sorry - the context of using dpmi was in relation to the problem of having > only > 512K for a font. or is that a video card limitation, and you would otherwise
That is a misunderstanding. You can have a hardware font with either 256 or 512 characters, not kilobytes, in VGA. Many text mode apps write directly to the text screen of the VGA hardware and expect the hardware to do the font. In the 512 character case, the 9th bit of the character number is in a bit which would otherwise set blinking. The text screen in this context is a memory area with a two dimensional array of characters and char properties. Only apps which do not write to the text screen can work with larger fonts at all. In the examples discussed in the DOS Unicode thread, UTF-8 encoded text is sent to a driver such as a CON driver or the BIOS TTY functions. The trick is that in UTF8, multiple bytes can be part of the same character. This allows having 1000s of different characters displayed, but of course you also need a big font to make full use of this. In particular the "JKC", Japanese Korean Chinese, parts of Unicode fonts are big. On the other hand, if you just want dozens of accented and umlaut chars for "western" text, a much smaller but still larger than 256 character font can be used :-). You could use a 512 character font in such a case and let your "UTF8 CON" trap only the non-ASCII chars and the manipulation of the 9th bit of the character. That might give you a bit of compatibility with apps which write directly to the text screen, as at least ASCII parts of their screen would still look sort of okay. > have to go into some sort of graphics mode in order to implement full UNICODE, > as Microsoft did with windows? (sounds of OpenGEM creeping in) well, maybe > some > sort of VESA video driver like linux does. can you borrow drivers from linux? You can of course use anything which lets you handle a big font - reading it from disk or ramdisk, putting it into XMS, EMS, DPMI memory, compressing it etc - to put a big Unicode font in action. However, as you already mention, this means that you will actually have to run in graphics mode. Which is not a big problem in DOS if you need ONLY graphics. The problem is that graphics are slower than text and - more evil - that as said, many DOS apps will directly write to the text screen buffer. But of course when you are in graphics mode, writing to the text screen does not have the expected effect of automatic hardware font based display of the text that you wrote... A workaround would be to "trap" all writes and then let software "manually" paint the graphical shape of the characters which got updated in the text screen buffer. This can be done and has been done e.g. in Desqview but it makes things even slower and you still run into the problem that the contents of the text screen buffer cannot represent text in a font of more than 256 (or at most 512) characters... So what does Windows and Linux do? Simple answer, they do not let apps write directly to the graphics card at all. Because apps always have to send their text to a driver, Windows and Linux can use arbitrary fonts. Yet even there, old apps which assume that each character is one byte will have a messed up layout in UTF8 where each Unicode character can need more than one byte... With well-behaved DOS apps which also write to drivers such as CON instead of directly to the graphics card, you get only as far as with old Windows and Linux apps. Only when you modify modern DOS apps to explicitly know that in UTF8, several bytes can be part of 1 character, only then and only for apps which write to e.g. CON it is possible to use a full Unicode font in DOS. Because such fonts are big, the necessary Unicode CON drivers will have to use slow graphics mode instead of the fast hardware text mode and they will have to use EMS, XMS, DPMI memory, a ramdisk or similar to store the big font. As you see, this is a long story :-) But I must say that I forgot what came out of the discussion a while ago. It was not clear to me WHICH size of font people wanted to use and whether they wanted Unicode display, keyboard, file names, URLs or other aspects of Unicode support... Maybe somebody can refresh our memory? Thanks :-) > by the way, I have an implentation of OpenGem 5 that is a complete Open Source > implementation. version 6 does not run. :-( Did you ask our GEM expert Shane (shaneland.co.uk afair) already? Regards, Eric ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
