U+2571 U+2572 U+2573 box drawings slope problem

[maverickwoo]

I am using font version 0.045, and I confirm that this is reproducible on macOS 12.5 with VS Code 1.69.2 using a minimal settings.json pasted below. All three versions are the latest as of this writing.

{
  "editor.fontFamily": "JuliaMono",
  "editor.fontSize": 14
}

Using this setup, I observe that the slopes of the strokes in the following three code points for box drawings are approximately ±45 degrees.

U+2571 ╱ Box Drawings Light Diagonal Upper Right To Lower Left
U+2572 ╲ Box Drawings Light Diagonal Upper Left To Lower Right
U+2573 ╳ Box Drawings Light Diagonal Cross

Unfortunately, this choice considerably reduces the utility of these code points for box drawings because the diagonal box lines drawn with them do not visually align. To illustrate this, consider the demo file at https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt. Here is the source code of one of the boxes towards the end of the file:

╔══╦══╗ 
║┌─╨─┐║ 
║│╲ ╱│║ 
╠╡ ╳ ╞╣ 
║│╱ ╲│║ 
║└─╥─┘║ 
╚══╩══╝ 

And here is a screenshot of this box drawn by VS Code in the above setup:

Perhaps it would be an improvement to make the slopes in these three code points steeper (and with suitable adjustments to the stroke lengths) such that the diagonal box lines will visually align with each other?

Thank you very much for your consideration. I really appreciate the effort you have put into this fantastic font.

[cormullion]

Hi! This is certainly possible to do, and I've tried making the changes.

However, it will be difficult to guarantee that it looks good in all situations; it depends on the line height. If you can adjust the line height of your editor, you can adjust it to look reasonably OK.

In VSCode it looks better in the terminal (line height 1) than in the editor (line height is obviously > 1).

In a MacOS Terminal, you can adjust the line height precisely so you can make the diagonals line up.

Unlike for vertical and horizontal lines, the diagonals can't overshoot/overlap for every setting of line spacing.

Here in Github, using the github font:

╔══╦══╗ 
║┌─╨─┐║ 
║│╲ ╱│║ 
╠╡ ╳ ╞╣ 
║│╱ ╲│║ 
║└─╥─┘║ 
╚══╩══╝ 

╱╲╱╲╱╲╱╲╱╲╱╲╱╲╱╲╱ 
╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╱ 
 ╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╱ 
╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╱ 
 ╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╱ 
╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╱ 
 ╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╳╲╱ 

[maverickwoo]

Thank you very much for the explanations. I acknowledge some line spacing adjustment may be needed to make the new slope-adjusted and lengthened diagonal strokes in Julia Mono line up.

If I may make a suggestion, perhaps the documentation can pick (i) a program and (ii) a line spacing and state that that particular setup is the "benchmark", i.e., the diagonal strokes in the released font files are intended to line up in that one tested setup, and line spacing adjustment may be needed in other programs to achieve the same result. This way, future users can know whether they are seeing a real bug or they just happen to be using a different setup that needs to be configured accordingly.

With this concept of benchmark setup in mind, my proposal for Mac would be to pick Terminal.app in the latest OS release, with both character spacing and line spacing stay at 1, which is essentially the default. The reason why I would advocate for staying at 1 for both spacings is because it may not be desirable to adjust either spacing. For example, if we need to change the line spacing to 0.83 to get the diagonal lines to line up, the rest of the text may not be readable. (In fact, this is a problem with SF Mono, which also needs a line spacing of 0.83 for the diagonals to line up, but at the expense of having very crowded text.)

With my proposed benchmark setup, on my machine (macOS 12.5; latest), here are a few screenshots comparing Julia Mono, Menlo, and SF Mono with their latest versions as of today:

• Julia Mono v0.045 renders (in Terminal.app here) the same as reported above (in VS Code).

• Menlo v7.0d1e1 achieves essentially "correct" diagonal lines.

• SF Mono v16.0d2e1 has almost the correct slopes, but the strokes are a tad bit too short and so the lines are disconnected. (This screenshot was taken at line spacing 1. If we reduce the line spacing to 0.83, then the diagonal lines will line up almost perfectly in slope, but there is still a tiny gap between the strokes. However, the text on the screen is very crowded and so a line spacing of 0.83 is not that usable in practice.)

Thank you very much for the fixes. I look forward to seeing the next release.

[DanielMGessel]

Apologies for jumping in here. I was just playing around with an SVG file I hacked up and noticed the block characters seem really tall. I was about to submit a new issue when I realized there is no fixed standard for line spacing! I was assuming that a monospace font should be designed to be spaced "font height" apart (1em); it seems obvious that monospace should apply to the vertical as well as horizontal (to an old hacker like me, anyway). A little more searching stopped me in my tracks when I discovered recommendations from 1.2em to 1.5em!

Using 1em spacing, the ratio of vertical to horizontal comes out to be about 15 to 9? So, for the block characters, what's the intended line spacing for JuliaMono? Closer to 1.5em?

