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

[Tyann]

Bonjour komame
Voici une piste de réflexion que j'ai eu hier, en regardant vôtre code et en analysant vos remarques.
Pour moi de 3 à 5 arguments nous n'avons rien d'autre à faire que d'appeler TEXTOUT_P (qui lui même teste si Gx est transmis ou pas), mais vous semblez en désaccord sur ce point ?
Avec 6 éléments si Gx est transmis c'est TEXTOUT_P? sinon c'est nôtre fonction car le paramètre 6 sera les attributs.
Si nous prenons une fonction de base avec une liste variable comme vôtre code.
TEXT_P( ...l) et que nous testons la taille de la liste de 3 à 5 -> TEXTOUT_P, à 6 teste de l(2) si TYPE=8 -> TEXTOUT_P.
Sinon nous construisons l'appel de la fonction locale dans une chaîne et utilisons EXPR().
Nous n'avons donc à écrire que 2 fonctions locales identiques avec 8 et 9 paramètres et nous mettrons les paramètres 7 et 8 par défaut si besoin.
Car le paramètre 9 ( couleur de recouvrement) ne peut pas avoir une valeur par défaut, pour suivre la syntaxe de TEXTOUT_P, alors que si j'ai bien compris dans
vôtre code vous semblez transmettre -1 pour la transparence.
Soit il est transmis et nous sommes en recouvrement, soit il est absent et nous sommes en transparence.

Hello komame
Here's a thought I had yesterday, looking at your code and analysing your comments.
For me, with 3 to 5 arguments we have nothing to do but call TEXTOUT_P (which itself tests whether Gx is transmitted or not), but you seem to disagree on this point?
With 6 elements, if Gx is transmitted it's TEXTOUT_P? otherwise it's our function because parameter 6 will be the attributes.
If we take a basic function with a variable list like your code.
TEXT_P( ...l) and we test the size of the list from 3 to 5 -> TEXTOUT_P, to 6 test of l(2) if TYPE=8 -> TEXTOUT_P.
Otherwise we construct the local function call in a string and use EXPR().
So we only have to write 2 identical local functions with 8 and 9 parameters and we'll default to parameters 7 and 8 if we need to.
Because parameter 9 (overlay colour) can't have a default value, to follow the syntax of TEXTOUT_P, whereas if I've understood your code correctly you seem to be transmitting
your code correctly, you seem to be transmitting -1 for transparency.
Either it's passed and we're in overlay, or it's absent and we're in transparency.




Translated with DeepL.com (free version)

[komame]

Hi Tyann,

(04-06-2024 06:50 AM)Tyann Wrote:  Here's a thought I had yesterday, looking at your code and analysing your comments.
For me, with 3 to 5 arguments we have nothing to do but call TEXTOUT_P (which itself tests whether Gx is transmitted or not), but you seem to disagree on this point?

For function with 3 parameters, I didn't have any concerns because it only occurs in one syntax [s,x,y]. As for 4 and 5 parameters, I myself fell into the trap I mentioned regarding the meaning of parameter names. So you're right, because (e.g., in case of 4 parameteres), the syntax [s,g,x,y] could be passed as [s,x,y,p]. If the parameters were described as [s,v1,v2,v3], I would have realized it.

(04-06-2024 06:50 AM)Tyann Wrote:  If we take a basic function with a variable list like your code.
TEXT_P( ...l) and we test the size of the list from 3 to 5 -> TEXTOUT_P, to 6 test of l(2) if TYPE=8 -> TEXTOUT_P.
Otherwise we construct the local function call in a string and use EXPR().

Following this line of thought (which seems like a very interesting approach), it's also possible to use a single EXPR call for list lengths from 1 to 3 (instead of three separate calls). This will simply require using MID to remove the curly braces after converting the list to a string.

(04-06-2024 06:50 AM)Tyann Wrote:  [...] if I've understood your code correctly you seem to be transmitting
your code correctly, you seem to be transmitting -1 for transparency.
Either it's passed and we're in overlay, or it's absent and we're in transparency.

Yes, I assumed that -1 represents transparency (as a default value) and wanted to handle it with a condition inside the code. Ultimately, this would allow us to have only two functions in the entire solution: one that takes parameters and calls TEXTOUT_P (when possible) or a function for custom drawing (when TEXTOUT_P cannot be used directly), and the other for handling custom drawing.

