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

[komame]

I've prepared a demo of this library with some basic animations added. I think it's worth taking a look.
https://www.hpmuseum.org/forum/thread-21...#pid186907

[Guenter Schink]

Piotr,
thanks a lot for your explanation.

Günter

[komame]

@Tyann, I have sent you the new version of the library (v1.02) with fixes. Please take a look at it and update the attachment with the program on the forum "HP Prime Software Library".

The documentation is available in three languages: English, French, and German.

@Günter, since you're German, could you please take a look at the German translation after Tyann updates the file and let us know if there are any errors?

Thank you.

[Guenter Schink]

(05-09-2024 07:53 AM)komame Wrote:  @Günter, since you're German, could you please take a look at the German translation after Tyann updates the file and let us know if there are any errors?

I'll do my best

Günter

[komame]

(05-10-2024 02:57 PM)Guenter Schink Wrote:  

(05-09-2024 07:53 AM)komame Wrote:  @Günter, since you're German, could you please take a look at the German translation after Tyann updates the file and let us know if there are any errors?

I'll do my best

The new version along with translations has been published, so we are awaiting your judgment

[Guenter Schink]

Hi Piotr and Tyann,

I've had a look at the help texts. The German text seems to be o.k. when compared to the English text. One might argue about capitalizing words in some places, but I think it's o.k. as they stand in just as vocabulary for parameters. For me it works as it is.

However, nitpicking perhaps, the target for the output isn't a "screen". Output is directed to a "graphics variable (G0..G9)" ("Grafikvariable") aka GROB which may be displayed on the screen.

And a question: You state that the maximum width of the string is 320. I didn't find such a limit in the documentation for TEXTOUT_P. Is this limit specific for ATEXTOUT_P (length of ICON buffer), thus breaking compatibility (in probably very rare cases), or did I simply miss this information?

Günter

[Tyann]

Bonjour Günter
Merci pour vôtre aide sur la documentation.
Comme nous devons fixer une taille à ICON, j'ai pensé que 320 étant la largeur de l'écran : cela suffisait .
Effectivement si l'affichage se fait dans une variable G1 à G9, celle ci pourrait être dimensionnée avec une largeur > 320.
Nous pouvons mettre une taille supérieure, mais de toute façon celle ci devra être limitée.
Pour ce qui est de TEXTOUT_P, je n'ai pas vérifié mais oui logiquement, elle ne devrait pas être limitée en taille, sauf si comme la taille des listes (fixée à 10 000) il y a une limite arbitraire.
Il faudrait tester cela ?

Hello Günter
Thanks for your help with the documentation.
As we have to set a size for ICON, I thought that 320 was the width of the screen: that was enough.
Indeed, if the display is in a variable G1 to G9, it could be sized with a width > 320.
We could set a larger size, but in any case it would have to be limited.
As for TEXTOUT_P, I haven't checked but yes, logically it shouldn't be limited in size, unless like the size of lists (fixed at 10,000) there is an arbitrary limit.
This should be tested?



Translated with DeepL.com (free version)

[Tyann]

Je viens de faire un petit test avec ce programme.
En augmentant le nombre de caractères graduellement, et la valeur retournée s'arrête à 511.
Il semble donc que TEXTOUT_P soit limité à 512 pixels.
Si quelqu'un peut confirmer ?

I've just done a little test with this program.
By gradually increasing the number of characters, the value returned stops at 511.
So it seems that TEXTOUT_P is limited to 512 pixels.
Can anyone confirm this?

Code:


EXPORT ESSTXT(n)
BEGIN
 LOCAL a:="";
 FOR I FROM 1 TO n DO
  a:=a+"0";
 END;
 TEXTOUT_P(a,0,0,2,0);
END;

[jte]

(05-12-2024 04:09 PM)Tyann Wrote:  ⋮
By gradually increasing the number of characters, the value returned stops at 511.
So it seems that TEXTOUT_P is limited to 512 pixels.
Can anyone confirm this?
⋮

TEXTOUT_P is indeed currently limited to a width of at most 511 pixels (and assumes 511 as the default width). This is subject to change, however.

(At one point, 511 was a natural limit due to the design at that point in time.)

[komame]

