5 ms·
While spending a lot of time with monospace fonts and mostly ASCII characters (programming and writing, terminal emulators, IRC/mail/MUDs/feeds in Emacs) and wo
by defanor 7y ago
While spending a lot of time with monospace fonts and mostly ASCII characters (programming and writing, terminal emulators, IRC/mail/MUDs/feeds in Emacs) and working on a hobby project involving text rendering and selection (with potentially proportional fonts and Unicode), I keep wondering whether it's even worth all the trouble.
In addition to what's mentioned in those articles, on larger documents rendering speed also matters; word cache (in addition to mentioned glyph cache) helps somewhat, but complicates other things even further, and calculating total document height (for scrolling) still requires to calculate all the positions, wrap the lines, etc, which in turn requires to render all the text first. Perhaps one can introduce yet another mechanism to only estimate that at first, and then elaborate the estimation in background, but that's yet another opportunity for bugs to creep in (and additional complication, of course). On the contrast, the programs that just use character grids (and perhaps don't handle bidirectional texts well) can be both faster and simpler, while still are quite capable of rendering texts, even with various styles/decorations and occasional images, in many languages.
There seems to be plenty of accidental complexity even in handwriting, but once it is used for computing and text manipulations are involved, the task appears to be much harder than it has to be.
- kccqzy 7y agoHave fun in your anglocentric world then. I don't think you have sympathy towards users for whom monospaced fonts do not work for their language, ASCII can't encode all the code points in their language. Rendering speed hasn't mattered since years ago. Browsers can render megabytes of pure text (hours of reading material) in seconds. LaTeX can typeset hundreds of pages in seconds.
- defanor 7y ago> I don't think you have sympathy towards users for whom monospaced fonts do not work for their language, I do, that's one of the reasons I'm trying to handle Unicode and proportional fonts in the first place. Given the circumstances, it is indeed preferable to do so, but given that it's basically encoding of approximated sounds (well, potentially information in general) on a 2D plane, it is a rather complicated (both code-wise and computations-wise) way to achieve such a task. > Rendering speed hasn't mattered since years ago. Browsers can render megabytes of pure text (hours of reading material) in seconds. Chrome only started using "complex path" for English texts a few years ago, employing mentioned word cache. Rendering megabytes of text in seconds is indeed achievable (especially if the words are cached, and it's not megabytes of integer sequences), but still complicates the rendering, and still slower than to open and navigate through the same megabytes of text in, say, less or vim, or even links -g. It's not an issue if you don't have to do it (or to use a program where it wasn't optimized well), but if you do, it is. Edit: added a reply to the second part.
- walterstucco 7y ago> I don't think you have sympathy towards users for whom monospaced fonts do not work for their language, I don't think he meant what you think. We could use ancient Egypt hieroglyphs to communicate, but in the end they are just a collection of symbols to mean sounds, so maybe a universal phonetic alphabet could alleviate the process of writing on electronic devices. this https://i.imgur.com/Xv7VIMN.png https://i.imgur.com/Xv7VIMN.png is ḫprj, which is kephri, which is kɛˈfrI the scarab-faced god. It would also avoid many of the ambiguities, for example this https://i.imgur.com/sdJBIuu.png https://i.imgur.com/sdJBIuu.png is wsjr, which is Osiris, pronounced oʊˈsaɪrɪs They both end with https://en.wikipedia.org/w/extensions/wikihiero/img/hiero_A40.png https://en.wikipedia.org/w/extensions/wikihiero/img/hiero_A4... which has a slightly different meaning in the two compositions, it reads differently but it's the same symbol
- pcr910303 7y ago> While spending a lot of time with monospace fonts and mostly ASCII characters (programming and writing, terminal emulators, IRC/mail/MUDs/feeds in Emacs) and working on a hobby project involving text rendering and selection (with potentially proportional fonts and Unicode), I keep wondering whether it's even worth all the trouble. Yeah... and that's why FireFox & Eclipse still doesn't get CJK character input right. The percentage of people that must use characters not included in ASCII is much bigger than people who do. It is worth the trouble, please consider users outside of the US & England.
- j-pb 7y agoI think it would have been better to have every body just learn english as their second (computer usage) language. I'm german and my english was horrible until I switches my computer and my websites to english ones. Imagine a world where everybody speaks at least one common tongue, we could have so much more peace and understanding. English becoming the esperanto of the world is an accident but I don't care which language it is, as long as it has less than 255 letters. (Hawaiian would have fit into a nibble which is cool)
- defanor 7y agoWhile it sounds nice to me too (and neither am I a native English speaker), apparently there was a bit of misunderstanding in another comment, and possibly here too: I rather wonder about a hypothetical more efficient (and computing-oriented) writing system, not just/necessarily/only using monospace latin characters. It doesn't seem very realistic that something like that would happen (judging by the mess that are date formats and units of measurement, which seem much easier to fix), but observing the complexity that doesn't come from fundamental constraints, it's hard to not wonder about that.
- j-pb 7y agoHawaiian has 16 Characters, Hangul was designed to be easy to learn, Lojban is based on Predicate logic. What they all lack is reach, and thats the most important feature when it comes to a common tongue. (That and having a phonetical system ^^')
- be5invis 7y agoThe story about line wrapping is mainly that, you: · Break the text into runs. · Calculate BiDi at paragraph level. · Shape every run to get its length and possible line breaking points. · Arrange the runs (now only have length, height, text isnide it and some breaking properties — glyphs and glyph positions are dropped) into lines. Such process is called “measuring”. And the real text display is delayed until a line become visible: you fetch out the text runs in the line and do the real display. In most times (like appending text) you do not to do much recalculation.