# [texhax] TeX Queries (2): Artificial Break

Paul Stanley paulrichardstanley at gmail.com
Sat Jul 14 23:28:13 CEST 2012

``` >  > Extract from TeXbook:
>  > "The `|\/|' tells \TeX\ to add an \break
>  > % makes the line tighter, to be fair
>  > ``{\sl^{italic correction}\/}'' to the previous letter, depending on
>  > that letter; this correction is about four times as much for an `\$f\$'
>  > as for a `\$c\$', in a typical italic font."
>  >
>  > What does the author mean by "makes the line tighter"?
>
> If the artificial break weren't there the line would be stretched too
> much; in other words, it's just a hand-made justification.
>
> Just to confirm, by "artificial break" are you refering to `\/' ?

Oh, no, I refer to \break, which is what the commented expression "makes
the line tighter, to be fair" also refers to. This has nothing to do
with what is being talked about here.

If I'm not mistaken, you're using a screen reader, and perhaps it got
things wrong here; what Don Knuth is saying is (removing macros):

The `\/' tells TeX to add an ``italic correction'' to the previous
letter ...

Then he adds \break after the word ``an'' so that TeX breaks the line
here instead of elsewhere, because TeX's default result here is not very
good. His remark about a tighter line comments on the use of \break, not
italic correction at all.

Thank you. It seems we were at cross purposes there.  I won't ask you
about the "default result"; however, I get the impression that
without looking at the end result one wouldn't be able to make the
necessary comparison and decide whether or not the `\break' insertion
was preferable.  By the way I do use a screen reader.

>  > What does "italic correction" actually mean?
> 		[snip]
>
> The italic correction adds a thin kern whose width depends on the
> preceding character; for instance, after an `f', it is much larger than
> after a `c', because in the former, the difference between the glyph's
> declared width and its real, visual width, i.e. its rightmost point,
> is much larger than in the latter. You can try this:
>
> Sorry, I'm not quite sure what you mean by the "declared" and "real" widths.

Well then I wasn't exactly crystal clear. Let's try again: the width
of a glyph is technically independent of the drawing of that glyph.
Suppose for instance that a glyph's rightmost point is at x-coordinate
50; then the glyph's width could very well be 52. What I have called
the ``real'' width is 50, and the ``declared'' width is 52; in other
words, all glyphs have a little bit of space on either side so that

For some glyphs, however, and italic glyphs in particular, especially an
italic ``f'', the declared width is smaller than the rightmost point; in
the above example, the declared width would be, say, 48; that means that
the glyph's right side hangs over the next glyph, which is generally
good, as long as the next glyph is in italic too; with an upright
parenthesis, things go wrong, hence italic correction.

I hope I've been clearer this time!

yes thank you, it is much clearer; though of course, I have some new
questions (I aint letting go yet :) ):

How is the declared width actually measured (i.e. where are the start
and end points of the declared width)?

is there a declared height as well, and if so, can the declared width
be different at different declared heights?

How can the declared width be less than the real width?  I've this
image of a painting taking up more space 	than is available on the
canvas, or is it the case that the declared width can be less than
the real width only in parts where kerning is possible? Incidentally,
I'm using the term kerning in the original sense as defined by
wikipedia (http://en.wikipedia.org/wiki/Kerning )

Does the algorithm determining the gap between two italic glyphs
perform kerning --- shaving off the declared width --- on both
adjacent glyphs, or just the preceding glyph?

Sorry for getting a bit bogged down in this. It's only through these
questions and indeed your answers that I am able to build a mental
picture of what's hidden from the screen reader in a PDF or DVI presentation.

Many thanks,
Paul

```