Disable ligatures via CSS |
||||
Issue descriptionChrome Version : 51.0.2704.84 OS Version: OS X 10.11.5 Hi, when using the fonts 'Menlo' or 'Menlo for Powerline' in hterm, this leads to ligatures, as described here: https://github.com/powerline/fonts/issues/42 The solution is to disable ligatures: https://gitlab.com/gnachman/iterm2/commit/511a8442d77e60797ac4bc2d5aaa94a6fa48a0a2 I've tried disabling ligatures with user-css in hterm without success: data:text/css;utf-8,body{font-feature-settings:"liga" 0;} Also, pointing user-css to the following gist didn't work: https://gist.github.com/felixgr/14ebe576d27ca7834cc6874ac8f5ed70 Can you advise? Possibly that CSS setting should be a default in hterm to prevent ligatures in all fonts on all clients? Cheers Felix UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36
,
Jun 21 2016
,
Jun 27 2016
groebert@google.com: have you tried changing your user-css to `data:text/css;utf-8,* { font-feature-settings: "liga" 0; }`? This fixes rendering me, at least as a workaround until it is fixed upstream.
,
Jun 27 2016
doing a bit of reading and playing around on a friend's OS X system, disabling ligatures appears to only impact "style" ones and not mess with distinct codepoints (e.g. U+00E6 will still be æ). this page was helpful: http://ilovetypography.com/OpenType/opentype-features.html posted https://chromium-review.googlesource.com/356530
,
Jun 28 2016
user-css = `data:text/css;utf-8,* { font-feature-settings: "liga" 0; }`
works for me. Thanks!
,
Jul 7 2016
The following revision refers to this bug: https://chromium.googlesource.com/apps/libapps/+/bf85c3b1f30696dca576bfdcb285ca11055876e5 commit bf85c3b1f30696dca576bfdcb285ca11055876e5 Author: Mike Frysinger <vapier@chromium.org> Date: Mon Jun 27 22:45:59 2016 hterm: disable ligatures When using OpenType fonts, some include ligatures that mess with the rendering (e.g. "ae" might be rendered as "æ" even though they are really two bytes). This messing with the display (the cursor can't find the right location) and just confuses users in a terminal fixed font setting. Some notable examples of this appear to be recent OS X systems with their Menlo font family. This should not impact distinct Unicode codepoints. i.e. U+00C6 is æ and will continue to be rendered as a single character. It should only affect the (incorrect) rendering of two different codepoints as a single one. BUG= chromium:621519 Change-Id: I49f8afb950fa620fef87a8230a88a4f00e060889 Reviewed-on: https://chromium-review.googlesource.com/356530 Reviewed-by: Rob Ginda <rginda@chromium.org> Tested-by: Rob Ginda <rginda@chromium.org> [modify] https://crrev.com/bf85c3b1f30696dca576bfdcb285ca11055876e5/hterm/js/hterm_scrollport.js
,
Sep 15 2016
this is released in the dev version in 0.8.34.3. it'll make it into stable once it's been vetted. |
||||
►
Sign in to add a comment |
||||
Comment 1 by vapier@chromium.org
, Jun 20 2016Components: Platform>Apps>Default>Hterm
Labels: -Type-Bug Type-Feature