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.

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/

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.

On 2023-08-13 19:16, Micah Waddoups wrote:
> 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.

Could you show a little of the script-generated Ada code, just for us to
understand the approach you have taken to represent the Unifont file?

While waiting for that, it may help the compiler if you disable the more
advanced compiler optimizations, because some of them are super-linear
in complexity and probably (but depending on the exact form of the Ada
code) do not help for this case, anyway.

> (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.)

I'm not familiar with the structure of the Unifont file, but if it is
something like a table with rows and columns, it should be rather easy
to translate it into a list of assembly-language constant-data definitions.

Assemblers are typically linear in complexity and should be able to
handle large data definitions, assuming there is not a myriad of
assembler labels that make references between different parts of the
data structure.

Exporting a data object from assembly to Ada is simple and does not
depend on the size of the object (but I admit I don't know how this is
done for dynamically linked libraries). The only part that needs thought
is how to define the Ada type of the object, but if the Unifont file is
a row-column table, in other words a list of "row" records, that should
be straight-forward too.

So I think the assembly-language solution is highly likely to work; its
drawback, of course, is non-portability. But the constant-data
definitions of most assembly languages are very similar to each other,
so the assembler-generating script should be easy to port to different
assembly languages.

On 2023-08-14 02:29, Micah Waddoups wrote:
> 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.

Transfers what to where?

> 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.

GTK does not render any fonts. It uses other libraries for rendering,
depending on the surface e.g. Pango for rendering in Cairo, which is
vector graphics surfaces. As for crude bitmap fonts GTK just rely on the
target OS back end to render them, e.g. Windows GDI. If you need a
bitmap of a system font glyph, you render the text into the memory
instead of a device context and take the result. Though I have no idea
what and why are you trying to do.

> 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.

Any GUI has a text view widget or equivalent, e.g. GtkTextView in GTK.
Most of them support bitmap drawable widgets where you can draw and
render bitmap system fonts if you wanted to recreate a text view.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2023-08-14 10:07, Niklas Holsti wrote:

> I'm not familiar with the structure of the Unifont file, but if it is
> something like a table with rows and columns, it should be rather easy
> to translate it into a list of assembly-language constant-data definitions.

A comparable case. I have XPM to Ada translator (for having built-in
images in GTK). It simply creates packages with declarations of
initialized arrays. No stack issues.

Doing something like that for bitmap fonts is just as simple. The only
minor issue is creating an index map: code point to the bitmap image
name (array), because a flat array would blow out.

P.S. I always wanted static functions in Ada for the purpose of all
static initializations of objects like maps etc.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

>Doing something like that for bitmap fonts is just as simple. The only
>minor issue is creating an index map: code point to the bitmap image
>name (array), because a flat array would blow out.

What does blow out mean in this context?

--
Regards, Kc

Sorry, my client hung up and I guess sent multiple copies whilst I was too
patient.

--
Regards, Kc

On 2023-08-14 11:25, Kevin Chadwick wrote:

>> Doing something like that for bitmap fonts is just as simple. The only
>> minor issue is creating an index map: code point to the bitmap image
>> name (array), because a flat array would blow out.
>
> What does blow out mean in this context?

If you tried:

type Font_Type is array (Code_Point) of Bitmap_Ptr;

The range of code points is 0..16#10FFFF#. E.g. when I implemented
Ada.Strings.Maps for Unicode, I could not use such arrays either as the
native ASCII implementation does.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2023-08-14 11:30, Kevin Chadwick wrote:
> Sorry, my client hung up and I guess sent multiple copies whilst I was too
> patient.

