All started in the Humans of Julia discord server, when one user was showcasing julia on a mobile device, and one thing that standed out was that the start banner text overflows, ruining the julia logo.
A similar thing happened on a zulip thread: mobile phone with julia. same thing:
it is a minor piece of code, and it does nothing, but visually stands out.
With those two things in mind, i decided to take the code on Base/version.jl and modify it, by adding some text overflow so that the logo isn’t altered, and remade the logo in braille unicode. The result of that is GitHub - longemen3000/BetterBanner.jl: trying to improve the julia banner , a package (not registered) to add a new Base.banner() function. those are the results:
I was asked to post this package here, so here we are.
I think we should think about potentially changing the built-in Base.banner() to use this new banner.
One possible complication would be if we change the format of the sparse matrix Braille plots in the future, which in theory could potentially cause the banner to break.
at least, even with the current banner, making so that the current text doesn’t overflow over the logo is already an improvement over the current function
I don’t think that’s too much of a problem - in contrast to a sparse matrix, the dots themselves don’t contain too much visual information. It’s the shape they make that’s special. Looking at the image above, if all dots were replaced by a single block character (the default fallback when no font in the display stack provides a glyph for the given character), only the a would become a uniform blob. All other large characters seem to already have a character of spacing between them and would mostly stay readable.
In the worst case, at least the overflow protection should be upstreamed, as I don’t think it depends on the dots specifically, only on the rendered textwidth.
Yeah, it might be easier to upstream this in two separate PRs. One PR for the overflow protection, and a second PR for the Unicode Braille dots.
Is there a way that we can detect whether the user’s terminal supports Unicode, and fall back to the ASCII version of the Julia logo of the terminal doesn’t support Unicode?
It’s not generally a question of whether the terminal alone supports unicode. It’s dependent on what font gets chosen when a user tries to render a unicode glyph. There are at least two points where this can go wrong:
The terminal doesn’t support unicode encoding and thus tries to render the data with the wrong encoding table
The terminal does support unicode, but there’s no font installed supporting the requested character
Both of these are really hard to detect from the perspective of a running program, as there’s no API for how something gets actually rendered on the screen. The former is arguably worse, since the terminal says “oh yeah I know what this is” and completely misses the mark. Look up mojibake for a (depending on your definition of) fun little excursion into the horrors of text encoding.
As far as the program is concerned, it sends magic bytes to some distinct process through a pipe and hopes that the receiving end can interpret whatever you sent correctly. There’s no feedback process here - it’s a legacy problem caused by UNIX/DOS saying “just text/bytes are fine, thank you. What do you mean there’s languages other than english?” as well as “who needs rich media anyway? My terminal can’t render that”.
It’s one of the things I really hate about modern (old) computing. If it were up to me, every inter process communication would have to specify which format a message was in.
I think you can live with some visual artifacts if you are using an ASCII only font or terminal. Julia code is documented to be UTF8 by default, so code, docstrings and results will at times look strange as well. I don’t know why one would use such a limited system in 2021, but I’m sure if that’s the decision you make you don’t mind that the banner is garbled.
