[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic