[tex-live] packaging

[cfrees at imapmail.org]

On Sat 10th Jul, 2010 at 22:49, Karl Berry seems to have written:

>    Suppose a line contains this reference:
>            <ts1-euro.enc
>    This presumably requires a matching file name so can I simply change it
>    to:
>            <yyy-ts1-euro.enc
>    for example?
>
> Yes, that's what I had in mind (and what other fonts do).

OK. Good. I understand that much.

>    I'm not sure what the last entry on the .map file lines does:
>            " fontinst-autoenc-ts1-euro ReEncodeFont "
>    This matches the following line in the encoding file:
>            /fontinst-autoenc-ts1-euro [
>    Does this need to match the filename? Or can this be left?
>
> The PostScript name (/fontinst...euro) doesn't *have* to match the
> filename (indeed, it doesn't), but it's probably asking for trouble not
> to also have it be unique across fonts, in the event that one day the
> two definitions are actually different.  I.e., better to add the yyy-
> there too.

I'm not sure I follow this. The definition of /fontinst...euro is the
stuff between the square brackets in the .enc file, correct? I would
have thought it would make sense for that to be the same across fonts
just because the encoding is the same.

If I found I needed a different encoding file, I wouldn't alter
ts1-euro.etx/ts1-euro.enc, I'd write a new .etx file and generate a new
.enc file. (Exceptions: if I found I'd made a mistake, I suppose; or if
I wanted to change the .etx file in a way which wouldn't affect the
.enc file; or if ts1.etx/ts1.enc changed; etc.)

> The problem I envision is this: a year from now, someone points out that
> font x now has ts1 character foobar, while font y still does not.  At
> that point, ts1 for x is going to want to be different from ts1 for y.
> And if the names are not distinct in the first place, compatibility
> could suffer.  It's just more robust and simpler (not for the
> implementor :) to keep them as separate names from the start.
>
> Wdyt?

I'm not understanding the problem. Suppose font x currently lacks
copyleft, say, to take a concrete ts1 character commonly missing, as
does font y. OK, so next year, x is updated to include copyleft but y
still lacks it. That's fine. The encoding file is just based on the etx
file and so included copyleft from the start. The definition doesn't
need to change.

I'm obviously not seeing the problem because I'd think changing the
name would just make things more confusing. It means having
 	/fontinst...euro-x = /fontinst...euro-y = /fontinst...euro
which will work, but seems needlessly complicated. A bit like having
many different commands with the same definition - it will work but
seems to introduce complications to no purpose. What am I missing?

- Clea