| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Not exercised anywhere except in the shell. I ran into it after running:
(print screen 34)
Introduced in commit d2f96cb0b6c5 on Sep 1. This is the sort of thing I
currently don't know how to write tests for :/
|
| |
|
|
| |
Fake screens can't handle them yet.
|
| |
|
|
|
|
|
| |
There's a new example app showing this ability.
Still to go: support for combining characters when rendering text and
streams.
|
| |
|
|
|
|
|
|
|
|
|
| |
https://en.wikipedia.org/wiki/Combining_character
The plan: just draw the combining character in the same space as the
previous character. This will almost certainly not work for some Unicode
blocks (tibetan?)
This commit only changes the data/memory/disk model to make some space.
As always in Mu, we avoid bit-mask tricks even if that wastes memory.
|
| |
|
|
|
|
|
|
| |
Yet another gnarly reason to start checking all arg metadata in
linux/pack.subx or something like that. With this bug most of my
programs (including browser-slack!) were working even though the
instruction stream was almost certainly misdecoded halfway through every
attempt to draw glyphs.
|
| |
|
|
| |
Open question fixed.
|
|
|
Unix text-mode terminals transparently support utf-8 these days, and so
I treat utf-8 sequences (which I call graphemes in Mu) as fundamental.
I then blindly carried over this state of affairs to bare-metal Mu,
where it makes no sense. If you don't have a terminal handling
font-rendering for you, fonts are most often indexed by code points and
not utf-8 sequences.
|