[Fedora-packaging] Re: Best way to add a line to a config file from another package?

[Vasile Gaburici]

On Wed, Aug 13, 2008 at 5:17 PM, Patrice Dumas <pertusus at free.fr> wrote:
> On Wed, Aug 13, 2008 at 04:26:00AM +0300, Vasile Gaburici wrote:
>> Well, changing the default configuration file is not necessarily
>> something that dvips developers need to hear about. The original
>> config.ps file has section saying:
>> % This shows how to add your own map file.
>> % Remove the comment and adjust the name:
>> % p +myfonts.map
>
> I may be missing something, but it seems to me that we shouldn't
> hardcode map files in here, but instead use updmap.

Yes, you are missing something. By default dvips uses a single map
called psfonts.map[*]. What updmap esentially does is is to keep that
in sync with 2 other maps (for pdftex and dvipdfm), starting from a
single source: updmap.cfg. But if we add type 42 fonts, we *don't*
want pdftex and dvipdfm map files to have the same entries as dvips.
So using an additional map for dvips, which overrides some entries in
the one generated by updmap, is reasonable.

[*] I've glossed over the fact that there are two files psfonts_t1.map
and psfonts_pk.map, but only one is read via a symlink. The symlink is
changed by updmap depending on whether you set  dvipsPreferOutline to
true or false.

Before my patch, otftotfm alrady installs it's own map, called
lcdftools.map, which serves as the master source map for the fonts it
has installed. It adds this map to updmap.cfg, so when updmap runs, it
basically copies any entries in lcdftools.map to the 3 maps (dvips,
pdftex, dvipdfm).

With my patch, otftoftm also creates a map called psfonts_t42.map, in
which it puts any t42 entries for the fonts it has installed. Except
that you don't need to run updmap to blast these entries to dvips
because it reads it directly (thanks to config.ps). It's okay not to
spread any of these t42 entries to other maps because no other program
can read those fonts. Actually, if you put a t42 font entry in
pdftex's map, it won't load the font at all.

I know this a bit hard to follow. I'll update the src rpm so you can
test this. I'm not adding any scriptlet for now, but I'll put
instructions for changing your user's config.ps in README.fedora.

>> However, if one were to change updmap to add ".t42" entries instead of
>> ".ttf" to psfonts_t1.map instead of my solution of using an additional
>> map, then one needs to make sure that the TeX distro ships t42
>> counterparts for all ttf fonts it ships because there is no fallback
>> for dvips anymore if dvipsPreferOutline is enabled. And there are some
>> ttf fonts shipped with TeXLive, but obviously no t42 versions.
>
> What about generating t42 versions, or have them in a package that dvips
> depends on (on fedora...)? And then patch updamap to use t42 fonts in
> priority over ttf fonts?

That was actually my first idea before I discovered that dvips can
read multiple maps by itself. It seems simpler, but it is far harder
to make work properly. If updmap automatically wrote t42 entries
instead of ttf entries into a single dvips map, then you'd have to
guarantee somehow that every ttf font has a t42 counterpart. Which is
not easy, because updmap is designed as "dumb" file synchronization
tool, not a font installer. Basically, it would have to check if the
t42 file exists, if not it would have to call otftotfm, which
essentially the reverse of how things are layered now, i.e. otftotfm
invokes updmap after all the required font files have been generated.
Updmap wansn't meant to do any of that. I doubt upstream would ever
accept the mission creep and significant changes in updmap that would
enatail.

>> It's not clear if dvips is even supported/maitained anymore by Radical
>> Eye. Their web page [http://www.radicaleye.com/dvips.html] says "To
>> get the latest version of dvips, simply get the latest version of
>> teTeX or some other TeX distribution that includes dvips. [...] I no
>> longer support installation of dvips independent of full installation
>> of a TeX distribution." So, presumably we'd have to send the patch to
>> TeXLive. Adding an additional map seemed a lot simpler than dealing
>> with this mess...
>
> It indeed seems that dvips is maintained by texlive folks, at least
> that's the conclusion I came to when looking at what should come from
> texlive or not.
>
> --
> Pat
>
> --
> Fedora-packaging mailing list
> Fedora-packaging at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging
>
>