Recently I noticed a thread in this forum about the fontfile.raw format. As it stated, this is the file that TexInf visuals use to display the font. Prolux (the poster) described the format, so I thought that it would be very nice to append my editor to support it. Besides, my Rio has all the fonts supporting Greek apart from the TexInfo Visual. Although the RLE encoding was not so straight forward, I managed to decode it and I upgraded my RioFontEditor utility to support it. The latest version is included in the attachment.

For those interested, and in order to fiil up the gap that prolux left with that posting, the exact RLE data format is the following for each character:

FONTDATA (RLE)
+0 : width
+4 : height
(following 4*height bytes of trash!!! (why?))
+8 + 4*height: k bytes of RLE information:
Let val be the value of one of the RLE bytes. That byte will represent val / 4 pixels of val % 4 color, where 0 is no luminance, 1 and 2 are halftones and 3 is full luminance.
When the sum of the (val/4) values reaches the width of the character, then the next scanline is being described in the same way. k must be dword aligned.

Cool addon to your editor - must check it out.

In reply to:

---

(RLE Font file info)

+4 : height
(following 4*height bytes of trash!!! (why?))
+8 + 4*height: k bytes of RLE information:

---

Hmm, I haven't looked myself, but could the 4*height "bytes" of Trash be 'n' "DWORDS" or long integers that encode the offset or index into the font table for the information for scanline 'n'?

This would be something that I'm sure the developers/users of the font would find useful for building a line of text, 1 "scan line" at a time.
In that they would be outputting each "character" 1 "row" at a time, which means that they need to find all the data for scan line row '0' to produce the top line of pixels, then repeat for scan line '1' etc to the height of the font.

"prolux" (I think, or someone in Empeg) did say a while ago that the large font is only decoded 1 character at a time and only "on the fly", so the whole font file is never fully decoded into memory (probably too large to do so) - and therefore this extra data is probably there to aid working with the font 1 character at time, 1 scanline at a time.

As anyone using that font will be decoding and outputting multiple characters for each "screen" of text, you need a optimised font format to aid this.

You might be right, but as long as I remember the values of that bytes had no meaning for the space (32) character, which I used a lot to decode the char. I will check it again though, to avoid any errors on the player. If you are right, I will post an upgraded exe. Thanks for the tip.

I am afraid that you were right. They are offsets to the scanlines. So I have updated the 'Save' code for the fontfile.raw (which had one more bug). So use the new version to save the files. If you have already created a font with the initial exe, just load it in the new one and re-save it.

One last bug fix. I just discovered that when you create a character with width not multiple of 2, then it is not displayed correctly in the Visuals. The new exe adds an additional blank (ending) column to those characters defined whose width is not multiple of 2, just before saving the file.
Sorry for any inconvinience guys... it wasn't easy to find out the raw font file format, and that's why I had those 2 bugs. Hope that this release will be the last.