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:a13:b0:63d:557f:b4c9 with SMTP id dw19-20020a0562140a1300b0063d557fb4c9mr8939qvb.3.1692074885103; Mon, 14 Aug 2023 21:48:05 -0700 (PDT) X-Received: by 2002:a17:902:d4ce:b0:1b5:1637:6313 with SMTP id o14-20020a170902d4ce00b001b516376313mr4862833plg.0.1692074884471; Mon, 14 Aug 2023 21:48:04 -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: Mon, 14 Aug 2023 21:48:03 -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: <5290b261-c8d8-4f0a-87f5-941d275a1e6dn@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <888f633e-4b01-4fc1-a32d-46fbc935c990n@googlegroups.com> Subject: Re: Unifont static compiled and stack size... From: Micah Waddoups Injection-Date: Tue, 15 Aug 2023 04:48:05 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:65526 List-Id: On Monday, August 14, 2023 at 10:03:01=E2=80=AFAM UTC-6, Dmitry A. Kazakov = wrote: > On 2023-08-14 17:10, Micah Waddoups wrote: > [...]=20 >=20 > > procedure Unifont_Hex_To_Ada is=20 >=20 > [...]=20 >=20 > What are you going to do with this?=20 >=20 > 1. This is not a font usable in a GUI framework.=20 >=20 > 2. This is not a drawable in-memory image for a GUI framework either.=20 > Provided, you wanted to render obtained images manually. These images=20 > must be in a format supported by the corresponding engine.=20 >=20 > E.g. GTK uses Pixbuf representation for drawable in-memory images. Which = is=20 >=20 > type Pixbuf_Image is array (Natural range 0..N*M-1) of GUChar;=20 > pragma Convention (C, Pixbuf_Image);=20 >=20 > containing 4 channels RGB + alpha, row-wise.=20 >=20 > And, no, normally you cannot draw in an arbitrary OS window.=20 >=20 > If you are so keen to use GNU Unifont, why do not you install it from=20 > its available formats like TrueType and be done with that? What is wrong= =20 > with other fixed-size fonts?=20 >=20 > Why do you want to render glyphs manually instead of using existing OS=20 > facilities and GUI libraries? You cannot get around these libraries=20 > without rewriting device drivers and who knows what else making the code= =20 > highly non-portable. > --=20 > Regards,=20 > Dmitry A. Kazakov=20 > http://www.dmitry-kazakov.de Jeff, Thanks for testing that. I am currently too busy with work to attemp= t much more for a day or two, but I am excited that the less fancy method w= orks! Dmitry, of course, you are correct. This was an attempt to take an image o= f 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 ea= sier to use in different languages has its benefits, so I don't need to use= that method.=20 The rendering is done with a small cache of per-need rendered Glyphs - eac= h rendered glyph is at least eight times larger before any styling or trans= formation. Rendering all the glyphs at once takes up more memory than is n= eeded and presupposes the destination format. So, in reality, more process= or 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 proce= ss and read the hex file every time it loads (that would be very inefficien= t design). =20 In the first rendering, the glyphs that are actually used are rendered int= o a cache with only Alpha values. This is essentially gray-scale and is th= e 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/c= olumn of just the first..last pixel boundaries). The plot map can very qui= ckly 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 tr= ansformed into full color (4-byte with alpha) to be sent to the GL, framebu= ffer, 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 h= andling system because effects, layers of glyph-combinations, markups (squi= ggle 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 av= oids having to add post-rendering effects as a later stage as much as possi= ble. Markups are done late, just before rotation (if any), but that is jus= t as it must be, since they are effectively a rendered element of a differe= nt size than the individual glyphs they markup, yet still done before the r= endered 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 functi= onality 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, thu= s replacing the normally convenient functionality provided by other systems= . I am *not* trying to replace actual device drivers or rely on a particul= ar operating system's device access scheme. That is why I am considering o= ther well established libraries supporting GL or maybe SDL. Not all progra= ms render text and input with the convenient systems, so this is nothing ne= w. 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 situa= tion, that will only prevent using the full Unicode range of glyphs and com= binations, not disable my ability to send/receive any given text with the d= isplay. =20 -Micah-