Custom Text Formatting (Previously: Getting long results in a program)

[Tyann]

(03-29-2024 07:59 PM)komame Wrote:  What method did you use to generate bold text?

Pour afficher en gras j'affiche le texte 2 fois, en x,y et en x+1,y.
Pour afficher en relief j'affiche le texte 2 fois, en x,y et en x+1,y+1.

To display in bold, I display the text 2 times, in x,y and in x+1,y.
To display in relief I display the text 2 times, in x,y and in x+1,y+1.

[komame]

(03-29-2024 09:33 PM)Tyann Wrote:  To display in bold, I display the text 2 times, in x,y and in x+1,y.

That's what I suspected. I don't know if you're aware, but even displaying the text several times in the same place (e.g., 3 times at exactly the same coordinates) will result in it being slightly bold.
This is because the antialiasing on the edges of the letters is semi-transparent, so when you apply the text multiple times in the same place, the smoothing pixels on the edges become less transparent or completely lose their transparency, making the letters appear thicker.
This can then achieve semi-bold effects.

[Tyann]

Bonjour komame

Je vais tester cela pour voir si le rendu est meilleur, j'ai commencé à intégrer
l'affichage italique dans mon programme DEFTEXT et il faut que je le remanie un peu.
Car les effets programmés se font après l'affichage du text et avec l'italique cela complique un peu les choses, selon les associations d'attributs l'ordre change.
De plus ma fonction TEXT_P fonctionne sur n'importe quel ECRAN G0 à G9, maintenant il faudra interdire l'emploi d'un écran utilisé pour le tampon (dommage que l'on ne puisse pas utiliser des variables locales pour les écrans).


Hello komame

I'm going to test this to see if the rendering is better.
italic display in my DEFTEXT program and I need to rework it a bit.
Because the programmed effects are done after the text is displayed and with italics it complicates things a bit, depending on the attribute associations the order changes.
What's more, my TEXT_P function works on any G0 to G9 SCREEN, so now I'll have to forbid the use of a screen used for the buffer (it's a shame we can't use local variables for screens).

Sachez que j'apprécie beaucoup vos remarques et conseils.

I really appreciate your comments and advice.

[komame]

Hi Tyann

(03-30-2024 09:38 AM)Tyann Wrote:  I'm going to test this to see if the rendering is better.

It's not supposed to be better, just different. What I'm talking about allows for achieving intermediate effects for text bolding. The method you're using will certainly produce a stronger bolding effect, but sometimes it may not be legible, especially for very small font sizes. Alternatively, someone may want to use multiple levels of text bolding.

(03-30-2024 09:38 AM)Tyann Wrote:  italic display in my DEFTEXT program and I need to rework it a bit.
Because the programmed effects are done after the text is displayed and with italics it complicates things a bit, depending on the attribute associations the order changes.
What's more, my TEXT_P function works on any G0 to G9 SCREEN, so now I'll have to forbid the use of a screen used for the buffer (it's a shame we can't use local variables for screens).

There is a way to buffer the image without using G0-G9

(03-30-2024 09:38 AM)Tyann Wrote:  I really appreciate your comments and advice.

My pleasure

[Tyann]

Quote:There is a way to buffer the image without using G0-G9

Très intéressant ???
Sinon de mon côté je me disais qu'avec GROBH_P et GROBW_P je peux savoir si G9 est utilisé
et le sauvegarder si besoin avec AFILES pour le restaurer ensuite.


Very interesting ???
If not, I was thinking that with GROBH_P and GROBW_P I can find out if G9 is being used
and back it up if necessary with AFILES to restore it later.

[komame]

(03-30-2024 04:05 PM)Tyann Wrote:  Very interesting ???
If not, I was thinking that with GROBH_P and GROBW_P I can find out if G9 is being used
and back it up if necessary with AFILES to restore it later.

I know a method that works without using files, almost like variables (although it has certain limitations).
I'll provide more details tomorrow, as unfortunately I'm very busy at the moment.

[komame]

