Reinhard Kotucha reinhard.kotucha at web.de
Mon Oct 4 12:55:45 CEST 2010

On 4 October 2010 Robin Fairbairns wrote:

> Karl Berry <karl at freefriends.org> wrote:
>
> >     Subject: [tex-live] The adforn package.
> >
> > Thanks for the report, but this bug needs to go to the package
> > maintainer, ie, Clea.  I've forwarded it.
>
> istm this is a latex-on-mac bug rather than something of clea's.

I can reproduce the problem on Linux too with the following file:
----------------------------------------
\documentclass{article}
\begin{document}
\end{document}
----------------------------------------

----------------------------------------
(/usr/local/texlive/2010/texmf-dist/tex/latex/psnfss/pifont.sty
(/usr/local/texlive/2010/texmf-dist/tex/latex/psnfss/upzd.fd)
(/usr/local/texlive/2010/texmf-dist/tex/latex/psnfss/upsy.fd))

LaTeX Font Warning: Font shape U/OrnementsADF/m/n' undefined
(Font)              using U/cmr/m/n' instead on input line 4.

----------------------------------------

When I remove the comment character in the file above, I get:
----------------------------------------
(/usr/local/texlive/2010/texmf-dist/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/local/texlive/2010/texmf-dist/tex/latex/base/size10.clo))
(/usr/local/texlive/2010/texmf-dist/tex/latex/psnfss/pifont.sty
(/usr/local/texlive/2010/texmf-dist/tex/latex/psnfss/upzd.fd)
(/usr/local/texlive/2010/texmf-dist/tex/latex/psnfss/upsy.fd))

LaTeX Font Warning: Font shape U/OrnementsADF/m/n' undefined
(Font)              using U/cmr/m/n' instead on input line 4.

----------------------------------------

The warning is still there, it's obviuosly triggered by pifont.sty and

> some time back, in some contorted logic related to case-insensitive
> file systems, it was decided that latex would accept fd files with
> the coding name ("u" in this case) in either upper or lower case,
> with lower case being the default.

I remember that too, but there still seems to be an inconsistency in
LaTeX.  If you need a particular font encoding, you have to load it in

The relevant piece of code in fontenc.sty is:
----------------------------------------
\DeclareOption*{%
\let\encodingdefault\CurrentOption
\edef\reserved at f{%
\lowercase{\def\noexpand\reserved at f{\CurrentOption enc.def}}}%
\reserved at f
\InputIfFileExists\reserved at f
[...stuff omitted...]
----------------------------------------

But there is no <encoding>enc.def file for U (unknown) encodings.
Thus, this piece of code is never executed here.

In pifont.sty we have:
----------------------------------------
\newcommand{\Pifont}[1]{\fontfamily{#1}\fontencoding{U}%
\fontseries{m}\fontshape{n}\selectfont}
\newcommand{\Pisymbol}[2]{{\Pifont{#1}\char#2}}
----------------------------------------

I suppose that \fontencoding{U} assumes an uppercase U when the name
of the the .fd file wasn't assembled by fontenc.sty already before.
And fontenc.sty isn't and can't be used here because there is no file
uenc.def.

Instead of renaming the file, I recommend to apply the following
patch:

----------------------------------------
@@ -1,5 +1,6 @@
\NeedsTeXFormat{LaTeX2e}
\RequirePackage{pifont}
----------------------------------------

Then file name conventions will remain consistent.

> is macos' file system case insensitive?  (i thought not, but i've
> no easy way of testing.)

AFAIK it's configurable, but it's case insensitive by default.  But I
assume that it's case-preserving at least, like NT-based Windows.

BTW, I wouldn't expect this problem on case-insensitive file systems
to be one and the same file, isn't it?  You can't even have both files
in the same directory.  Since I can reproduce the problem on Linux, I
doubt that it's a file system issue at all.

Furthermore, I suppose that Clea tested it on a case-insensitive file
system and thus didn't encounter the problem.  Clea, can you confirm?

Regards,
Reinhard

--
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------