Parameters of the TEXTSIZE

[komame]

Does anyone know what the third and fifth parameters of TEXTSIZE are responsible for?

The basic form is TEXTSIZE(text, [font]), which returns a list {width, height} containing the size in pixels of the specified text provided as the first parameter, using the font size (allowed values from 0 [default] to 7, as described in the TEXTOUT_P help) specified in the second parameter.

For example:
TEXTSIZE("Prime",3) → {39,16}

The third parameter definitely only accepts positive integer values because for other values, it triggers a "Error: Invalid input" and I'm not sure what this parameter is responsible for.

The fourth parameter seems to be the maximum length of the field in pixels where we are trying to fit the text, and then in the width value (first element of the result list), we get the size considering as many characters as will fit in that field.

For example:
TEXTSIZE("Prime",3,0,28) → {18,16}
where 18 is the width of "Pri", because if we add one more char, we get "Prim", which has a width of 31, so it exceeds 28.

The fifth parameter - also a positive integer, but I couldn't determine what it's for.

Help opens the description for TEXTOUT, so there is a bug in the reference to the description for TEXTSIZE here.

Does anyone know more about these parameters?

[Guenter Schink]

(03-14-2024 09:14 PM)komame Wrote:  Does anyone know what the third and fifth parameters of TEXTSIZE are responsible for?

...

Does anyone know more about these parameters?

Maybe the syntax is the same as in "TEXTOUT" in order to have the same parsing of the command, but then disregarding parameters 3 and 5. I just gave the 3rd parameter which under my assumption would be "textColor", an excessive high value, e.g.999999999. Then it returns "Error:Invalid input" Conclusion (perhaps) it uses the same syntax as TEXTOUT, but disregards parameter 3(textColor) and parameter 5(backgroundColor). Thus it's easy for the system to evaluate parameter 4(width). Great find, by the way.

When using hex numbers it seems to be more obvious(assuming still). You first have to set integers to a length > 32. e.g. 64 in the setup screen. Now entering a value of #FFFFFFh for textColor works as there are four channels, while #1FFFFFFFFh gives the error, no fifth channel there.

Perhaps it works this way
Günter

[komame]

(03-15-2024 11:24 PM)Guenter Schink Wrote:  Maybe the syntax is the same as in "TEXTOUT" in order to have the same parsing of the command, but then disregarding parameters 3 and 5. I just gave the 3rd parameter which under my assumption would be "textColor", an excessive high value, e.g.999999999. Then it returns "Error:Invalid input" Conclusion (perhaps) it uses the same syntax as TEXTOUT, but disregards parameter 3(textColor) and parameter 5(backgroundColor). Thus it's easy for the system to evaluate parameter 4(width). Great find, by the way.

When using hex numbers it seems to be more obvious(assuming still). You first have to set integers to a length > 32. e.g. 64 in the setup screen. Now entering a value of #FFFFFFh for textColor works as there are four channels, while #1FFFFFFFFh gives the error, no fifth channel there.

Hi, Günter.

Thank you for your comment.
What you suggest makes sense. It's likely that during the implementation of the TEXTSIZE instruction, a portion of the code was copied from the definition of the TEXTOUT instruction due to their similarity. So, it's another messy instruction that needs to be rebuilt, much like TEXTOUT_P with 2D mode.

Additionally, it can be said that TEXTSIZE(obj, font) is an alternative to TEXTOUT_P(obj, {"2D", font}) with the difference that TEXTOUT_P in 2D mode does not work correctly with text strings and returns a slightly wider width than TEXTSIZE. This slightly wider width probably results from the initial assumption for TEXTOUT_P that the measurement should provide the X coordinate for the next text, potentially appearing after the measured text (so, it took into account the position where the given text is being inserted). Unfortunately, for 2D mode, we have another bug (or inconsistency) here, because coordinates are required but ignored in 2D mode, and the provided width (slightly increased) is always calculated from the point (0, 0).

For example:
TEXTSIZE(123,4) → {27,20}
TEXTOUT_P(123,0,0,{"2D",4}) → {29,20}
TEXTOUT_P(123,50,50,{"2D",4}) → {29,20}

[Guenter Schink]

Hi Piotr,

I didn't know the problem with 2D. Inconsistencies is a dominating characteristic of the PRIME. It's such a pity, as Tim and Cyrille were obviously very capable developers. But you can't be successful once your management doesn't provide the necessary resources. An indication of the problems may be that we haven't heard anything from Moravia for quite a while. Perhaps they realize that's a mission impossible to rectify the problems with their intended man power.

BTW: in my little Python program on L-System fractals using TEXTSIZE was rather convenient to have centered and right aligned TEXTOUT. A short snippet.

Code:

import hpprime as hp
def strip(arg): 
   return str(arg)[1:-1]

def TxtOut(t,x,y,f,c,*args):
   if len(args)>2:
      raise(SyntaxError("too many arguments"))
   if True in [isinstance(i,list) for i in t]:
      raise(TypeError("can't convert 'list' object to str implicitly")) 
   parms=(int(x),int(y),int(f),int(c))
   if len(args)>0:parms+=(int(args[0]),)
   if len(args)>1:parms+=(int(args[1]),)
   return hp.eval('TEXTOUT_P('+string(t)+','+strip(parms)+')')

def TxtRight(t,x,y,f,c,*args):
   x -= hp.eval('TEXTSIZE('+string(t)+','+str(f)+')')[0]
   TxtOut(t,x,y,f,c,*args)

def TxtCenter(t,x,y,f,c,*args):
   x  -=  (hp.eval('TEXTSIZE('+string(t)+','+str(f)+')')[0])/2
   TxtOut(t,x,y,f,c,*args)

Günter

[komame]

(03-16-2024 07:47 PM)Guenter Schink Wrote:  Inconsistencies is a dominating characteristic of the PRIME. It's such a pity, as Tim and Cyrille were obviously very capable developers. But you can't be successful once your management doesn't provide the necessary resources.

Regarding the inconsistency - I completely agree. For the time when Prime was in the hands of HP, many mechanisms were implemented without being tested. Even completely flawed, non-working features were described in release notes (as new features), but simply didn't function. Publishing non-working mechanisms has a hugely negative impact and introduced more harm than good in Prime.
As for the programmers you mentioned, I have my own observations on that matter. Being a proficient programmer is one thing, but just writing code is not everything; you also also need to be capable of designing and even anticipating to some extent, and in this aspect, it didn't look very good (for example, the parameters we have in the instruction and the order in which they appear, as well as their consistency with other similar functions, are the domain of programmers in this case). Of course, the management is responsible to some extent for all the issues that occur with Prime, but in my opinion, the programmers (analyzing their statements and reactions) had a free hand in what they published, and no one controlled it, which means that besides programming, they also decided what happened in the project and bear at least partial responsibility for the lack of quality in what they published. There are specific examples of a complete lack of testing (which is unacceptable), so it looks like they went for quantity of changes but completely forgot about quality.
Of course, the vast majority of their work consists of very well-functioning solutions and this should be appreciated.

(03-16-2024 07:47 PM)Guenter Schink Wrote:  An indication of the problems may be that we haven't heard anything from Moravia for quite a while. Perhaps they realize that's a mission impossible to rectify the problems with their intended man power.

Indeed, the lack of information from Moravia is a significant problem, but I hope that will change. Certainly, the Product Manager should definitely visit the forum more frequently and provide some general information. It's good that there's Jeff, and he at least occasionally shares some information about the bugs that have been fixed.
On the other hand, from what I observe today, Moravia's current strategy is primarily focused on fixing bugs. And that's a very reasonable decision because you can't build anything good on a weak, unstable foundation. Once stability is improved and quality is raised, then it will be time for development. Unfortunately, identifying all the bugs from previous years is a huge task, and there are many, mainly in the PPL area but also in the user interface. Many of them have already been identified, and quite a few have even been fixed, but there is still a lot of work to be done. That's what Moravia is doing - fixing what was once neglected. The budget is probably limited, so everything is progressing very slowly, but it is moving forward.

[Tyann]

Bonjour

En travaillant sur DEFTEXT il m'est venu une idée, le 5 éme paramètre de TEXTSIZE ne pourrait t-il pas être les flags d'attributs ( Gras, Italic , etc...) qu'est censé supporter TEXTOUT_P en mode "2D" ?
Car un même texte prends plus de largeur en italique par exemple.


Hello

While working on DEFTEXT, I had an idea: couldn't the 5th TEXTSIZE parameter be the attribute flags (Bold, Italic, etc.) that TEXTOUT_P is supposed to support in "2D" mode?
Because the same text is wider in italics, for example.

[komame]

(03-31-2024 01:06 PM)Tyann Wrote:  While working on DEFTEXT, I had an idea: couldn't the 5th TEXTSIZE parameter be the attribute flags (Bold, Italic, etc.) that TEXTOUT_P is supposed to support in "2D" mode?
Because the same text is wider in italics, for example.

I also had such a thought. However, we have two parameters whose meaning is unknown, and it's difficult to guess "what the author had in mind". Perhaps someday someone from Moravia will answer this question.