Re: Unifont static compiled and stack size...

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

On Sunday, August 13, 2023 at 3:19:55 PM UTC-6, DrPi wrote:
> Le 13/08/2023 à 18:16, Micah Waddoups a écrit : 
> > I tried to compile the Unifont hex file, converted with a script into variable Ada code, but it went on forever, gradually blowing up my memory. I used an .ads file and aimed for a static build, but I suspect I would have hit the stack size limit for executables if I succeeded 
> > 
> > My request for insight is: 
> > (A) How do you recommend I compile the Unifont into a form that is usable within my Ada program. (I am thinking compiling C and importing, since C is so basic it might just work, but even better would be Assembly and I don't know how to import a large data variable compiled in Assembly or if I can even compile that much data using Assembly... It should work, but the compiler might complain and I still have to figure out the importing part.) 
> > 
> > (B) Do you think this has a chance of succeeding if I compile the font as a shared library? That doesn't affect initial stack limits, right? 
> > 
> > Just to be clear, I am trying to import values 0 .. 16#FFFFF#, way beyond the two byte limit that so many libraries are functionally bound by in one bottle neck or another. I want to support something similar to 'kmscon', but with some shortcuts since I don't want to redo everything that others have done well. I just want to finish my library to a point of usefulness and focus on other projects. I felt compelled to create this library because every other library I looked at was broken in some way and even the most common font systems fail to support Unicode's full character range, making much of it useless. I figured I could create the exact effects that I am trying to with Unifont both in graphical windows of various OSs, and on the Linux terminal if I rewrite enough of the low level code that I don't have to rely on the less complete existing libraries. Admittedly, I have too little time to work on it, and am so far behind other people wonderful work that I will certainly have many holes and omitted functionality that should eventually be added later. My goal is to both make my programming projects possible and free certain features from too restricted licensing.
> I don't have the answer to your question. 
> 
> However, I'll think twice before writing my own Unicode implementation. 
> It is way harder than you think. Managing all code points (0 .. 
> 16#FFFFF#) is not enough. 
> You can read more here : https://mcilloni.ovh/2023/07/23/unicode-is-hard/

Thank you, you are quite right.  I have no intention of correctly handling Unicode for now.  Just interpreting a few things, like combinations that overlay one sort of glyph onto another, and correctly handling Unifont's duospace variations for the immediate future.  I know I am doing things the hard way, but I looked into the easier ways and couldn't find anything I could use.  My attempt is tightly focused on Unifont, so a lot of vector, baseline, aspect, sub-pixel rendering, etc. means nothing to what I am attempting.  I have instead of a terminal that uses Unifont as a font, a partial rendering library that plots characters and Unicode sequences in such a way that any number of non-printing characters can be sequenced in front of one or more printing glyphs, all without changing the line and index.  Only the Alpha channel is rendered until the final rendering on the text area canvas (which is purely image graphics since all the rendering is internal).  Along with this is a custom system of input that allows non-standard key combinations so that AE, OE, (c), etc. can be input as their actual characters instead of having to be copied and pasted from a character search tool or a fancy text input converter (like macOS with specific programs or word processors).  I don't know why such developments have gone stale, but input support seems to be halted, per language, at the minimum operable level of development.  This is one of the reasons I love Apple computers - They tend to go a little beyond the minimum.  I am hoping I can rely on a GL library and probably the ICU library at some point.  I have yet to see.  Anyway, my library already has the beginning of limited support for text direction and flow that can print in any reasonable direction to accommodate various languages or block-character-graphics and a way to interpret where click/touch input maps to within the rendered text.  It even has the beginning of a spread-sheet like separation of text areas, allowing a cursor or a scrolled view to be handled as expected or better when switching focus between cells.  It is a long way from finished, but when combined with my other components, like object-oriented support for encoding and streaming, I feel it is getting closer to an eCS or OS/2 workplace shell in quality of handling programmed objects.  The more that is handled well at the low level, the less work has to be complicated at the higher level.  GUIs are a real problem for me because they are so sophisticated and automated that I can barely even attempt my own projects or a code base that transfers between graphical, terminal and other operating systems.  GTK, GL libraries, and SDL are great and I plan to use at least one of them, but only to render the image buffer and collect input from modern hotplug-able devices.  If I can get around to it I might try to support pseudo virtual terminals like GNU Screen does, but just managing application spawns with all their input/output being configurable is likely enough for me right now.