Hi Eric, I usually put a good deal of thought into such things before I implement them.
I more or less completely agree with what you suggest. As it turns out… What I implemented is very similar to what you propose with only a couple minor differences. Albeit, those would improve space requirements and provide additional functionality. I just didn’t bother to spend the additional time needed to expand it in those ways. V8F font files only contain special characters that differ from the default base set. I thought about doing the full 512. But, just stuck with 256 for now. Yes it is the blink/intensity bit. vfont can load V8F files on top of one another. So, in theory… If a language is English (default), plus Greek + Turkish characters, it could load them on top of one another. I considered how mixing BIOS and custom characters could / would result in jumpy text. But, considered it a minor issue. Examining the already existing CP fonts like Turkish, they already are jumpy looking. However, jumpiness could be reduced some by first loading a custom English base. These are some of the reasons why the installer does not just “load” a specified font for any given language. Instead, it jumps out to the batch file. That file could load one, two or twenty different fonts sets. Or even use an entirely different scheme to make the characters available. You are absolutely correct that combining all of the characters into a single font resource file would be an improvement. That would reduce disk foot print and remove the potential for duplicate characters across different custom fonts. There is an additional advantage of the V8F font file. It is not a flat binary map of characters.It is extensible to add functionality. It doesn’t even assume that the characters are 8-bit wide. In theory, it could contain a 16x16 Chinese character set. Then have a VGA BIOS load the first half into the standard 256 set and the second half into the extended set. Then with a little programming magic, use both sets to provide a high res double wide font. That would limit the screen resolution to 40x25. But, it would look really nice. All of that extra stuff would be nice. But, time is a precious resource and I frequently need to focus on other things. Sometimes, only the most pressing needs get resolved. :-) Jerome > On Dec 17, 2019, at 3:58 PM, Eric Auer <e.a...@jpberlin.de> wrote: > > > Hi Jerome, > > as you want to minimize disk usage beyond the already space > efficient compressed CPI format "CPX", how about this idea: > Make a list of all codepages supported by the installer and > read all fonts for those. Because most fonts will be created > from common ancestors, only modifying a few accented chars, > you should get a reasonably small set of characters. Assuming > that all messages used by the installer only use a lot less > than the 256 different characters of each codepage, the whole > ACTIVE set is likely to be below 256 or at least below 512 > different characters. Then merge all those into ONE font and > use THAT font, together with the raw Unicode version of your > message strings, to display text in all languages. You can of > course also use mappings from codepage to unicode to "512font" > to keep the message files small (1 byte per char, not UTF-8) > because you know for each file which codepage it uses :-) > > Similar things exist in Unicode-aware editors for DOS, but my > suggestion would be far more lightweight: It would use actual > text mode (in VGA: up to 512 chars) and you could take care > that most of 7-bit ASCII stays untouched for best compatibility > while working with messages and files in non-codepage context. > > In any case it would be interesting to count how many distinct > characters the whole installer is likely to encounter at all :-) > > And the common ancestor assumption will make it a lot easier to > know which char shapes to include from which codepage and which > not to include. The "one font for all" approach would still get > the common ancestor included as well, but I think that is GOOD > because you get a consistent font style. > > When you mix a BIOS font with only a few accented chars taken > from codepage fonts, for comparison, you are likely to get a > somewhat jumpy style for the text. > > I hope this was thought-inspiring and not too long to read :-) > > Eric > > PS: VGA 512 char mode uses one of the color bits as the 9th bit > of the characters, I think the blink or the brightness bit :-) > > > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
