Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate writing core unicode glyphs into console font space #201

Closed
dankamongmen opened this issue Dec 23, 2019 · 9 comments
Closed
Assignees
Labels
enhancement New feature or request question/research Further information is requested
Projects
Milestone

Comments

@dankamongmen
Copy link
Owner

The Linux console appears to allow pretty much arbitrary glyph replacement using the PIO_FONT and PIO_FONTX ioctl(2)s. If so, can we perhaps hijack this space to load those Unicode glyphs we rely on internally? This would include:

  • box drawing characters
  • braille patterns
  • block glyphs

I'm pretty sure we can load these up; the thing that concerns me more is whether we're going to piss off users by doing so. Requires investigation.

@dankamongmen dankamongmen added enhancement New feature or request question/research Further information is requested labels Dec 23, 2019
@dankamongmen dankamongmen added this to Low priority in realtext Feb 21, 2020
@dankamongmen dankamongmen self-assigned this Feb 21, 2020
@dankamongmen
Copy link
Owner Author

Much to my surprise today, I verified that PIO_FONT and friends (see console_ioctl(4)) is available to unprivileged processes, at least on my Debian workstation. So it seems this is wholly doable, hot shit.

@dankamongmen dankamongmen added this to the 1.5.0 milestone May 19, 2020
@dankamongmen
Copy link
Owner Author

I think we ought prioritize this. Right now we look like garbage on the console, arguably worse than straight ncurses apps. Some rounded box drawing, the two half block characters, and the grid characters could really improve things (we'd quickly become the best-looking thing on the console IMHO). Let's aim for 1.5.0.

@dankamongmen
Copy link
Owner Author

While we ought provide a notcurses_options flag to disable reprogramming of the console font (should we? I want to be able to depend on some of these glyphs), we can I think dump the actual content of the font at runtime, and thus preserve elements of it. I think that's a solution that would keep most complaints at bay.

@dankamongmen dankamongmen removed this from the 1.5.0 milestone Jun 2, 2020
@dankamongmen dankamongmen added this to the 1.6.0 milestone Jun 15, 2020
@dankamongmen dankamongmen modified the milestones: 1.6.0, 1.7.0 Jun 30, 2020
@dankamongmen
Copy link
Owner Author

Initial results using the linuxconjammer PoC are extremely positive!

@dankamongmen
Copy link
Owner Author

Ok, using linuxconjammer I can extract the font details, including height and glyph, and also the UTF16->fontindex mapping. I first shim an upper and lower half block into the font glyphs -- we can do this much more intelligently; I'm just shoving them in the back -- and then I search the UTF16 map for the upper and lower half blocks. If I do not find them, I add entries to the rewritten font glyphs. If I find them and they're pointing to different font entries, I rewrite them. This change is persistent across processes within the virtual console (it does not affect other virtual consoles). If I then run notcurses-view or anything else, the half block blitter works as expected (except still with very few colors :().

This is never going to look great due to the restricted number of colors (though once we're reprogramming the palette on the fly, watch out!). But it's a definite improvement. If we shim in the glyphs necessary for the quadblitter, that will help even more (since we use quadblitter in a lot of places). Though perhaps we ought instead look for the necessary quadblitter glyphs, and make the NCBLIT_DEFAULT interpretation dependent on their presence (especially since we'd definitely need to take this into account for NCBLIT_BRAILLE...

anyway, consider this whole idea proven out in concept!

@dankamongmen
Copy link
Owner Author

When we do this, make sure we take any UTF16 values previously mapped to the font indexes we blow away, and delete them, since they ought now fall back to the default glyph.

@dankamongmen
Copy link
Owner Author

console-after

dankamongmen added a commit that referenced this issue Jul 13, 2020
dankamongmen added a commit that referenced this issue Jul 13, 2020
* use ioctl(KDGETMODE) to detect Linux console
* diagnostic on KDGETMODE
* add logdebug()
* unit test for notcurses_drop_planes(), add ncplane_putnstr_aligned()
* linuxconsole PoC
* linuxconsole: dump unicode->font table
* linuxconsole: explode glyphs
* linuxconsole: show 7 glyphs per 'line'
* linuxconjammer: shim console font with half blocks
* signals: handler for SIGTERM
* man pages: update notcurses_init() for options
* add NCOPTION_NO_FONT_CHANGES #201
@dankamongmen
Copy link
Owner Author

We're now adding unicode mappings for the vast majority of box-drawing characters, and it's working perfectly. Our boxes and lines now look proper in the console. Huzzah!

dankamongmen added a commit that referenced this issue Jul 13, 2020
…acters (#794)

Part 1 of a two-part revolution in Linux console graphics. Map all the line-drawing Unicode characters to similar glyphs. This means all our nice corners freely translate into rigid corners etc in the console, rather than hateful default characters (usually black diamonds). The demo and all widgets now look correct when drawing lines and boxes. Next, we'll add the actual glyphs for the block-drawing characters, and we'll have the finest graphics ever seen on a text-mode Linux console. #201
@dankamongmen
Copy link
Owner Author

OK! We've got full Quadblitter2 power in the fuckin' console now! w000000000000000t! Amazing!

realtext automation moved this from Low priority to Closed Jul 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question/research Further information is requested
Projects
No open projects
realtext
  
Closed
Development

No branches or pull requests

1 participant