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


Reply via email to