[Tyann]

Hé komame
Je crois que nous touchons au but pour la structure de la fonction.
Voici un 'petit code' qui a l'air de faire le travail, j'ai fais 2 ou 3 tests.
Le marquage de la chaîne dans une chaîne:" \"chaîne\",..." ne semble pas poser de problème à EXPR().
Il y a sûrement matière à améliorer : la fabrication de la fonction peut être extériorisée, je pense.
Bien à vous.

Hey komame
I think we've hit the nail on the head when it comes to the structure of the function.
Here's a 'little code' that seems to do the job, I've done 2 or 3 tests.
Marking the string in a string: "\"string\",..." doesn't seem to be a problem for EXPR().
I'm sure there's room for improvement: the function can be made externally, I think.
Kind regards.

Code:

EXPORT ATEXTOUT_P(...l)
BEGIN
 LOCAL d:=SIZE(l),t:=TYPE(l(2)),i,f;
 CASE
  if 2<d<6  OR (d==6  AND t==8) then
   f:="TEXTOUT_P("+STRING(l);
   f:=SUPPRESS(f,"{}");
   //EXPR(f);
  end;
  if 5<d<8  OR (d==8  AND t==8)then  
   IF t≠8 THEN 
    l:=INSERT(l,2,G0);
   END;
   IF d<8 THEN
    l(0):=GET(TEXTSIZE(l(1),l(5)),1);
   END;
   f:="atextout_p("+STRING(l);
   f:=SUPPRESS(f,"{}"); 
   //EXPR(f);
  end;
  if d>7 then
   IF d==8 THEN
    l:=INSERT(l,2,G0);
   END;
   f:="atextout_p("+STRING(l);
   f:=SUPPRESS(f,"{}");
   //EXPR(f);
  end;
  default
   //RETURN "Erreur de syntaxe";
   f:="Erreur de syntaxe";
 END;
 f;
END;

[komame]

(04-06-2024 04:01 PM)Tyann Wrote:  I think we've hit the nail on the head when it comes to the structure of the function.
Here's a 'little code' that seems to do the job, I've done 2 or 3 tests.
Marking the string in a string: ""string",..." doesn't seem to be a problem for EXPR().
I'm sure there's room for improvement: the function can be made externally, I think.

It looks good, but a few minor corrections are required.

1. You used:
f:=SUPPRESS(f,"{}");
however, this won't work for cases where you want to display text containing curly braces because they will be removed. That's why I suggested using MID earlier. If you still insist on using SUPPRESS, it's also possible, but it needs to be implemented using slightly different syntax:
f:=SUPPRESS(f,{1,SIZE(f)}).

2. The condition:
5<d<8 OR (d==8 AND t==8)
can be simplified to
5<d<9
because the two subsequent conditions already exclude t=8 and d=8 respectively, and in conjunction with 5<d<9, they will behave the same way.
This, in turn, allows us to change
d>7
to
d>8
And then the following condition can be removed:
IF d==8 THEN
  l:=INSERT(l,2,G0);
END;

3. Missing protection against too many parameters. A "Syntax error" should be triggered when more than 9 parameters are provided. Currently, providing 10 or more parameters does not trigger an error.

4. And one minor oversight: you need to add closing parentheses in the EXPR expressions.

Here is the code after all these corrections:

Code:

EXPORT ATEXTOUT_P(...l)
BEGIN
 LOCAL d:=SIZE(l),t:=TYPE(l(2)),i,f;
 CASE
  if 2<d<6  OR (d==6  AND t==8) then
   f:="TEXTOUT_P("+STRING(l)+")";
   f:=SUPPRESS(f,{1,SIZE(f)});
   //EXPR(f);
  end;
  if 5<d<9 then  
   IF t≠8 THEN 
    l:=INSERT(l,2,G0);
   END;
   IF d<8 THEN
    l(0):=GET(TEXTSIZE(l(1),l(5)),1);
   END;
   f:="atextout_p("+STRING(l)+")";
   f:=SUPPRESS(f,{1,SIZE(f)}); 
   //EXPR(f);
  end;
  if d==9 then
   f:="atextout_p("+STRING(l)+")";
   f:=SUPPRESS(f,{1,SIZE(f)});
   //EXPR(f);
  end;
  default
   //RETURN "Erreur de syntaxe";
   f:="Erreur de syntaxe";
 END;
 f;
