Views::AttrText.GetContentArea() returns incorrect text size

Question

Hello!

Why does Views::AttrText.GetContentArea() returns incorrect text size - instead of actual size taken by the text it returns Views::AttrText.Bounds value?

It is said (here https://doc.embedded-wizard.de/mosaic_views_attrtext?v=8.20#GetContentArea) that Views::AttrText doesn't support auto scaling but there is no mention of the same limitation regarding GetContentArea().

This function is really needed if, for example, user wants to provide custom text centering facilities if non-monospaced fonts are used by AttrText, because the default text centering style Views::TextAlignment[AlignHorzCenter] works really bad with dynamically changed texts (text jumps several pixels left or right from the center depending on the contents of the text string).

PS: the same issue exists in prototyper and in STM32 support package.

Answer 1

Hello,

regarding the method Views::AttrText.GetContentArea(), our documentation is inprecise here concealing the fact, that the Attributed Text view calculates horizontally always with the whole available width. This is usually the width of the Attributed Text view (stored in its property Bounds) or the value specified in the property WrapWidth. In turn, vertically the text height is calculated depending on the displayed text content. This actual restriction results from the complex layout mechanisms of the Attributed Text view and can't be avoided actually.

If possible use the regular Text view instead. Its method GetContentArea() doesn't depend on the complex layout mechanism, so it can calculate also horizontally with the real text width.

Alternatively, you can enclose in Attributed Text the interesting text position between a pair of {lnk:#} .. {lnk} attributes. Then at the runtime, you can ask the Attributed Text view for the corresponding areas. Please see Arrange other views on the content of the Attributed Text view and Add links.

Regarding your second issue, would you please provide us an example demonstrating your particular problem with the text jumping several pixel left or right from the center depending on the contents of the text string?

Best regards

Paul Banach

Comments

Hello.

Using ordinary Text view brings another hassle when you need to draw numbers like "88.8" and the dot sign plus fractional part have to be smaller than integer part. I implemented this via 2 text views but it is some additional task to align fractional part with integer one when latter changes in size. But OK, I already did this.

Regarding the second issue you can reproduce it using via following:
1. Create a text view, assign to it some monospaced font like Courier New. Apply horizontal centering style to it.
2. Using integer effect modify the text view so that it is showing animation with numbers from "11" to "99"
You'll see that the text view is jiggling left or right depending on the numbers shown even though we are using monospaced font and every character should have same horizontal size.

 

Best regards,
Maxim.

---

Hello,

first at all thank you very much for the indication. Following your instructions I was able to reproduce the issue #2. You are right, the text may appear slightly moved when using the align mode right or centered in the Text view. The reason is, the alignment calculates in this case with the right end of the last displayed glyph. The glyphs however can have different size even in case of monospaced fonts. Therefore the distances between the glyphs are controlled by using metric information associated to every glyph. In case of the last glyph the metric was ignored with the intention to ensure that all glyphs appear well alligned at the right edge. 

Thus this behavior was intended as a feature not a bug to allow precise right aligned text. Anyway, I agree this behavior is not optimal. So I see two possibilities, how you can progress:

Option 1: You can limit in this special application case to use the left aligned mode and if necessary scroll the text horizontally so it appears centered. You have to calculate the necessary scroll offset. However using monospace font this should be not difficult. 

Option 2: In case of right aligned or centered text you can calculate an additional offset missing for the last glyph and apply it to the property ScrollOffset of the Text view. The following code calculates fromthe metric of the last glyph an offset and assigns it to the property ScrollOffset . This compansates the original calculation error:

var Resources::Font font = yourTextView.Font;
var string          text = yourTextView.String;
var char            lc   = text[ text.length - 1 ];
var int32           da = font.GetGlyphAdvance( lc ) - font.GetGlyphOrigin( lc ).x -
                         font.GetGlyphSize( lc ).x;

if ( da > 0 )
  yourTextView.ScrollOffset.x = -da;
else
  yourTextView.ScrollOffset.x = 0;

Hope one of the above worakrounds is sufficient for you. With the next version we will rework the alignment functionality and correct the behavior.

Best regards

Paul Banach

---

Thank you, Paul, for your response.

My current workaround was to create an array of offsets for all possible values of the widest symbols like "8", "88", "888" ... and use these offsets for centering the text in left-aligned mode depending on current amount of digits being shown.
But your second approach looks nicer. I will try it.

Best regards,
Maxim.

---

Hello, Option #2 only works when the text is right justified. When center justified, it still jiggles. I'm using RobotoMono size 256 in case you need the font details. I have a simple application with nothing but a text widget that is center justified and I still see the issue. What am I missing?

---

Hi xaviesh

It must be left or right justified because you are doing its centering yourself.
I also switched to option 2 + left justified text and it works nice. 

---

Hello,

first at all, we are sorry for the problems with the text alignment.

Some background information for this issue. The Text view like all other views in Embedded Wizard has rectangular Bounds area. This area limits the view to not draw anything outside its Bounds area. Some customers, however, had the problem with italic fonts being clipped at the right view edge if the text is right aligned. 

The reason here was, that especially in case of italic fonts one glyph may become wider than its advance. In this manner two glyphs lying side by side may appear interlaced. Last glyph, however, may become arranged a little bit over the right edge of the view Bounds and is clipped then. Our intention was to provide an automatically working feature so the text is always looking correctly. For this purpose, we adapted in 8.20 the alignment algorithms to take in account the width of the last glyph.

With this adaptation text was not clipped anymore. On the other hand, this modification had the side effect of calculating the width of a text row too exactly. The advance of the last glyph was ignored. The above described issue with jitter was the consequence.

We have come to the conclusion, that the well-intentioned text alignment modification in 8.20 was incorrect. We will revert to the preceding version and add an additional Padding property to the Text view permitting the developer to specify a gap around the text, which prevents the italic text clipping at view edges. In this case the developer will have to take care of the right property setting for the used font. No automatism is used anymore. We are working on this adaptation and we plan to provide it with the next release as soon as possible.

In the meantime we recommend to use the left aligned mode for displaying the text or using the above desrcibed workaround with ScrolllOffset.

Thank you for your understanding.

Best regards

Paul Banach

---

Hello Paul, thank you so much for the detailed explanation. It helps with understanding the problem. Unfortunately, our application relies heavily on having this fixed and working like before. I've made an internal release with the monospace fonts instead and have everything right justified as a temporary fix but there is a lot of pressure to have it fixed as we're entering field trials shortly. Do you have an estimate for when we could expect the fix from you for this issue. Thanks!

---

Hello,

we have prepared a patch for Mosaic framework. This patch should correct the alignment problem with regular Text view on Embedded Wizard 8.20. The patch IS NOT intended for versions other the 8.20.

Please note: This patch does not fix alignment problems with Attributed Text. These expect the adaptation of the Graphics Engine, which is a bigger task, so we will corrected it with next release.

Following are the steps to install the patch:

1. Exit Embedded Wizard if it is running actually.

2. In Windows Explorer navigate to the installation folder of Embedded Wizard. Usually this is the Folder C:\Programs(x86)\Embedded Wizard 8.20.

3. Within the Embedded Wizard folder navigate to the sub-folder Mosaic.

4. Download the following ZIP file:

Mosaic_Patch_820.zip

5. Un-zip the file and copy the both enclosed files Resources.ewu and Views.ewu to the in step 3 opened Mosaic folder. You will eventually need to confirm the operation to be performed with higher privilege.

6. Start Embedded Wizard again.

As mentioned above in this thread the patch reverts the alignment algorithms to the older version 8.10. Additionally the Text view has been enhanced by a new property Padding. With Padding you are free to specify an additional gap to add on the left and right edges of the Text view. You do this usually with italic text, when the displayed text appears clipped at the edges. If the text appears correctly, you can ignore Padding.

Well, I hope, the patch helps you to progress while we do focus on the next official release. This however will take some weeks. Let me know whether everythink is working now as expected, or even not ...

Best regards

Paul Banach

---

Works perfectly! Thank you Paul.