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

Inconsistencies between turnstiles and their slashed variants #92

Open
anderslundstedt opened this issue Jan 26, 2021 · 12 comments
Open
Labels
enhancement may be implemented as an enhancement

Comments

@anderslundstedt
Copy link

anderslundstedt commented Jan 26, 2021

As always, thanks for a great font!

I have noticed that the slashed variants of various turnstiles do not look exactly as their corresponding turnstile plus a slash, which I guess would be the desired looks. I mainly use '⊢', '⊣', '⊨', '⫤', but I guess the problem would apply to other turnstiles as well. The turnstiles which have no separate code point for their slashed version look OK when appending u+0338.

Screen Shot 2021-01-26 at 16 40 45

@cormullion
Copy link
Owner

Ah interesting, I will investigate this. One of my skills is being inconsistent... :)

Thanks!

@cormullion cormullion added the enhancement may be implemented as an enhancement label Jan 26, 2021
@anderslundstedt
Copy link
Author

FWIW, this sort of inconsistency does not seem limited to only turnstiles. For example, the strokes in '≈' gets thinner in '≉', and similarly for '<' and '>' when turned into '≮' and '≯', respectively. On the other hand, many other symbol pairs look consistent to my eyes—for example, '=' and '≠', '≡' and '≢', '≺' and '⊀', and '≻' and '⊁'.

@cormullion
Copy link
Owner

cormullion commented Jan 29, 2021

I made a few changes so that the slashed versions are more consistent (well in this picture even the slashed ones get slashed, which probably doesn't happen in real life):

Screenshot 2021-01-29 at 08 47 22

Sometimes there are many different ways to be consistent - and the fixed width is an added factor to contend with here. It's all a compromise ... (that's my excuse anyway 😃).

@anderslundstedt
Copy link
Author

Looks good! Will try them out in the next release.

@cormullion cormullion added fixed? might be fixed, needs to be checked by issue author and removed enhancement may be implemented as an enhancement labels Feb 4, 2021
@anderslundstedt
Copy link
Author

Some issues remain:

  • 22a2+0338 looks like 22ac and not as a slashed 22a2. (The mirror of 22a2 is 22a3 and 22a3+0338 looks correct.)
  • Connected to the previous point, 22ac should decompose as 22a2+0338 (https://www.compart.com/en/unicode/U+22AC) so it should probably be changed as well.
  • 2ae4 and 2ae4+0338 look smaller than their respective mirrors 22a8 and 22ad (=22a8+0338).

Screen Shot 2021-02-05 at 14 13 51

@cormullion cormullion added enhancement may be implemented as an enhancement and removed fixed? might be fixed, needs to be checked by issue author labels Feb 10, 2021
@cormullion
Copy link
Owner

I've made a few more adjustments - they're currently on the current master...

@anderslundstedt
Copy link
Author

The only inconsistency I now notice is that 22a2+0338 and 22ac do not look like a slashed 22a2 (but more like a slashed 22a6).

@cormullion
Copy link
Owner

What needs fixing? I'm getting quite confused now... :)

Screenshot 2021-02-13 at 15 15 24

@anderslundstedt
Copy link
Author

It might be me misunderstanding something, but here is how I see the problem. Currently 22a2+0338 and 22ac both look like a slashed 22a6. I would like 22a2+0338 and 22ac both to look like a slashed 22a2.

FWIW, in support of my opinions:

  • The mirror of 22a2 is 22a3 and 22a3+0338 looks like a slashed 22a3. Thus similarly 22a2+0338 ought to look like a slashed 22a2.
  • According to https://www.compart.com/en/unicode/U+22AC, 22ac "decomposes" as 22a2+0338. Thus 22ac ought to look like 22a2+0338, which, by the previous point, ought to look like a slashed 22a2.

@anderslundstedt
Copy link
Author

It might be me misunderstanding something, but here is how I see the problem. Currently 22a2+0338 and 22ac both look like a slashed 22a6. I would like 22a2+0338 and 22ac both to look like a slashed 22a2.

Expanding on this: in your image, the length of the horizontal stroke makes 22a2+0338 (=22ac) look more like a slashed 22a6 than a slashed 22a2.

@cormullion
Copy link
Owner

I think something's not working quite right here, I've been trying to get predictable results for an hour now and failing... Could be a software error, who knows...

I may have to leave this to one side for a while.

@anderslundstedt
Copy link
Author

Fair enough!

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

No branches or pull requests

2 participants