[Fontinst] fontinst fontdsize variance?
Lars Hellström
Lars.Hellstrom at residenset.net
Thu Feb 11 18:58:44 CET 2016
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
More information about the fontinst
mailing list