artist_port text editor issue with 'f' character

[johannphilippe]

Funny bug this time :smile: Artist port branch, in the text_and_icons example : write a 'f' in a text editor, all fine. write a second one, it disappears. write a third one, it re appears write a fourth one, it disappears ... etc It seems to be only with the 'f' character

[johannphilippe]

I also noticed that input_box text can overflow a little bit if the elements size is limited to some sizes. It did overflow for a x limit of 30, and it doesn't for a x limit of 40 (with view_limits).

[djowel]

I don't have time to investigate right now, but if you can dig deeper (e.g. set up break points and see where it leads to), that would be great!

PS> All the more reason to delegate this task to another (preferably native) library.

[johannphilippe]

The overflow seems to happen on master branch as well. It seems to only reproduce when the input_box is inside a limit with view_limits.max.x < 40. I tried to investigate, but couldn't find the real reason for this. Actually, it is not a big deal,, since a input_box with a width < 40 is quite small (should be quite rare to use this elements with a small size like this). So it doesn't seem to be a "bug" to me, but rather a widget design property.

About the 'f' character, I'm still trying to figure out

[johannphilippe]

As a reminder, "f" characters are only displayed if impair number of f are typed. The issue seems related to the text_layout::impl class. In the constructor, the 'f' character generates the same line breaks than another character. But in the flow method, it seems to be different.

F characters :

//First f typed
Break line type in constructor at index 0 : 0 
breakline in flow loop at index 0 :  0 
breakline in flow loop at index 0 :  0
// second f typed 
Break line type in constructor at index 0 : 3 
Break line type in constructor at index 1 : 0 
breakline in flow loop at index 0 :  3 
breakline in flow loop at index 0 :  3 
// third f typed
Break line type in constructor at index 0 : 3 
Break line type in constructor at index 1 : 3 
Break line type in constructor at index 2 : 0 
breakline in flow loop at index 0 :  3 
breakline in flow loop at index 1 :  0 
breakline in flow loop at index 0 :  3 
breakline in flow loop at index 1 :  0 

Not F characters :

// First character (anything but f) typed
Break line type in constructor at index 0 : 0 
breakline in flow loop at index 0 :  0 
breakline in flow loop at index 0 :  0 
// Second character (anything but f) typed
Break line type in constructor at index 0 : 3 
Break line type in constructor at index 1 : 0 
breakline in flow loop at index 0 :  3 
breakline in flow loop at index 1 :  0 
breakline in flow loop at index 0 :  3 
breakline in flow loop at index 1 :  0 
// Third character (anything but f) typed
Break line type in constructor at index 0 : 3 
Break line type in constructor at index 1 : 3 
Break line type in constructor at index 2 : 0 
breakline in flow loop at index 0 :  3 
breakline in flow loop at index 1 :  3 
breakline in flow loop at index 2 :  0 
breakline in flow loop at index 0 :  3 
breakline in flow loop at index 1 :  3 
breakline in flow loop at index 2 :  0 

It appears that the flow loop doesn't go to the last index when user typed a sequence of 'f'. Also we can see that the line break types aren't the same :

• sequence of no_break then a indeterminate for other characters than f
• alternance of no_break and indeterminate for 'f' character when there is a pair number of 'f'. Sequence of no_break when impair number of f.
• This leads to the new_line lambda not being called when there is a pair number of 'f' typed.

[djowel]

Nice hunting! I suspected something like this. I thought it might have something to do with F-ligatures: https://creativepro.com/typetalk-the-ins-and-outs-of-f-ligatures/

[djowel]

The overflow seems to happen on master branch as well. It seems to only reproduce when the input_box is inside a limit with view_limits.max.x < 40. I tried to investigate, but couldn't find the real reason for this. Actually, it is not a big deal,, since a input_box with a width < 40 is quite small (should be quite rare to use this elements with a small size like this). So it doesn't seem to be a "bug" to me, but rather a widget design property.

It's good if I can resolve this issue, though, for correctness.

[johannphilippe]

Same bug for succession of 'f' and 'i' chars. So that may indeed be related to ligatures !

[djowel]

Same bug for succession of 'f' and 'i' chars. So that may indeed be related to ligatures !

Indeed!

[djowel]

BTW, do you mind filing another issue for the overflow issue?

[johannphilippe]

Nice hunting! I suspected something like this. I thought it might have something to do with F-ligatures: https://creativepro.com/typetalk-the-ins-and-outs-of-f-ligatures/

   void hb_buffer::shape(hb_font const& font)
   {
       hb_feature_t userfeatures[1];
       userfeatures[0].tag = HB_TAG('l','i','g','a');
       userfeatures[0].value = 0;
       userfeatures[0].start = HB_FEATURE_GLOBAL_START;
       userfeatures[0].end = HB_FEATURE_GLOBAL_END;
      hb_shape(font.get(), _buffer.get(), userfeatures, 1);
   }

Confirmed it has to do with ligatures.

[johannphilippe]

So, the error occurs with OpenSans and DejaVu fonts, but not with Roboto it seems. Edit : Roboto has issues as well, but not for 'ff'. The disappearances happens with 'fi' and 'fl'