Smartforms and longtexts issue

[matteo_montalto]

Hi all gurus,

I'm not an expert on the argument as I've worked on Smartforms just for minor corrections... I need your help and suggestions.

We have some Z smartforms in our SRM system; they are used to print purchase orders and contracts previews, but there's an issue regarding longtexts; in attachment you can see the structure of a smartform (others are similar to this one).

Basically, for each item of the document that is processed, there's a loop over a longtext internal table and the corresponding text row is printed out.

That was the way the original smartform was structured; anyway now we've some problems as such a procedure doesn't allow to format correctly the text.

In fact, TDFORMAT field of wa_longtext work area is never evaluated in such schema so it is non-relevant.

Moreover, given that wa_longtext has type BBP_PDS_LONGTEXT, we know that TDLINE can contain up to 132 chars.

In our smartform, there's a fixed width place in TA_ITEM table to store longtexts, and this leads sometimes to unwanted start of a new line.

To provide an example, consider the following text note:

This is an example note to show the specific "start of a new line" problem related to the missing evaluation of the tdformat field of the structure wa_longtext.

This string is 160 chars long, so it will be splitted into 2 different row of the longtext internal table:

1) This is an example note to show the specific "start of a new line" problem related to the missing evaluation of the tdformat field

2) of the structure wa_longtext.

Suppose now that in our smarform the longtext node has enough space for ... say... 120 chars ( I did not understand yet how to check for this value as the TA_ITEM node table doesn't mention explicitly where TE_longtext will be inserted): the resulting output would then be:

This is an example note to show the specific "start of a new line" problem related to the missing evaluation of the tdf

ormat field

of the structure wa_longtext.

which is quite awful

My guess is that we should reconsider from scratch the longtext routines on these smartforms, anyway any hint or specific suggestion on the argument would be highly appreciated, even on the best practice in order to achieve our desiderata.

Thanks, kind regards,

M.

[matteo_montalto]

Another question: I tried to make some experiments on a smartform, and managed how to assign a row type to my longtexts.

So, up to now I defined a row type as follows:

LINE, which is split in 2 subsection; the first one is 2,5 CH (characters) long, while the second subsection, which will contain the text, is 66 char long; see the attached screenshot:

However, when I assign this row type to my longtext cell (ignore the first section, just to be considered as a margin), I notice that MORE that 66 chars are filling the row; this is probably due to the fact there's a style assigned to the document (ZBBP).
Specifically, these are the parameters of the paragraph type used to print the longtexts:

So, it's clear that Helvetica, 10 pts. is actually smaller than the CH unity of measure used in my tab definition, as more that 66 chars are shown by the smartform.

Is there a rule to convert from CH u.o.m. to specific font dimension? I need to modify the smartform so that each text line can contain up to 66 chars.

Thanks

[Former Member]

Regarding the characters space. I would experiment with placing 66 characters in a row in your desired font, making sure the cell in which the characters are is defined in cm's or mm's. Then shrink the size of the cell till the 66 characters do not fit anymore. As such, you know how much space your 66 characters need.

Alternatively, define a variable type c length 66 and migrate your data into this field.

Good luck,

Steven

[Former Member]

Why don't you just use the 'Include text' in text type in the smartform?

Then SAP handles all the formatting according the format of the original text. If you want to edit the formatting, just go to SO10, and edit the original text (preferably in the old text editor).

Hope this helps

[matteo_montalto]

Thanks for your help, Steven

my doubt is that I cannot find a corrispondence between CH u.o.m. and string length; this would probably be possible if I was using a monospace font, but that's not the case. So, filling a string with an hundred "i" and filling a string with an hundred "m" would probably result in different CH length. 😛

Your other suggestion could instead be intesting; fixing a defined length, I could in the initialization form split texts on that measure,being sure that this length fits properly on the page width.

This is off course a workaround, anyway, better than nothing

EDIT: I just tried, results are not that good, however better than nothing. Considering the worst case, which I assumed to be a string filled with "m" (largest character using Helvetica font), the maximum string lenght is 73... In order to consider this as the upper bound, an average string of text of 73 chars fills more or less half the width of the page, which is quite horrible to see

[matteo_montalto]

I was wondering ... is there any FM or method that could "measure" the length of a text string in terms of effective space on the screen?
Something that could say, in example, that the string "Hello this is an example of text", written in a certain font A with size 10 will fill approximately 10 cm (or other unit of measure, as TW, IN, MM, PT) ?

This should be *really* helpful as it could be used to determine width of string printed with a proportional font (as Helvetica, or Times).

If there's a way to get it, I could build a routine which will dinamically build each text line until the maximum available space is reached,

Referring to the example above, and considering a space of 7,5 cm, the routine should act as follows:

1) evaluating hello" written in Helvetica, 10 --> width of 3 cm;

2) is 3 < maximum available space ? Yes, so repeat step 1 with the following word

3) If 2) is ok, then concatenate ammissible words in a string separated by space.

This could be an optimal solution...