Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unscii – a bitmapped Unicode font for blocky graphics

pelulamu.net

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Unscii – a bitmapped Unicode font for blocky graphics

#11

Post by Klover »

lubujackson wrote: post #5

It's a little confusing, but my read is that this is a generalized set of old font characters that were used for graphics (like code 437) plus a bunch of unicode symbols that are also useful for graphics. With the idea being you could make much more intricate art from this font set. I think the more interesting idea would be to use it to encode movies similar to how ASCII animations work - I wonder how compressed and…

Nice approach! Unless I missed something you’d still be having very few colours, a limited resolution, comparatively poor performance to an OpenGL rendered DRM output (as in, also a command line environment), and if you simply use deflate or zstd for your compression you’ll have none of the streaming benefits of h264 or newer. I like your idea though.

Re: Unscii – a bitmapped Unicode font for blocky graphics

#13

Post by kyberias »

It's a bit unclear why this exists. It seems to combine glyphs from 8-bit computers and place them in Unicode space even though the standard doesn't define many of them.

I guess the reason is to be able to combine them in some "art".

Perhaps those missing code points could be added by the Consortium based on this feedback.

Re: Unscii – a bitmapped Unicode font for blocky graphics

#14

Post by dancek »

Wow, pelulamu.net still exists! I remember a friend talking about it about 20 years ago, i.e. when we were in school.

The font looks nice and is probably strictly an improvement over most terminal fonts of the same size. I just wish they had a 24 or even 32px size for the hidpi displays we have these days. I wonder if it's easy to run a linux console font in double size.

Re: Unscii – a bitmapped Unicode font for blocky graphics

#15

Post by kristopolous »

I had an adjacent project about 6 years ago which included a Unicode drawing program, text engine and image converter (https://github.com/kristopolous/unifig) ... I think the mirror I have at http://9ol.es/blocky/ is still functional. Edit, no it's not... I can bring it up to functional if people request.

I spent a decent amount of time on it, nobody paid any attention though. Oh well, not everything's a winner.

Re: Unscii – a bitmapped Unicode font for blocky graphics

#17

Post by djmips »

kristopolous wrote: post #15

I had an adjacent project about 6 years ago which included a Unicode drawing program, text engine and image converter ( https://github.com/kristopolous/unifig ) ... I think the mirror I have at http://9ol.es/blocky/ is still functional. Edit, no it's not... I can bring it up to functional if people request. I spent a decent amount of time on it, nobody paid any attention though. Oh well, not everything's a winner.

Hey, I think it's cool. Would like to try.

Re: Unscii – a bitmapped Unicode font for blocky graphics

#18

Post by yesenadam »

thristian wrote: post #6
fireattack wrote: post #3

What does "Unicode" mean in "Unicode font"? From what I can see it only has a handful (ascii?) characters. Edit: after some testing it seems that "unscii-16-full" is the one (and only one?) that supports some Chinese characters, but it's unusable because glyphs stack on each other.. (screenshot: https://files.catbox.moe/262742.png )

It means that it supports characters outside the basic 127 ASCII or 256 ISO-8859-1 characters, like the Box Drawing[1] and Block Elements[2] characters defined in Unicode. [1]: https://en.wikipedia.org/wiki/Box_Drawing [2]: https://en.wikipedia.org/wiki/Box_Drawing

[2] https://en.wikipedia.org/wiki/Block_Elements

Re: Unscii – a bitmapped Unicode font for blocky graphics

#20

Post by Sharlin »

kyberias wrote: post #13

It's a bit unclear why this exists. It seems to combine glyphs from 8-bit computers and place them in Unicode space even though the standard doesn't define many of them. I guess the reason is to be able to combine them in some "art". Perhaps those missing code points could be added by the Consortium based on this feedback.

> some ”art”

Eh, text art is a venerable art form as old as teletypes.

Post reply on HN