search

neolode / mintty

Automatically exported from code.google.com/p/mintty
GNU General Public License v3.0
0 stars 0 forks source link

Report font changes #335

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
For font changes that affect width properties, there is sequence \033[?7700h to 
get them reported.
With the newer glyph detection capability it would also make sense to get *all* 
font changes reported, maybe by asking \033[?7700;2h or some other mode 
setting; notification could be something like ^[[0W or just the same as for the 
width change notification.

Original issue reported on code.google.com by towom...@googlemail.com on 10 May 2012 at 3:17

GoogleCodeExporter commented 9 years ago 
Seems fair enough. I'll have to think about the protocol.

Original comment by andy.koppe on 10 May 2012 at 7:45

GoogleCodeExporter commented 9 years ago 
Hmm, '\033[?7700;2h' already means switching on private modes 7700 and 2, i.e. 
that sequence takes a list of mode numbers. Moreover, the ambiguous width might 
change not only when the font is changed, but also when the locale or character 
encoding is changed, so maybe a separate protocol for font changes would be 
more appropriate.

How about another private mode number in the 77xx range, and sending xterm's 
OSC 50 sequence when the mode is enabled and the font changes?

Original comment by andy.koppe on 30 May 2012 at 5:04

GoogleCodeExporter commented 9 years ago 
Or, not have a new mode at all, and redefine the ambiguous width reporting to 
report both font changes and ambiguous width changes?

Original comment by andy.koppe on 30 May 2012 at 5:06

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Just remembered, on Cygwin 1.7 the ambiguous width actually is determined by 
the locale and charset only, via the wcwidth() function. That's to ensure that 
mintty matches the widths reported by wcwidth(). If the font has a wide 
character where a narrow one is expected, the glyph is squished into a single 
cell. Issue 123 requests the reverse.

The widths found in the font are only taken into account on Cygwin 1.5 and 
MSYS, which don't have a proper locale system.

Original comment by andy.koppe on 30 May 2012 at 8:00

GoogleCodeExporter commented 9 years ago 
Comment 2: I think, OSC 50 is now disabled by default in xterm for some 
security concerns, so I'm not sure it would be a good choice.

Comment 3: Good proposal for me, agreed; although in theory someone might be 
interested in width changes but not in information about specific glyphs...
Whether or not you decide to share the mode request sequence, I would suggest 
to share the response sequences anyway.

Comment 5: So on MSYS, do you check some typical character widths in the font 
to maintain mode 7700 or does it not work here?

Original comment by towom...@googlemail.com on 31 May 2012 at 11:28