Terminology doesn't displays the _ character depending of font size and cli application using #1
Labels
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: enlightenment/terminology#1
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I have seen this issue since long time, I think I had already reported it in the past and maybe it was fixed, but there still problems in some cases (using VIM for example), for a better explaining i recorded a small video showing the issue: https://www.youtube.com/watch?v=a7pk66ECHYU
Video note correction: the different DPI makes it to show / not show in different sized redimensions (but the issue happens always in any dpi value, it just changes on which font sizes happens)
related: https://phab.enlightenment.org/T2070
not sure why you migrated this here... i think on phab it wss lcear that the font renders outside the min/max bounds it gives for chars. the text grid is a strict grid. any content that goes outside the textgrid bounds will not draw as that is by definition. if the _ is outside those bounds on the last line then it doesn't draw because the font wants to draw outside the bounds it says characters use. solution: use another font. :)
It happens with "DejaVu Sans Mono", which is the default font in Terminology 🤔 and one of the most widely supported amount of international characters out there (so the best to be used as default)
I just checked the original font and the _ character looks like this: https://i.imgur.com/oUGbusA.png - I don't know if this position is included in the max bounds of the grid or only the main box, but for sure is a part of the bounds to be rendered since many characters use parts like this one. I don't think terminology / text grid should include an extra space for that (this will also look ugly, and waste space) but i think it should be simply rendered