[lucida] Instructions on updmap-sys (Type 1)

[Bruno Voisin]

> Le 25 juin 2016 à 06:13, Norbert Preining <preining at logic.at> a écrit :
> 
> On Fri, 24 Jun 2016, Bruno Voisin wrote:
>>>> Did you try "Map=lucida.map" instead of "Map lucida.map"? This
>>>> shouldn't matter, but you never know.
>>> 
>>> Aha, that is spot on! The very same command with Map=lucida.map does work this time! It looks it matters after all, at least on my system. :)
> 
> That is strange ... we use 
> 	Getopt::Long
> for argument processing, and that should support the above both
> styles on practically all systems.

Based on the initial error message, posted later by Paulo, the problem might not be connected with "=" at all. Here's what I think happened in the three steps reported by Paulo:


- Originally with "--enable Map lucida.map", probably because of a pre-existing lucida.map already referenced in updmap.cfg, updmap considered nothing had changed and refused to proceed further, yielding

/usr/local/texlive/2016/texmf-config/web2c/updmap.cfg unchanged.  Map files not recreated.


- Then with "--enable MixedMap=lucida.map" updmap.cfg changed, prompting updmap to proceed. If that interpretation is correct, the use of MixedMap in itself wasn't the reason things worked, nor "=", just the fact they caused updmap.cfg to change.


- Trying finally "--enable Map=lucida.map" caused again updmap.cfg to change, and updmap to proceed. Again not because of the "=", but because of the implied updmap.cfg change.


Often a few years back, with teTeX's original (very slow) shell-based updmap, I was hit by this while testing font installation and had to resort to the two-step process

sudo updmap-sys --disable test-map-file.map
sudo updmap-sys --enable Map test-map-file.map

in order to coerce updmap into taking into account changes inside the file test-map-file.map.

Bruno