Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connecting orthogonal and diagonal box-drawing glyphs #2271

Closed
Logo121 opened this issue Apr 2, 2024 · 4 comments
Closed

Connecting orthogonal and diagonal box-drawing glyphs #2271

Logo121 opened this issue Apr 2, 2024 · 4 comments
Labels

Comments

@Logo121
Copy link
Contributor

Logo121 commented Apr 2, 2024

Continuation of #2197.

This problem exists before the introduction of the Unicode 16.0 box-drawing diagonals, where the "diamond" diagonals do not connect with the orthogonals ones 🮮┼
image

To my understanding the "cell-masking" done in those diagonals are to remove the gaps that appear when 2 (non-parallel) lines join, which I followed for the diagonal lines in 16.0. However, in the schematic symbols section we have these:
image
Which kinda assumes connection with diagonals and orthogonal lines (at least for these 4 characters. I can't really find examples of circuit diagrams with those microcomputers so I can't tell if diagonal/orthogonal connections are needed in general). Right now connecting them results in something like this:
image

The potential solutions are:

  1. Make all lines unclipped, and only deal with cases where gaps appear in a single character (like 🯘🯙🯚🯛)
    • For the other cases like 🮠🮡 🮢🮣, we just ignore the gap problem, or try to reduce it somehow like using a rounded cap?
    • Essentially what FairfaxHD does.
  2. Modify the width of the diagonal lines so that they connect to orthogonal lines directly.
    • This is cleaner but would probably result in lines varying quite a bit in thickness. Also requires some calculations for every kind of slopes.
  3. Deal with the schematic symbols directly and assume no diagonal-orthogonal connection should happen otherwise.
    • This means making 𜰉𜰊 unclipped unlike the other diagonal lines, or making the vertical connection part of 𜰐𜰑 a spline like in FairfaxHD: image
    • Note that the spline form is not used in the Fullwidth equivalent (KreativeSquare), which is the Unicode reference glyph.

... or a mixture of the above.

While we're at it we might also want to disable HVContrast for all box-drawing glyphs, if that makes the situation better.

Affected glyphs:

  • The "diamond" diagonals 🮠🮡🮢🮣🮤🮥🮦🮧🮨🮩🮪🮫🮬🮭🮮 (and their derivatives)
  • The "corner-to-edge" diagonals 🯐🯑🯒🯓🯔🯕🯖🯗🯜🯝🯞🯟
  • Maybe these 2 double diagonals 𜰟𜰠
  • Some schematic symbols 𜰉𜰊𜰐𜰑
@be5invis
Copy link
Owner

be5invis commented Apr 2, 2024

Well these symbols were included in Sharp MZ computers and their original fonts are bitmap fonts, so I do not think they ever considered this problem seriously...
I think for the schematics we should not clip them at the cell border -- and only for them because they are designed to be connected to H/V lines. For the others? keep the current design.

@be5invis
Copy link
Owner

be5invis commented Apr 2, 2024

And ps. maybe you should consider make the logic gate symbols shorter vertically under NWID -- match the height of the horizontal resister symbol.

@Logo121
Copy link
Contributor Author

Logo121 commented Apr 2, 2024

I think for the schematics we should not clip them at the cell border -- and only for them because they are designed to be connected to H/V lines. For the others? keep the current design.

ok

And ps. maybe you should consider make the logic gate symbols shorter vertically under NWID -- match the height of the horizontal resister symbol.

I did consider this, but I wasn't sure what could function as a "non-inverted" version of LOGIC GATE INVERTED INPUTS if I make them not stretch to cell boundary.
...Well, not like the original charset has an equivalent anyway, so idk

Copy link

github-actions bot commented Jun 6, 2024

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants