# [OS X TeX] TL2008 destroys my geometry

Herbert Schulz herbs at wideopenwest.com
Sun Jan 4 12:36:25 EST 2009

On Jan 4, 2009, at 11:01 AM, Alain Schremmer wrote:

> On Jan 4, 2009, at 11:37 AM, Peter Dyballa wrote:
>
>> you must not dictate how an user typesets his or her documents.
>> Particularly foul is to load an input encoding clandestine. This
>> will print an u from an input x (or something like that). The
>> decision on encodings used belongs to the user, not the package
>> author
>
> This anarchist agrees. But, the freedom must be real, that is the
> decision on encodings must be CLEARLY posed to the user who must
> understand it. I for one have no idea what the whole thing is.
>
> Best regards
> --schremmer

Howdy,

I assume you are talking about the whole encoding mess.

The problem is that once you get past the basic 128 character ASCII
set there have been multiple, INCOMPATIBLE ways of representing
(encoding) the extended character set; e.g., Mac Roman, Latin 1,
UTF-8. The last encoding is the first that seems to have universal
acceptance. TeX got around this problem by only using ASCII characters
and macros to construct accented character, etc. In LaTeX the inputenc
package allows for a translation from the stored encoding to something
LaTeX can understand.

There are actually three things that must cooperate. The Editor must
save and read the source file in a known encoding so that it can
display the extended character set correctly. In TeXShop this is done
with a line such as

%%!TEX encoding = UTF-8 Unicode

near the top of the file before saving the file (or changing the
default encoding to UTF-8 in TeXShop->Preferences). The second is to
tell LaTeX how to interpret the extended character set (i.e.,
understand the a certain character number means é) using a line like

\usepackage[utf8]{inputenc}

for UTF-8 encoding. Finally the font you are using must have that
character in a certain location in the font file. To do this a line like

\usepackage[T1]{fontenc}

tells LaTeX how to map the particular input code to an actual glyph to
be printed with ink onto the paper. Oh, one more thing, the font
itself must have the character or a blank glyph will be printed; e.g.,
the Latin Modern fonts, an extended version of Computer Modern, does
have the character while Computer Modern doesn't.

Hope that I've got that right and it's comprehensible.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)