Generation of selected graphic symbols

[GoogleCodeExporter]

Unfortunately, most TrueType fonts do not include a range of graphic symbols 
that have traditionally been available in X bitmap fonts (and thus with xterm).
It would be nice to generate some of them - preferably the easy ones...
(like xterm generates VT100 line drawing characters).

(see attached file since pasting them in here doesn't seem to work for most 
either)

Among these, I would appreciate the following most:
- rounded corners (for nice menu borders)
- broken lines (for scrolled menus)
- eighths stair case (for a fine-grained application scrollbar)
- and some nice markers for menus and text:
  check mark, open right arrow, hyphenation point, return symbol

Original issue reported on code.google.com by towom...@googlemail.com on 17 May 2011 at 8:47

Attachments:

• missing-symbols.txt

[GoogleCodeExporter]

A sensible request, but also a lot of work, so don't expect this to be 
implemented quickly. Meanwhile, would a character fallback scheme or some way 
for the application to enquire about glyph availability be helpful?

See also the closely related issue 130 regarding VT100 linedraw characters.

Btw, one font that does have most of those characters and also generally good 
Unicode coverage is the free and open source DejaVu Sans Mono, available from 
http://dejavu-fonts.org.

Original comment by andy.koppe on 18 May 2011 at 7:35

• Changed state: Accepted
• Added labels: Difficulty-Hard, Priority-Low

[GoogleCodeExporter]

Thanks for the link. I also checked the other font mentioned on the cygwin list.
Unfortunately, neither contains the rounded corners. DejaVu actually doesn't 
contain any line drawing border elements, worse than Lucida Console.

In any case, a query feature could be helpful, and a fallback scheme, too. To 
be taken with care, however, since some of the MS fonts do contain borders 
(even rounded ones) but poorly aligned, so the result would be terrible (e.g. 
Ming). Other fonts leave gaps between line drawing and block elements (e.g. 
Everson Mono).

Still looking for more useful fonts...

Original comment by towom...@googlemail.com on 26 May 2011 at 2:14

[GoogleCodeExporter]

Update: I probably tried with an older version of DejaVu. The current version 
has many symbols indeed - just the rounded corners are not very round, well.
So, DejaVu as a fallback font would probably be a good idea.

Original comment by towom...@googlemail.com on 26 May 2011 at 9:08

[GoogleCodeExporter]

Those poorly aligned line drawing characters are presumably due to Windows' GDI 
font linking scheme, which substitutes glyphs from different fonts in case 
glyphs are missing from a font. Unfortunately the substitutes don't necessarily 
have the same shape, which of course is particularly noticeable with the line 
drawing characters. The list of substitutes for each font can be found in the 
registry at HKLM\SOFTWARE\Microsoft\Windows 
NT\CurrentVersion\FontLink\SystemLink.

A font fallback scheme implemented in mintty would have much the same problem, 
hence what I had in mind was a character fallback scheme, similar to what's 
already being done for the VT100 graphics. If a glyph for a particular line 
drawing character isn't available in the selected font, mintty would go through 
a list of decreasingly similar characters until finding one that has a glyph. 
For the rounded corners, this would probably mean first trying the pointy 
corners before falling back to ASCII '+'.

Regarding the glyph query sequence, how about the following: the application 
sends a to-be-determined CSI or OSC sequence with a semicolon-separated list of 
Unicode codepoints represented as decimal numbers, and mintty replies with the 
same sequence except that it leaves out codepoints that don't have glyphs 
available. (The more obvious thing to do would be to use the actual characters 
instead of decimal numbers, but that would have the same security issue as for 
example the window title query.)

Original comment by andy.koppe on 28 May 2011 at 8:43

[GoogleCodeExporter]

Any way to switch off this GDI font linking for checking actual font 
capabilities?
Thanks for the hint.

I checked DejaVu again and it does show many characters on one machine but not 
on another (and it is the current version on both). So apparently they are 
missing in the font itself and the presumably good result is due to the font 
linking ... :(

About the query sequence: good proposal; I would suggest to include an empty 
position for each glyph not available so an application can decide whether to 
check by glyph values or by filled index in the glyph sequence, like this:
OSC 7771;?;8227;10003;9166 BEL
->
OSC 7771;!(or whatever);8227;;9166 BEL

Also if feasible, it might make sense to distinguish (or selectively query) 
whether a glyph is contained natively, i.e. in the actual font, or only by 
fall-back.

Original comment by towom...@googlemail.com on 30 May 2011 at 2:54

[GoogleCodeExporter]

You could switch off the GDI font linking by removing the relevant entries in 
the registry (after first backing them up). Or you could just look at the font 
in 'Character Map', which as far as I know only shows characters that the font 
has glyphs for.

In mintty, the VT100 linedraw character mapping is done on arrival of each 
character, which means you need to rerun whatever test you're doing when you 
change font.

Including empty positions for missing glyphs in the reply sequence seems fair 
enough. The sequence would only report characters that the font natively has 
glyphs for (by using Windows' GetGlyphIndices() function). I don't know how to 
determine whether font linking provides a replacement, and it doesn't seem 
worth trying to find out.

Original comment by andy.koppe on 31 May 2011 at 5:26

[GoogleCodeExporter]

I implemented the OSC 7771 sequence as suggested, in r1196. I realised why the 
'?' and '!' are needed when getting a feedback loop due to terminal echo.

Original comment by andy.koppe on 9 Jun 2011 at 5:50

[GoogleCodeExporter]

Hi Andy!
I wondered why sometimes my graphic borders would not display and found that 
DejaVu includes the Box Drawing glyphs but DejaVu Bold does not (and I used 
bold mode for graphic borders).
Thus it would be useful to enhance this glyph detection by considering the 
current character attribute, i.e. looking at the bold font after "ESC[1m".
Also, the response should terminate with ^G as documented rather than a single 
ESC (missing the usual '\').

Original comment by towom...@googlemail.com on 11 Oct 2011 at 12:45

[GoogleCodeExporter]

Taking the bold attribute into account makes plenty of sense. Implemented in 
r1230 on branches/1.0.

The OSC reply sequence is terminated with escape followed by backslash, i.e. I 
don't see a missing backslash. (OSC requests can use either ^G or ST, but 
replies always use ST, because IIRC that's what the standard requires. 
Admittedly the documentation does not make that clear.)

Original comment by andy.koppe on 12 Oct 2011 at 6:47