Hacker News Reader

Comment by samwillis | Hacker News Reader

If text rendering hates you, an editable text renderer is 10x worse.

Anyone who has spent any time working on contenteditable or any of the browser based rich text editors knows what a nightmare it is. The temptation to abandon all hope and start from scratch with a canvas element and build you own renderer and editor is strong. You start researching how to do it, maybe even create a quick prototype but quickly discover all the edge cases in this article and more.

People who have spent significant parts of their career fixing all the inconsistencies between browsers and devices such as Marijn Haverbeke with ProseMirror (and CodeMirror) should get a Gallantry award for the work they have done.

View on HN

https://lord.io/text-editing-hates-you-too/

Generally speaking, implementing this stuff from scratch is a terrible idea; especially on the web, it’s not possible to implement this stuff from scratch without losing platform functionality that is not exposed—though in the last couple of years the primitives have reached the point in functionality and consistency where you can get surprisingly close on most platforms. But things like touch grippies can’t be done, and I wouldn’t be surprised if various fancier touch keyboard interactions like swiping space bar to move the caret can’t be done (I haven’t tried, and I’m not sure how they’re implemented).

Things like CodeMirror are generally good, but it’s still not terribly uncommon for them to be completely broken on some less common but still up to spec and maintained platforms, because they’re simply being too clever for the web as a platform and I wish they’d relax and stop trying to be quite so clever.

It makes me marvel at Google's engineering since they re-built Docs from scratch using canvas.

Exactly, the new Google Docs is a great example of how it can can be done, but only by a company with the resources they have.

I have wandered if the solution is to use WASM to take a desktop rich text editor and make it available in the browser within a Canvas element.

Yeah I'm really interested in seeing something like that, for general purpose. I'd love to see what's possible with WASM + WebGPU for stuff like this.

No, new Google Docs sucks

For one, extensions that help with translation no longer function because there is no text for them to read.

For two, any language that uses an IME (Chinese, Japanese, Korean, Thai, etcc...) the experience is super subpar

Yes, and Flutter, the web version, also does it from scratch. Which means CJK sucks on Flutter

Marijn is a wizard and ProseMirror is an incredible piece of software, but Marijn isn't dealing with text rendering issues. I'm obviously oversimplifying but here goes: ProseMirror is a wrapper over contenteditable and gives us all the control we need. However, it's still the contenteditable that takes care of text rendering and cursor selections.

The real people dealing with those issues are folks working on Zoho Writer or Google Docs - who ship their own text layout engine as part of their rich text editor :)

If there's an open source initiative that wraps over ProseMirror but renders to their own layout engine - that would be a one kickass project!

In 2004 or thereabouts we were building custom in-house CMS and wanted to make easy to use wysiwyg editor with just a select features: bold, italic, links, images, headings. I mean, how hard can it be, right? Oh boy. After much developing and cursing we just defaulted to TinyMCE or whatever it was at that time. 1/10, would not try again.

And it is still pretty much the same in 2022.

FCKEditor was a bit cleaner, IMO. But only marginally.

Also, there was ‘WYMeditor’, which displayed the semantic structure of text instead of a WYSIWYG rendition—so I kept meaning to try it out some time, but never got around to it in earnest. Textile and Markdown took hold before I again had a need for a complex editor, which is probably for the better.

