Re: Unifont static compiled and stack size...

[Micah Waddoups <micah.waddoups@gmail.com>]

On Monday, August 14, 2023 at 10:03:01 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2023-08-14 17:10, Micah Waddoups wrote:
> [...] 
> 
> > procedure Unifont_Hex_To_Ada is 
> 
> [...] 
> 
> What are you going to do with this? 
> 
> 1. This is not a font usable in a GUI framework. 
> 
> 2. This is not a drawable in-memory image for a GUI framework either. 
> Provided, you wanted to render obtained images manually. These images 
> must be in a format supported by the corresponding engine. 
> 
> E.g. GTK uses Pixbuf representation for drawable in-memory images. Which is 
> 
> type Pixbuf_Image is array (Natural range 0..N*M-1) of GUChar; 
> pragma Convention (C, Pixbuf_Image); 
> 
> containing 4 channels RGB + alpha, row-wise. 
> 
> And, no, normally you cannot draw in an arbitrary OS window. 
> 
> If you are so keen to use GNU Unifont, why do not you install it from 
> its available formats like TrueType and be done with that? What is wrong 
> with other fixed-size fonts? 
> 
> Why do you want to render glyphs manually instead of using existing OS 
> facilities and GUI libraries? You cannot get around these libraries 
> without rewriting device drivers and who knows what else making the code 
> highly non-portable.
> -- 
> Regards, 
> Dmitry A. Kazakov 
> http://www.dmitry-kazakov.de

Jeff, Thanks for testing that.  I am currently too busy with work to attempt much more for a day or two, but I am excited that the less fancy method works!


Dmitry, of course, you are correct.  This was an attempt to take an image of the font source.  I assumed a few concessions against size efficiency to make it slightly more speed efficient would be needed, and it turned out I have to do the bit value extraction without the Boolean + 'with Pack' combo.  I can figure out what went wrong there later, since making the method easier to use in different languages has its benefits, so I don't need to use that method. 

 The rendering is done with a small cache of per-need rendered Glyphs - each rendered glyph is at least eight times larger before any styling or transformation.  Rendering all the glyphs at once takes up more memory than is needed and presupposes the destination format.  So, in reality, more processor work is being done by doing it in stages, but less is being done in each stage, so there is more room for other processing at each stage.  This is just the raw bitmap font that I want in the program without having to process and read the hex file every time it loads (that would be very inefficient design).  

 In the first rendering, the glyphs that are actually used are rendered into a cache with only Alpha values.  This is essentially gray-scale and is the value-map used for any transformations, glyph combining, and plotting on a per-line image plot map (which is another abstraction by line and index/column of just the first..last pixel boundaries).  The plot map can very quickly be changed for insertions, deletions, changing text direction or flow, etc. and only at the final rendering of the View-able area is the Alpha transformed into full color (4-byte with alpha) to be sent to the GL, framebuffer, GTK, or other pixel-map handling system.  Much like modern rendering systems, a lot of calculations happen behind the scenes at each key-press, only it is my attempt to combine it all into one library and scale it into a project  that can be plugged into whatever graphics system is being used.   It is probably slower in response to input than GTK or any native text handling system because effects, layers of glyph-combinations, markups (squiggle line, underline, etc), and colorization all go into the font rendering before it hits the graphics buffer, but it feels to me more correct and avoids having to add post-rendering effects as a later stage as much as possible.  Markups are done late, just before rotation (if any), but that is just as it must be, since they are effectively a rendered element of a different size than the individual glyphs they markup, yet still done before the rendered map is turned over to the graphics system.

The reason people rely on device drivers, native widgets, and less-portable combinations of libraries is that they incorporate the features and functionality desired into them, including how to handle input.  I am attempting to take the lowest level of input (key-presses, clicks, touch, etc) like a video game might, and outputting an image already rendered for display, thus replacing the normally convenient functionality provided by other systems.  I am *not* trying to replace actual device drivers or rely on a particular operating system's device access scheme.  That is why I am considering other well established libraries supporting GL or maybe SDL.  Not all programs render text and input with the convenient systems, so this is nothing new.  Also, since this scheme still tracks each character by line and index, even if I am only able to support text-mode terminal interface in one situation, that will only prevent using the full Unicode range of glyphs and combinations, not disable my ability to send/receive any given text with the display.  

-Micah-