optimised rendering for large areas

[derhuerst]

Using breseham for drawing every shape is extremely convenient, but the visual noise is significant. It might be better to render continuous, large surfaces with a background color, e.g. using chalk.

the borders of the area would look different however, so this would require some further investigation.

[rastapasta]

Nice idea which actually was kinda implemented at some point with mixed results (especially the feature-borders as you guessed) - had all water surfaces filled with background colors once with no need for chalk though, as the Canvas and BrailleBuffer already got background color support in them :)

So it would be a matter for the Canvas/Renderer - maybe first step to try around/see how it would look, would be to add the logic to respect the features' background-color style property, which currently is only pulled in for the global background color.

[edit: typo]

[derhuerst]

Also, an approach to improve the visual quality might be to reduce shapes like large roads to a single line.

[verdy-p]

Drawing lines are problematic as it is difficult to connect them with the limited set of plain-text symbols. Using braille patterns is a smart solution, but there are also block characters (including those from the OEM PC charset) which would effectively better to render surfaces (outside lines and text labels)

Finally an option to set the prefered encoding and terminal emulation would be fine for compatiblity (the default telnet client in Windows does not support this Xterm emulation, but supports VT220, restricted to 8-bit charsets, and "ANSI.SYS" emulation for its native console.

For Windows 10 the anternative is to install the optional Ubuntu Bash feature supported by Microsoft. Still it does not render any one of the Braille patterns, probably because of font exclusions (not suitable for monospace rendering) so we also see "?" in square boxes instead of Braille patterns: here also using the symbols in the PC OEM subset would work.

These terminal settings could go to a "c" config key. Also adding the "?" key to show the help screen and some of the current terminal settings (including the terminal size in rows/columns) would be helpful to avoid the irritating text scrolls (use the clear screen terminal command, and make sure you won't use display anything on the last column of the last row).

As well, some labels will cause problems when they are not restricted to basic European alphabets (Latin/Greek/Cyrillic) or some half-width Japanese Kanas/Hangul Jamos, as they are not always rendered with a monospaced fonts (or not rendered at all in some terminals): this includes various Arabic characters. Sinograms and Hangul clusters could work but would be using two columns

[fenwick67]

Just an FYI, I've experimented with using ASCII 220 and 223 half-block characters for raster images here, and have had success on Windows:

https://github.com/fenwick67/term-px

[verdy-p]

Yes but windows terminal supports any characters that are in the following suitable monospaced fonts:

• Terminal (8-bit OEM encoding): supports [▀]2580, [▄]2584, [█]2588, [░]2591, [▒]2592, [▓]2593, [■] 25A0, [▬]25AC
• Courrier New (Unicode), supports [▀]2580, [▄]2584, [█]2588, [▌]258C, [▐]2590, [░]2591, [▒]2592, [▓]2593, [■] 25A0, [▬]25AC
• Consolas (Unicode), supports the same subset as Courier New
• Lucida Console (Unicode), supports the same subset as Courier New
• MS Gothic (Unicode),
• NSimsun (Unicode),
• SimSun-ExtB (Unicode),
• Noto Emoji (Unicode),
• Noto Moto (Unicode),
• and legacy raster fonts for DOS terminals, encoded in legacy 8-bit OEM codepages (multiple versions are installed with distinct resolutions for CGA, EGA, VGA: 6x8, 8x8,16x8, 5x12, 7x12, 8x12, 16x12, 12x16, 10x18).

In summary, we can still improve bitmap emulation with additional symbols [▌]258C, [▐]2590 with vertical subdivisions of the character cell, or [■] 25A0, [▬]25AC for additional horizontal subdivisions of the character cell, or [░]2591, [▒]2592, [▓]2593 for better approximation of pixel patterns.

What is needed is a function that evaluates the rate of error for each candidate character when it is used to approximate a rectangular colorful bitmap, and selecting two representative colors (not the same pairs for dot pattern characters and for block characters), and then having a simple sort to select the best (character,color pairs, error) member to get the actual (character,color pair) to use.

To create such evaluation function, the best is to have a basic monochromatic bitmap data representative of the character, at everage terminal font sizes (ignoring cleartype): typically for 12pt font sizes.

Then that function can be extended to include as well several other box drawing characters also supported in these fonts.

An optional extension would evaluate all candidate characters of the OEM character set (including Latin and Greek letters, digits, punctuation), unless they are disabled to represent something else such as actual text labels for the map.

We may then return two versions of text-rendered bitmaps: one for 8-bit legacy OEM codepage, another for the Unicode codepage. This would result in two terminal emulations:

• ANSI.SYS/OEM for old Windows versions (Win95/98) that don't have any Unicode API and whose terminal output is restricted to display only characters in the current 8-bit codepage,

• ANSI.SYS/Unicode for modern Windows with native Unicode API not needing the unicode emulation layer (WinXP, Vista, WinNT, Win2000, WinServer, Win7, Win8/8.1 and Win10), where the terminal displays any characters (even those outside the current display codepage selected by "CHCP") but its display memory is an array of 16-bit WCHAR instead of an array of 8-bit CHAR.

[verdy-p]

To see what it can give on a Windows terminal, just copy paste this line in the terminal:

[▀]2580, [▄]2584, [█]2588, [▌]258C, [▐]2590, [░]2591, [▒]2592, [▓]2593, [■] 25A0, [▬]25AC

This will convince you that it is possible to offer a better rendering of bitmap images than just using the first 3 characters of this list, and still better than using Braille dot patterns, not supported except if your windows terminal uses one of the two supported Unicode codepages (as set by "CHCP 65000" for the legacy UTF-7 encoding, or "CHCP 65001" for modern UTF-8 encoding)

Note that the Windows terminal used by the "Ubuntu Bash" extension on Windows 10 is set by default to use codepage 650001 (UTF-8), and its default font selected is "Consolas" (you can change this font but cannot change the 65001 codepage used and you cannot start a windows command to run CHCP because all programs in "/mnt/c/Windows/System32" are restricted and not readable/executable under this Linux environment). And in the list of monospaced fonts I have given above and that are recognized as suitable for the Windows terminal, none of them have Braille dot pattern symbols (which are currently only found in fonts that include other characters with variable width, notably for alphabets, but also various other symbols with distinct metrics).

To use Braille patterns in a Windows console, you need to install a separate font (Unicode encoded) containing only them, or containing other alphabetic letters in monospace style (you could include the same subset of characters as the small subset supported by the Terminal Truetype font).

A solution for this is to install a "font server" driver that would allow creating a custom synthetic font, taking its source glyphs from one or more fonts and adjusting their metrics), in order to emulate a real monospace font (without having to create and install any new font, or stealing their glyph data to create a new standard font). Such font server drivers are supported by the Windows API and used notably to support wellknown Adobe softwares, or to support fonts in other formats (such as legacy fonts for Linux text terminals, or the legacy *.FON bitmap fonts for DOS text terminals), or font server drivers that support the new SVG fonts, or legacy X11 fonts, or the many existing PostScript fonts, or legacy PCL fonts used by old HP printers that did not have support for TrueType or PostScript.

[rastapasta]

Thank you for all your wonderful high quality input @verdy-p !

Based on it, i just started to work on a mapping logic for the currently 2x4 sized, bit operation based BrailleBuffer. It will map all possible characters to the most-pixel-overlaying ▀ ▄ █ ▌▐ ▓ ■ ▬ equivalent and will allow an easy implementation without touching too many other parts of the current logic. Let's see how that goes and how we can continue from there ;)

The next logical step would indeed be the automatic terminal type detection and giving the user the choice to switch during runtime.

Thanks again!

[rastapasta]

This looks already so much better than i expected 😮 mapper works, just finishing up -> push ;)