My client (Thunderbird) hung today too. Coincidence? Where is my trusted
tin foil hat? (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2023-08-13 18:16, Micah Waddoups wrote:
> 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

As I understand it, the file in question is for code points 0 .. 16#FFFF#, with
a maximum of 32 bytes per code point. A straightforward representation of this is

package Unifont is
type Byte is mod 2 ** 8 with Size => 8;

type Line is array (1 .. 2) of Byte with Size => 16;

type Bitmap is array (1 .. 16) of Line with Size => 256;

function Width_8 (Map : in Bitmap) return Boolean is
(for all L of Map => L (2) = 0);

type Code_Point is mod 16#FFFF# + 1;

type Font_Map is array (Code_Point) of Bitmap with Size => 2 ** 24;

Font : constant Font_Map := (others => (others => (others => 0) ) );
end Unifont;

Font will occupy 2 MB.

We can test this with

with Ada.Text_IO;
with Unifont;

procedure Unifont_Test is
-- Empty
begin -- Unifont_Test
Ada.Text_IO.Put_Line (Item => Unifont.Font (0) (1) (1)'Image);
end Unifont_Test;

and see what happens:

$ gnatmake -m -j0 -gnat12 -gnatan -gnato2 -O2 -fstack-check unifont_test.adb
x86_64-linux-gnu-gcc-12 -c -gnat12 -gnatan -gnato2 -O2 -fstack-check
unifont_test.adb
x86_64-linux-gnu-gcc-12 -c -gnat12 -gnatan -gnato2 -O2 -fstack-check unifont.ads
x86_64-linux-gnu-gnatbind-12 -x unifont_test.ali
x86_64-linux-gnu-gnatlink-12 unifont_test.ali -O2 -fstack-check
$ ./unifont_test
0

so this representation seems to be workable. It should be trivial to write a
program to read the file and produce the real array aggregate for Font.

--
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail
13

On Monday, August 14, 2023 at 4:06:39 AM UTC-6, Jeffrey R.Carter wrote:
> On 2023-08-13 18:16, Micah Waddoups wrote:
> > 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
> As I understand it, the file in question is for code points 0 .. 16#FFFF#, with
> a maximum of 32 bytes per code point. A straightforward representation of this is
>
> package Unifont is
> type Byte is mod 2 ** 8 with Size => 8;
>
> type Line is array (1 .. 2) of Byte with Size => 16;
>
> type Bitmap is array (1 .. 16) of Line with Size => 256;
>
> function Width_8 (Map : in Bitmap) return Boolean is
> (for all L of Map => L (2) = 0);
>
> type Code_Point is mod 16#FFFF# + 1;
>
> type Font_Map is array (Code_Point) of Bitmap with Size => 2 ** 24;
>
> Font : constant Font_Map := (others => (others => (others => 0) ) );
> end Unifont;
>
> Font will occupy 2 MB.
>
> We can test this with
>
> with Ada.Text_IO;
> with Unifont;
>
> procedure Unifont_Test is
> -- Empty
> begin -- Unifont_Test
> Ada.Text_IO.Put_Line (Item => Unifont.Font (0) (1) (1)'Image);
> end Unifont_Test;
>
> and see what happens:
>
> $ gnatmake -m -j0 -gnat12 -gnatan -gnato2 -O2 -fstack-check unifont_test.adb
> x86_64-linux-gnu-gcc-12 -c -gnat12 -gnatan -gnato2 -O2 -fstack-check
> unifont_test.adb
> x86_64-linux-gnu-gcc-12 -c -gnat12 -gnatan -gnato2 -O2 -fstack-check unifont.ads
> x86_64-linux-gnu-gnatbind-12 -x unifont_test.ali
> x86_64-linux-gnu-gnatlink-12 unifont_test.ali -O2 -fstack-check
> $ ./unifont_test
> 0
>
> so this representation seems to be workable. It should be trivial to write a
> program to read the file and produce the real array aggregate for Font.
>
> --
> Jeff Carter
> "I wave my private parts at your aunties."
> Monty Python & the Holy Grail
> 13

Thank you all for replying while I was working away from home.

Jeff, you missed a digit - it's five F's 16#FFFFF# because that is as high as Unifont goes in my copy of the hex file. Of course the technique should be able to go higher if that changes, but Unicode is pretty exhaustive as it is and Unifont is meant to keep up with every version and addition to the Unicode code points, so I sincerely hope for no trouble for a while yet. I checked, and it seem my system has about 8 megabytes as the stack size limit, so with the ranges left empty it is not 32 megabytes, but still pretty big. Good looking code, by the way. Very easy to read. Mine is appended, but it was really a quick hack of a job with too little sleep. I probably should have done a Z Shell script (maybe take 20 seconds?), but I thought the two second efficiency of writing a compiled composer was worth it ....somehow...

Niklas, I think you have the most actionable suggestions for me to test. Thank you.

Dmitry, Thank you for trying to understand. Since both methods of rendering fonts made available by GTK, I consider it GTK providing it. I don't want any more imports than I can provide easily with a static compile or as accompanying dynamic modules (reason hereafter mentioned), and Licensing needs to be the most permissive possible. The idea is to be able to create a shell or a variety of other programs using my library as a very focused kind of interface that supports more characters and more languages that my other most available options, so the font is important, even if I'm just drawing to the Linux frame buffer. I meant a transfer of code from one platform to another. Sometimes in a graphical window that acts like a text interface window, sometimes on the linux frame buffer, and in the extreme case some times on the text console without any particular font support. The main collection of code is supposed to support all that with very limited modification to say transfer from Linux to macOS or MS Windows? I hope this s answered your questions.

Oh, and to all, I have already abandon the idea of using Boolean with Pack, since it no longer seems to work and was a bit *too* verbose

pragma Ada_2012;
pragma Wide_Character_Encoding (UTF8);

with Ada.Text_IO;
use Ada.Text_IO;

procedure Unifont_Hex_To_Ada is

Target_Name: String := "./src/unifont.ads";
Source_Name: String := "unifont_all-15.0.06.hex";
Target: aliased File_Type;
Source: aliased File_Type;
Buffer: aliased String (1 .. 96) := (others=>' ');
Index, F: Positive := 1;
Previous, Current, Length, L: Natural := 0;
Finished: aliased Boolean:= False;
subtype Hex_Character is Character range '0' .. 'f'
with Static_Predicate=> (Hex_Character in '0' .. '9') or (Hex_Character in 'A' .. 'F') or (Hex_Character in 'a' .. 'f');
type Byte is mod 2 **8;
type Bit is mod 8;
--type Bytes is array (Natural range <>) of aliased Byte;
Bit_X: Bit := 0;
Byte_X: Byte := 0;
function Find (Item: Character)
return Natural
is
begin
for
N in Buffer'Range
loop
if Item = Buffer(N)
then return N;
end if;
end loop;
return 0;
end Find;
function Enum return Natural
is
First: Positive := 1;
Last: Natural := Integer'Max ((Find (':') -1), 0);
begin
return R: Natural
do
R := Natural'Value ("16#" &Buffer (First..Last) &'#');
end return;
end Enum;
procedure Next_Byte
is
S: String renames Buffer (F .. L);
begin
loop
if
(Index in S'Range) and (Index +1 in S'Range)
then
exit;
else
Index := S'First;
if
(Index in S'Range) and (Index +1 in S'Range)
then
exit;
else
raise Program_Error with "Next_Byte-> Somehow there are no Hex codes in string... line " &Current'Img &", string => " & S;
end if;
end if;
end loop;
if
S (Index) in Hex_Character
and
S (Index +1) in Hex_Character
then
Byte_X := Byte'Value ("16#" &S (Index..Index +1) &"#");
Bit_X := 0;
Index := Index +2;
end if;
end Next_Byte;
procedure Next_Line
is
begin
for
N in Buffer'First .. Length
loop
Buffer (N):= ' ';
end loop;
begin
Get_Line (Source, Buffer, Length);
exception
when others => null;
end;
if
Length < 32
then
Put_Line (Standard_Error, "empty or incomplete line at code point " &Natural'Image (Enum) &" (" &Current'Img &" + 1)");
else
Previous:= Current;
Current:= Enum;
if
((Previous + 1) = Current)
or else (Current = 0)
then
F:= Find (':') +1;
L:= Length;
Next_Byte;
else
F:= Find (':') +1;
L:= Length;
Next_Byte;
Put_Line (Standard_Error, " Missing character range in Source: " &Previous'Img &" .. " &Current'Img);
end if;
end if;
end Next_Line;

subtype Index_Type is Natural range 0 .. 16#FFFFF#;
subtype Y_Type is Integer range 1 .. 16;
subtype X_Type is Integer range 1 .. 16;
type Size_Type is
record
Y: aliased Y_Type:= Y_Type'First;
X: aliased X_Type:= X_Type'First;
end record;
type Size_Set_Type is array (Index_Type) of aliased Size_Type;
type Size_Set_Access is access all Size_Set_Type;
function Dot return String is
begin
if
1 = ((Byte_X / 2 **(7 - Natural(Bit_X))) and 1)
then
if
Bit_X = Bit'Last
then
Next_Byte;
else
Bit_X := Bit_X +1;
end if;
return "True";
else
if
Bit_X = Bit'Last
then
Next_Byte;
else
Bit_X := Bit_X +1;
end if;
return "False";
end if;
end Dot;
Cache_Size: Size_Set_Access := new Size_Set_Type'(others => (16, 8));
Size: Size_Set_Type renames Cache_Size.all;

begin

begin
Open (Source, In_File, Source_Name);
exception
when others =>
raise Status_Error with " Source File not found: " &Source_Name;
end;

On 2023-08-14 17:10, Micah Waddoups wrote:
>
> Jeff, you missed a digit - it's five F's 16#FFFFF# because that is as high as Unifont goes in my copy of the hex file. Of course the technique should be able to go higher if that changes, but Unicode is pretty exhaustive as it is and Unifont is meant to keep up with every version and addition to the Unicode code points, so I sincerely hope for no trouble for a while yet. I checked, and it seem my system has about 8 megabytes as the stack size limit, so with the ranges left empty it is not 32 megabytes, but still pretty big. Good looking code, by the way. Very easy to read. Mine is appended, but it was really a quick hack of a job with too little sleep. I probably should have done a Z Shell script (maybe take 20 seconds?), but I thought the two second efficiency of writing a compiled composer was worth it ...somehow...

You're right. Sorry for misreading that. But increasing Code_Point to include
16#F_FFFF# still works for me.

Unicode defines code points up to 16#10_FFFF#, but perhaps those over 16#F_FFFF#
are unused. Increasing Code_Point to include 16#10_FFFF# still works for me.
That's 34 MB. It won't fit on the stack, but luckily library-level constants
aren't allocated on the stack.

--
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail
13

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

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-

On 14.08.23 10:31, Dmitry A. Kazakov wrote:
>
> P.S. I always wanted static functions in Ada for the purpose of all static initializations of objects like maps etc.
>

If data form the equivalent of a static Ada array,
thus a mapping from an index type to a value type,
could you approximate the static initialization
of maps using expression functions?

Simplifying example:

package sttc is

type Key is range 1 .. 7;
type Value is new Character;
type Cursor is private;

function lookup (K: Key) return Cursor;
function element (C: Cursor) return Value;

private
type Cursor is new Key;
end sttc;

package body sttc is

function lookup (K: Key) return Cursor is (Cursor (K));

function element (C: Cursor) return Value is
(case C is
when 1 => 'M',
when 2 => 'M',
when 3 => 'X',
when 4 => 'X',
when 5 => 'I',
when 6 => 'I',
when 7 => 'I'
);

end sttc;

On 2023-08-15 10:40, G.B. wrote:
> On 14.08.23 10:31, Dmitry A. Kazakov wrote:
>>
>> P.S. I always wanted static functions in Ada for the purpose of all
>> static initializations of objects like maps etc.
>>
>
> If data form the equivalent of a static Ada array,
> thus a mapping from an index type to a value type,
> could you approximate the static initialization
> of maps using expression functions?

In general case no. Initialization cannot be decomposed into functions.
E.g. when requires global [yet static] data, many places to set etc.

P.S. Expression functions are evil. I wonder why there is no expression
gotos and labels? If you sell your soul to the devil, get the whole
package! (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:ubhpme$370q7$1@dont-email.me...
> On 2023-08-15 10:40, G.B. wrote:
>> On 14.08.23 10:31, Dmitry A. Kazakov wrote:
>>>
>>> P.S. I always wanted static functions in Ada for the purpose of all
>>> static initializations of objects like maps etc.
>>>
>>
>> If data form the equivalent of a static Ada array,
>> thus a mapping from an index type to a value type,
>> could you approximate the static initialization
>> of maps using expression functions?
>
> In general case no. Initialization cannot be decomposed into functions.
> E.g. when requires global [yet static] data, many places to set etc.
>
> P.S. Expression functions are evil. I wonder why there is no expression
> gotos and labels? If you sell your soul to the devil, get the whole
> package! (:-))

Ada only allows expressions to be evaluated at elaboration time (outside of
generic instantations), and expressions have a well-defined and simple
control flow (even accounting for conditional expressions and quantified
expressions, both of which implicitly appear in aggregates even in Ada 83 --
allowing programmers to write them explicitly makes the code more readable
than the horrible work-arounds commonly used pre-Ada 2012). Gotos and labels
have arbitrary control flow, which can be much harder to analyze. (Janus/Ada
converts the majority of code into an expression form for optimization --
essentially most id statements become if expressions, and so on. It simply
punts when the control flow is too complex to convert, so the unrestricted
use of gotos effectively prevents most optimization as well as static
analysis.)

If it was up to me, I would have left out declare expressions and quantified
expressions, so the capabilities of expression functions would have been
much more limited. But it seems valuable to be able to abstract an
expression without changing the semantics (as requiring a separate body
does).

Randy.