> On Feb 8, 2025, at 2:40 AM, [email protected] wrote:
>
>
>
>> On Feb 8, 2025, at 12:12 AM, Ladislav Lacina via Freedos-devel
>> <[email protected]> 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].
I have not documented the file format. But, it is NOT 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.
You could easily include something like “Created by Kasmar” + CRLF.
:-)
>
> 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.
Font Data - varies, basically ((Width /
8) + 1) * Height * Characters. 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