END;

It's a pity that in PPL there's no capability to throw errors. Simply returning the string "Syntax Error" doesn't effectively address the issue, as it fails to trigger an error within the program, allowing it to continue execution. I propose using the EXPR("Syntax error"), which raises an "Syntax error" and terminates program execution. I know it's just a workaround, but at the moment, I don't know of a better solution.
It would be beneficial to have a built-in mechanism in PPL where any error can be raised on demand.

[komame]

(04-06-2024 09:27 PM)komame Wrote:  4. And one minor oversight: you need to add closing parentheses in the EXPR expressions.

Actually, it's not necessary because PPL correctly interprets and executes commands where closing parentheses aren't explicitly provided, in cases where they occur at the very end of the command.

Additionally, I found another bug that resulted in accepting a command with 9 parameters when the second parameter wasn't GROB (the issue also occurs in your proposal). To fix this in my proposal, we need to add "t==8" in the last condition of the "CASE" statement: d==9 => d==8 and t==8.

In the previous example, I made a mistake in suggesting the use of SUPPRESS. Of course, SUPPRESS should only be applied to the converted-to-string list, not the entire expression:
f:=STRING(l);
f:="TEXTOUT_P("+SUPPRESS(f,{1,SIZE(f)});

The corrected code is below:

Code:

EXPORT ATEXTOUT_P(...l)
BEGIN
 LOCAL d:=SIZE(l),t:=TYPE(l(2)),i,f;
 CASE
  if 2<d<6  OR (d==6  AND t==8) then
   f:=STRING(l);
   f:="TEXTOUT_P("+SUPPRESS(f,{1,SIZE(f)});
   //EXPR(f);
  end;
  if 5<d<9 then  
   IF t≠8 THEN 
    l:=INSERT(l,2,G0);
   END;
   IF d<8 THEN
    l(0):=GET(TEXTSIZE(l(1),l(5)),1);
   END;
   f:=STRING(l);
   f:="TEXTOUT_P("+SUPPRESS(f,{1,SIZE(f)});
   //EXPR(f);
  end;
  if d==9 and t==8 then
   f:=STRING(f);
   f:="TEXTOUT_P("+SUPPRESS(f,{1,SIZE(f)});
   //EXPR(f);
  end;
  default
   EXPR("Syntax error");
 END;
 f;
END;

I have only one question regarding your assumptions. It seems to me that the "atextout_p" function should always be called with 9 parameters because all default parameters should be set by the calling the main function, which receives a variable number of parameters. However, I see that you are doing it differently because the generated calls have from 7 to 9 parameters. Does this mean that you want to create 3 functions named "atextout_p"?

[Tyann]

Bonjour komame
Très bon boulot, le coup des 10 arguments ou plus m'est venu après ; par contre le coup des accolades je n'y avais pas pensé.
Effectivement il est dommage que PPL ne permet pas le déclenchement d'erreurs volontairement ( Jeff si tu nous lis ).
Maintenant il faut une nouvelle fonction ATEXTSIZE qui calculera la taille du texte en italique car avec la structure que nous avons mis en place, lorsque une largeur limite n'est pas spécifiée nous la fournissons nous même justement avec TEXTSIZE.
De même si nous fournissons une taille limite> à la taille du texte, TEXTOUT_P prend la taille du texte comme valeur.
Actuellement je décale la copie d'écran de 3 pixels par 3 pixels et la dernière copie s'effectue sur le reste de pixels 1 ou 2.
Selon la taille de la police le nombre de pixels décalés varient et donc la nouvelle taille devra renvoyer cette valeur.
Je vous joint le code, et j'attends vos remarques, conseils et éventuelles corrections.
Je vous joint également un petit code que j'utilise pour les erreurs et qui peut être associé.