The solution I mentioned utilizes the ICON object. A particular characteristic of ICON is that you can also draw on it exactly the same way as on G0-G9. The only limitation here is that you must specify the maximum buffer size in advance (or buffers, as it's often better to have several small ones instead of one large). By defining such a buffer, you assume that you will draw something on it, so during its definition, we can assume that it is entirely in a uniform color. This makes its size relatively small in the source code. Then it doesn't matter whether the buffer is 20x20 pixels or 320x240 pixels because it will occupy a similar amount of space in the source code.

Here is an example of using a buffer based on ICON for drawing transparent text:

Code:

EXPORT DRAWTEXT_P(text,x,y,font,alpha)
BEGIN
LOCAL size=TEXTSIZE(text,font);
RECT_P("buffer");
TEXTOUT_P(text,"buffer",1,1,7);
BLIT_P(x,y,"buffer",1,1,size[1],size[2],#FFFFFF,alpha);
END;

ICON buffer 89504E470D0A1A0A0000000D49484452000001400000001A0100000000EE89B822000000027​4524E5300010194FDAE0000001D494441547801EDCA31010000008230FA97D60AFEB27B6464341A8​F63015D3D0C2DD86ED4F60000000049454E44AE426082;

In this example, I used a buffer with a size of 320x28 pixels because that is sufficient to draw text at the maximum font size using TEXTOUT_P.

[chromos]

I may be misremembering, but I think I read somewhere that the ICON command is deprecated and no longer recommended. Can someone confirm or deny this?

[komame]

(03-31-2024 05:54 PM)chromos Wrote:  I may be misremembering, but I think I read somewhere that the ICON command is deprecated and no longer recommended. Can someone confirm or deny this?

It all depends on the purpose for which you want to use it. If you simply want to store sprites in it in "read-only" mode (as was done in the early days of HP Prime), then it's obsolete. But what I showed is not for storing sprites; it's for using as a temporary graphics buffer that also works in "write" mode, and you can dynamically change it during program execution to avoid overwriting images currently stored in G0-G9.
For example, if you write a graphics library and use G9 as a buffer in it, then someone who uses this library in their program, where they also use G9 for other purposes specific to that program, will have a problem because your library will overwrite what they have in G9, and the program will not work correctly. By using ICON in "write" mode, you avoid such problems. It simply works as if you had additional buffers outside of G0-G9 that work very similarly, but you can have as many of them as you want.
When something is "deprecated", it means that its use is not recommended because there is another, better solution. However, in this case, there is no other solution that provides these capabilities, so using ICON is the only option in this regard.

[chromos]

Thank you for the explanation. Hopefully Moravia won't remove "deprecated" ICON command from future firmware release(s), which would invalidate programs that use it.

[Tyann]

Bonjour komame

Oui j'y ai pensé aussi, car je savais que l'on peut utiliser les instructions graphiques avec ICON,
mais effectivement Tim et Cyrille déconseillaient de continuer à l'utiliser (sans doute un retrait était il prévu, à voir peut être avec Jeff ).
Par contre il faut un buffer de 330 pixels à cause du décalage qu'il faut créer pour l'angle (j'ai pris 10 pour être large).
Je tamponne les trois premières lignes dans le buffer à x=10, puis les trois suivantes à x=9 etc...
ensuite je fais mon TEXTOUT_P avec x=10, puis recopie sur le Gx en x en commençant par 10 pui 9 et ainsi de suite.

Hello komame

Yes, I thought about it too, because I knew that you could use graphical instructions with ICON,
but indeed Tim and Cyrille advised against continuing to use it (no doubt a withdrawal was planned, perhaps to be checked with Jeff ).
On the other hand, you need a buffer of 330 pixels because of the offset you need to create for the angle (I used 10 to be wide).
I stamp the first three lines in the buffer at x=10, then the next three at x=9 etc...
then I do my TEXTOUT_P with x=10, then copy to the Gx in x starting with 10 then 9 and so on.

Translated with DeepL.com (free version)

[komame]

(04-01-2024 06:04 AM)Tyann Wrote:  Yes, I thought about it too, because I knew that you could use graphical instructions with ICON,
but indeed Tim and Cyrille advised against continuing to use it (no doubt a withdrawal was planned, perhaps to be checked with Jeff ).

Hello Tyann,

If a programmer says that TEXTOUT_P is deprecated (hypothetically) because a new function, SUPERTEXTOUT_P, has been created in its place, which does the same thing much faster but doesn't support color output (meaning text can only be output in black), does it mean that no one should use TEXTOUT_P anymore? It exactly means that if you use the TEXTOUT_P function and output text in black, you should replace it with SUPERTEXTOUT_P. However, if you need to output color, the new function can't do that, so you must resort to available solutions to achieve it. The same goes for ICON. The functionality of ICON has only been partially replaced by support for graphic files (png, jpg), but a solution that replaces it 100% hasn't been offered, so in certain situations, ICON cannot be avoided (until something in PPL is provided to fully replace it).
I had this thought that "Resources" which store image definitions (and they are stored in RAM) could be expanded, and the ability to modify them using graphic instructions could be added. Then it could be confidently said that ICON is "deprecated".

In the case of such a library with text-graphic functions that you are creating, I wouldn't have any concerns about using ICON, because it's simply needed here.

(04-01-2024 06:04 AM)Tyann Wrote:  On the other hand, you need a buffer of 330 pixels because of the offset you need to create for the angle (I used 10 to be wide).
I stamp the first three lines in the buffer at x=10, then the next three at x=9 etc...
then I do my TEXTOUT_P with x=10, then copy to the Gx in x starting with 10 then 9 and so on.

My example above only concerned displaying transparent text (just the simplest method to demonstrate ICON functionality in write mode), which is why I mentioned 320 pixels.

[Tyann]

J'ai remplacé G9 par ICON dans mon programme et cela fonctionne plutôt bien, mais il me reste encore quelques modifications à faire.
Tout cela m'a donné matière à réflexion et alors que je suis parti sur un programme à 2 instructions, DEFTEXT pour définir les paramètres et TEXT_P pour afficher, je me demande si il ne serait pas mieux de créer une seule fonction basée sur la syntaxe TEXTOUT_P avec donc la possibilité de définir des attributs tels que : italique, gras, sous lignés , encadrés ou barrés.
TEXT_P(s,[g],x,y[,p,c,a,l,f);
avec s=chaîne à afficher
g=écran (par défaut G0)
x et y= coordonnées d'affichage
p=police (par défaut 0)
c=couleur (par défaut 0=noir)
l= largeur limite (par défaut tout le texte)
f=couleur de fond (par défaut transparent)
Cela pourrait offrir à la communauté de nouvelles fonctionnalités et pour que ce projet soit écrit avec rigueur et efficacité, je vous propose que nous le réalisions ensemble vu vos capacités de programmation supérieures aux miennes.
Qu'en dites vous ?

I've replaced G9 with ICON in my programme and it works quite well, but I still have a few changes to make.
All this has given me something to think about, and while I've decided on a programme with 2 instructions, DEFTEXT to define the parameters and TEXT_P to display, I'm wondering whether it wouldn't be better to create a single function based on the TEXTOUT_P syntax, with the option of defining attributes such as italics, bold, underlined, framed or strikethrough.
TEXT_P(s,[g],x,y[,p,c,a,l,f);
with s=string to display
g=screen (default G0)
x and y= display coordinates
p=police (default 0)
c=colour (default 0=black)
l=width limit (default is all text)
f=background colour (default is transparent)
This could offer the community some new features and to ensure that this project is written rigorously and efficiently, I suggest that we do it together, as your programming skills are superior to mine.
What do you say?


Translated with DeepL.com (free version)

[komame]

(04-01-2024 09:08 PM)Tyann Wrote:  I've replaced G9 with ICON in my programme and it works quite well, but I still have a few changes to make.
All this has given me something to think about, and while I've decided on a programme with 2 instructions, DEFTEXT to define the parameters and TEXT_P to display, I'm wondering whether it wouldn't be better to create a single function based on the TEXTOUT_P syntax, with the option of defining attributes such as italics, bold, underlined, framed or strikethrough.
TEXT_P(s,[g],x,y[,p,c,a,l,f);
with s=string to display
g=screen (default G0)
x and y= display coordinates
p=police (default 0)
c=colour (default 0=black)
l=width limit (default is all text)
f=background colour (default is transparent)
This could offer the community some new features and to ensure that this project is written rigorously and efficiently, I suggest that we do it together, as your programming skills are superior to mine.
What do you say?

Sure, I can help. Although from what you're writing, it seems like you've already tackled the hardest part. This reorganization to consolidate everything into one function probably isn't a big challenge.
Due to the fact that PPL does not support default parameter values for function parameters, this needs to be implemented through several functions with the same name, which take a different number of parameters but internally refer to one common function with predetermined values for all parameters.

I also wanted to show you the differences between various bold modes:
   

The numbered lines are as follows:
1. regular text,
2. bold by displaying 3-times in the same place,
3. bold by displaying 2-times with a 1-pixel horizontal shift,
4. bold by combining points 2 and 3.

Notice that between points 2 and 3, the difference for large fonts is not significant (the solution with a horizontal shift results in slightly thicker letters), but when you look at very small fonts, you can see that option 2 provides much sharper letters (more readable) than option 3.

btw, Super-bold looks pretty cool; consider adding it as one of the formatting options as well.
I'll leave it up to your decision.

[Tyann]

Bonjour komame

Merci pour vôtre aide, mon approche rejoint la vôtre, une même fonction avec un nombre de paramètres différents.
J'ai placé le paramètre d'attributs en position 7 pour que la largeur limitée et le recouvrement restent optionnels.
Oui le superbold est très sympa, par contre une question me vient : ces différents attributs doivent être pouvoir combinés: gras et sous lignés par exemple.
Comment cela se passerait-il pour ces différents types de 'bold', peut-être utilisé une valeur décimale ?
TEXT_P avec moins de 6 ou 7 paramètres selon que l'on transmet Gx ou pas est tout simplement un TEXTOUT_P mais je pense que TEXT_P doit quand même être programmé pour pouvoir utiliser cette seule instruction en toute circonstances.
Enfin pour tester si le second paramètre fourni est un Gx ou pas j'ai utilisé TYPE qui renvoie 8 (fonction) pour un Gx.
Tout cela vous paraît-il cohérent ?

Hello komame

Thanks for your help, my approach is the same as yours, the same function with a different number of parameters.
I've set the attributes parameter to position 7 so that the limited width and the overlap remain optional.
Yes, the superbold is very nice, but one question comes to mind: these different attributes should be able to be combined: bold and underlined for example.
How would this work for these different types of bold, perhaps using a decimal value?
TEXT_P with less than 6 or 7 parameters depending on whether Gx is transmitted or not is simply a TEXTOUT_P but I think that TEXT_P should still be programmed to be able to use this single instruction in all circumstances.
Finally, to test whether the second parameter supplied is a Gx or not, I used TYPE which returns 8 (function) for a Gx.
Does all this seem coherent to you?

Translated with DeepL.com (free version)

[komame]

(04-03-2024 05:15 AM)Tyann Wrote:  Thanks for your help, my approach is the same as yours, the same function with a different number of parameters.
I've set the attributes parameter to position 7 so that the limited width and the overlap remain optional.

There is another way to handle default parameter values. I'm not sure if it will be better, but it doesn't require creating separate functions with different numbers of parameters. For this purpose, you can use a variable-length argument. This solution allows passing from 1 to 16 values to the function. Then it's just a matter of checking the types of the passed values, which can be done by comparing entire lists.

For example (inside the "CASE", all permissible scenarios should be listed):

Code:

EXPORT DRAWTEXT_P(...par)
BEGIN
  LOCAL pt;
  pt:=EXECON("TYPE(&1)",par);
  CASE
    IF EQ(pt,{2,8,0}) THEN
      //set params default values
    END;
    IF EQ(pt,{2,0}) THEN
      //set params default values
    END;
    IF EQ(pt,{2,8,0}) THEN
      //set params default values
    END;
    RETURN "Syntax Error";
  END;
  //The rest of the function's code 
END;

(04-03-2024 05:15 AM)Tyann Wrote:  Yes, the superbold is very nice, but one question comes to mind: these different attributes should be able to be combined: bold and underlined for example.
How would this work for these different types of bold, perhaps using a decimal value?

There are many possibilities here. It's a matter of preference. It could even be a string where each character corresponds to enabling a specific format, for example: B - bold, U - underline, I - italic, S - strikethrough, D - double-bold, F - framed. If any of these letters appear in the string (using INSTRING), then it's clear that a specific format needs to be set. But decimal presentation is also fine.

[Tyann]

Bonjour komame

Utiliser une seule fonction avec une liste variable ressemblerait beaucoup à ce que je faisais avec DEFTETXT qui utilisais une liste pour les paramètres.
Mais cela implique beaucoup de tests et j'ai voulu tenter une autre approche avec des fonctions séparées et j'ai l'impression que cela simplifie beaucoup le code.
Une chaîne pour les attributs, hum c'est très intéressant, je garde cela en réserve.

Un autre problème que je ne sais pas comment gérer pour l'instant, est la largeur limitée avec du texte en italique ?
En effet si j' affiche "TYANN" avec disons une largeur de 50 en normal et ensuite en italique : du fait du décalage il me manquera une partie du dernier caractère affiché.
Conserver les caractères ou la largeur en pixels ?
Qu'en pensez-vous ?

Hello komame

Using a single function with a variable list would be very similar to what I was doing with DEFTETXT, which used a list for the parameters.
But this involves a lot of testing and I wanted to try another approach with separate functions and I have the impression that this simplifies the code a lot.
A string for the attributes, um that's very interesting, I'll keep that in reserve.

Another problem that I don't know how to deal with at the moment is the limited width with italic text?
If I display "TYANN" with, say, a width of 50 in normal and then in italics: because of the offset I'll be missing part of the last character displayed.
Should I keep the characters or the width in pixels?
What do you think?

Translated with DeepL.com (free version)

[komame]

(04-03-2024 08:53 PM)Tyann Wrote:  Using a single function with a variable list would be very similar to what I was doing with DEFTETXT, which used a list for the parameters.
But this involves a lot of testing and I wanted to try another approach with separate functions and I have the impression that this simplifies the code a lot.

Why do you think so? Are you sure you understood my suggestion regarding the use of EXECON and the ellipsis parameter? (by the way, I've never seen anyone use an ellipsis in a PPL program before). In this approach, each function's place is replaced by just one IF statement (which is the same as writing a function header) and no additional tests are needed.
Could you show the code of your DEFTEXT function? Maybe I'm misunderstanding something.

(04-03-2024 08:53 PM)Tyann Wrote:  Another problem that I don't know how to deal with at the moment is the limited width with italic text?
If I display "TYANN" with, say, a width of 50 in normal and then in italics: because of the offset I'll be missing part of the last character displayed.
Should I keep the characters or the width in pixels?
What do you think?

The same issue applies to the bolding you apply because it widens the text by 1 pixel, so there's also a possibility that the last pixel will be "cut off", right? In my opinion, "width" is crucial because if I have 50 pixels allocated for text in my program (among other graphical elements), and the text turns out to be longer, it should truncate it to 50 pixels to prevent it from overlapping other graphical elements (at least that's how I understand this limitation).

In the future, it's probably worth considering also writing an additional function that will return the dimensionss of the text after formatting, something like an extended version of TEXTSIZE.

[Tyann]

Bonjour komame
Oui hier soir, je vous ai répondu rapidement, ce que je voulais dire c'est qu'avec une seule fonction il faut tester combien il y a d'éléments dans la liste et aussi le type du second élément.
Avec plusieurs fonctions les tests ne commencent qu'à partir de 6 éléments et portent seulement sur le type du second. (du moins si mon approche est correcte).
Ceci dit, vôtre méthode avec EXECON ( une instruction que j'utilise rarement) facilite les choses.
Je vous joint le code que j'ai écrit avec plusieurs fonctions pour voir ce vous en pensez.
Concernant la largeur, je suis d'accord avec vous et un 'TEXTSIZE' avec attributs serait effectivement nécessaire
Merci de vôtre patience.

Hello komame
Yes, last night I gave you a quick answer. What I meant was that with a single function you need to test how many elements there are in the list and also the type of the second element.
With several functions, the tests don't start until there are 6 or more elements and only the type of the second element is tested (at least if my approach is correct).
That said, your method with EXECON (an instruction I rarely use) makes things easier.
I've attached the code I wrote with several functions to see what you think.
Regarding the width, I agree with you and a 'TEXTSIZE' with attributes would indeed be necessary.
Thank you for your patience.

Code:

ICON buffer 89504E470D0A1A0A0000000D494844520000014A0000001C01000000002FF2CBF6000000027​4524E5300007693CD3800000018494441547801EDC10109000000C3A0F54FFD1C073580230304B40​001D69772FE0000000049454E44AE426082;
EXPORT TEXT_P(s,x,y)
BEGIN
 TEXTOUT_P(s,x,y);
END;
EXPORT TEXT_P(s,g,x,y)
BEGIN
 TEXTOUT_P(s,g,x,y);
END;
EXPORT TEXT_P(s,g,x,y,p)
BEGIN
 TEXTOUT_P(s,g,x,y,p); 
END;
EXPORT TEXT_P(s,g,x,y,p,c)
BEGIN
 IF TYPE(g)≠8 THEN
  TEXT_P(s,G0,g,x,y,p,c); 
 ELSE
  TEXTOUT_P(s,g,x,y,p,c);
 END;
END;
EXPORT TEXT_P(s,g,x,y,p,c,a)
BEGIN
 LOCAL l;
 IF TYPE(g)≠8 THEN
  TEXT_P(s,G0,g,x,y,p,c,a)
 ELSE
  l:=GET(TEXTSIZE(s,p),1);
  TEXT_P(s,g,x,y,p,c,a,l); 
 END;
END;
EXPORT TEXT_P(s,g,x,y,p,c,a,l)
BEGIN
 IF TYPE(g)≠8 THEN
  TEXT_P(s,G0,g,x,y,p,c,a,l);
 ELSE
 //affichage attributs transparent
 END;

END;
EXPORT TEXT_P(s,g,x,y,p,c,a,l,f)
BEGIN
 //affichage attributs recouvrement 

END;

Vous remarquerez qu'à chaque appel avec G0, les paramètres changent : 'g' devient 'x', 'x' devient 'y' etc...
J'avoue que ce truc m'a fait des noeuds au cerveau.

You'll notice that each time you call G0, the parameters change: 'g' becomes 'x', 'x' becomes 'y' etc...
I have to admit that this thing gave me brain knots.


Translated with DeepL.com (free version)

[komame]

(04-04-2024 07:34 PM)Tyann Wrote:  With several functions, the tests don't start until there are 6 or more elements and only the type of the second element is tested (at least if my approach is correct).

You should also consider this for functions with 4 and 5 parameters, as TEXTOUT_P can also be called without specifying the GROB parameter:
TEXTOUT_P("text",20,20,1);
TEXTOUT_P("text",20,20,7,#255d);

So testing the second parameter is necessary here as well.

(04-04-2024 07:34 PM)Tyann Wrote:  I've attached the code I wrote with several functions to see what you think.
.
.
.

Let's assume we call such a command: TEXT_P("text",20,20,7,#255d,"B"). This will trigger the TEXT_P function with 6 parameters, and within it, a test of the 2nd parameter will occur. Since the 2nd parameter is not of type GROB, G0 will be substituted, and the function will be called again with 7 parameters. Within it, another test of the 2nd parameter will occur, and the TEXT_P function will be called for the third time, this time with 8 parameters. Inside it, another test of the 2nd parameter will occur, and only at this point will the actual drawing code be invoked. This is a rather convoluted and costly path. Don't you think that instead of repeatedly passing all parameters and repeatedly performing tests of the 2nd parameter type, it would be much better to call the target function directly with all parameters, by hard-coding default values?

(04-04-2024 07:34 PM)Tyann Wrote:  You'll notice that each time you call G0, the parameters change: 'g' becomes 'x', 'x' becomes 'y' etc...
I have to admit that this thing gave me brain knots.

When the meaning of parameters changes during program execution, it's better not to assign them names suggesting a specific meaning, as this can be misleading. Just name them v1, v2, etc. In the documentation for the call, you can provide parameter names and indicate which ones are optional, but in the code, imho it's better not to assign names with specific meanings in such cases.

I will return for a moment to the "CASE" scenario. Here is the final code that achieves the same:

Code:

EXPORT TEXT_P(...p)
BEGIN
  LOCAL pt;
  pt:=EXECON("TYPE(&1)",p);
  CASE
    IF EQ(pt,{2,0,0}) THEN
      TEXTOUT_P(p[1],p[2],p[3]);
    END;
    IF EQ(pt,{2,8,0,0}) THEN
      TEXTOUT_P(p[1],p[2],p[3],p[4]);
    END;
    IF EQ(pt,{2,8,0,0,0}) THEN
      TEXTOUT_P(p[1],p[2],p[3],p[4],p[5]);
    END;
    IF EQ(pt,{2,0,0,0,0}) THEN
      TEXTOUT_P(p[1],p[2],p[3],p[4],p[5]);
    END;
    IF EQ(pt,{2,8,0,0,0,0}) THEN
      TXT_P(p[1],p[2],p[3],p[4],p[5],p[6],"",-1,-1); 
    END;
    IF EQ(pt,{2,0,0,0,0,2) THEN
      TXT_P(p[1],G0,p[2],p[3],p[4],p[5],p[6],-1,-1); 
    END;
    IF EQ(pt,{2,8,0,0,0,0,2}) THEN
      TXT_P(p[1],p[2],p[3],p[4],p[5],p[6],p[7],GET(TEXTSIZE(p[1],p[5]),1),-1); 
    END;
    IF EQ(pt,{2,0,0,0,0,2,0}) THEN
      TXT_P(p[1],G0,p[2],p[3],p[4],p[5],p[6],p[7],-1); 
    END;
    IF EQ(pt,{2,8,0,0,0,0,2,0}) THEN
      TXT_P(p[1],p[2],p[3],p[4],p[5],p[6],p[7],p[8],-1); 
    END;
    IF EQ(pt,{2,0,0,0,0,2,0,0}) THEN
      TXT_P(p[1],G0,p[2],p[3],p[4],p[5],p[6],p[7],p[8]); 
    END;
    IF EQ(pt,{2,8,0,0,0,0,2,0,0}) THEN
      TXT_P(p[1],p[2],p[3],p[4],p[5],p[6],p[7],p[8],p[9]); 
    END;
    RECT_P(""); // if none of the above syntaxes is found, it triggers an 'Invalid input' error
  END;
END;

TXT_P(s,g,x,y,p,c,a,l,f)
BEGIN
// Here is the drawing logic.
END;

It looks more readable, there is less of it, and all calls require only one "IF" before the direct invocation of the drawing procedure, because after the condition is met, the number of parameters, their types, and their order are known.

However, this solution also has its drawbacks because it doesn't automatically handle binary integers. The type for a binary integer is different from a regular numeric type, so adding alternatives in specific cases within the "CASE" is required (the number of "CASE" items won't increase, but additional ones will need to be added to the lists in "OR" mode).

So let's optimize what you've already prepared and move on to the drawing function.