Distinguishing between hyphens and dashes in the editor

[klembot]

Originally reported by: Thomas M. Edwards (Bitbucket: tmedwards, GitHub: tmedwards)

---

The current editor font does not allow one to visually distinguish between the hyphen-minus and en-dash characters, which should be fairly easy. Worse still, the em-dash character is barely distinguishable from either of the previously mentioned characters.

Distinguishing the en-/em-dashes from each other is less of a concern, but distinguishing them from the hyphen-minus should be considered a necessity (especially with people copy-pasting from word processors).

(Full disclosure: I became aware of this issue because I had to debug it for someone recently.)

---

• Bitbucket: https://bitbucket.org/klembot/twinejs/issue/154

[klembot]

Original comment by Chris Klimas (Bitbucket: klembot, GitHub: klembot):

---

Just noting that embedding the full DejaVu font is not looking feasible -- it weighs in at 500-800K depending on which version. Not to say that it isn't a better choice overall, though.

[klembot]

Original comment by Chris Klimas (Bitbucket: klembot, GitHub: klembot):

---

I was weighing Office Code Pro and even Courier Prime, but I think DejaVu is the right way to go.

[klembot]

Original comment by Thomas M. Edwards (Bitbucket: tmedwards, GitHub: tmedwards):

---

Option (a) entails checking not only the names of created passages, but also all link markup, especially for those cases where auto-creation of passages from links happens. Expecting Twine 2 to properly check all basic links (specifically, I mean, from basic markup and macros, but not JavaScript or when $variables are involved) for all story formats, with their varying markup, is an unlikely proposition (at least, until there are proper Twine 2<->story format hooks in place for that sort of thing; e.g. I mean, AFAIK, Twine 2 still does terrible things with SugarCube's square-bracketed link markup).

So, at the moment, my feeling is that (b) is the only real option, since (a) is, currently, unrealistic.

[klembot]

Original comment by greyelf (Bitbucket: greyelf, GitHub: greyelf):

---

So does that mean that: a) passage names should be automatically checked so they do not contain characters like en-dash and em-dashes, or that: b) Authors will just need to be more careful if they are coping passage names from software like MS Word. (which can silently convert standard characters like hyphens to em-dashes without the Author actually knowing/noticing)

[klembot]

Original comment by Chris Klimas (Bitbucket: klembot, GitHub: klembot):

---

I feels that's an unnecessary burden on story format authors, and opens a can of worms with regards to all the possible confusions Unicode can offer, i.e. https://en.wikipedia.org/wiki/Homoglyph#Unicode_homoglyphs

[klembot]

Original comment by greyelf (Bitbucket: greyelf, GitHub: greyelf):

---

Should passage names be able to contain en-dash and em-dashes as well as hyphens, and if so will the story formats handle when an Author incorrectly uses the wrong one in a link?

[klembot]

Original comment by Thomas M. Edwards (Bitbucket: tmedwards, GitHub: tmedwards):

---

DejaVu Sans Mono ( @wikipedia.org, @dejavu-fonts.org ) might work. It certainly distinguishes between the hyphen-minus and en-/em-dashes clearly. It also has fairly good (though not perfect) coverage of Unicode planes 0 & 1 (basic & supplementary multilingual planes), though browsers are fairly good about filling in missing runes, so that's probably less interesting than it might otherwise be.

[klembot]

Original comment by Chris Klimas (Bitbucket: klembot, GitHub: klembot):

---

Any suggestions on alternatives? I picked Source Code Pro because I liked Source Sans Pro. There is a difference in lengths with Cousine, what I went with originally, but I'm not sure it would pop out to me in text.

[klembot]

2.4 uses the system font now.