• Unifont static compiled and stack size...

    From Micah Waddoups@21:1/5 to All on Sun Aug 13 09:16:27 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From DrPi@21:1/5 to All on Sun Aug 13 23:19:49 2023
    TGUgMTMvMDgvMjAyMyDDoCAxODoxNiwgTWljYWggV2FkZG91cHMgYSDDqWNyaXTCoDoNCj4g SSB0cmllZCB0byBjb21waWxlIHRoZSBVbmlmb250IGhleCBmaWxlLCBjb252ZXJ0ZWQgd2l0 aCBhIHNjcmlwdCBpbnRvIHZhcmlhYmxlIEFkYSBjb2RlLCBidXQgaXQgd2VudCBvbiBmb3Jl dmVyLCBncmFkdWFsbHkgYmxvd2luZyB1cCBteSBtZW1vcnkuICBJIHVzZWQgYW4gLmFkcyBm aWxlIGFuZCBhaW1lZCBmb3IgYSBzdGF0aWMgYnVpbGQsIGJ1dCBJIHN1c3BlY3QgSSB3b3Vs ZCBoYXZlIGhpdCB0aGUgc3RhY2sgc2l6ZSBsaW1pdCBmb3IgZXhlY3V0YWJsZXMgaWYgSSBz dWNjZWVkZWQNCj4gDQo+IE15IHJlcXVlc3QgZm9yIGluc2lnaHQgaXM6DQo+ICAgKEEpIEhv dyBkbyB5b3UgcmVjb21tZW5kIEkgY29tcGlsZSB0aGUgVW5pZm9udCBpbnRvIGEgZm9ybSB0 aGF0IGlzIHVzYWJsZSB3aXRoaW4gbXkgQWRhIHByb2dyYW0uIChJIGFtIHRoaW5raW5nIGNv bXBpbGluZyBDIGFuZCBpbXBvcnRpbmcsIHNpbmNlIEMgaXMgc28gYmFzaWMgaXQgbWlnaHQg anVzdCB3b3JrLCBidXQgZXZlbiBiZXR0ZXIgd291bGQgYmUgQXNzZW1ibHkgYW5kIEkgZG9u J3Qga25vdyBob3cgdG8gaW1wb3J0IGEgbGFyZ2UgZGF0YSB2YXJpYWJsZSBjb21waWxlZCBp biBBc3NlbWJseSBvciBpZiBJIGNhbiBldmVuIGNvbXBpbGUgdGhhdCBtdWNoIGRhdGEgdXNp bmcgQXNzZW1ibHkuLi4gIEl0IHNob3VsZCB3b3JrLCBidXQgdGhlIGNvbXBpbGVyIG1pZ2h0 IGNvbXBsYWluIGFuZCBJIHN0aWxsIGhhdmUgdG8gZmlndXJlIG91dCB0aGUgaW1wb3J0aW5n IHBhcnQuKQ0KPiANCj4gKEIpIERvIHlvdSB0aGluayB0aGlzIGhhcyBhIGNoYW5jZSBvZiBz dWNjZWVkaW5nIGlmIEkgY29tcGlsZSB0aGUgZm9udCBhcyBhIHNoYXJlZCBsaWJyYXJ5PyAg VGhhdCBkb2Vzbid0IGFmZmVjdCBpbml0aWFsIHN0YWNrIGxpbWl0cywgcmlnaHQ/DQo+IA0K PiBKdXN0IHRvIGJlIGNsZWFyLCBJIGFtIHRyeWluZyB0byBpbXBvcnQgdmFsdWVzIDAgLi4g MTYjRkZGRkYjLCB3YXkgYmV5b25kIHRoZSB0d28gYnl0ZSBsaW1pdCB0aGF0IHNvIG1hbnkg bGlicmFyaWVzIGFyZSBmdW5jdGlvbmFsbHkgYm91bmQgYnkgaW4gb25lIGJvdHRsZSBuZWNr IG9yIGFub3RoZXIuICBJIHdhbnQgdG8gc3VwcG9ydCBzb21ldGhpbmcgc2ltaWxhciB0byAn a21zY29uJywgYnV0IHdpdGggc29tZSBzaG9ydGN1dHMgc2luY2UgSSBkb24ndCB3YW50IHRv IHJlZG8gZXZlcnl0aGluZyB0aGF0IG90aGVycyBoYXZlIGRvbmUgd2VsbC4gIEkganVzdCB3 YW50IHRvIGZpbmlzaCBteSBsaWJyYXJ5IHRvIGEgcG9pbnQgb2YgdXNlZnVsbmVzcyBhbmQg Zm9jdXMgb24gb3RoZXIgcHJvamVjdHMuICBJIGZlbHQgY29tcGVsbGVkIHRvIGNyZWF0ZSB0 aGlzIGxpYnJhcnkgYmVjYXVzZSBldmVyeSBvdGhlciBsaWJyYXJ5IEkgbG9va2VkIGF0IHdh cyBicm9rZW4gaW4gc29tZSB3YXkgYW5kIGV2ZW4gdGhlIG1vc3QgY29tbW9uIGZvbnQgc3lz dGVtcyBmYWlsIHRvIHN1cHBvcnQgVW5pY29kZSdzIGZ1bGwgY2hhcmFjdGVyIHJhbmdlLCBt YWtpbmcgbXVjaCBvZiBpdCB1c2VsZXNzLiAgSSBmaWd1cmVkIEkgY291bGQgY3JlYXRlIHRo ZSBleGFjdCBlZmZlY3RzIHRoYXQgSSBhbSB0cnlpbmcgdG8gd2l0aCBVbmlmb250IGJvdGgg aW4gZ3JhcGhpY2FsIHdpbmRvd3Mgb2YgdmFyaW91cyBPU3MsIGFuZCBvbiB0aGUgTGludXgg dGVybWluYWwgaWYgSSByZXdyaXRlIGVub3VnaCBvZiB0aGUgbG93IGxldmVsIGNvZGUgdGhh dCBJIGRvbid0IGhhdmUgdG8gcmVseSBvbiB0aGUgbGVzcyBjb21wbGV0ZSBleGlzdGluZyBs aWJyYXJpZXMuICBBZG1pdHRlZGx5LCBJIGhhdmUgdG9vIGxpdHRsZSB0aW1lIHRvIHdvcmsg b24gaXQsIGFuZCBhbSBzbyBmYXIgYmVoaW5kIG90aGVyIHBlb3BsZSB3b25kZXJmdWwgd29y ayB0aGF0IEkgd2lsbCBjZXJ0YWlubHkgaGF2ZSBtYW55IGhvbGVzIGFuZCBvbWl0dGVkIGZ1 bmN0aW9uYWxpdHkgdGhhdCBzaG91bGQgZXZlbnR1YWxseSBiZSBhZGRlZCBsYXRlci4gIE15 IGdvYWwgaXMgdG8gYm90aCBtYWtlIG15IHByb2dyYW1taW5nIHByb2plY3RzIHBvc3NpYmxl IGFuZCBmcmVlIGNlcnRhaW4gZmVhdHVyZXMgZnJvbSB0b28gcmVzdHJpY3RlZCBsaWNlbnNp bmcuDQoNCkkgZG9uJ3QgaGF2ZSB0aGUgYW5zd2VyIHRvIHlvdXIgcXVlc3Rpb24uDQoNCkhv d2V2ZXIsIEknbGwgdGhpbmsgdHdpY2UgYmVmb3JlIHdyaXRpbmcgbXkgb3duIFVuaWNvZGUg aW1wbGVtZW50YXRpb24uIA0KSXQgaXMgd2F5IGhhcmRlciB0aGFuIHlvdSB0aGluay4gTWFu YWdpbmcgYWxsIGNvZGUgcG9pbnRzICgwIC4uIA0KMTYjRkZGRkYjKSBpcyBub3QgZW5vdWdo Lg0KWW91IGNhbiByZWFkIG1vcmUgaGVyZSA6IGh0dHBzOi8vbWNpbGxvbmkub3ZoLzIwMjMv MDcvMjMvdW5pY29kZS1pcy1oYXJkLw0K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Micah Waddoups@21:1/5 to DrPi on Sun Aug 13 17:29:41 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Niklas Holsti@21:1/5 to Micah Waddoups on Mon Aug 14 11:07:14 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Niklas Holsti on Mon Aug 14 10:31:43 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Micah Waddoups on Mon Aug 14 10:21:00 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Kevin Chadwick on Mon Aug 14 11:43:48 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Kevin Chadwick on Mon Aug 14 11:39:45 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey R.Carter@21:1/5 to Micah Waddoups on Mon Aug 14 12:06:35 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kevin Chadwick@21:1/5 to All on Mon Aug 14 09:25:07 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kevin Chadwick@21:1/5 to All on Mon Aug 14 09:30:58 2023
    Sorry, my client hung up and I guess sent multiple copies whilst I was too
    patient.

    --
    Regards, Kc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Micah Waddoups@21:1/5 to Jeffrey R.Carter on Mon Aug 14 08:10:01 2023
    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;

    begin
    Create (Target, Out_File, Target_Name);
    exception
    when others =>
    Open (Target, Out_File, Target_Name);
    end;


    begin
    Put_Line (Target, "pragma Ada_2012;");
    Put_Line (Target, "pragma Wide_Character_Encoding (UTF8);");
    New_Line (Target, 2);
    --Put_Line (Target, "with ada.unchecked_conversion;");
    --New_Line (Target, 2);
    Put_Line (Target, "package Unifont is");
    Put_Line (Target, "subtype Index_Type is Wide_Wide_Character range Wide_Wide_Character'Val (0) .. Wide_Wide_Character'Val (16#FFFFF#);");
    Put_Line (Target, "subtype Y_Type is Integer range 1 .. 16;");
    Put_Line (Target, "subtype X_Type is Integer range 1 .. 16;");
    Put_Line (Target, "type Size_Type is record Y: aliased Y_Type := 1; X: aliased X_Type := 1; end record;");
    Put_Line (Target, "type Size_Set_Type is array (Index_Type) of aliased Size_Type;");
    Put_Line (Target, "type Glyph_Type is array (Y_Type, X_Type) of Boolean");
    Put_Line (Target, "with Pack, Size=> 256;");
    Put_Line (Target, "type Glyph_Set_Type is array (Index_Type) of aliased Glyph_Type;");
    Put_Line (Target, "Glyph: constant Glyph_Set_Type :=");
    Put (Target, "(");
    loop
    exit when End_Of_File (Source);
    Next_Line; -- Load Next Line and extract Code Point index
    if
    Length > 64
    then
    Size (Current) := (16, 16);
    Put_Line (Target, "Wide_Wide_Character'Val (" &Integer'Image(Current) &") =>");
    Put (Target, "(");
    for Y in 1 .. 16
    loop
    Put_Line (Target, Y'Img &" =>");
    Put (Target, "(");
    for X in 1 .. 16
    loop
    if
    X < 16
    then
    Put (Target, Dot &", ");
    else
    Put (Target, Dot &")");
    end if;
    end loop;
    if
    Y < 16
    then
    Put_Line (Target, ",");
    else
    Put_Line (Target, "),");
    end if;
    end loop;
    elsif
    Length > 32
    then
    Put_Line (Target, "Wide_Wide_Character'Val (" &Integer'Image(Current) &") =>");
    Put (Target, "(");
    for Y in 1 .. 16
    loop
    Put_Line (Target, Y'Img &" =>");
    Put (Target, "(");
    for X in 1 .. 8
    loop
    Put (Target, Dot &", ");
    end loop;
    for X in 9 .. 16
    loop
    if
    X < 16
    then
    Put (Target, "False, ");
    else
    Put (Target, "False)");
    end if;
    end loop;
    if
    Y < 16
    then
    Put_Line (Target, ",");
    else
    Put_Line (Target, "),");
    end if;
    end loop;
    end if;
    end loop;
    Close (Source);
    Put_Line (Target, "others => (others => (others => False)));");
    New_Line (Target);
    Put_Line (Target, "Size: constant Size_Set_Type :=");
    Put (Target, "(");
    for N in Index_Type'Range
    loop
    Put (Target, "Wide_Wide_Character'Val (" &Integer'Image(N) &") =>");
    Put (Target, "(" &Integer'Image(Size(N).Y) &", " &Integer'Image(Size(N).X) &")");
    if
    N < Index_Type'Last
    then
    Put_Line (Target, ",");
    else
    Put_Line (Target, ");");
    end if;
    end loop;
    Put_Line (Target, "end Unifont;");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Put_Line (Target, "");
    Close (Target);
    end;
    end Unifont_Hex_To_Ada;

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Micah Waddoups on Mon Aug 14 18:02:58 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey R.Carter@21:1/5 to Micah Waddoups on Mon Aug 14 17:59:16 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Micah Waddoups@21:1/5 to Dmitry A. Kazakov on Mon Aug 14 21:48:03 2023
    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-

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From G.B.@21:1/5 to Dmitry A. Kazakov on Tue Aug 15 10:40:45 2023
    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;

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to G.B. on Wed Aug 16 08:17:50 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randy Brukardt@21:1/5 to Dmitry A. Kazakov on Thu Aug 17 22:04:18 2023
    "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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)