From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a05:6214:14b0:b0:635:e19a:6cc4 with SMTP id bo16-20020a05621414b000b00635e19a6cc4mr142930qvb.2.1691972982980; Sun, 13 Aug 2023 17:29:42 -0700 (PDT) X-Received: by 2002:a17:903:41c5:b0:1b9:fef8:9af1 with SMTP id u5-20020a17090341c500b001b9fef89af1mr3507023ple.5.1691972982317; Sun, 13 Aug 2023 17:29:42 -0700 (PDT) Path: eternal-september.org!news.eternal-september.org!news.mixmin.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 13 Aug 2023 17:29:41 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=65.130.210.206; posting-account=uAiShQoAAABL1dOXlVllWlQArz9o0jAG NNTP-Posting-Host: 65.130.210.206 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7304574e-7813-4db2-b70b-6b4921bdc8ffn@googlegroups.com> Subject: Re: Unifont static compiled and stack size... From: Micah Waddoups Injection-Date: Mon, 14 Aug 2023 00:29:42 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:65513 List-Id: On Sunday, August 13, 2023 at 3:19:55=E2=80=AFPM UTC-6, DrPi wrote: > Le 13/08/2023 =C3=A0 18:16, Micah Waddoups a =C3=A9crit :=20 > > I tried to compile the Unifont hex file, converted with a script into v= ariable 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=20 > >=20 > > My request for insight is:=20 > > (A) How do you recommend I compile the Unifont into a form that is usab= le 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 do= n't know how to import a large data variable compiled in Assembly or if I c= an even compile that much data using Assembly... It should work, but the co= mpiler might complain and I still have to figure out the importing part.)= =20 > >=20 > > (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?=20 > >=20 > > Just to be clear, I am trying to import values 0 .. 16#FFFFF#, way beyo= nd the two byte limit that so many libraries are functionally bound by in o= ne 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 a= nd 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 c= ommon font systems fail to support Unicode's full character range, making m= uch of it useless. I figured I could create the exact effects that I am try= ing to with Unifont both in graphical windows of various OSs, and on the Li= nux 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 littl= e 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 eve= ntually be added later. My goal is to both make my programming projects pos= sible and free certain features from too restricted licensing. > I don't have the answer to your question.=20 >=20 > However, I'll think twice before writing my own Unicode implementation.= =20 > It is way harder than you think. Managing all code points (0 ..=20 > 16#FFFFF#) is not enough.=20 > 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 ov= erlay one sort of glyph onto another, and correctly handling Unifont's duos= pace variations for the immediate future. I know I am doing things the har= d 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, baseli= ne, 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 rend= ering library that plots characters and Unicode sequences in such a way tha= t 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 A= lpha channel is rendered until the final rendering on the text area canvas = (which is purely image graphics since all the rendering is internal). Alon= g with this is a custom system of input that allows non-standard key combin= ations so that AE, OE, (c), etc. can be input as their actual characters in= stead of having to be copied and pasted from a character search tool or a f= ancy text input converter (like macOS with specific programs or word proces= sors). I don't know why such developments have gone stale, but input suppo= rt seems to be halted, per language, at the minimum operable level of devel= opment. This is one of the reasons I love Apple computers - They tend to g= o 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 lib= rary already has the beginning of limited support for text direction and fl= ow that can print in any reasonable direction to accommodate various langua= ges or block-character-graphics and a way to interpret where click/touch in= put maps to within the rendered text. It even has the beginning of a sprea= d-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. I= t 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 getti= ng closer to an eCS or OS/2 workplace shell in quality of handling programm= ed 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 atte= mpt my own projects or a code base that transfers between graphical, termin= al 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 j= ust managing application spawns with all their input/output being configura= ble is likely enough for me right now.