> On Feb 8, 2025, at 12:12 AM, Ladislav Lacina via Freedos-devel
> <freedos-devel@lists.sourceforge.net> wrote:
>
> Hi! I am still working on font editor Kasmar (WIP version here:
> http://www.laaca.borec.cz/kasmar_f.zip )
> And I would like to add support for format V8F which is used in FreeDOS
> installer.
:-)
> This format is not complicated (although relying in BIOS definition on target
> machines, especially in 14px size, could be problematic) however I miss one
> thing in this format.
Yes, it is a possibility.
When I created the initial fonts, many of the “new” characters needed adjusted
vertically to align with existing BIOS characters.
However after watching numerous install videos on YouTube, it does not seem to
be an issue.
> There is nowhere defined for which code page is the file defined.
At present, correct. The FreeDOS installer simply uses the file naming scheme
to tell VFONT which font to load.
> Of course, I know that for purpose of FD install it does not matter but for
> other purposes is this a limitation.
> My editor internaly converts all code page files to unicode mapping and for
> this it needs to know for which code page is the font defined. Otherwise I
> have to let it on user which is certainly possible but not optimal.
> So I propose to add some WORD value into header with information of code page
> (like 852, 866 and so on)
I am not opposed to improving the file format. We just need to determine the
least problematic and easiest way to support what you want.
I have not documented the file format. But, it is complex and could be mostly
figured out by examining VFONT [1].
However, that program is in assembly and does not have many code comments to
explain why or what is happening.
A better and easier program to look at is MKV8FONT [2]. Although it also lacks
comments, it is written in Turbo Pascal and is therefore much easier to read
and understand. That program is what I use to create the smaller V8F files from
simple bitmap fonts.
Since it is not complex and I don’t know to what level you deciphered the
existing V8F format, I’ll describe it here.
The initial block contains the format identifier string “V8FONT” + CRLF. This
is used to identify it as a V8 Power Tools Font File. (Side note… When used
with VFONT, if this string is not present, the file is assumed to be a simple
flat bitmap font.)
This is followed by any text someone may wish to have embedded in the file.
Such as a copyright notice, credits or whatever. The text is terminated by a
EOF character. This permits a user to simply “type” a V8F file and view the
Identifier string and following text without sending a bunch of garbage to the
display. At present, the ability to include user text is not really used.
The remainder of the file contains data blocks identified by single byte. At
present, there are two block types.
Block type 0, is the terminate block and is at the end of the file and contains
no data. Everything after this block is to be ignored.
Block type 1, is a font style #1 (default font) block header. It contains:
Block type ID - 1 byte, this is referred to
as a Style byte in MKV8FONT. The idea being various font styles
(like, underline,
italics, etc) could be included in the file. However, no additional styles
have been defined
other than default.
Size of the block in bytes - 1 word, this is more of an offset
from current position to the next block.
the value is (Size of
Header - 1 + total bytes of font data).
First - 1 word, The first
character to change.
Count - 1 word, Number of characters
to change.
Width - 1 word, Bit Width of
characters.
Height - 1 word, Bit Height of
characters.
Font Data - varies, basically ((Width /
8) + 1) * Height. At present, they are all 8 bits wide.
That is all here to the format is at present.
However, this allows a couple things. First, the file only needs contain those
characters that need replaced for different codepages. It also permits
overlaying multiple fonts on top of each other. It also allows the file to
contain many size variations in a single font file.
Although I did not spend much time on the format, it was designed to be
extendable through the block types. The blocks are handled much like those in
WAVE files. Excluding the terminate block, all other blocks are to include the
block size information. Any unknown block types are to be skipped.
I think the simplest thing would be to create an additional block type that
contains the CodePage data and place it somewhere in the block chain. Most
likely at the beginning before the character replacement blocks. This would
maintain compatibility with the existing VFONT utility.
I propose using block type 0x10, 0x20, 0x40 or 0x80 to contain codepage data.
I’m not picky on the format of the block. However, if I every get around to
writing an actual spec for the format, I would like to include the
format/layout information for that block.
:-)
Jerome
[1] https://github.com/LoopZ/V8Power/blob/master/SOURCE/VFONT.ASM
[2] https://github.com/shidel/makeV8Font/blob/master/mkv8font.pas
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
