2

I'd like to write some code that properly renders in any font (and I cannot use UTF8 input). Is there a way to find out if \textendash is properly defined for the current font?

With \ttfamily, -- does not render as en dash, but as -- literally, \textendash renders as opening brace {.

So I guess, I need an own macro that uses textendash if available, and - otherwise.

\documentclass{minimal}
\begin{document}
  This -- should work the same \textendash{} in any font.

  \ttfamily
  This -- should work the same \textendash{} in any font.
\end{document}
mhchem
  • 3,485
  • 12
  • 37
  • 1
    OT1 encoding is weird do you have to use that or can you use T1 (when the same characters are in the same slots for all fonts) – David Carlisle Jan 04 '16 at 01:20
  • 3
    cmtt is a monospace font, so what do you expect textemdash to do in that case? make a dash the same width as - or break the monospace nature of the font and make a double length dash or make a dash a bit longer than - but still with the same character width,m just smaller sidebearing or.... – David Carlisle Jan 04 '16 at 01:23
  • 1
    Please do not use minimal for examples as it is not suitable. – cfr Jan 04 '16 at 01:28
  • @DavidCarlisle 1. I want to use that in my package. What options do I have concerning input encoding? 2. I'd would use whatever the font creator defined as 'en dash'. I don't mind if it looks indistinguishable from a normal dash. And in case there is no definition, I'd just fall back to the normal dash. – mhchem Jan 04 '16 at 01:31
  • @cfr Why is minimal not suitable for minimal working examples? – mhchem Jan 04 '16 at 01:32
  • @mhchem See http://tex.stackexchange.com/questions/42114/why-should-the-minimal-class-be-avoided?s=2|0.0000. – cfr Jan 04 '16 at 02:10
  • @cfr I read that and learned a bit. I also read the linked https://tex.stackexchange.com/questions/20974 that comes to a different conclusion. – mhchem Jan 04 '16 at 02:37
  • As far as I know, the current consensus is that it ought not be used for examples here. Note that the advantages mentioned there concern debugging (where it does have advantages) and standalone graphics without any text (where standalone would be a better choice or so people now seem to think). Neither of those applies to your example. – cfr Jan 04 '16 at 02:55
  • But really you should ask @DavidCarlisle for follow up on this. I'm just going by the reasons given to me for not using this class for examples here by those involved in writing the class originally and those currently involved in developing the LaTeX kernel. – cfr Jan 04 '16 at 02:57

1 Answers1

5

Mostly what you are seeing is just an artifact of OT1 encoding which isn't really as single encoding at all: each of the classic tex fonts has a separate encoding, and notably the tt font is quite different so that verbatim printing of ascii works.

With T1 you get more consistent results.

enter image description here

\documentclass{article}
\usepackage[T1]{fontenc}
\begin{document}
  This -- should work the same \textendash{} in any font.

  \ttfamily
  This -- should work the same \textendash{} in any font.
\end{document}

You can't really automatically detect from TeX which character is in which slot. The LaTeX font setup just decided to pretend that all the classic fonts had the same "OT1" encoding in order to give a half sensible interface. So as you can not tell the character shapes, you can not detect by testing that the encoding of cmtt is really not the same as the encoding of cmr.

David Carlisle
  • 757,742
  • This means, I have no chance to provide a LaTeX package that consistently outputs an en dash, because it may be used in documents with different encodings and different fonts? I knew that this limit would be somewhere, but did not expect it to be at the 'dash level'. – mhchem Jan 04 '16 at 01:36
  • 1
    @mhchem it's only going to fail in OT1 encoded ttfamily so you can write a command that just uses - in that case and uses the normal \textendash everywhere else. – David Carlisle Jan 04 '16 at 01:39