(05-12-2024 02:36 PM)Guenter Schink Wrote:  [...] The German text seems to be o.k. when compared to the English text. One might argue about capitalizing words in some places, but I think it's o.k. as they stand in just as vocabulary for parameters.

When it comes to parameter names, it's a matter of certain assumptions I've made. However, if we were to assume that in the English version we write like this:

Syntax:
ATEXTOUT_P(text, [screen], x, y, [fontSize], [textColor], [attr], [alpha], [width], [backColor])

then the translation into German would look like this

Syntax:
ATEXTOUT_P(Text, [Bildschirm], x, y, [Schriftgröße], [Textfarbe], [Attr], [Alpha], [Breite], [Hintergrundfarbe])

which may be more in line with the spelling rules in German (but not entirely consistent with the "camel case" naming convention). However, it's not a matter of translation quality but rather a matter of agreeing on how parameter names should look (which are often written in abbreviations).

(05-12-2024 02:36 PM)Guenter Schink Wrote:  [...] the target for the output isn't a "screen". Output is directed to a "graphics variable (G0..G9)" ("Grafikvariable") aka GROB which may be displayed on the screen.

Regarding the "screen", it's also a matter of terminology (originally Tyann used the term "screen" in our conversations, and I responded in the same way, and somehow it stuck), but your observation is valid. Analyzing the built-in help, different descriptions are used for G0-G9, sometimes simply "graphic" (e.g., TEXTOUT, BLIT, LINE, TRIANGLE), sometimes "GROB" (e.g., PIXON, ARC), and sometimes the description is omitted altogether or simply "G" is used (e.g., FILLPOLY, INVERT_P). I think I'll stick with "GROB" because it's probably the most universal term.

(05-12-2024 02:36 PM)Guenter Schink Wrote:  And a question: You state that the maximum width of the string is 320. I didn't find such a limit in the documentation for TEXTOUT_P. Is this limit specific for ATEXTOUT_P (length of ICON buffer), thus breaking compatibility (in probably very rare cases), or did I simply miss this information?

Now that we've clarified that TEXTOUT_P also has a limit, there's nothing stopping us from increasing the size of the ICON buffer to 511 (plus a few pixels to support italic text).

Günter, thank you very much for your valuable feedback. I'm really glad you didn't find any language errors (that was very important to me).
With the next update, I'll make corrections to the descriptions (in all language versions, including English) according to the above suggestions, and I'll add translations for the other languages available in the HP Prime help.

[Guenter Schink]

Nice being able to add a bit to improve this great work.

Günter

[komame]

Hi Tyann,

I've been experimenting with ICON a bit, and it turns out that when I generate a string for ICON as an empty buffer directly on the HP Prime, it's smaller than the one generated using DIMGROBHelper.
Despite increasing the buffer size from 331 pixels to 522 pixels, the string for ICON has decreased by 40 characters (202 => 162).

This is a program I wrote to generate such an empty buffer string:

Code:

EXPORT ICONBUFFER(w,h)
BEGIN
  local iconstring,f:=CHAR(RANDINT(30,97,122));
  DIMGROB_P(G9,w,h,0);
  AFiles(f):=G9;
  iconstring:=ΣLIST(EXECON("RIGHT(0+SUPPRESS(STRING(&1),\"#h\"),2)",SETBASE(AFilesB(f,0,AFilesB(f)),4)));
  DelAFiles(f);
  RETURN "ICON buffer " + iconstring +";";
END;

I want to make it clear right away that this program won't work for any files with graphical content; it can only be used to generate an empty buffer. Perhaps with a bit more experimentation, it might be possible to replace DIMGROBHelper with a program on the HP Prime for normal graphics as well, but for now, I haven't delved into that topic quite so deeply yet.

Additionally, I changed the "Err" function and used PIECEWISE in it, which made it more compact (single-line) and allowed for removing the "Invalid Input" error generation because it is default for PIECEWISE when no condition is met.

I also added translations for Dutch [NLD - Nederlands], Portuguese [POR - Português] and Simplified Chinese [ZHS - 中文(简体)]. However, I encountered an issue with Japanese language, which requires a bit more work to achieve satisfactory results, so I'll address that a bit later.

EDIT (May 17, 2024): A Japanese translation has been added.

The new version v1.03 with the above changes has been published: https://www.hpmuseum.org/forum/thread-21...#pid187156

Best wishes