preview:

so vivid!

[derhuerst]

Looks great! More characters available with full Unicode: ◢, ◣ , ◤ , ◥.

[rastapasta]

You can try it on the ascii branch - algorithm needs tweaking. Tried to use the full available set of block characters, but couldn't get it rendered nicely. Commented all but ▀▄■█ , give it a try for yourself!

Switching rendering modes is bound to the c key (flips config.useBraille when pressed)

[rastapasta]

made the algorithm smooth and working well, merged to master! currently used charset is for now:

[▀]2580, [▄]2584, [█]2588, [▌]258C, [▐]2590, [■] 25A0

[verdy-p]

Yes but not within Windows (even with Ubuntu Bash, which still uses the Windows console even it it is using Unicode, i.e. codepage 65001=UTF-8) with its supported fonts (I gave a basic list) that *must* be monospaced, otherwise they are not selectable in the terminal. This means that all characters in the font must have the same metrics. May be there are other suitable fonts that may be installable on Windows to support more symbols. But the list of block characters supported are working on all platforms (Windows/Linux/MacOS/Android) because they are part of widely used legacy charsets, and because the terminal fonts for Windows have served as a minimum base subset to support in many other fonts. It would be interesting to develop an opensource monospace font (mapped with Unicode) for extending bitmap image emulations: it would be installable on Windows, Linux, Unix, MacOS. I gave the name of the high quality font from the Google Noto font set. I could have also named the monospaced font made by Michael Everson (wellknown member of Unicode) that supports many symbols as well: I've not checked if they would support more block graphics. 2017-05-12 19:54 GMT+02:00 Jannis Redmann <notifications@github.com>:

…

Looks great! More characters available with full Unicode: ◢, ◣, ◤, ◥ <http://www.fileformat.info/info/unicode/block/geometric_shapes/list.htm>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUqG4QFV_YgBxuEKRv-2vb5_mSOO33Bks5r5JzzgaJpZM4NJOPr> .

[rastapasta]

Updated the telnet cluster as well, try out the current implementation by connecting and pressing c - cheers!