A word processor must prioritize resource allocation differently than a typesetting application does (text-in-progress != final copy). Same for why greedy linebreaking algo fits a text editor better than say, Knuth/Plass: computationally expensive niceties bother text editing.
-
-
Why though? To save computational resources for MineSweeper or covert Bitcoin operations? Word Processors generally don't have to do very much.
1 reply 0 retweets 2 likes -
Try editing a >5.000 words paragraph, hyphenation on, kerning on, OT features on, H&J international multi-line paragraph composer on, and get frustrated with sluggish text reflows. Even defaults in InDesign do this trade-off; MS Word prioritizes smooth line wraps just a tad more.
2 replies 0 retweets 1 like -
Replying to @rhythmvs @letterror and
Buffer serialization of text strings is complicated enough already. Word processors (should) do lots of things designers take for granted; resources spent on live grammar checks and markup/syntax parsing cannot be spent on text shaping and kerning table lookups.
1 reply 0 retweets 0 likes -
Should we hold the word processor engineers to a lower standard than the ones who build operating systems, browsers, video, VR, or games? It's about balancing functionality with available resources. I imagine Word could try just a bit harder without much cost.
1 reply 0 retweets 1 like -
No, but engineers are governed by the laws of nature too. Yes, it’s about functionality and UX. Speed of real-time user input is the constraint here: at 120 wpm (≈30k kph), there’s ~8 keystrokes per second. Now go re-compute nice typography every 0.12"…
1 reply 0 retweets 0 likes -
Have you seen some of the games the kids play these days? There is plenty of computing power around on even the most basic devices.
1 reply 0 retweets 2 likes -
Again, it’s not about powerful computers, but about what can be feasibly computed. Video frames are predictable and can be buffered; unknown text input cannot. You can’t compute the unknown.
2 replies 0 retweets 0 likes -
Replying to @rhythmvs @letterror and
Even when word processors are already statistically predicting the unpredictable (as in text completion, which is expensive enough), you should not then also solve >250 possible line wraps for every possible next key, only one of which will be displayed for just a few millisecs.
1 reply 0 retweets 0 likes -
Replying to @rhythmvs @letterror and
(Though I would very much want to be shown wrong, too. It’d be great to have the practically impossible, i.e. real-time WYSIWYG text editing with perfect typesetting.
@raphlinus?)2 replies 0 retweets 0 likes
It's a complicated space. I think increasingly document production is not WYSIWYG because of the diversity of form factors, so this doesn't seem the most important problem to solve right now.
-
-
Replying to @raphlinus @letterror and
Exactly! — I'm excited to eventually see your work on the xi editor come to fruition! I assume that built-in proper text shaping is a difficult core problem to tackle, especially with a view to uncompromising performance.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.