(Now, if we convince all the ‘whitepaper’¹ authors that their incredibly complex layout of ‘a wall of text and occasional pictures’ doesn't require PDF and that I don't have a 14" portrait-oriented screen—that would be great.)

(¹ as opposed to greenpaper, I guess.)

I wish we could've used Textile back then, I used it for my personal blog, but it was no go since the users were Word-people who literally made html pages with Word and tried to upload those to CMS. Oh, that brings back memories... Trying to clean up a mess that resulted from users pasting rich content from Word to our content editor and then wondering why it broke their site from certain point onwards.

Ah, that was a dark time for WYSIWYG editing on the web. I actually made my own back in that era [0] (well a little later, but when TinyMCE and CKEditor were still the goto solutions), and getting it to work cross-browser when IE6 was still a thing and had no dev tools was an absolute nightmare.

[0]: https://github.com/nicoburns/ghostedit

I'm currently trying to get text layout working in a game and the /only/ text control provided by the engine is one that "can" be editable, since it's assumed for non-editable text you'd just use graphics. However, this game has a lot of dialogue and must be translated into multiple languages so that's not a realistic option.

It's a fucking nightmare. It turns out it uses Cairo internally so that's not bad, but I /need/ to know where the last glyph is and answering questions about how your text actually is going to be laid out in the end is next to impossible everywhere I look.

Since, again, this has to work in multiple languages including CJK I am loathe to code my own text control but I may have to.

Have you looked into harfbuzz? afaik it's designed to solve that problem, for all languages.

https://harfbuzz.github.io/

I'll keep it in mind, but right now I'm trying to only use the classes that are provided by the engine or my own code as much as possible, since adding a dependency becomes a whole /thing/ in cross-platform game engines sometimes.

Check out slug if you haven't already: https://sluglibrary.com/

Not sure if your game has any spatial 3D consideration but this project uses real time Multi-channel signed distance field generation :

[1] https://github.com/Chlumsky/msdfgen

It's pain all the way down على طول الطريق uʍop ʎɐʍ ǝɥʇ llɐ

Maybe it's just on my side but the l's in the flipped "all" seem to be either displayed upright or not at the correct height. Which would only support the linked article.

For extra pain, you can go at the text above with your browser's devtools and change the font-family to something funny like Comic Sans MS.

Turns out text rendering _really_ does hate you.

The flipped text is doing a trick where you pick things from Unicode that merely look like upside down Latin letters. Some of them deliberately are exactly that for whatever reason, some aren't. So the effect isn't exactly perfect and shouldn't be. There isn't actually a plain text way to say "for some reason render this upside down" because like, why.

Alright, makes sense. Regarding the "why", well, Unicode has a lot of weirdness already. Like the subscript/superscript characters that don't cover any complete alphabet. And after seeing various tricks like t̢̬̯̮̥͋͒̔̾̽͘͟ḥ̛̙̟͍̦͉͔̤̝͔̪̮̳̠̩̗͔͕̽̐̏͟͢i̔̊̃̌̆͋ͫ̏̽ͧͪ̂҉̺͚̺̤̳̥̰̬̻̜͈̦̰͙̲͘ͅs̢̓̾̎̃͛ͧͪͬͨ̍͂ͩ̅̑̎͌̚̚͏̗̙͚͉͢ not much surprises me anymore.

Unicode's goals include subsuming all prior existing text encodings. That means ASCII and ISO-8859-1 of course, but also really obscure encodings that maybe only were ever used on a handful of machines. The idea is if your project isn't using Unicode, the reason shouldn't ever be "Oh we need this obscure character - we use it for compatibility with our 1978 Huge Corp X42 mainframe but it isn't in Unicode".

This is often the reason why character X is in Unicode but seemingly equally useful character Y isn't. At some point somebody put X in an encoding on some archaic hardware you've never seen, but not Y. In this sort of case neither X nor Y are things you should emit if you don't need them, but they're in Unicode in case somebody finds a pile of Huge Corp X42 tapes and wants to convert that to Unicode.

In cases where both X and Y, and even the more obscure Z are encoded, chances are Unicode has them all because humans (not just some obscure computer hardware from the dark ages) used X, Y and Z to write stuff, and another Unicode goal is to be able to encode all human writing systems. The over-abundance of combining forms you abused on your word "this" is almost all for that reason.

Those are actually just regular l's, and the "upside down n" is just a regular "u". The more interesting letters are from the Unicode IPA Extensions range: https://unicode-table.com/en/blocks/ipa-extensions/

Yeah CodeMirror is good. I highly respect Marijn's endurance to work on something like that and have it come out so slick.

My most recent war story here is trying to work around the text cursor and selection indicator bug on iOS Safari/WebKit. They are displayed in front of all other elements on the page, even when outside of a scroll areas overflow, super annoying for heybred web apps.

So I decided to implement my own cursor and text selection. Cursor was ok, just make it transparent and replace it with an element drawn in the correct position.

Text selection on the other hand… it seemed ok at first within a paragraph but the minute you span between blocks, columns or are in tables, oh dear… and that’s before I got to RTL text.

Gave up in the end.

Reply on news.ycombinator.com