From: Ethan A M. <me...@uw...> - 2020-06-24 18:56:23
|
On Wednesday, 24 June 2020 10:20:48 PDT Dima Kogan wrote: > Ethan A Merritt <me...@uw...> writes: > > > Back when people cared about x11, the tools and fonts necessary to set > > up utf8 support were maintained, albeit difficult to use. Now I cannot > > get it to work at all. I imagine it is still possible but I cannot > > point to a recipe for how to do it. > > > > I think the best advice is "don't use the x11 terminal". > > Yeah, that's too bad, but I think we can do better than that advice > suggests. > > I use the x11 terminal almost exclusively for one reason: it's > dramatically faster and lighter than all the alternatives. The > difference is very noticeable when X-forwarding or when repeatedly > replotting (interactively rotating a 3D plot, using feedgnuplot > --stream, etc). > > So I really would like to keep this working reasonably. If we currently > have a unicode problem that makes tic mark labels render improperly, an > easy "fix" would be to not feed unicode to the x11 terminal. That is exactly what "set encoding XXX" does, for any XXX that is not utf8. Or did you mean that <x11 terminal + non-ascii encoding> would be a special case when generating tic labels? We generally try to keep terminal-specific tests out of the core code, but we do have tests for TeX-based terminals so it's not an absolute prohibition. > If somebody > has the time and motivation to fix it properly, that'd be awesome of > course, but just sending ascii across would solve the 99% case in the > meantime. > > But I can't reproduce the issue in this report, and until that happens, > there's nothing to "fix". For a long time now utf8 has been the default on linux. So I would expect that most linux users would have to deal with this when using the x11 terminal with their default locale. Ethan |