Le 13/08/2023 à 18:16, Micah Waddoups a écrit :executables if I succeeded
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
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.)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
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(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
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/
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.)
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.
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.
Sorry, my client hung up and I guess sent multiple copies whilst I was too patient.
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?
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 forexecutables if I succeeded
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.
On 2023-08-13 18:16, Micah Waddoups wrote:executables if I succeeded
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
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
procedure Unifont_Hex_To_Ada is
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 meantto 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
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
P.S. I always wanted static functions in Ada for the purpose of all static initializations of objects like maps etc.
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?
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! (:-))
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 365 |
Nodes: | 16 (3 / 13) |
Uptime: | 05:17:47 |
Calls: | 7,785 |
Calls today: | 7 |
Files: | 12,914 |
Messages: | 5,750,432 |