Fix/line breaking

[dnmeid]

There seem to be various issues with the line breaking and shrinking and text handling that have accumulated over many versions or are fresh.
Related issues: #3671, #4305, #4343, #4359, #4372,
I'm trying to get this straight asap.

Some of the bugs seem to be there for quite a while so the question is if this is now still a fix or a change. I guess some presets and styles had been created with the last breaking behavior. I don't know if it is better to say: "now the old stuff works again as expected and you in-between guys are out of luck" or "the existing bug is now the new normal and the old stuff has been broken so long that it doesn't matter anymore".
Overall it should affect only some rather seldom cases.

• Line breaking will now again first shrink and only break inside a word if there is no shrinking option any more. This will affect a lot of dynamic text in a positive way but should not affect presets or styles that have been carefully tweeked. (actually that was bugging me for quite a while and I'm so happy to fix this)

• Second difference is the alignment when the test overflows the space. Since quite a while it seems that in case of overflow always the beginning of the text was fitted into the available space and then aligned. This now changes it back to the original concept that also uses the bottom lines or the center lines for bottom or center alignment. I think both variations are not 100% great, the last behavior was maybe 50% nice and the original behavior 60% nice. Given that this shouldn't be a feature that people use on purpose, I think it is acceptable to go back to the original behavior and maybe even improve this a little in the future (not part of the fix).

• Line height measurement is rather exact and line height of 100% still gives no visual shift when alignment changes

• unicode chars are now again preserved when breaking a line

• some unicode chars are not rendered

• style preview and button rendering are using different emoji fonts

• line height is still fixed to 1.0 and not 1.1 like originally. I think this change is quite old too and we should keep it for now and make this a configurable property eventually

• a lot of tests are failing now because my cheapo free AI wasn't able to fix them in acceptable time. Also some tests are looking useless to me, had they been checked in deph?

Unfortunately I have based that branch on main. I don't know if it is easy to merge into 5.0 stable

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3f74937e-28bc-4919-b36c-d7766d584eb4

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[dnmeid]

Ok, here is the current pitfall:
For Color emojis we are using basically Noto Color Emoji font, but not the original version provided by Google because it is not compatible with webkit. Instead we are using a version that has been designed as a replacement for the Apple emoji font. This one is compatible with webkit and as far as we know also with chromium but not gecko. It has some more quirks:

• it is using bitmaps (sbix format), that are quite large, don't look nice and scale poorly
• it is overall quite heavy with 40MB
• it is somehow working on Chrome but not recommended
• major quirk: as a replacement for Apple emoji it uses the same typographic measurements as Apple emoji and this leads to a vertical offset of the glyphs (known from [BUG] Unicode "glyphs" not rendering correctly in 4.0.0 #3351) and also a smaller size than Noto

So what are the options?

• Continue using this font: vertical offset of glyphs, no color emoji preview on firefox
• Adjust the font metrics in the font (my font editor can do that but not export the sbix layers properly): still no preview on firefox
• Generate our own sbix font derived from the official Noto color emoji: will have correct position but breaks sizing as the glyphs are larger and still no preview on firefox
• Generate our own sbix font derived from the official Noto and reduce size: will have correct position and roughly the same glyph size as today but still bad look and big filesize and still no preview on firefox
• Use official Noto: will give best visual quality at chromium and gecko at smaller filesize, but no preview rendering of color emojis in Safari, glyph position is good but glyph size is larger than today
• Use adjusted Noto: will give best visual quality at chromium and gecko at smaller filesize, but no preview rendering of color emojis in Safari, glyph position is good and glyph size is similar to today
• Use different fonts for different engines: everything can work but not a quick fix

Additionally I have to mention that even if we use Noto in the COLR1 version for chromium and gecko, there will be slightly differences because different versions of chromium support different font features and e.g. our skia-canvas does not support black and white variation codes but the chrome browser does (#3671)

What to do?

[Julusian]

Some of the bugs seem to be there for quite a while so the question is if this is now still a fix or a change. I guess some presets and styles had been created with the last breaking behavior.

yeah im not sure. Cosnidering its 3 weeks after 5.0.0, and 17% of users have upgraded, our aim should be to match 4.3. But changing anything now does worry me about user frustration, but leaving it to 5.1 to fix things that broke in 5.0 will be just as frustrating. So I dont know what is best, other than asap if theyre going to be in 5.0

Since quite a while it seems that in case of overflow always the beginning of the text was fitted into the available space and then aligned.

Did I break this when optimising the parsing so that it wouldnt try and chunk a 10_000 character long string into 1000s or lines, to then only draw 3 of them?

Also, if top and middle align show the first lines, should bottom align show the last or first lines?

Unfortunately I have based that branch on main. I don't know if it is easy to merge into 5.0 stable

Probably is (cherry pick once merged). Thats how I've been applying things, and this area should still match almost identically.

Use different fonts for different engines:

This is appealing to me. If we can have chrome and the backend working well and the same for 5.0 then I think that is good enough for today, getting other browsers to work can be the next patch or 5.1

Also some tests are looking useless to me, had they been checked in deph?

Yeah a lot of the tests I have mostly left to claude. The ones I have read looked fine, but I havent read all of it (way too time consuming and tedious) and figured that its better than not having any tests.

[dnmeid]

Use different fonts for different engines

This is appealing to me. If we can have chrome and the backend working well and the same for 5.0 then I think that is good enough for today

Ok, I'll go ahead with providing a current but size-adjusted font that works for all but Safari. We'll leave this broken for Safari and see what happens.

Also, if top and middle align show the first lines, should bottom align show the last or first lines?

I did fix this in the first round, but now have decided to stay with the behaviour of 4.3. It seems that it is like that for a long time and maybe the change was intentional. At least I found it a little bit irritating because our default alignment is center/center that the shown part of the text was changing and it is not easy to understand what part is shown.

So the font and test updates will be the last part of this fix.

[dnmeid]

After thinking about this now for a day and some experimentation, I have a slightly different pitch:
The color emoji font is super hard to adjust because of the different color layers and their incompatibilities but is provided quite well. It is from the Noto font-family and we are using a lot of Noto fonts because they have a super complete range of glyphs for all script systems. The notably exception is plain latin text where we use Arimo because it is much more compact and has a good readability at the small sizes we are usually dealing with.

We now have a Monospaced font (also Noto) and maybe want to support more fonts in the future. Actually it would be best to not tweak the fonts, but tweak the rendering in the canvas at a font based level. Unfortunately this is not easy to do and also questionable if we should do it for a tool like Companion where typography is not the top priority. Anyhow different fonts should match when used in the same line.

So my current go is to adjust the Arimo font to match all of the other used Noto fonts. That way we always can add and update Noto without tweaking and Arimo should stay quite fixed. To compensate for the wider lines of Noto, I'll introduce a factor that reduces the resulting metrics to the current metrics of Arimo (roughly 0.85). We'll call that our new line height 1.0.
As I have written earlier, to get back the line height from our early versions, we'd need 1.1 and for roughly the original line height of Noto 1.2.

I think that fits nicely in the future strategy, fixes some existing font problems and doesn't break too much.
This will in deed lead to all the Noto fonts being rendered ~6% smaller than today. For Users of the non-latin fonts this could mean a different word wrap of their texts, but they won't loose visible text.

[dnmeid]

Always when you think, you're done...

Actually finished with my list with the now new known issue of problematic emoji rendering in preview renderer in WebKit browsers.

Another little thing I noticed but am willing to ignore for now: The preview now shows a tiny bit of shift when changing the alignment of 100% text. The canvas in core does not. I assume some rounding errors.

Not to ignore: The text shrinking doesn't work smooth when the maximum text size is close to 100% but not exactly 100%.

[dnmeid]

Getting close, now a bug seems to have (re-)appeared that the browser canvas works different than the node canvas.