5 ms·
Instead of trying to hack drawings into plain text, why not add enough Unicode drawing symbols to create functional, basic line drawing using just Unicode symbo
by wolverine876 4y ago
Instead of trying to hack drawings into plain text, why not add enough Unicode drawing symbols to create functional, basic line drawing using just Unicode symbols. It seems doable:
Currently Unicode's box drawing range (U+2500 - U+257F) [0] has 128 symbols, but the resolution seems much too low and the angles and options too limited. Visually, you get one line segment per 'monospace' (specifically, each visual segment extends from the center of one monospace to the center of an adjoining one), and generally it's straight and only at the four 90 deg angles.
More useful is the Block Elements range (U+2580 - U+259F) [1]. I don't know the intent of it, but it effectively subdivides each character space into 4 cells that could be used like pixels. Due to Unicode's effectively unlimited capacity, we could provide much more powerful:
Simply divide each character space into a grid, as with Block Elements (I think font designers already do this, but don't recall the details well), let's say 12x16 = 192 cells (a somewhat arbitrary number; if that ratio is wrong or there's an existing standard, it can be adjusted). We might need higher resolution: Think of each cell as a pixel: A text character usually is much smaller than 1 inch, but zoomed into 1 inch/character you would have only ~12 dpi. What resolution is needed for basic line drawing?
Displaying a line would require characters to overlay each other, which is built into Unicode and necessary for many languages, though I don't know if there's currently a limit to how many characters can be overlayed. We would need up to 192, or more if we adopt a higher resolution.
We could add lower-resolution symbols for manual drawing - the Block Elements range does something similar - otherwise, manual drawing would be tedious. A solution with 192 cells is designed to be used programmatically. With a little structure, we could organize the code points so that the developer can predict the location of each code point without looking them up, e.g., a predictable offset from the first codepoint.
Also, I wonder if drawing is within Unicode's current scope. The Box Drawing range says [0]: "All of these characters are intended for compatibility with character cell graphic sets in use prior to 1990.". That implies a disinterest in its use or development, though the Block Element range [1] includes no such disclaimer, and scopes and interests can change. Also, are there other Unicode ranges that cover graphics besides the Box Drawing range and Block Element range?
[0] https://www.unicode.org/charts/PDF/U2500.pdf https://www.unicode.org/charts/PDF/U2500.pdf
[1] https://www.unicode.org/charts/PDF/U2580.pdf https://www.unicode.org/charts/PDF/U2580.pdf
- wolverine876 4y agoHey @dang: Why would this comment start about 5 threads down the page, and then drop another few threads within 2 minutes? It's not the end of the world, but maybe there's a bug? It doesn't seem to fit the model of a spammy comment, at least not to my eye. Edit: Oddly, my next comment started at the top, as comments usually do: https://news.ycombinator.com/item?id=31643249 https://news.ycombinator.com/item?id=31643249