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

[Tyann]

Bonjour komame

Cela me convient, c'est d'autant plus pertinent que TEXTOUT_P accepte une couleur RGB étendue et même une liste à 2 éléments pour la couleur (j'ai juste testé pour le texte ) et ne renvoie pas d'erreur !


Hello komame

That's fine by me, especially since TEXTOUT_P accepts an extended RGB color and even a 2-element list for the color (I just tested for the text) and doesn't return an error!

[komame]

(04-15-2024 05:11 AM)Tyann Wrote:  That's fine by me, especially since TEXTOUT_P accepts an extended RGB color and even a 2-element list for the color (I just tested for the text) and doesn't return an error!

Hi Tyann,

Of course, TEXTOUT_P accepts both formats. The {color,alpha} format is an alternative to RGB(R,G,B,A), and it works in all drawing instructions, because color can always be provided as a hexadecimal integer value (e.g., #RRGGBB or #AARRGGBBh, which is what the RGB function returns). Why do you think the fact that TEXTOUT_P accepts this helps in any way? Are you looking to utilize it for syntax checking using IFERR instruction?

EDIT:
It's a pity that TEXTOUT_P ignores the alpha coefficient included in the color. In all other graphic instructions, it is properly handled, and semi-transparent objects are drawn. For me, this is a bug in TEXTOUT_P.

[Tyann]

Hé komame
Oui je suis d'accord qu'il s'agit d'un bug , d'autant plus que si vous mettez un fond alors là : la valeur alpha est prise en compte et fonctionne (sur le dernier argument).

Connaissez vous la formule pour extraire la valeur alpha d'une valeur renvoyé par un RGB étendu ?

Il faut donc maintenant réécrire ATEXTOUT_P avec un maximum de 9 paramètres, Ha je vais finir par devenir chèvre .


Hey komame
Yes, I agree that it's a bug, especially as if you set a background then the alpha value is taken into account and works (on the last argument).

Do you know the formula for extracting the alpha value from a value returned by an extended RGB?

So now you have to rewrite ATEXTOUT_P with a maximum of 9 parameters, Ha I'm going to end up going goat .

[komame]

(04-15-2024 06:55 PM)Tyann Wrote:  Do you know the formula for extracting the alpha value from a value returned by an extended RGB?

The formula is:
BITSR(color,24)

(04-15-2024 06:55 PM)Tyann Wrote:  So now you have to rewrite ATEXTOUT_P with a maximum of 9 parameters, Ha I'm going to end up going goat .

ATEXTOUT_P for 9 parameters looks very similar:

Code:

EXPORT ATEXTOUT_P(...l)
BEGIN
 LOCAL d:=SIZE(l);
 IF TYPE(l(2))≠8 THEN 
  l(−2):=G0;
  d:=d+1;
 END;
 IF 2<d<7 THEN
  LOCAL f:=STRING(l);
  RETURN EXPR("TEXTOUT_P("+SUPPRESS(f,{1,DIM(f)}));
 END;
 IF d<9 THEN
  l:=CONCAT(l,SUB({320,−1},d-6,2));
 ELSE
  IF d>9 THEN Err(0); END;
  IF l(9)<0 THEN Err(2); END;
 END;
 l;
 atextout(l(1),l(2),l(3),l(4),l(5),l(6),l(7),l(8),l(9));
END;

I understand your frustration with the constant changes. In this situation, maybe let's stick with 10 parameters and one common transparency coefficient to avoid further complicating things.

[Tyann]

Bonjour komame

Merci pour la formule.
La question est : avoir 2 niveaux de transparence est -il vraiment utile ?
Un seul niveau sous forme d'argument facilitera bien les choses : pas d'extraction sur RGB, pas de test sur le type pour savoir si c'est une liste et si elle a bien une taille de 2 éléments.
Si il y a un fond la transparence s'appliquera aux 2 (texte et fond) ?

Hello komame

Thank you for the formula.
The question is: is having 2 levels of transparency really useful?
A single level in the form of an argument will make things much easier: no extraction on RGB, no test on the type to know if it's a list and if it has a size of 2 elements.
If there's a background, the transparency will apply to both (text and background)?

[komame]

Hi Tyann,

(04-16-2024 04:38 AM)Tyann Wrote:  A single level in the form of an argument will make things much easier: no extraction on RGB, no test on the type to know if it's a list and if it has a size of 2 elements.
If there's a background, the transparency will apply to both (text and background)?

Agreed. Let's do it this way.

[Tyann]

Bonjour komame

Ok pour moi, donc nous gardons la technique à 1 buffer même si il y a un fond ?
Nous affichons le texte sur le fond dans le buffer, puis nous copions le tout sur Gx en transparence ?
J'ai bon ?

Hi komame

Ok for me, so we keep the 1 buffer technique even if there is a background?
We display the text on the background in the buffer, then we copy the whole thing to Gx in transparency?
Am I right?

[komame]

Hi Tyann,

(04-17-2024 05:16 AM)Tyann Wrote:  ...so we keep the 1 buffer technique even if there is a background?
We display the text on the background in the buffer, then we copy the whole thing to Gx in transparency?
Am I right?

You've got it exactly right!

[Tyann]

D'accord, petite question subsidiaire :
Nous utilisons la convention 0=opaque et 255=transparent comme RECT_P OU PIXON_P ?
(et dans ce cas il faut inverser la valeur dans le programme pour BLIT_P : (255-t))

OK, small subsidiary question:
Do we use the convention 0=opaque and 255=transparent as RECT_P OR PIXON_P?
(and in this case you need to invert the value in the program for BLIT_P: (255-t))

[komame]

(04-17-2024 10:48 AM)Tyann Wrote:  OK, small subsidiary question:
Do we use the convention 0=opaque and 255=transparent as RECT_P OR PIXON_P?
(and in this case you need to invert the value in the program for BLIT_P: (255-t))

Yes, this is another bug in BLIT_P, where the alpha value is inconsistent (inverted) with other PPL graphics commands. Personally, I would probably prefer ATEXTOUT_P to be consistent with most commands in terms of transparency.

EDIT:
Woo-hoo! I've just become a Senior Member!

[Tyann]

Hé komame

J'ai une version qui semble fonctionnelle et que je vous soumet pour améliorations et contrôle.
Quelques points à souligner :
Le buffer n'est pas à la bonne taille dans le listing, je pense que 29 pixels devraient aller (mes calculs se font sur cette valeur : hauteur de police n°7 + 3).
Pour BLIT_P en mode transparence, j'avais mis au départ comme couleur avant l'alpha 0 (noir) mais cela donne un résultat bizarre, en mettant comme couleur la même valeur que l'alpha cela fonctionne correctement, je ne sais pas trop pourquoi.
Si vous le souhaitez vous pouvez modifier les modes gras et relief (16 et 32) ou en rajouter .
Peut être enfin le temps de la publication ?

Hey komame

I've got a version that seems to work and that I'm submitting to you for improvement and checking.
A few points to highlight:
The buffer is not at the right size in the listing, I think 29 pixels should fit (my calculations are based on this value: font height n°7 + 3).
For BLIT_P in transparency mode, I had initially set the front colour to alpha 0 (black) but this gives a strange result. Setting the colour to the same value as the alpha works correctly, I'm not sure why.
If you like, you can change the bold and relief modes (16 and 32) or add more.
Maybe it's finally time to publish?

Code:

ICON buffer 89504E470D0A1A0A0000000D494844520000014A0000001C01000000002FF2CBF6000000027​4524E5300007693CD3800000018494441547801EDC10109000000C3A0F54FFD1C073580230304B40​001D69772FE0000000049454E44AE426082;
EXPORT ATEXTSIZE(s,p,a)
BEGIN
 LOCAL h,l,f;
 {'l','h'}:=TEXTSIZE(s,p);
 IF BITAND(a,8) THEN
  l:=l+CEILING(h/3);
 END;
 IF BITAND(a,16) THEN
  l:=l+1;f:=1;
 END;
 IF BITAND(a,32) THEN
  l:=l+1-f;h:=h+1;
 END;
 {l,h}; 
END;
EXPORT ATEXTOUT_P(...l)
BEGIN
 LOCAL d,f;
 IF TYPE(l(2))≠8 THEN l(−2):=G0;END;
 d:=SIZE(l);
 IF d<7 THEN
   f:=STRING(l);
   f:="TEXTOUT_P("+SUPPRESS(f,{1,DIM(f)});
   RETURN EXPR(f);
 END;
 IF d<10 THEN
   l:=CONCAT(l,SUB({0,320,−1},d-6,3));
 ELSE
   IF l(10)<0 THEN Err(2);END;
 END;
 IF l(2)≠8 THEN Err(2);END;
 IF d>10 THEN Err(0);END; 
 atextout(l(1),l(2),l(3),l(4),l(5),l(6),l(7),l(8),l(9),l(10));
END;
atextout(s,g,x,y,p,c,a,t,l,f)
BEGIN
 LOCAL i,j,k,n,fi,fr,ft;
 LOCAL ii,h,hh,d;
 IF (63<a  OR a<0)  OR (255<t  OR t<0) THEN
  Err(2);
 END;
 fr:=(f≥0);ft:=(t>0);t:=255-t;
 {'k','h'}:=ATEXTSIZE(s,p,a);
 hh:=h;l:=MIN(l,k);
 IF fr THEN
  RECT_P("buffer",0,0,330,29,f);
 ELSE
  BLIT_P("buffer",10,0,g,x,y-3,x+l,y+h); 
 END;
 i:=1;
 REPEAT 
  IF i==16 THEN
   TEXTOUT_P(s,"buffer",10,3,p,c,l);
  END;
  IF BITAND(a,i) THEN
   CASE
    if i==1 then //barré
     j:=CEILING(h/2)+3; 
     LINE_P("buffer",10,j,10+l,j,c);
    end;
    if i==2 then //sous ligné
      LINE_P("buffer",10,h-2+3,10+l,h-2+3,c);  
    end;
    if i==4 then //encadré
     RECT_P("buffer",10,0,10+l-1,h-1+3,c,{0,255}); 
    end; 
    if i==8 then //italique 
     n:=CEILING(h/3);j:=10;d:=3;
     FOR ii FROM 1 TO n DO
      BLIT_P("buffer",j-1,h-d,"buffer",10,h-d,10+l,h);
      j:=j-1;h:=h-3;d:=MIN(h,3);
     END;
     fi:=1;
    end
    if BITAND(a,16) then //gras
     TEXTOUT_P(s,"buffer",11,3,p,c,l);
    end;
    if BITAND(a,32) then //relief
     TEXTOUT_P(s,"buffer",11,4,p,c,l);
    end;
   END;//CASE
  END;//BITAND
  i:=i*2;
 UNTIL i==64;
 IF fi THEN
  h:=hh+3;j:=10;d:=3;
  n:=CEILING(h/3);y:=y+h;
  FOR ii FROM 1 TO n DO
   EXPR("BLIT_P(g,x,y-d,\"buffer\",j,h-d,j+l,h"+IFTE(ft,",t,t)",")"));
   j:=j-1;y:=y-3;h:=h-3;d:=MIN(h,3);
  END;
 ELSE
  EXPR("BLIT_P(g,x,y-3,\"buffer\",10,0,l+10,h"+IFTE(ft,",t,t)",")"));
 END;
END;

P.S
Félicitations pour vôtre nouveau statut sur ce forum.
Congratulations on your new status on this forum.

[komame]

Tyann,

(04-17-2024 08:42 PM)Tyann Wrote:  The buffer is not at the right size in the listing, I think 29 pixels should fit (my calculations are based on this value: font height n°7 + 3).

Today I have to leave and I will only be back late in the evening. However, after quick tests, I can say that the buffer must have 31 pixels because the largest text placed at position 0,0 of the buffer is 27 pixels high (the first row of pixels is then empty), additionally, we need to consider the relief (1 pixel) and 3 pixels of descent to accommodate accents for small fonts. At the moment, the solution clips the bottom part of letters such as "g" or "y" and the underline (if defined) regardless of the font size.

For example:
ATEXTOUT_P("ABÓgy123",40,40,7,0,2);

(04-17-2024 08:42 PM)Tyann Wrote:  For BLIT_P in transparency mode, I had initially set the front colour to alpha 0 (black) but this gives a strange result. Setting the colour to the same value as the alpha works correctly, I'm not sure why.

In the case of BLIT_P, you made a mistake regarding the value of the [c] parameter, which we discussed earlier. The issue is that the [c] parameter is required when specifying the [alpha] parameter. To avoid hiding pixels, the [c] parameter was supposed to have transparency defined statically, for example {0,255}, but you substituted it with "t", so from the BLIT_P perspective, it's a normal color for which pixels are not supposed to be copied, so it couldn't work correctly. You should invoke it like this:
BLIT_P(g,x,y-d,"buffer",j,h-d,j+l,h,{0,255},t)
without using EXPR and then your variable "ft" is unnecessary.

(04-17-2024 08:42 PM)Tyann Wrote:  Maybe it's finally time to publish?

Not yet

(04-17-2024 08:42 PM)Tyann Wrote:  Congratulations on your new status on this forum.

Thanks!

[komame]

I took another look at your code, this time a bit more closely. The basic question that comes to mind is: Why did you revert most of the optimizations I previously suggested? You reverted the variables "n", "d", "hh" (which I removed), as well as iterating in the loop using "n" (instead of "h") and all those calculations in each iteration that seemed unnecessary. You also reverted my changes to the positioning of underlining and striking through. Did you not like all of that?

[komame]

Hi Tyann,

To avoid bothering you further, I've decided to implement all the corrections and optimizations myself. Here is the final version of the library, ready for publication:

Code:

// Custom Text Formatting Library v1.00 by Tyann & Komame
ICON buffer 89504E470D0A1A0A0000000D494844520000014B0000001F010000000046A4D266000000027​4524E5300010194FDAE0000001E494441547801EDCA310100000C0220FBA75C9359C10070935F9DA​AAAAA5ADAB10D75F21D64EC0000000049454E44AE426082;

EXPORT ATEXTSIZE(s,p,a)
BEGIN
 LOCAL h,l,f;
 {'l','h'}:=TEXTSIZE(s,p);
 IF BITAND(a,8) THEN
  l:=l+CEILING(h/3);
 END;
 IF BITAND(a,16) THEN
  l:=l+1;f:=1;
 END;
 IF BITAND(a,32) THEN
  l:=l+1-f;h:=h+1;
 END;
 {l,h}; 
END;

EXPORT ATEXTOUT_P(...l)
BEGIN
 LOCAL d,f;
 IF TYPE(l(2))≠8 THEN l(−2):=G0;END;
 d:=SIZE(l);
 IF d<7 THEN
   f:=STRING(l);
   f:="TEXTOUT_P("+SUPPRESS(f,{1,DIM(f)});
   RETURN EXPR(f);
 END;
 IF d<10 THEN
   l:=CONCAT(l,SUB({0,320,−1},d-6,3));
 ELSE
   IF d>10 THEN Err(0);END; 
   IF l(10)<0 THEN Err(2);END;
 END;
 IF l(2)≠8 THEN Err(2);END;
 atextout(l(1),l(2),l(3),l(4),l(5),l(6),l(7),l(8),l(9),l(10));
END;

atextout(s,g,x,y,p,c,a,t,l,f)
BEGIN
 LOCAL i,j,k,fi,fr;
 LOCAL ii,h;
 IF 63<a OR a<0 OR 255<t OR t<0 THEN
  Err(2);
 END;
 fr:=(f≥0); t:=255-t;
 {'k','h'}:=ATEXTSIZE(s,p,a);
 l:=MIN(l,k);
 BLIT_P("buffer",11,0,g,x,y-3,x+l+1,y+h+4); 
 IF fr THEN
  RECT_P("buffer",11,3,11+k+1,3+h-1,f,f);
 END;
 i:=1;
 REPEAT 
  IF i==16 THEN
   TEXTOUT_P(s,"buffer",11,3,p,c,l);
  END;
  IF BITAND(a,i) THEN
   CASE
    if i==1 then //barré / strikethrough
     j:=CEILING(h-p-2); 
     LINE_P("buffer",11,j,11+l,j,c);
    end;
    if i==2 then //sous ligné / underline
      LINE_P("buffer",11,h-2+3,11+l,h-2+3,c);  
    end;
    if i==4 then //encadré / frame
     RECT_P("buffer",11,2,11+l-1,h-1+3,c,{0,255}); 
    end; 
    if i==8 then //italique / italic
     j:=11;
     FOR ii:=h+3 DOWNTO -2 STEP 3 DO
      BLIT_P("buffer",j,ii,"buffer",11,ii,11+l,ii+3);
      j:=j-1;
     END;
     fi:=1;
    end
    if BITAND(a,16) then //gras / bold
     TEXTOUT_P(s,"buffer",12,3,p,c,l);
    end;
    if BITAND(a,32) then //relief
     TEXTOUT_P(s,"buffer",12,4,p,c,l);
    end;
   END;//CASE
  END;//BITAND
  i:=i*2;
 UNTIL i==64;
 IF fi THEN
  j:=11;
  FOR ii:=h+3 DOWNTO -2 STEP 3 DO
    BLIT_P(g,x,y+ii-3,"buffer",j,ii,j+l,ii+3,{0,255},t);
    j:=j-1;
  END;
 ELSE
  BLIT_P(g,x,y-3,"buffer",11,0,l+11,h+6,{0,255},t);
 END;
END;

Err(n)
BEGIN
 LOCAL l:={};
 CASE
  if n==0 then EXPR(":"); 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;

All that's left is to prepare a brief description and usage examples.

[Tyann]

Bonjour komame

Je n’ai pas annulé vos modification, j’avais juste repris mon ancien code pour plus de facilité de compréhension pour moi.
Concernant BLIT_P , je n’avais pas compris cela du tout , donc ici lorsque ’t’ vaut 255 il n y a aucune transparence ?
J’avais cru comprendre que lorsque la transparence est précisé, la couleur était ignoré !
Je suis content que nous soyons au bout et que vous ayez fourni le code final.
Je vais être indisponible pour quelques jours , vous pouvez si vous le souhaitez faire la description, je reprendrai la traduction en français si nécessaire.
Merci de vôtre patience, je suis content d'avoir pu travailler sur ce projet avec vous et j'ai beaucoup appris.

Hello Komame
I did not cancel your modifications, I just reverted to my old code to make it easier for me to understand. Regarding BLIT_P, I didn't understand that at all, so here when 't' is 255 there is no transparency? I understood that when the transparency is specified, the color was ignored! I'm glad we're at the end and you've provided the final code. I will be unavailable for a few days, you can provide the description if you wish, I will translate it into French if necessary. Thank you for your patience, I am happy to have been able to work on this project with you and I learned a lot.

[komame]

I will prepare the description and send it to you for review. We will publish everything in full upon your return.
Thank you very much for your involvement. Working with you is a real pleasure.

Komame.

[Tyann]

Bonjour komame
Je viens de charger la dernière version que vous avez publié.
J'ai 2 remarques :
1) Lors d'un affichage en relief avec un fond, un 'p' par exemple a un pixel du jambage hors du fond, pour remédier à cela j'ai retiré le '-1' de '3+h-1' sur la ligne après le test IF fr THEN RECT_P(.........
2) Sur l'affichage des MAJUSCULES accentuées comme 'Â' en encadré pour les polices 1 et 2 les accents sont hors cadre .

Hello komame
I've just downloaded the latest version you published.
I have 2 comments:
1) When displayed in relief with a background, a 'p' for example has one pixel of the leg outside the background, to remedy this I removed the '-1' from '3+h-1' on the line after the test : IF fr THEN RECT_P(.........)
2) On the display of accented CAPITALS such as 'Â' in the box for fonts 1 and 2, the accents are out of frame.


Translated with DeepL.com (free version)

[komame]

(04-22-2024 09:09 AM)Tyann Wrote:  I've just downloaded the latest version you published.
I have 2 comments:
1) When displayed in relief with a background, a 'p' for example has one pixel of the leg outside the background, to remedy this I removed the '-1' from '3+h-1' on the line after the test : IF fr THEN RECT_P(.........)
2) On the display of accented CAPITALS such as 'Â' in the box for fonts 1 and 2, the accents are out of frame.

Hi Tyann,

The '-1' was intentionally applied because my goal was to maintain compatibility with TEXTOUT_P, which leaves one pixel "p" at the bottom beyond the background (even without formatting). The same applies to accents, as the TEXTOUT_P command for small fonts displays them above the background.

Try it:
TEXTOUT_P("pÂ",10,10,1,0,255,#BBBBBBh);

However, I just noticed that the background should be one pixel higher (but only the top edge, as the bottom one is in the correct position relative to the original TEXTOUT_P), so according to this approach, '-1' should be applied for the bottom edge, and additionally, it should also be applied for the top edge. If compatibility is not important to you, you can change these settings.

[Tyann]

Hé komame
Dans ce cas pas de problème cela convient très bien ainsi.

Hey komame
In that case, no problem, it's fine like this.