Page MenuHomePhabricator

Text style quirks
Open, Showstopper IssuesPublic

Description

After thoroughly documenting the Efl.Canvas.Textblock.style_apply method I have come with the following list of items that I think should be addressed.
Some look like errors or oversights, others are just API weird spots (in my opinion).
Feel free to provide patches for them, or create subtasks, or just discuss them here!

Line size:

  • linesize cannot be <100% but linerelsize can. They should be equivalent.
  • linerelsize=0 disables it, instead of 100% which makes more sense.
  • linerelsize can be merged with linesize if it accepts %, just like align.
  • Relationship between linesize, linerelsize and linefill must be clarified. What happens exactly when you supply more than one?

Naming:

  • Some words are separated with underscores (like underline_color) whereas some other aren't (like linesize).
  • password and replacement_char could be merged (password mode could be disabled when replacement_char=""
  • The backing properties were renamed to background, but the attributes in style_apply are still called backing.

Wrapping:

  • According to the initial all_styles_get, wrap seems to default to word, but that's not true.
  • Wrap cannot be disabled. none is available in Efl.Text_Format_Wrap but not in the formatting string ("" does not work).

Missing API:

  • linesize can only be set through style_apply but has no equivalent property in Efl.Text_Format.
  • multiline is not available through style_apply
  • There is no way to retrieve the list of available fonts (for the font_family property), as there was in Legacy.
segfaultxavi triaged this task as Normal priority.

I will revisit all comments, but for the last one

  • multiline is not available through style_apply

multiline is canvas property and it is not related to text styling, if the user do not want multiline, then his text should not have a line or paragraph break.

It looked like a useful enough thing to have. It also affects line wrapping, which CAN be modified through style_apply.
My use case is that a user wanting to have a long, wrapping text can configure everything using style_apply except the multiline property, which is a shame.

  • linesize cannot be <100% but linerelsize can. They should be equivalent.

linesize is not a percentage, it is a size in pixel.

  • linerelsize=0 disables it, instead of 100% which makes more sense.

actually the two have the same effect, 0 or 100%

  • linerelsize can be merged with linesize if it accepts %, just like align.

linesize is pixel size not relative percentage.

  • Relationship between linesize, linerelsize and linefill must be clarified. What happens exactly when you supply more than one?

First thing none of these value can be less than the calculated line size (height)
linesize : user can specify line size in pixel, this is ideal when we are dealing with pixels (for example movie subtitle on video)
linerelsize : user can specify line size depending on calcualted size, this is ideal for Editor application where you can increase distances between lines for better reading.
linefill : user can specify line size depending on canvas size, this is ideal when you want to show a specific amount of lines in the canvas.

  • Some words are separated with underscores (like underline_color) whereas some other aren't (like linesize).

prefix and suffext for the line word are writing as one word (underline or linesize).

  • password and replacement_char could be merged (password mode could be disabled when replacement_char="".

I see it is a little bit confusing when the user enables password but it is not shown because replacment_char is empty, but still making two-property affecting each other values could be more confusing.

  • According to the initial all_styles_get, wrap seems to default to word, but that's not true.

Yes this is a bug/limitation

  • Wrap cannot be disabled. none is available Efl.Text_Format_Wrap but not in the formatting string ("" does not work).

Yes this is a bug/limitation

  • linesize can only be set through style_apply but has no equivalent property in Efl.Text_Format.

Yes this is a bug/limitation (linesize,linerelsize,linefill)

  • linesize cannot be <100% but linerelsize can. They should be equivalent.

linesize is not a percentage, it is a size in pixel.

I knoooooow. What I mean is that, with a 10-pixels font, you can set linerelsize=50% and you get a line spacing of 5 pixels, so the lines overlap. However, you CANNOT set linesize=5. This is strange, because both properties look equivalent in all regards except this.

  • linerelsize=0 disables it, instead of 100% which makes more sense.

actually the two have the same effect, 0 or 100%

Exactly, so we can remove the special case for 0 since it is not needed. Anyway, I can remove it from the docs.

  • linerelsize can be merged with linesize if it accepts %, just like align.

linesize is pixel size not relative percentage.

I knoooooooow. What I mean is that we can have a single property named linesize and make it accept BOTH numbers AND percentages (Just like the align property, which accepts both things). This will save us one property, and having to explain what happens when you set linesize and linerelsize at the same time.
Same thing with linegap and linerelgap.

  • Relationship between linesize, linerelsize and linefill must be clarified. What happens exactly when you supply more than one?

First thing none of these value can be less than the calculated line size (height)

Hmmmm... sorry but I can set linerelsize to things below 100% and it works.

linesize : user can specify line size in pixel, this is ideal when we are dealing with pixels (for example movie subtitle on video)
linerelsize : user can specify line size depending on calcualted size, this is ideal for Editor application where you can increase distances between lines for better reading.
linefill : user can specify line size depending on canvas size, this is ideal when you want to show a specific amount of lines in the canvas.

I knooooooooooooooow (dude, I just wrote the docs for these properties, what makes you think I do not understand them?). I repeat: What happens exactly when you supply more than one?
What we need to explain is what will happen when the user sets the 3 properties simultaneously. Of course we can answer "undefined behavior" but saying "the smaller value is used" or "the biggest value is used" is much better.

  • Some words are separated with underscores (like underline_color) whereas some other aren't (like linesize).

prefix and suffext for the line word are writing as one word (underline or linesize).

Neither line nor size are prefixes not suffixes. This property should clearly be called line_size. Same thing with tab_stops, line_rel_size, line_gap, line_rel_gap and line_fill.

  • password and replacement_char could be merged (password mode could be disabled when replacement_char="".

I see it is a little bit confusing when the user enables password but it is not shown because replacment_char is empty, but still making two-property affecting each other values could be more confusing.

How about we set the default value for replacement_char to *? In this way, when the user enables password mode it works immediately, and he can still customize it if he wants to.

  • According to the initial all_styles_get, wrap seems to default to word, but that's not true.

Yes this is a bug/limitation

Can you create a task to fix this issue and add the link here?

  • Wrap cannot be disabled. none is available Efl.Text_Format_Wrap but not in the formatting string ("" does not work).

Yes this is a bug/limitation

Can you create a task to fix this issue and add the link here?

  • linesize can only be set through style_apply but has no equivalent property in Efl.Text_Format.

Yes this is a bug/limitation (linesize,linerelsize,linefill)

Can you create a task to fix this issue and add the link here?

  • Wrap cannot be disabled. none is available Efl.Text_Format_Wrap but not in the formatting string ("" does not work).

Yes this is a bug/limitation

Can you create a task to fix this issue and add the link here?

D10888 will fix this one

segfaultxavi raised the priority of this task from Normal to Showstopper Issues.Jan 8 2020, 8:02 AM

There are still some open issues here. Are there any plans to work on them?
I don't think we can stabilize style_apply() if we don't fix some of these issues.
At least I would like to have the multi-word properties separated with underscores.

ali.alzyod added a comment.EditedJan 8 2020, 9:02 AM

@segfaultxavi properties are :
tab_stops
line_size
line_rel_size
line_gap
line_rel_gap
line_fill

Done in D11043

segfaultxavi updated the task description. (Show Details)Jan 9 2020, 3:09 AM
segfaultxavi updated the task description. (Show Details)Jan 9 2020, 3:17 AM
According to the initial all_styles_get, wrap seems to default to word, but that's not true.

This should be fixed too

segfaultxavi lowered the priority of this task from Showstopper Issues to Normal.Jan 9 2020, 3:19 AM

I think the remaining issues do not affect the API (they are implementation or documentation issues, or the API can be extended later). Therefore I am lowering the priority of this.

According to the initial all_styles_get, wrap seems to default to word, but that's not true.

This should be fixed too

True!

segfaultxavi updated the task description. (Show Details)Jan 9 2020, 3:21 AM
segfaultxavi updated the task description. (Show Details)Jan 9 2020, 7:59 AM
segfaultxavi raised the priority of this task from Normal to Showstopper Issues.

The backing inconsistency is important... raising priority again :)

@segfaultxavi @ali.alzyod

While making a patch for "backing -> background_type", I handled other strings together for new property names (and their new definitions).
Could you check if D11064 meets the purpose properly ?

segfaultxavi updated the task description. (Show Details)Jan 17 2020, 7:31 AM

@woohyun @segfaultxavi
since D11064 can take some time to be approved, We did patch with D11188 to update backing color property