129

I typically use

\textit{Some italicized text}

while some of my colleagues use

{\it Some other text}

Should I bother changing one or the other, or does it matter?

Related:

Is there any reason not to use \let to redefine a deprecated control sequence to the currently recommended one?

5 Answers 5

126

From l2tabu:

Why not use obsolete commands? Obsolete commands do not support LaTeX2e's new font selection scheme, or NFSS. {\bf foo}, for example, resets all font attributes which had been set earlier before it prints foo in bold face. This is why you cannot simply define a bold-italics style by {\it \bf Test} only. (This definition will produce: Test.) On the other hand, the new commands \textbf{\textit{Test}} will behave as expected producing: Test.

Apart from that, with the former commands there is no ‘italic correction’, cf. for instance halfhearted ({\it half}hearted) to halfhearted (\textit{half}hearted).

enter image description here

4
  • 14
    To be fair, it's not really that hard to write {\it half\/}hearted. This is how it would be done in TeX, after all.
    – TH.
    Commented Aug 29, 2010 at 2:27
  • 28
    It should be noted that when the blockquote talks about “obsolete”, it means obsolete in >= LaTeX2e. Those commands are not obsolete in Plain-tex or ConTeXt.
    – morbusg
    Commented Jul 29, 2011 at 4:28
  • 2
    (I'm not sure, if there commands existed 2010, but) what about {\bfseries textOne {\itshape textTwo}}? Are they outdated too? What are they for? {\itshape half}hearted doesn't work nice.
    – user1
    Commented Sep 3, 2017 at 20:42
  • 2
    @Ben They the corresponding "switching" commands and stack correctly (i.e. \itshape\bfseries produces the correct output). Useful for some layout definitions (e.g. in KOMA or titlesec).
    – Caramdir
    Commented Sep 11, 2017 at 18:43
52

Hmm, I just posted this as an answer to another question, but just as I was posting, that question was closed—with a referral here. So I'll throw in my 2¢ here...

The reason I don't like \it and \bf is that they do not play well together. That is, they do not nest as one would intuitively expect:

Whereas \textit and \textbf do play well together:

This is nice. However, you may notice that it still fails to handle nested style adjustments to small caps, since the Computer Modern fonts do not contain slanted or bold small caps:

If this is a problem for you, then what I recommend—and I just happened to learn about this yesterday myself—is the wonderful slantsc package in combination with the lmodern package. slantsc provides, among other things, \rmfamily (roman), \ttfamily (typewriter/​teletype), \sffamily (sans-serif), \bfseries (boldface), \itshape (italics), \slshape (slant/​oblique), and \scshape (small caps). With these, small caps can obtained in slanted form:

As a bonus, slantsc fixes \textsl to behave properly with \textsc, so you can continue using those if you like.

Alas, I haven't yet found a package which fixes the behavior of nested instances of \textit. In typesetting, when you nest italics, you're supposed to come back out of italics to roman. For example, the word "Titanic" below is in nested italics:

Tanaka, Shelly. On Board the Titanic: What It Was Like When the Great Liner Sank. New York, NY: Hyperion/​Madison Press, 1998.

As a workaround, you can usually write \textrm to temporarily return to non-italics in those cases, but of course this is only valid if you know the exact number of nested italic levels, which may not always be the case, especially inside a macro.

Update:

As others have pointed out, \textit and \textsl do automatic italic correction, whereas \it, \itshape, \sl, and \slshape do not. Thus, you can write \textit{stuff}, but you must write {\it stuff\/} or {\itshape stuff\/} to get the same effect.

5
  • 11
    I would not expect \textit (or any other command intended to do italics) to generate non-italic text. On the other hand I'd expect \emph (which is used to emphasize) to switch to italics if not already in italic mode while to switch off italics when in italic mode (because emphasizing is usually done this way). And guess what, that's exactly what \emph does. The correct way to type the title above therefore is: On Board the \emph{Titanic:} What It Was Like When the Great Liner Sank. Note that Titanic is emphasized, not italicised.
    – celtschk
    Commented Jan 20, 2012 at 19:42
  • 1
    @celtschk: Cool, I did not know that! (Or I think I did once long ago and forgot!) Thanks so much for pointing this out. Commented Jan 23, 2012 at 17:03
  • 1
    Note that cfr-lm will give you access to the same features but uses slightly different commands. cfr-lm relies on virtual fonts but also makes other features of the LM family available (e.g. different styles of figures, different weights etc.). Disclaimer: I wrote cfr-lm.
    – cfr
    Commented Dec 17, 2013 at 23:46
  • 3
    @celtschk, ‘Titanic’ is not set in italics because it’s emphasized, but because its a custom of English typography to italicize names of vessels, like (family) names are set in small caps elsewhere. Therefore using \emph would be inappropriate.
    – Crissov
    Commented Jan 29, 2014 at 10:30
  • 2
    Note that Latin Modern also features an upright italic font.
    – cfr
    Commented Apr 27, 2015 at 2:47
40

The \it syntax is inherited from LaTeX 2.09, and is regarded as supported 'for historical reasons only' in LaTeX2e. For bold, you should go for \textbf rather than \bf. For italic, you'd usually use \emph rather than \textit as it's semantic mark up and as it handles the italic correction automatically.

14
  • 49
    I beg to differ. If you want to set italic text, \textit is the way to go. But if you want to emphasize some text, then you should use \emph{}.
    – qbi
    Commented Jul 28, 2010 at 20:12
  • 19
    It's very rare that you want inline italic that isn't in some way semantic. For longer blocks, \itshape is the way to do things, of course.
    – Joseph Wright
    Commented Jul 28, 2010 at 20:24
  • 1
    Of course, semantic markup should always be preferred over syntactic one, but the question was specific about the difference between \textit and \it Commented Jul 28, 2010 at 20:45
  • 4
    Or, if you want a command that is used in the same way as \it, use \itshape.
    – Sharpie
    Commented Jul 28, 2010 at 21:53
  • 15
    \emph is semantic: it says 'make things emphasised'. On the other hand, \textit means make this italic. By convention, \emph makes things italic, but you can redefine it to do something else (for example, the beamer class makes text red). On the other hand, \textit is always italic. So it is usually advised to use \emph in a document, using \textit only when you need definitely italic text. This might make a good question, as I'd then have more space to give detail!
    – Joseph Wright
    Commented Aug 18, 2010 at 18:25
3

I don't completely agree with Caramdir's answer, since it is true that \it should not be used because it is obsolete, however the corresponding non-depreciated command is \itshape.

So, in your example \it should be replaced with \itshape. However, in some cases as for \textit{half}hearted vs {\itshape half}hearted, the former is preferable.

2
  • Is this a new answer or is it a replication of Caramdir comment or Todd Lehman answer?
    – Bobyandbob
    Commented Oct 1, 2018 at 16:35
  • 1
    @Bobyandbob: It is a new answer since without the comment Caramdir's answer is misleading: it asserts that \it is obsolete since it has no italic correction. Todd Lehman on the other hand points out that \bf and \it don't play well together, however they should be replaced with \bfseries and \itshape (so is not a reason to change to \textbf/\textit)! He also wrongly implies that you need the package slantsc for \itshape and \bfseries, which is not true
    – estownya
    Commented Oct 1, 2018 at 20:23
3

Regarding the deprecated "old font commands", I find them quite useful for equations.

Let's say e.g. that I want to write a symbol for an external potential as $V_{ext}$. However, it is a common convention to use upright characters for subscripts and superscripts that are labels rather than variables, which can be written as either

V_{\mathrm{ext}}   or
V_{\rm ext}

I strongly prefer the latter, as the lower character-count and nesting-level makes reading and editing easier. Though there are cases where the advantage is diminished, e.g. with vector component notations like

f_{\mathrm{ext},i} vs
f_{{\rm ext},i} or
f_{\rm ext\it,i}       % <- not tested

Some modern document classes do not provide the old-style commands anymore. In this case, they can be reintroduced with \DeclareOldFontCommand, see e.g. What exactly does \DeclareOldFontCommand and \DeclareRobustCommand do?.

7
  • Yeah, I think it was a dumb choice to deprecate and move to a command with more characters, why not just redefine \rm with the new functionality, or provide a package that makes pointers such that the better shorter name can be used.
    – RJ Acuña
    Commented Feb 17, 2022 at 19:18
  • @RicardoAcuna Redefining existing commands can have all sorts of nasty follow-up effects. E.g. a bibliography style may depend on the old style commands and then silently do the wrong thing (which is generally worse than an error message). As for the "more character" commands: I think we got bitten there by a "cleaner, more uniform syntax" (good practice for programming) vs "everyday typesetting usability" trade-off.
    – kdb
    Commented Feb 19, 2022 at 9:31
  • You forget latex isn’t designed to be a programming language, I know it’s Turing complete. But, the point of latex is every day typesetting. Maintainers treat it as a programming language, that’s stupid. It’s not it’s a typesetting program, so usability trumps uniform syntax.
    – RJ Acuña
    Commented Feb 19, 2022 at 21:47
  • I mean I guess back-compatibility is important. But instead of deprecating, they could add a versioning package \usepackage{latexv2022} just full of pointers. That way you don’t break back compatibility because the pointers are just local to the Tex file.
    – RJ Acuña
    Commented Feb 19, 2022 at 21:51
  • 1
    @RicardoAcuna I agree there, it is not a programming environment. I just suspect, that treating it as one is what got us the deprecation of \rm and the like.
    – kdb
    Commented Feb 19, 2022 at 23:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .