GNOME Bugzilla – Bug 789534
Line width fixes/cleanups
Last modified: 2021-06-10 15:26:12 UTC
Some more or less related issues: 1. Underline (escape sequence) and strikethrough should use pango_font_metrics_get_{underline,strikethrough}_{position,thickness} to get the desired position and thickness, rather than guessing from the height, ascent and descent. 2. Regex/hyperlink underlines, and the outlined cursor are 1px wide. This isn't wise, especially with hidpi in mind. I guess 1px could remain as a safety cap, but the default should always be a value that scales with the font (e.g. the same as escape sequence underline width). (Also, check if there's anything else that's currently 1px regardless of the font size [apart from padding]. Furthermore, revise regex_underline_position too.) 3. I think VTE_LINE_WIDTH (which is hardly used anyway) should be deprecated/removed, or at least renamed to VTE_LINE_MIN_WIDTH and made sure that this is its only role. 4. I hate the interface of _vte_draw_draw_line(), it draws a line by taking 5 dimension values: the 4 coords plus a minimum width. Its usage is hence ambiguous: shall the actual width go to these 4 coords, or the 5th such parameter? The minimum width shouldn't be enforced by this method, but taken into account whenever we compute the desired width for whatever purpose. Plus, its interface and implementation has a counterintuitive off-by-one and as such, when the method is used, a similar (opposite) off-by-one is also required. I can't see the point of having this method, rather than drawing a filled rectangle using a simpler and better API. 5. Similarly, I'd revise if we need _vte_draw_draw_rectangle() with its hardcoded VTE_LINE_WIDTH (only used for the outlined cursor), I guess we'd better draw it manually using 4 lines and ditch this method too. Or at least have the exact width injected as a parameter.
2b. Another case of hardwired "1px": _vte_draw_terminal_draw_graphic(): heavy_line_width = light_line_width + 2; With giant fonts, heavy lines are hardly heavier than light ones.
6. Faux bold also shifts by a hardcoded 1px, at the end of _vte_draw_text(). Presumably hardly distinguishable from the base font at large font sizes. (I think, for a somewhat okay-ish look, it should shift by 1px multiple times in a loop to "n-strike", rather than "double-strike" with a larger offset. Or maybe time to drop this feature entirely?) (Why did I think we'd dropped faux bold already?)
In case of faux bold, the background is also extended by a hardcoded 1px, see bug 682692 comment 5.
(In reply to Egmont Koblinger from comment #2) > 6. Faux bold also shifts by a hardcoded 1px, at the end of _vte_draw_text(). > Presumably hardly distinguishable from the base font at large font sizes. (I > think, for a somewhat okay-ish look, it should shift by 1px multiple times > in a loop to "n-strike", rather than "double-strike" with a larger offset. > Or maybe time to drop this feature entirely?) > > (Why did I think we'd dropped faux bold already?) I've proposed dropping it in bug 756010.
VTE_LINE_WIDTH is used for the outline rectangle cursor's width, and it wouldn't look great if the outline cursor was narrower when it's at the edge of the terminal. So if we increase the outline rectangle cursor's width for larger fonts, we should probably increase the padding, too. Which is a bit problematic because the padding is taken from CSS. Or shall we make it the maximum of the CSS value and the line width? Probably it would be even better to make the cursor half-inline, half-outline, rounded towards more outline pixels.
I feel like using CSS at all for the padding was a mistake... > Probably it would be even better to make the cursor half-inline, half-outline, rounded towards more outline pixels. That's probably the best suggestion here: use as many outside pixels as possible, and if the line width is greater than that, use inside pixels.
> I feel like using CSS at all for the padding was a mistake... I have weird feelings about it too. Can we deprecate and eventually remove it? Would you want to have an API instead? Or drop its configurability (let the value be computed from the font size using a hardwired algorighm, perhaps the very same value as the outline cursor width (or half thereof))?
I think API is fine, although usually you wouldn't need to change this value at all.
See also https://gitlab.gnome.org/GNOME/vte/issues/134.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2442.