Hello komame
Very good work, the idea of 10 arguments or more came to me afterwards; on the other hand, the braces idea hadn't occurred to me.
It's a shame that PPL doesn't allow errors to be triggered voluntarily (Jeff, if you're reading this).
Now we need a new ATEXTSIZE function that will calculate the size of italic text because with the structure we've set up, when a width limit isn't specified we supply it ourselves with TEXTSIZE.
Similarly, if we supply a size limit> for the text size, TEXTOUT_P takes the text size as its value.
I currently offset the screen copy by 3 pixels by 3 pixels and the last copy is made on the remaining 1 or 2 pixels.
Depending on the font size, the number of pixels shifted will vary and so the new size should return this value.
I've attached the code, and I look forward to your comments, advice and any corrections.
I've also attached a little code that I use for errors and that can be linked.

Code:

texti1(s,g,x,y,f,c)
BEGIN
 LOCAL h,i,j:=10,l,d:=3,n,v;
 {'l','h'}:=TEXTSIZE(s,f)+{10,0};
 n:=CEILING(h/3);y:=y+h;
 FOR i FROM 1 TO n DO
  BLIT_P("buffer",j,h-d,l+j,h,g,x,y-d,x+l,y);
  j:=j-1;y:=y-3;h:=h-3;d:=MIN(h,3);
 END;
 TEXTOUT_P(s,"buffer",10,0,f,c);
END;

Code:


Err(n)
BEGIN
 LOCAL l:={};
 CASE
  if n==0 then EXPR("syntaxe"; end;
  if n==1 then UPPER(1); end;
  if n==2 then l(1); end;
  if n==3 then l+{1,2}; end;
  if n==4 then CROSS([1],[1,1]);end;
 END;
END;

[komame]

It seems I updated my post while you were writing yours. There are still a few threads to clarify. In my opinion, the entire solution should have 3 functions: ATEXTOUT_P (exported), atextout_p (internal), and TEXTSIZE_P (exported). Each of them only once (only one syntax), with "atextout_p" always called with 9 parameters or a list (with a number of parameters from 7 to 9) assuming GROB is always explicitly specified.

EDIT: I like your idea of simulating error triggering. The implementation of TEXSIZE_P also doesn't seem to be complicated. It can be achieved through simple calculations.

[Tyann]

Je préférerai avoir 2 fonctions atextout_p, une avec 8 paramètres et l'autre avec 9, car nous aurons directement les variables s,g,x,y....etc
Tandis qu'avec une seule fonction atextout_p et une liste toute la programmation va se faire à coups de 'l(x)' moins lisible et plus lourdingue non ?
Pour ATEXTSIZE, j'ai noté la taille en hauteur de chaque police car ce n'est pas linéaire, quelquefois elle augmente de 2 et d'autres fois de 4 pixels.
Ensuite je pense que CEILLING(hauteur,3)+largeur fournie par TEXTSIZE devrait faire l'affaire pour le mode italique ?


I'd prefer to have 2 atextout_p functions, one with 8 parameters and the other with 9, because we'll have the s,g,x,y....etc variables directly.
Whereas with a single atextout_p function and a list, all the programming is going to be done using 'l(x)', which is less readable and more cumbersome, isn't it?
For ATEXTSIZE, I've noted the height of each font because it's not linear, sometimes it increases by 2 and other times by 4 pixels.
Then I think that CEILLING(height,3)+width provided by TEXTSIZE should do the trick for italic mode?

[komame]

(04-07-2024 09:31 AM)Tyann Wrote:  I'd prefer to have 2 atextout_p functions, one with 8 parameters and the other with 9, because we'll have the s,g,x,y....etc variables directly.
Whereas with a single atextout_p function and a list, all the programming is going to be done using 'l(x)', which is less readable and more cumbersome, isn't it?
For ATEXTSIZE, I've noted the height of each font because it's not linear, sometimes it increases by 2 and other times by 4 pixels.
Then I think that CEILLING(height,3)+width provided by TEXTSIZE should do the trick for italic mode?

I understand your argument regarding the issue with the list as a parameter. However, for me, the best solution would be to create only one function "atextout_p", which always takes 9 parameters and contains all the drawing logic once, without breaking it down into different cases. Since it's an internal function anyway, the last parameter can be handled in many ways internally. However, if you prefer two functions, I won't insist on anything.
Regarding ATEXTSIZE, after all, the height of the selected font can be measured using TEXTSIZE, so it doesn't matter that it doesn't change linearly. By applying formatting, we only change the width, which can be calculated for italics considering the previously measured height. And for bold, we add an additional 1 pixel. This way, it can be done very precisely.

[Tyann]

Bonjour komame

Après réflexion une seule fonction atextout_p(...l) me semble pas mal.
Nous pourrons savoir grâce à la taille de la liste de 8 ou 9 si on est en transparence ou pas
sans valeur par défaut et pour les variables je propose de récupérer celles ci sur une seule ligne
de la manière suivante :

Hello komame

After some thought, a single atextout_p(...l) function doesn't seem too bad.
We'll be able to tell from the size of the list of 8 or 9 whether we're in transparency or not
without a default value and for the variables I propose to retrieve them on a single line
as follows:

Code:


atextout_p(...par)
BEGIN
 LOCAL s,g,x,y,p,c,a,l
 LOCAL f,fr
 {'s','g','x','y','p','c','a','l'}:=par({1,8});
 IF SIZE(par)==9 THEN f:=par(9); fr=1;END.
............
END;

fr sera le drapeau de recouvrement pour décider si nous copions Gx dans le buffer ou si nous le remplissons avec RECT_P() à la couleur f.
Je vais avoir moins de temps cette semaine, mais je vais tacher d'avancé la dessus.
Bien à vous.

'fr' will be the overlay flag to decide whether we copy Gx into the buffer or fill it with RECT_P() at colour f.
I'll have less time this week, but I'll try to make some progress on this.
All the best.

[komame]

Hello Tyann,

(04-08-2024 05:23 AM)Tyann Wrote:  After some thought, a single atextout_p(...l) function doesn't seem too bad. We'll be able to tell from the size of the list of 8 or 9 whether we're in transparency or not
without a default value and for the variables I propose to retrieve them on a single line
as follows:

Code:


atextout_p(...par)
BEGIN
 LOCAL s,g,x,y,p,c,a,l
 LOCAL f,fr
 {'s','g','x','y','p','c','a','l'}:=par({1,8});
 IF SIZE(par)==9 THEN f:=par(9); fr=1;END.
............
END;

Sorry, perhaps I didn't express myself clearly. I completely agree with not using a list in the atextout_p function. I just meant not to create two functions with 8 and 9 parameters, but only one with 9 parameters. In case we need 8 parameters, we can simply pass a predefined value in the 9th parameter (e.g., -1).

I think it's time to establish the method of passing formatting attributes. If a string would be acceptable for you, my proposal is as follows:
B - bold
D - darkening
I - italic
U - underline
S - strikethrough

The formatting string could have from 0 to 5 characters. B indicates bold (1 pixel shift), and D indicates triple display, so all combinations can be made, e.g., "BD". If you have a different idea for attributes, please let me know.

It would also be good to apply a semi-transparent mode because currently PPL does not support displaying semi-transparent texts. This would have to apply separately to the text and separately to the background.
What do you think about this?

[Tyann]

Hé komame
En passant à une fonction atextout(...l), je me suis aperçu que la construction avec EXPR pour l'appel de celle-ci n'était plus obligatoire et du coup les ... non plus (je vous joint le code modifié).
En ce qui concerne le 9 ème paramètre, je ne pense pas qu'une valeur par défaut doit être employée pour la raison suivante : tout comme TEXTOUT_P, ATEXTOUT_P doit renvoyer une erreur si la valeur ne correspond pas à une couleur, sauf si vous avez une solution à l'esprit.
Pour ce qui est des attributs, j'étais personnellement parti sur une valeur numérique en ayant à l'esprit que pour ce paramètre qui n'est pas connu de TEXTOUT_P nous devons nous même renvoyer une erreur si la valeur est hors plage, cependant si la même chose est facilement faisable avec une chaîne pas de problème pour moi (on peut même envisager les 2).
Un truc auquel j'ai pensé si nous arrivons dans atextout() et que le paramètre attributs est nul ( 0 ou ""), nous retombons sur un simple TEXTOUT_P, peut être faudra t-il penser à traîter ce cas particulier.
Enfin pour ce qui est de vôtre proposition de semi transparent, je ne vois pas très bien à quoi cela correspond mais pourquoi pas, par contre j'aimerai bien aussi un paramètre 'encadré'.
Concernant le code dans ATEXTSIZE, je n'ai pour l'instant traité que le cas de l'italique.

Hey komame
When I switched to an atextout(...l) function, I realized that the EXPR construction for calling it was no longer mandatory, so neither were the ... (I've attached the modified code).
As for the 9th parameter, I don't think a default value should be used for the following reason: just like TEXTOUT_P, ATEXTOUT_P should return an error if the value doesn't match a color, unless you have a solution in mind.
As far as attributes are concerned, I had personally opted for a numerical value, bearing in mind that for this parameter, which is not known to TEXTOUT_P, we ourselves must return an error if the value is out of range. However, if the same thing can easily be done with a string, no problem for me (we can even consider both).
Something I've been thinking about is that if we go into atextout() and the attributes parameter is null (0 or ""), we end up with a simple TEXTOUT_P. Perhaps we should think about handling this special case.
Finally, as for your semi-transparent proposal, I don't really see what it means, but why not? On the other hand, I'd also like to see a 'framed' parameter.
As for the code in ATEXTSIZE, so far I've only dealt with the case of italics.

Code:

ICON buffer 89504E470D0A1A0A0000000D494844520000014A0000001C01000000002FF2CBF6000000027​4524E5300007693CD3800000018494441547801EDC10109000000C3A0F54FFD1C073580230304B40​001D69772FE0000000049454E44AE426082;
EXPORT ATEXTSIZE(s,p,a)
BEGIN
 LOCAL h,l;
 {'l','h'}:=TEXTSIZE(s,p);
 IF a>31 THEN
  l:=l+CEILING(h/3);
 END;
 {l,h}; 
END;
EXPORT ATEXTOUT_P(...l)
BEGIN
 LOCAL d:=SIZE(l),t:=TYPE(l(2)),i,f;
 CASE
  if 2<d<6  OR (d==6  AND t==8) then
   f:=STRING(l);
   f:="TEXTOUT_P("+SUPPRESS(f,{1,DIM(f)});
   EXPR(f);
  end;
  if 5<d<9 then  
   IF t≠8 THEN 
    l:=INSERT(l,2,G0);
    d:=d+1;
   END;
   IF d<8 THEN
    l(0):=GET(ATEXTSIZE(l(1),l(5),l(7)),1);
   ELSE
    l(8):=MIN(GET(ATEXTSIZE(l(1),l(5),l(7)),1),l(8)); 
   END;
   atextout(l); 
  end;
  if d==9  AND t==8 then
   atextout(l);  
  end;
  default
   Err(0);
 END;
END;
atextout(par)
BEGIN
 LOCAL s,g,x,y,p,c,a,l;
 LOCAL f,i,j:=10,n,fi,fr,ii;
 {'s','g','x','y','p','c','a','l'}:=par({1,8});
 IF SIZE(par)==9 THEN
  f:=par(9);fr:=1;
 END;

Edit :
J'ai maintenant je pense un code fonctionnel complet, surement très perfectible et dans lequel on peut ajouter vos suggestions.
A noter que la ligne :

Code:

   l(8):=MIN(GET(ATEXTSIZE(l(1),l(5),l(7)),1),l(8));

qui consiste à vérifier que la largeur fournie n'est pas> à la taille du texte est déplacée dans atextout .
Je fais encore quelques tests et vous montre cela ensuite.

I think I now have a complete working code, which can certainly be improved and to which your suggestions can be added.
Note that the line :

Code:

 l(8):=MIN(GET(ATEXTSIZE(l(1),l(5),l(7)),1),l(8));

which consists of checking that the width supplied is not > the text size is moved to atextout .
I'll run a few more tests and then show you how it works.

[komame]

(04-08-2024 05:58 PM)Tyann Wrote:  When I switched to an atextout(...l) function, I realized that the EXPR construction for calling it was no longer mandatory, so neither were the ... (I've attached the modified code).

Regarding the use of a list in "atextout", thanks to this, you could have dispensed with EXPR on the "ATEXTOUT_P" side, but at the same time, you had to add list-to-variable conversion in "atextout" (which was not necessary with EXPR). You simply replaced one conversion with another conversion, but this is quite a good solution, so I think we should leave it as you suggested.

(04-08-2024 05:58 PM)Tyann Wrote:  As for the 9th parameter, I don't think a default value should be used for the following reason: just like TEXTOUT_P, ATEXTOUT_P should return an error if the value doesn't match a color, unless you have a solution in mind.

In the solution I was thinking of, there wouldn't be such a problem, but your current solution with the list that you proposed is also very good, so there's no point in dwelling on the 9th parameter for now. Let's forget about it - we may revisit it later if needed.

(04-08-2024 05:58 PM)Tyann Wrote:  As far as attributes are concerned, I had personally opted for a numerical value, bearing in mind that for this parameter, which is not known to TEXTOUT_P, we ourselves must return an error if the value is out of range. However, if the same thing can easily be done with a string, no problem for me (we can even consider both).

As for attributes in the form of a text string, I simply prefer this call:
ATEXTOUT_P("text",G0,10,10,7,255,"BU")
because it's immediately clear what it refers to. Such a call is slightly less readable:
ATEXTOUT_P("text",G0,10,10,7,255,3).
But I don't see a problem with sticking to numeric flags if that's your preference.

However, in response to your question, there is a way to easily check if the given sequence of attributes contains only allowed values, and this can be done by using SUPPRESS. Assuming that the given attributes are in the variable "attr", we can check it like this:
SUPPRESS(attr,"BDIUS")

If the result is different from "" (an empty string), it means we have not allowed attributes.
One could also check for duplicate occurrences, which is also quite easy, although in this case, it seems unnecessary to me because even if any attribute is provided more than once, it will not have any negative impact.

(04-08-2024 05:58 PM)Tyann Wrote:  Something I've been thinking about is that if we go into atextout() and the attributes parameter is null (0 or ""), we end up with a simple TEXTOUT_P. Perhaps we should think about handling this special case.

I think this shouldn't be difficult at all.

(04-08-2024 05:58 PM)Tyann Wrote:  Finally, as for your semi-transparent proposal, I don't really see what it means, but why not?

Have you ever used the alpha channel in PPL? Here's an example of using the alpha channel for two rectangles that overlap each other and also overlay an image:
   

Currently, I'm writing a demo that extensively utilizes this feature. Combined with animations, you can achieve amazing graphical effects.
The same mechanism can be used for text to achieve transparent letters.
However, I think we'll come back to this later because I don't want to overly complicate this solution at this stage.

(04-08-2024 05:58 PM)Tyann Wrote:  On the other hand, I'd also like to see a 'framed' parameter.

As for "framed" you were the first to use that term, it was in post #33:

(04-01-2024 09:08 PM)Tyann Wrote:  [...] 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. [...]

At that time, I even wanted to ask you what "framed" means, but then it was not very important, and ultimately, I forgot to ask later.
Perhaps it's an issue with the translation generated by DeepL?

(04-08-2024 05:58 PM)Tyann Wrote:  I think I now have a complete working code, which can certainly be improved and to which your suggestions can be added. [...]

It's very late already, and I have to go to sleep. But I'll gladly take a look at it tomorrow after work.

[Tyann]

Bonjour komame
Des lettres transparentes, comme on peut le faire avec RECT_P() ou FILLPOLY_P(), ah je crois deviner que BLIT_P sera utile ?
Je vous joint une copie d'écran pour les textes encadrés.
Mon code actuel utilise le buffer pour l'italique et les 2 gras, puis le tout est recopié vers Gx et ensuite les autres effets sous-lignés, barrés etc... sont appliqués directement sur Gx, mais je pense que pour la transparence cela devra être modifié ?
Je fais encore quelques tests ce soir et si tout se passe bien je publie mon code demain avec quelques commentaires.
Bien à vous.

Hello komame
Transparent letters, as can be done with RECT_P() or FILLPOLY_P(), ah I think I can guess that BLITBLT_P will be useful?
I've attached a screenshot for framed text.
My current code uses the buffer for the italic and the 2 bold, then the whole thing is copied to Gx and then the other underlined effects, strikethrough etc... are applied directly to Gx, but I think that for transparency this will have to be modified?
I'm doing a few more tests this evening and if all goes well I'll publish my code tomorrow with a few comments.
All the best.

   

[komame]

Hi Tyann,

In the case of semi-transparent text, everything has to be done in the buffer and then applied to Gx using BLIT_P. Besides, I think even if we didn't use transparency, it's a good approach to do everything in the buffer anyway.

[Tyann]

Bonjour komame

Avant de programmer l'italique, je n'utilisais pas de tampon tout se faisait dans Gx.
De plus j'ai pensé que pour les textes italiques encadrés je serai obligé de tracé le cadre penché
pour qu'il se remette droit lors de la recopie et j'ai vu cela comme une difficulté évitable en traçant directement dans Gx.
J'ai un petit problème de décalage de 1 pixel en x et y lorsque je trace un cadre sur un texte avec le mode recouvrement (TEXTOUT_P et RECT_P avec les mêmes x,y font un décalage) , je dois procéder à plusieurs essais pour bien cerner le problème.


Hello komame

Before programming italics, I didn't use a buffer, everything was done in Gx.
What's more, I thought that for framed italic text I would have to draw the frame tilted so that it came back straight when I copied it.
I saw this as a difficulty that could be avoided by drawing directly in Gx.
I'm having a small problem with a 1-pixel offset when I draw a frame over text in overlay mode (TEXTOUT_P and RECT_P with the same x,y are offset), and I'll have to try a few times to get to the bottom of the problem.

[komame]

Hello Tyann,

If you want to use both semi-transparency and italics simultaneously, there's no other option but to create everything in the buffer. However, there is a way to achieve a common (universal) solution, where the drawing order of individual elements is always the same, so drawing it in the buffer doesn't complicate things much.

Best wishes

[Tyann]

Hé komame
La transparence me pose plusieurs questions :
le texte doit être affiché avec BLIT_P et doit être transparent par rapport au contenu de Gx donc il faut 2 tampons ou un seul de hauteur double ?

Ou alors on affiche le texte en premier puis le gras puis les lignes et on copie Gx de manière transparente à la fin et là un seul tampon ?
Mais est ce que le résultat est identique ?
Et si il n 'y a pas de transparence l'ordre doit changer non ?

Hey komame
I have several questions about transparency:
the text must be displayed with BLIT_P and must be transparent in relation to the content of Gx, so do you need 2 buffers or just one of double height?

Or do you display the text first, then the bold, then the lines and copy Gx transparently at the end, then just one stamp?
But is the result the same?
And if there's no transparency, the order has to change, doesn't it?

[komame]

Tyann,

A single buffer with normal height is sufficient.

The algorithm is as follows:

1. copy the target region from Gx to the buffer
2. [if the background color is specified => draw the backgroud]
3. [if a frame or underline is enabled => draw them]
4. [if italics are enabled => shift the content of the buffer left in 3-line blocks]
5. overlay the text using TEXTOUT_P
6. [if a strikethrough is enabled => draw it]
7. [if bold is enabled => overlay the text again (shifted 1 pixel to the right or overlaid in the same location)
8. [if italics are disabled => copy the buffer to Gx in one step using transparency]
9. [if italics are enabled] => copy the buffer in 3-line blocks with a right shift directly to Gx, also applying transparency.
   

Note that when there is no transparency or no italics, the steps are exactly the same, you just skip the block shifting or simply set the alpha value in BLIT_P to 255 (255 = no transparency).

I have now realized that BLIT_P has another bug (in total 3 that I have found myself), because the last two parameters ([c] and [alpha]) should be swapped, as currently when using the [alpha] value, the [c] parameter is also required, which may cause unexpected skipping of copying pixels of color specified in [c].

EDIT:
When I analyze it now, points 3 and 6 could be drawn directly on Gx at the very end. This should simplify the implementation somewhat (although this approach is not entirely my style).

Best wishes

[Tyann]

Bonjour komame

Si je comprends bien et résume : vous afficher le texte normalement sur le fond et
vous recopiez les 2 en transparence sur le fond ?
Si il y a recouvrement je ne vois pas de problème.
Si le niveau de transparence est faible (est il réglable dans vôtre idée ?) et qu'il y a des motifs
dans le fond, cela ne rsique t-il pas de les altérer ?
Effectivement tracer le cadre dans Gx me semble judicieux, car dans le tampon il y a la difficulté de le tracer penché si l'italique est activé.
En tout cas merci pour le détail des opérations.

Hello komame

If I understand correctly and summarise: you display the text normally on the background and
you copy the 2 in transparency onto the background?
If there is an overlap, I don't see a problem.
If the level of transparency is low (is it adjustable in your idea?) and there are patterns in the background, that's not a problem.
in the background, won't that alter them?
Drawing the frame in Gx seems a good idea, because in the buffer it's difficult to draw it at an angle if italics is activated.
In any case, thank you for the details of the operations.