[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A question about spacing



I've just tried out the eco bundle of virtual founts to use old style
numerals by default with the ec founts (CTAN/fonts/eco/) and discovered
that TeX finds it harder to work out decent line breaks.  The difference is
enough to cause overfull \hboxes in normal 11pt prose on A4 paper using the
standard width; switching to `straight' ec gets rid of the problem, as does
slackening TeX's typesetting parameters.  Now then, I'm not keen on making
TeX sloppier, and using the ec founts is missing the point of having the
eco founts.  A better solution is needed.

Now then, the vfs etc were created by fontinst from the ec pl files like this:

\input fontinst.sty

\declareencoding{TEX TEXT COMPANION SYMBOLS 1---TS1}{TS1}

\installfonts

\installfamily{T1}{cmor}{\hyphenchar\font='177 }

\installfont{ecorm0500}{ecrm0500,tcrm0500}{T19}{T1}{cmor}{m}{n}{<5>}
(etc)

I would have thought fontinst would use all the data from the pl files to
create the new vpls, but it seems that it does not use the spacing
information.  I've just asked the author (Sebastian Kirsch
<skirsch@t-online.de>) of the eco set about the problem, and he tells me:

>It seems that the font dimens of fonts produced by fontinst are all a
>little tighter than the original fonts. You can see this from the
>following extracts from ecorm1000.pl and ecrm1000.pl:
>
>--- ecorm1000.pl                --- ecrm1000.pl
>(FONTDIMEN			(FONTDIMEN
>   (SLANT R 0.0)		   (SLANT R 0.0)
>   (SPACE R 0.332996)		   (SPACE R 0.333252)
>   (STRETCH R 0.109998)		   (STRETCH R 0.166626)
>   (SHRINK R 0.109998)		   (SHRINK R 0.111084)
>   (XHEIGHT R 0.429993)		   (XHEIGHT R 0.43045)
>   (QUAD R 1.0)			   (QUAD R 0.999756)
>   (EXTRASPACE R 0.109998)	   (EXTRASPACE R 0.111084)
>   )				   (PARAMETER D 8 R 0.6831665)
>				   (PARAMETER D 9 R 0.694275)
>				   (PARAMETER D 10 R 0.891449)
>				   (PARAMETER D 11 R 0.194397)
>				   (PARAMETER D 12 R 0.891449)
>				   (PARAMETER D 13 R 0.249939)
>				   (PARAMETER D 14 R 0.499878)
>				   (PARAMETER D 15 R 0.088867)
>				   (PARAMETER D 16 R 1.199997)
>				   )
>---
>
>Perhaps this is a bug in fontinst, I don't know; it may be a simple rounding
>error.
>
>_Someone_ should perhaps ask Alan Jeffrey why fontinst changes the font
>dimens.

So I thought I might as well do the asking myself.  Has anyone got any idea
what's going on, why it's going on, and what can be done about it?

Rowland.