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

[Tyann]

Bonjour komame

C'est bon pour moi, excellent travail.

Hello komame

That's it for me, excellent work.

[Guenter Schink]

Tyann, Piotr

Nice presentation of a kollaborative effort. Very interesting and informative to follow your work.

I hope that I don't raise a dump question! It's about ICON. I think I've understood how you utilize it, but I have no clue what all these figures in the creating statement 'ICON buffer ....' after 'buffer' do.

Would you mind to elaborate a bit on this?

Regards, Günter

[Tyann]

Bonjour Guenter
Merci pour vôtre commentaire.
Concernant ICON, je pense que cela fonctionne comme DIMGROB_P, les nombres sont censés représenter des données graphiques ainsi que la taille .
Dans le cas de ATEXTOUT_P, les données graphiques n'ont pas grande importance il s'agit juste d'avoir un tampon qui ne monopolise pas une des variables G1 à G9, pour que celle ci reste utilisable par ATEXTOUT_P tout comme l'instruction intégrée TEXTOUT_P.
Personnellement j'utilise un petit programme sur PC nommé DIMGROBHelper qui permet de définir ces valeurs selon une image et de copier coller ensuite dans le code PPL.
Komame ou quelqu'un d'autre pourra surement vous en dire plus que moi sur le sujet.

Hello Guenter
Thank you for your comment.
Concerning ICON, I think it works like DIMGROB_P, the numbers are supposed to represent graphic data as well as the size.
In the case of ATEXTOUT_P, the graphical data isn't very important, it's just a question of having a buffer that doesn't monopolise one of the variables G1 to G9, so that it can still be used by ATEXTOUT_P, just like the built-in instruction TEXTOUT_P.
Personally, I use a small program on my PC called DIMGROBHelper, which lets you define these values according to an image and then copy and paste them into the PPL code.
Komame or someone else can probably tell you more about this than I can.


Translated with DeepL.com (free version)

[Guenter Schink]

Moin Tyann

(05-05-2024 03:25 PM)Tyann Wrote:  Concerning ICON, I think it works like DIMGROB_P, the numbers are supposed to represent graphic data as well as the size.

thank you very much for your answer. When I look at the syntax for DIMGROB, it seems pretty clear how to create a grob with a few numbers. The example in the HELP seems to be easy to follow. But in the ICON statement, I can't see any structure, only a sequence of arbitrary? length.

Perhaps someone can shed some light on it.
Anyway thanks for your effort.

Günter

[komame]

(05-05-2024 03:41 PM)Guenter Schink Wrote:  When I look at the syntax for DIMGROB, it seems pretty clear how to create a grob with a few numbers. The example in the HELP seems to be easy to follow. But in the ICON statement, I can't see any structure, only a sequence of arbitrary? length.

Perhaps someone can shed some light on it.
Anyway thanks for your effort.

Hi Günter,

When using the DIMGROB command, graphical data is provided directly, byte by byte. However, with ICON, the situation is quite different because internally, it's a graphic file in the "png" format, which, like "jpg", is a compressed format. Therefore, you can't extract individual pixels from it directly, as they take up much less space after compression. If you were to save a "png" file created in any graphic editor on a PC and then convert it to hexadecimal format, you would get something similar to what we input for ICON.

An icon with dimensions 10x10 looks like this:
ICON name 89504E470D0A1A0A0000000D494844520000000A0000000A0100000000A549F2100000000274524E​5300010194FDAE000000184944415478017DC2010D0000008320FBA77A336D7006EE0C0752117786​35152C0000000049454E44AE426082;
while an icon with dimensions 1000x10 looks like this:
ICON name 89504E470D0A1A0A0000000D49484452000003E80000000A01000000000FBC495D0000000274524E​5300010194FDAE0000001E494441547801EDCD310100000C0220FB97DE5AE80305C82DD9ED767BC7​03E048DD5B5690EF480000000049454E44AE426082;
As you can see, a 100 times larger area occupies just a few bytes more, thanks to compression.

The advantage of ICON is that you can draw on it similarly to G0-G9. As you probably know, the values of local variables declared outside the body of any function in PPL are stored between individual program runs and are reset to their initial values only when you enter the source code, which ends with its compilation (or after manually executing a "check").
If you change the content of ICON during program execution (drawing on it), it remains changed similarly to PPL variables until you recompile the source code again (check). The disadvantage of ICON compared to G0-G9 is that the image size cannot be dynamically changed during program execution, so what you declare in the source code remains at the same size, and to change it, you need to edit the source code.

As Tyann mentioned, you can generate the hexadecimal string for ICON using the DIMGROBHelper:
https://www.hpcalc.org/details/7472