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!

[verdy-p]

Note that there are ongoing discussions on the Unicode mailing lists to add other block characters (there were already supported in old OS'es that did not have full bitmap graphics, and that were used already for creating games, or that were used in existing national terminal protocols, notably for BBS, Videotex, French Minitel...) Windows has supported the French Minitel protocol in earlier versions of its terminal and even provided suitable fonts (unfortunately encoded using non-standard 8-bit code, but still not in Unicode/ISO 10646). I think that block graphics characters will soon be extended: the current needs are full coverage of 2x2 and 2x3 blocks. There are other encoded characters that are used to emulate flashing block cursors with various heights. 2017-05-12 23:21 GMT+02:00 Michael Straßburger <notifications@github.com>:

…

made the algorithm smooth and working well, merged to master! currently used charset is for now: [▀]2580, [▄]2584, [█]2588, [▌]258C, [▐]2590, [■] 25A0 [image: screen shot 2017-05-12 at 23 10 09] <https://cloud.githubusercontent.com/assets/1259904/26017333/59d6b446-3769-11e7-9794-516356705e44.png>[image: screen shot 2017-05-12 at 23 10 13] <https://cloud.githubusercontent.com/assets/1259904/26017395/95b68ca2-3769-11e7-9123-0155ac2b0a3b.png> — 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/ABUqG1ZcIN_-YA2YQNiwKiKl8AHZBQ94ks5r5M1ngaJpZM4NJOPr> .

[verdy-p]

It would be better to out "clear screen" (or moveto row1/col1) before refreshing the map over the existing page, instead of scrolling text. This is very irritating to see this scroll ! 2017-05-13 1:12 GMT+02:00 Michael Straßburger <notifications@github.com>:

…

Updated the telnet cluster as well, try out the current implementation by connecting and pressing c - cheers! — 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/ABUqG2Y0dL27H7Rbzmhcgx8jFSlDOa75ks5r5OdOgaJpZM4NJOPr> .

[rastapasta]

It would be better to out "clear screen" (or moveto row1/col1) before
refreshing the map over the existing page, instead of scrolling text. This
is very irritating to see this scroll !

this actually is already implemented - see Renderer.coffee

[verdy-p]

Also the first screen that appears should be showing the presentation and some help about keyboard. The next keypress will show the map but at anytime the key "?" or "h" should display an help screen using basic text and not dependant on terminal emulation. It would show the keymap, and the keymap should contain a "c" key to display the terminal configuration options: - select the emulation type (ANSI.SYS for DOS/Windows, VT100, VT220, XTERM are the most common) if this is not detected at start of the telnet session where it is negociated. - select the codepage to use: Unicode (UTF-8, UTF-7), legacy OEM codepages for DOS (437, 850, JIS-based) - select enabled symbols subsets (if supported by the codepage, otherwise disabled implicitly): common blocks, Braille patterns, or custom sets (using a list of Unicode hex codepoints, or byte codes from legacy codepages). Some common subsets should be preconfigured for the common emulation types. - propose to save these settings by showing the environment variable or parameter value to use when launching mapscii, or that an be entered on the Telnet session by pressing a key to enter this value as a string - see for example the color settings in for the "ls" command on Linux shells. - when running the tool from the local terminal, it should use the current locale config that already specifies an emulation 2017-05-13 1:17 GMT+02:00 Philippe Verdy <verdy_p@wanadoo.fr>:

…

It would be better to out "clear screen" (or moveto row1/col1) before refreshing the map over the existing page, instead of scrolling text. This is very irritating to see this scroll ! 2017-05-13 1:12 GMT+02:00 Michael Straßburger ***@***.***>: > Updated the telnet cluster as well, try out the current implementation by > connecting and pressing c - cheers! > > — > 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/ABUqG2Y0dL27H7Rbzmhcgx8jFSlDOa75ks5r5OdOgaJpZM4NJOPr> > . >

[verdy-p]

No it is not working on Windows that uses another escape sequence (the emulation is different: on Linux see the "termcap" database or "curses" library). 2017-05-13 1:19 GMT+02:00 Michael Straßburger <notifications@github.com>:

…

It would be better to out "clear screen" (or moveto row1/col1) before refreshing the map over the existing page, instead of scrolling text. This is very irritating to see this scroll ! this actually is already implemented - see Renderer.coffee <https://github.com/rastapasta/mapscii/blob/master/src/Renderer.coffee#L148-L153> — 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/ABUqG0mijN1fc1JrOVAbazKgNfpQ6hMgks5r5OkdgaJpZM4NJOPr> .