[Fontinst] fontinst fontdsize variance?

[Lars Hellström]

Karl Berry skrev 2016-02-08 19.47:
> [Lars and I have had an exchange about design size variances.  We
> thought we should resend it to the list for public archiving.  So
> several messages follow, slightly edited. --karl]

That ended up a bit confusing, I fear; my mails (delivered by Karl) with 
original timestamps, and his with forward-time timestamps. Oh well...

Since the patch I produced last week apparently does not apply cleanly to 
the sources on CTAN, I've made a full archive available for download instead:
http://www.mdh.se/polopoly_fs/1.85446!/Menu/general/column-content/attachment/fontinst-1.935.zip
(This kind of quick "put it on the web" action has certainly gotten a lot 
tricker since universities started appointing Mordac the Preventer of 
Information Services as webmaster by default. In academia, the Web has 
deteriorated considerably since the turn of the millenium. Anyhow...)

I think the new version fixes the problem cleanly without introducing any 
other problems, but I'd better get the original reporter a chance to try it 
out as well before proceeding to a CTAN upload.

What I had to change was to make fontinst preserve _all_ the digits of the 
designsize as given, which basically means one cannot temporarily store it 
into a dimen register; instead it needs to be treated as a plain sequence of 
character tokens. This means the unit is just a nuisance, so in addition I 
changed how fontinst stores mapfont information in glyphbases. First, the 
designsize is now stored without a unit in \g-GLYPH macros (even though the 
unit is still there in the \set(scaled)rawglyph argument, for backwards 
compatiblity). Second, the actual digits of the designsize are hidden away 
in a helper macro, to reduce memory usage; since the number of distinct 
designsizes encountered on any single run is quite low (maybe a dozen for 
extreme cases like the EC fonts, very often just one), the repetition is 
considerable. (These per-designsize helper macros are a bit like the robust 
commands in LaTeX2e, and will expand away as soon as \saved_mapfont is 
redefined to not be \relax.)

There should be no changes in the normal catcodes interfaces.

I also discovered (and fixed) an _old_ bug relating to the designsize, which 
was not just an issue about it being less than an sp off like that Karl 
forwarded. It turns out \mtx_to_pl (which writes ligless PL files for base 
fonts) had hardwired the value of 10.0pt for the designsize, regardless of 
what the \setrawglyph commands said. Since the VPL gets its (MAPFONT 
(FONTDSIZE ...) ...) from the \setrawglyphs, this would also lead to vftovp 
complaining about the wrong designsize in the VF. On the other hand it was a 
bit hard to hit this bug, because the only way to get glyphs with designsize 
other than 10pt is to get the metrics from a PL, and \frompl for obvious 
reasons doesn't do \mtx_to_pl. However if someone had been out to fake a 
cmsl5 by doing

   \transformfont{cmsl5}{\slantfont{167}{\frompl{cmr5}}}

(don't know what DVI drivers would do if asked to slant a MetaFont, but a 
cmr5.pfb obviously can be slanted) then previously that cmsl5.pl would have 
said (DESIGNSIZE R 10.0) wheras cmsl5.mtx would have 
\setrawglyph...{5.0pt}... The designsize may be just a silly magic number 
for the virtual font mechanisms, but this case I think vftovp would have a 
point in complaining.

Come to think of it, though: there seems to be a similar issue with ligful 
PLs (do I notice now when writing this); that one need not be as easy to 
fix. But can anyone figure out how to trigger it? If not then I might be 
inclined to let in slide...

Lars Hellström