[prev in list] [next in list] [prev in thread] [next in thread] List: freedos-dev Subject: Re: [fd-dev] mkeyb From: Matthias Paul <Matthias.Paul () post ! rwth-aachen ! de> Date: 2002-05-13 13:44:08 [Download RAW message or body] On 2002-05-08, Kurt Zammit wrote: >> Later an utility CPI2FNT could be written to convert CPI fonts, >> internalization project is ready for it the utility could be >> extended with kernel support and the like. > > BTW, is it worth it to write CPI2FNT? I guess it shouldn't be > difficult to write as I already have a text file documenting > the CPI file format. ;-) If you just want to extract the fonts, it's not very difficult, even a simple DEBUG script would be sufficient. If you really want to parse the file *and* handle all the existing special cases and sub-format types instead of just looking at specific offsets, it is more complicated. Anyway, there's no longer a need for a tool like this, as it already exists: I think, my CPI.EXE tool can handle all .CPI and .CP files in existence anywhere, no matter if they are from MS-DOS 3.30-6.22, Windows 95/98/SE/ME, PC DOS 3.30-2000, various MS-DOS OEM issues like those from ASI, AST, Compaq, Hewlett-Packard, or Toshiba, DR DOS 3.40 - 7.05 (including Novell DOS and OpenDOS), PTS-DOS 6.51 - 2000, OS/2, Windows NT/2000/XP, Linux, and several other sources like the files from Dimitri Vulis or Kosta Kostis. It also supports the .CPI files found in Russian, Arabic, and Hebrew issues of MS-DOS. You can use it to create font files in many different formats. FYI here's a dump of the help screen: c:\> CPI /H |CPI V4.07 (010307) .CPI & .CP codepage file analyzer, validator and decompiler |Copyright (C) 1994-2001 Matthias Paul & Axel C. Frinke. All rights reserved. | |CPI [@] [@] [/?|/Help[:topic]] [/!|/About] [/CP[I]File[:filespec]] | [/Report[:filespec]] [/Name[:description]] [/Verbose[:0..6]] | [/Font[:filespec]] [/Drfont[:filespec]] [/Lut[:filespec]] [/Map[:filespec]] | [/Style:0..25] [/Export:cplist] [/Getfonts:fntlist] [/Overwrite] [?|&] | | /?, /Help Display this help screen or specific help for a topic (+) | /!, /About Display the 'About' info screen | /Cpifile (+) .CPI/.CP file name <EGA.CPI>; extension: <.CPI>; CPI.EXE=StdIn | /Report Report file name <''=StdOut>; extension: <.RPT> | /Name File description of .CPI/.CP file for verbatim file commenting | /Verbose Dump mode <1>; 0=no; <2>,4,6=DRFONT LUT; 3,4=font; 5,6=bitmaps | /Font Extract font data to files *<font>; extensions: <codepage> | /Drfont Extract DRFONT data to files *<font>; extensions: <font-spec> | /Lut Extract DRFONT look up tables to files; extensions: <codepage> | /Map Extract DRFONT character table to list file; extension: <.MAP> | /Style (+) Export <0>-6=BIN-raw/ROM/RAM/PSF0/1/SH/CHED; 7-12/13-18/19-24= | /Export Export codepages from list <''=all codepages> | ASM-hex/dec/bin | /Getfonts Export fonts from list <''=all fonts> | ip/il/p/l/mp/ml | /Overwrite Force to overwrite existing files | ?, & Online edit mode (prompts for additional parameter input) c:\> CPI /H:C |CPI V4.07 (010307) .CPI & .CP codepage file analyzer, validator and decompiler |Copyright (C) 1994-2001 Matthias Paul & Axel C. Frinke. All rights reserved. | |Overview on codepage file parameter usage: | | /Cpifile[:filespec] Specifies .CPI/.CP file(s) (automatic format detection). | /CPIFile[:filespec] Assumes file(s) to be in DOS .CPI file format. | /CPFile[:filespec] Assumes file(s) to be in Linux .CP file format. | |Overview on valid filespec(s) for codepage file parameter(s): | | - A single file, e.g. c:\dos\ega.cpi | - A wildcard mask, e.g. c:\dos\*.cpi | - A list of filespecs, e.g. c:\dos\ega.cpi,c:\dos\ega2.cpi | - A list file (e.g. @c:\cpi.fl), containing a list of filespecs. | |All these types can be combined in a single command line at the same time, |but you may not combine /Cpifile with one of /CPIFile or /CPFile parameters: |If you do, /Cpifile will be ignored. Also, limitations apply in the usage of |list files: A filespec for a list file may not contain wildcards, and a |list file may not contain filespecs for other list files. And these are the currently supported output formats (I may add more as I find info about them): c:\> CPI /H:S |CPI V4.07 (010307) .CPI & .CP codepage file analyzer, validator and decompiler |Copyright (C) 1994-2001 Matthias Paul & Axel C. Frinke. All rights reserved. | |Overview on /Style parameters: | | 0 = Raw binary data files | 1 = Binary data files (display fonts in ROM-BIN format) [FEDIT.COM, FED.EXE] | 2 = Binary data files (display fonts in RAM-BIN format) | 3 = Binary data files (display fonts in Linux PSF format 0) | 4 = Binary data files (display fonts in Linux PSF format 1) | 5 = Binary data files (display fonts in Sven Hansen FONTEDIT SH-BIN format) | 6 = Binary data files (display fonts in Digital Research CHED format) | 7 = ASM source include files, hex-values (portrait) | 8 = ASM source include files, hex-values (landscape) | 9 = Standalone ASM source files, hex-values (portrait) | 10 = Standalone ASM source files, hex-values (landscape) | 11 = Modular ASM source files, hex-values (portrait) | 12 = Modular ASM source files, hex-values (landscape) | 13 = ASM source include files, decimal values (portrait) | 14 = ASM source include files, decimal values (landscape) | 15 = Standalone ASM source files, decimal values (portrait) | 16 = Standalone ASM source files, decimal values (landscape) | 17 = Modular ASM source files, decimal values (portrait) | 18 = Modular ASM source files, decimal values (landscape) | 19 = ASM source include files, binary values (portrait) | 20 = ASM source include files, binary values (landscape) | 21 = Standalone ASM source files, binary values (portrait) | 22 = Standalone ASM source files, binary values (landscape) | 23 = Modular ASM source files, binary values (portrait) | 24 = Modular ASM source files, binary values (landscape) | 25 = Binary data files (display fonts in PTS SFE-CP) Getting, for example, the fonts in the 16x8 and 8x8 resolutions for codepage 853 from the DR-DOS 7.03 EGA.CPI file, for codepage 667 from the PTS-DOS 6.51 DISPLAY.CPI, for codepage 915 from the PC DOS 2000 915.CPI, and for codepages 737 and 775 from the Windows 2000 EGA.CPI files and store them as Linux PSF1 files, is as easy as: c:\> CPI /C:c:\drdos.703\ega.cpi,c:\ptsdos.651\display.cpi, ... ... c:\pcdos.2k\915.cpi,c:\windows.2k\ega.cpi ... ... /E:667;737;775;853;915 /F:c:\tmp\ /G:8x8;16x8 /S:4 and you'll find the following PSF1 files in the C:\TMP\ directory afterwards: EGA2.853, EGA4.853 <- from DR-DOS EGA.CPI DISPLAY1.667, DISPLAY3.667, <- from PTS-DOS DISPLAY.CPI 9151.915, 9153.915. <- from PC DOS 915.CPI EGA1.737, EGA3.737, EGA1.775, EGA3.775 <- from Windows 2000 EGA.CPI The numbers 2/4 and 1/3 correspond with the number of the entry in the resolution table inside a .CPI file - mind, that they are stored in four significantly different .CPI file formats and that the DR-DOS files hold 6x8, 8x8, 14x8, and 16x8 fonts, whereas the other files only provide 8x8, 14x8, and 16x8 fonts. Well, the output file naming rules are subject to change a bit in the future, so that the file extension will reflect the file type, not the codepage any more (for better compliancy with file associations), but it is a bit difficult to find a good naming scheme in 8+3. CPI.EXE does *not* import fonts into .CPI files at present; I always planned to add this but I never came around. After all, CPI.EXE was only meant as an debugging aid to help me research and analyze the various file formats; it was never meant as a "production level tool". Meanwhile, I do no longer think, adding a font import feature would be really useful for several reasons: - I don't like to have .CPI files without also having the source code for them. Otherwise you will always end up more or less messing around with modified issues of existing .CPI files, instead of having the freedom to roll your own from scratch. - For those, who don't need more than just deal with display .CPI files from standard (non-OEM) MS-DOS and PC DOS, tools, which can do just this, already exist (although they are not very flexible). Personally, I don't really bother with the FONT sub-format, because I consider it as being too limited to be useful in the future. It should be supported for the sake of compatibility, but that's all. Not more than a side product of the ongoing search for a better solution. But it is not my primary goal, just a small mile stone. NB. - The Windows NT FONT.NT sub-format overcomes the major limitation of the FONT format, but at the price of much (!) larger files, if you were really going to add hundreds of codepages. It's a quick and cheap fix based on something that was already not really thought through, but not a real solution. And, to support the FONT.NT format under plain MS-DOS/PC DOS, you would need a new MODE utility, which would translate FONT.NT to FONT before it sends the data to DISPLAY.SYS. - DR DOS also supports the MS-DOS/PC DOS FONT format for compatibility, so having files in this format does not "harm". - The only existing solution which would allow to store an almost unlimited number of codepages without unnecessary bloating is the DR DOS 6.0+ DRFONT .CPI file format, which adds one level of indirection by using a 16-bit character lookup table, and thereby helps to significantly cut down the file size. It also allows to specify ranges, but this feature is not currently used because the resulting .CPI files are still small enough. Worth mentioning is that the 16-bit lookup table suits perfectly to be extended to Unicode. (And needing a new MODE utility anyway, it would be just as easy to add support for DRFONT as adding support for FONT.NT - or both.) The problem with DRFONT files is, that, unless you only want to change the font style as a whole (which is easy), you cannot patch around in DRFONT files as easily as you can in standard MS-DOS/ PC DOS FONT files. So in practise you will have to create them from scratch when you want to add new codepages. Therefore you will need font source code as well - preferably as assembler macros, as this will make us independent of any specific font editor, even a simple ASCII text editor would be sufficient to directly edit the assembler files in the worst case. But since it is undesireable to create the characters by manually writing the assembler source for them, a font editor which is capable of 16-bit wide fonts would be fine as well. Digital Research's CHED can do this and was used to create the font database for DR DOS, but this cannot be used for FreeDOS, as it is not publically available and a very crude tool, anyway. This is where Michal's UFDES comes in now. IMHO, UFDES should be the base for all future bitmap font designing and editing under (Free)DOS. The advantage of UFDES is, that it comes with a feature-rich and convenient graphical UI to create fonts and/or manipulate existing ones, that it stores the characters together with their code points in Unicode, that it is not limited to 8-bit codepages, that it can handle bitmaps up to 64x64, and that it can display and work with two independent fonts files at the same time. It stores its fonts in .UFT files. There is already a tool named BIN2UFT which converts binary fonts into the .UTF format when you have a mapfile describing the translation from the corresponding 8- or 16-bit codepage to Unicode. Most other tools are able to generate binary fonts. The .MAP files should be in a format like (CP437.MAP): |0x00 0x0000 # NULL |0x01 0x263A # WHITE SMILING FACE |0x02 0x263B # BLACK SMILING FACE |0x03 0x2665 # BLACK HEART SUIT |0x04 0x2666 # BLACK DIAMOND SUIT |0x05 0x2663 # BLACK CLUB SUIT |0x06 0x2660 # BLACK SPADE SUIT |0x07 0x2022 # BULLET | [...] |0xFC 0x207F # SUPERSCRIPT LATIN SMALL LETTER N |0xFD 0x00B2 # SUPERSCRIPT TWO |0xFE 0x25A0 # BLACK SQUARE |0xFF 0x00A0 # NO-BREAK SPACE There is also a tool named UFT2MAC to create assembler macros, as we will need (or at least prefer) them to create .CPI files from scratch. For example letter A (U+0041) in 16x8 resolution: |U_0041_16x8 MACRO | db 00000000b ; 1 | db 00000000b ; 2 | db 00000000b ; 3 | db 00111000b ; 4 | db 01101100b ; 5 | db 11000110b ; 6 | db 11000110b ; 7 | db 11000110b ; 8 | db 11111110b ; 9 | db 11000110b ; 10 | db 11000110b ; 11 | db 11000110b ; 12 | db 00000000b ; 13 | db 00000000b ; 14 | db 00000000b ; 15 | db 00000000b ; 16 |ENDM U_0041_16x8 Again, it is possible to bypass this step, but I would prefer not to, so that we really have full source code for a given .CPI file instead of some binary images linked together. We would need people who are willing to create .MAP files for all the codepages not covered so far (Michal has created quite a bunch already). In many cases I do have fonts for them or at least paper charts, but I don't have the time to look up all the code points in Unicode. If you want "your" codepage to be supported in the future (no matter how bizarre or old it is), just give us the .MAP file and the rest should be easy. And if the mapping is not covered by http://www.unicode.org already, it may (after a few formatting changes) even help them as well. Once having the mapping table, it is often only a matter of adding two or three new characters to fully support another codepage, since most variations of Latin, Greek, and Cyrillic characters are already in the database. And we would need people who can provide suitable bitmap fonts at least in the standard resolutions 16x8, 14x8 and 8x8 containing all the various Arabic, Hebrew, and Far East characters. Same here, I already have many such font files, but we would need someone who speaks at least one Arabic language or Hebrew, and is willing to identify all these glyphs... That's next to impossible for someone not speaking these languages, we can only guess... Now, having someone around here from Latvia, maybe Kristaps would be willing to provide mapping tables for codepages 770..774? (775 is already covered.) I would also have a few questions in regard to some oddities in the Lithuanian LIR codepage/keyboard driver package, in case you would be familiar with it. In regard to automatic conversion of vector fonts into bitmap fonts, I am interested in seeing some results, say converting Windows Arial to 16x8. At the moment I must admit that I am a bit sceptical this would really give professionally looking results when the bitmap resolution is as small as 16x8, 14x8, or even 8x8. How many of the thousands of vector fonts do you want to express in just a 16x8 grid? It /should/ work fine for larger resolutions, so this might make sense for .FNT files to be used in windowed DOS boxes under Windows, but I doubt it would be really useful for .CPI files and plain text mode. Printer bitmap fonts have larger resolutions, but so many other restrictions apply to them that it will be difficult to automatize this as well - though it would definitely be great! I remember how many hours it took me to design and tweak a nice looking euro symbol for the NEC Pinwriter series (for NECPINW.CPI), so that it was as conformant with the design rules for the euro logo as possible and still looked nice in the flow of text when combined with the resident fonts in the printer in all the possible resolutions... And display font resolutions are even smaller - designing a highly readable and nice looking type face, which does not suffer from ugly aliasing effects at such a low resolution takes much time. Sometimes you can spend days changing the design of just a few character over and over again until they finally match your expectations and fit in nicely with the rest of the font... Good taste is nothing an automatic converter could ever develop, I would think... But let's see, maybe I'm wrong... ;-) I cannot speak for others, but the reason /I/ am after creating universal .CPI files for DOS is to lay the foundation to what Microsoft and others should have done already with their DOS NLS system, that is: Support as many countries and codepages as possible and provide means to view (or create) files in other character sets, codepages, and/or languages without the need to convert them - no longer being limited to just a few codepages (usually two for each country). Another goal is platform independence - would the ISO codepages be fully integrated into the existing codepage switching logic, I would probably switch over from 437 to ISO 8859-1 under DOS. Others may want to work in one of the Windows codepages. (I know that there are already solutions to do this, but none of them is really seamless and they all have restrictions and trade-offs - even Kosta Kostis' ISO .CPI files.) The other goal is that the font must be very readable and homogene in design. I don't need the latest "Bonanza" or "Handwriter" font creations for my text mode work (well, I don't even need them in a GUI text processor ;-). So my needs for different fonts under DOS are limited, say, one which resembles the existing fonts used in graphics card ROMs and DOS .CPI files, one or two high quality fonts with serifes ("Courier", maybe a non-proportional variant of "Times Roman", but at 16x8 this will always remain only vague approximations), another few sans serifes ("Letter Gothic", maybe a non-proportional variant of "Helvetica" - Michal also has created a nice one of this category), one which is fully ISO 9241 conformant (a checklist item for use in some environments), an extra thin font for some laptop LCDs, and maybe a set of inverse fonts are all I'd need in text mode under DOS or Linux. Greetings, Matthias -- <mailto:Matthias.Paul@post.rwth-aachen.de>; <mailto:mpaul@drdos.org> http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org ---------- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: fd-dev-unsubscribe@topica.com ==^================================================================ This email was sent to: freedos@progressive-comp.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bAgbuZ Or send an email to: fd-dev-unsubscribe@topica.com T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================ [prev in list] [next in list] [prev in thread] [next in thread]