WISH: ellipsization in rich-text

[hiiamboris]

I would like rich-text to support an ellipsize flag in options.

This is limited to western languages and makes less sense for hieroglyphic or languages where grapheme clusters can include whole words or more. But should still be useful for many apps. Common example: text in a table cell, where showing scrollbars would be an overkill.

What to consider here:

1. Text may be bigger than the canvas both horizontally and vertically (it mostly depends on the wrapping mode, but when canvas is too narrow even a single letter may not fit it)

   Ellipsis should indicate both conditions: at the last line to indicate that the text continues below, and at every line's end to indicate that that line itself is trimmed

2. Ellipsized line may have less than 3 chars to be replaced with the ellipsis. Ellipsis itself may be wrapped to a new line.

   Solution is to use the ellipsis codepoint 2026h … as it's only one char.

3. The moment surface becomes slightly smaller than text, last word may overflow to the next line due to word wrapping.

   We to ellipsize that word to bring it back up with as many chars as fit the line together with the ellipsis. The word itself may be smaller than the ellipsis though.

4. Only the displayed text should be ellipsized, not the /text facet..

   Right now I have to make a full copy of the rich-text's /text. I would prefer to avoid that overhead.

   Question then is what should text metrics (like caret-to-offset) report? I lean towards them working with the original text, as if ellipsis did not exist. Though it's likely a non-issue, since ellipsization and editor's caret are mutually exclusive.

5. Rich-text data may alter the font and size of the character slot where ellipsis is inserted.

   While uncommon, this fact invalidates any assumption on the ellipsis width measured separately. Best workaround so far is to remeasure the text size after ellipsization and keep chopping the characters before the ellipsis until we encounter a line-feed.

6. Ellipsis width is not to be relied upon.

   For some reason unknown to me, I can't just measure the ellipsis size and then chop enough letters from the tail of the line to make enough space for that ellipsis to be inserted. First, there's kerning between ellipsis and the word that is not accounted for, but that's small. In practice the only reliable solution I've found so far is to measure the width of a double ellipsis ……. Anything short of that, e.g. ..… or . … is not enough.

Assembled together I expect it to work like this:

• For a single line rather straightforward:

  https://link.storjshare.io/raw/jwtiabvp6myahg3zzf3q5zoii7la/gif/spaces/example-ellipsization-single-nowrap.gif
  

• For a single paragraph with wrapping on:

  https://link.storjshare.io/raw/jwtiabvp6myahg3zzf3q5zoii7la/gif/spaces/example-ellipsization-single-wrap.gif
  

• For multiple paragraphs without wrapping each line is ellipsized independently to indicate its continuation behind the canvas:

  https://link.storjshare.io/raw/jwtiabvp6myahg3zzf3q5zoii7la/gif/spaces/example-ellipsization-multiline-nowrap.gif
  

  The problem currently is that this makes /data spill to the next lines. I will have to copy and alter the data block as well if I'm going to support ellipsization of text with arbitrary colors and fonts. Which is going to slow it down and bloat again considerably, as /data format is not optimized for modification.

• For multiple paragraphs with wrapping, all lines are wrapped anyway, so only the last line gets ellipsized:

  https://link.storjshare.io/raw/jwtiabvp6myahg3zzf3q5zoii7la/gif/spaces/example-ellipsization-multiline-wrap.gif
  

The code that produces the above result can be found here. It's quite big as you may see, and not scalable to hundreds of such ellipsized texts, that's why I think it should be provided by the R/S code in the View module.