Well, here's that SVG if you want to play with it - apologies that it's just a junk file... I wonder if there are reference images for a set of SVGs to test rendering conformance? We always used reference images for graphics driver work.

<svg width="2in" height="2in"
     preserveAspectRatio = "none"
     viewBox="0 0 90 90"
     xmlns="http://www.w3.org/2000/svg"
     style="background: #000; fill:#000;">
<g transform="translate(0 90) scale(1 -1.0)">
<style>
@font-face {
  font-family: JuliaMono;
  src: url("https://cdn.jsdelivr.net/gh/cormullion/juliamono/webfonts/JuliaMono-Bold.woff2");
  font-weight: normal;
}
.f
{font:bold 10px "JuliaMono";}
.j
{font:bold 10px "JuliaMono";}
</style>
<rect x="0" y="0" width="90" height="90" style="fill:#024;stroke:#036;stroke-width:3px" />
<text transform="translate(0 90) scale(1 -1)"
  class="f" text-anchor="left" stroke-width="0" style="fill: #FFF; line-height: normal">
<tspan class="f" x="0" dy="1em">0123456789ABCDEF</tspan>
<tspan class="j" x="0" dy="1em">0123456789ABCDEF</tspan>
<tspan class="f" x="0" dy="1em">ABCabc</tspan><tspan class="j">ABCabcmmmmlmmmmmmmmmmm</tspan>
<tspan class="f" x="0" dy="1em">𝙰𝙱𝙲𝙳𝙴𝙵𝙶</tspan><tspan class="j">𝙰𝙱𝙲𝙳𝙴𝙵𝙶𝙷𝙸𝙹𝙺𝙻𝙼𝙽3mm ┃mmmmmmmmmmmm</tspan>
<tspan class="f" x="0" dy="1em">𝒪𝒫𝒬ℛ𝒮𝒯</tspan><tspan class="j">𝒪𝒫𝒬ℛ𝒮𝒯𝒰𝒱𝒲4mm┃ mmmmmmmmm</tspan>
<tspan class="j" x="0" dy="1em">5mm mm┃mmmmmmm</tspan>
<tspan class="f" x="0" dy="1em">6mmmmmmmmmmmm</tspan>
<tspan class="f" x="0" dy="1em">7mmmmmmmmmmmm</tspan>
<tspan class="f" x="0" dy="1em">8wait MMM what </tspan>
<tspan class="f" x="0" dy="1em">9wait what </tspan>
<tspan class="f" x="0" dy="1em"> wait what </tspan>
<tspan class="f" x="0" dy="1em"> wait what </tspan>
<tspan class="f" x="0" dy="1em"> wait what </tspan>
</text>
</g>
</svg>

[cormullion]

The font is primarily intended for coding, so it should work in terminals. Most of the terminal emulators have line spacing set to 1, 100%, or 0:

Terminal	iTerm	Kitty	Alacrity	Wezterm
1.0	100	0	1.0	1.0

I think the default is OK, but if anything it's quite 'tight', so it wouldn't be a surprise if someone chooses a looser (wider) setting. Usually we're relying on the app cropping the glyphs, which many do well.

The box drawing characters overshoot so that they should still work at 1.1 (110%?), but they will start to show gaps at 1.2 and more.

It would take some effort to define any kind of standard. Even just on MacOS (which is all I have access to), the appearance of box drawing characters varies a lot from app to app, font to font. On Terminal, the display of box glyphs changes according to whether you're moving the cursor up the screen or down the screen. (!)

[DanielMGessel]

Yeah - kitty draws it's own box and braille characters. I'm happy with it for now. Emacs is less consistent. Thanks for the info on the "overshoot" - I thought it might be contributing to this issue, but with no standard for line spacing (let alone character cell aspect ratio) it seems it's all in the "tuning".

[cormullion]

Yes - I think of an OTF font file as being like the score for a piece of music - it gets interpreted by different performers with different results, and who's to say whether there's a definitive performance.. 😀

[anderslundstedt]

In iTerm I can get box characters to line up correctly at the maximum line spacing of 200:

In verbatim environments in XeLaTeX I can get box characters to line up correctly up to a line spacing of 1.4:

At 1.5 they almost line up, but there seems to be an issue with at least the glyph for ‘┐’ but probably also with the glyph for ‘┘’:

[DanielMGessel]

Maybe I’ll look at the files a bit more closely…

[anderslundstedt]

In iTerm I can get box characters to line up correctly at the maximum line spacing of 200:
[…]

In verbatim environments in XeLaTeX I can get box characters to line up correctly up to a line spacing of 1.4:
[...]

And in TextEdit version 1.17 (380.2) on MacOS Monterey 12 I cannot even make the box characters connect at a line spacing of 1.1 (but 1.0 stil works):

[DanielMGessel]

It'd take some deep digging to find out, but I wonder if some render paths are clipping the glyphs Or scaling characters to fit vertically? Scaling may result in too thick or thin horizontal lines. Alas, the Unicode standard, despite having box drawing and “retro” graphics characters, discourages character cell models and terminal emulation in general. To that I say, “Fight the Power!”

[github-actions]

This issue has been open for 30 days with no activity.