[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in fontinst?

>Rebecca and Rowland wrote:
>> Now then...  fontinst.sty says this:
>> \declareencoding{TEX~TEXT~WITHOUT~F-LIGATURES}{OT1}
>> which is clearly wrong.   The problem is that there doesn't appear to be a
>> suitable .etx file supplied with fontinst for this encoding; nor does there
>> appear to be a fontname code for this encoding.  Any suggestions?
>OK, this is clearly wrong.  I guess the fix is to come up with a new
>encoding name (eg OT1n) and then add a line

Righto.  I have, by the way, produce an encoding file which appears to do
the job.  Would anyone like to have a look at it with a view to including
it with fontinst?

>But this doesn't solve the problem, since as you observed:
>> Another problem is that, even if an appropriate etx file were written, it
>> would still produce an incorrect .mtx file, because cmcsc10 is a small caps
>> fount (cmr5 also uses TEX TEXT WITHOUT F-LIGATURES encoding).
>Not much I can do here, since there's a culture clash about what
>constitutes an encoding here.  Knuth's idea is that a small cap A is
>logically the same as a letter `a', so the encoding of cmr5 and cmcsc10
>is the same.  Adobe's idea is that a small cap A is optically not the
>same as a letter `a'.

If only!  Adobe's idea is that a small cap A is optically not the same as a
letter `a' in the case of expert encoded founts, but that a small cap A is
logically the same as a letter `a' in the case of SC & OsF founts.

> And fontinst is stuck in the middle.
>Knuth's fonts don't contain enough info for fontinst to be able to work
>out whether the font is a small caps font or not.  This is a tricky one
>to fix, since the problem is in the conversion phase .pl -> .mtx, and
>the .mtx file is cached, so you can't rely on it being generated when
>you read in cmr5.pl.  The nearest fix would be to create a file
>   \declareencoding{TEX TEXT WITHOUT F LIGATURES}{OT1c}
>then use it when reading in cmcsc10, eg:
>   \installfont ... {hacksc,cmcsc10,otherstuff} ...
>but this won't work if cmcsc10.mtx has already been generated.

Indeed.  What about Lars's idea? :

>As for the problems with declaring encodings so that \pltomtx chooses the
>correct ETX file: Shouldn't the easiest solution be to include a
>"\pltomtxwithetx" command in fontinst that allows the user to explicitly
>specify which ETX file to use, for use in cases like cmcsc10 when the
>information in the PL file simply isn't enough?

And would it perhaps be possible to add an extension to fontinst's command
set so that you could force it to to a pltomtx conversion while using

>> I had a look at ot1c.etx to see if that could be any help; it says that:
>> % This is used exclusively to install faked small-caps fonts;
>> % real small caps fonts are installed using the default T1.etx.
>> Since this is wrong - you can't install an OT1 encoded real small caps
>> fount using T1.etx - I'm at a bit of a loss.
>This comment just means `nobody should be using OT1 these days, it's
>just legacy software'.

Ah...  If only this were true.  LaTeX uses OT1 encoding by default; I for
one have no idea how to create a LaTeX format that uses T1 encoding by
default.  We're going to be stuck with most people using OT1 for most
things until this situation changes.

>As you may note, I dind't put a huge amount of effort into the OT1
>support, since there's just too many ideosyncracies about OT1 (eg the
>encoding changing under your feet!)  I just use T1 these days...  Not
>that that's much use...

It wouldn't be so bad if Adobe were any more consistent, would it?