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

Re: MF hackery (arrow kit) + CM design questions


> Last night, I only wanted to investigate why the triple arrows in the
> MS2 arrow kit were turning out bolder than the single and double ones,
> but I eventually ended up applying lots of minor corrections and
> improvements throughout al of the MF sources for the arrow kit,
> resulting in one big patch attached below:

Yes, I knew that  the MF source of the arrowkit needs improvement, as that
is among the oldest stuff in the whole business. 

> * triple arrowheads redesigned to match single and double arrowheads,
>   using |rule_thickness| instead of |bar| or |1.5bar|.

I once did a similar experiment, but I could not get the triple arrowhead
to look right. Perhaps yours is better.
 
> * all characters: added or updated |penlabels| to get points numbered
>   in the GFtoDVI proof sheets.
> 
> * all characters: added |adjust_fit(0,0)| where it was missing to
>   get width characters boxes fixed properly.
> 
> * many characters: adjusted lft/rt positioning of control points.
>   In general, the tips of arrowheads are positioned with lft/rt 
>   while overshooting ends for extensible arrows are centered on
>   the middle of the control points, i.e. without using lft/rt.
> 
> * dashed arrows and arrow extension pieces: improved the code using 
>   for-loops instead of tedious repetions of |drawdot|.
>   
> * changed the width of arrow extension pieces to 12u# (equivalent
>   to 2/3 of 1em) instead of 14u#, and use a factor of 3/2 instead 
>   of 4/3 for the wide extension pieces, so that they end up being 
>   exactly 18u# wide (equivalent to 1em) instead of 18.66u#.

Sounds great. Thanks a lot for that work.
   
> Remaining problems:
> 
> * The construction of zero-width characters is different from
>   that of Knuth's mapstochar.  Instead of directly specifying
>   a width of 0pt#, he first used a non-zero width, followed 
>   by |adjust_fit(0,0)| and a call to |zero_width|.  Is there
>   any difference other than correctly setting the width of the
>   proof-sheet box?  The problem is that calling |adjust_fit(0,0)|
>   after specifying a width of 0pt# gives a division-by-zero error.
> 
> * The gaped squiggly arrows produce some stray pixes within the 
>   are that should be erased.  Anyone knows how to fix this???
> 
> * There are still a few remaining inconsistencies as to when 
>   points are positioned at hround(w-u) or hround(w-u-eps), etc.

Yes, the production of the arrowkit involved a lot cut and paste from
different sources, so inconsistencies were unavoidable.
 
> * I haven't yet tested if the dot separation of dashed arrowheads
>   and arrow extension pieces fits smoothly.  With 8 dots per 12u#
>   the dot separation would be 1.5u# and the first dot would have 
>   to be positioned at 0.5dot_sep (or 0.75u#) from the edges of 
>   the character box.  I hope this will be satisfied in all cases.
> 
> * I haven't yet checked if all the arrows (apparently assembled
>   from various sources) follow the design principles of Knuth's
>   latest sources or if some of them are still based on old CM.

You are right about the sources (mainly cmsy, msam and msbm, IIRC)
Could you explain the `latest' design principles and their diffence
to `old CM' ?
 
> * It is unclear to me why there is an |italcorr| specification
>   for some of the arrow extension pieces.  I presume this would
>   be totally unecessary in an unslanted symbol font anyway.

Cut and paste errors ?!  

> P.S. Another unrelated MF problem: It appears that the vector 
> accent from cmmi has a slanted arrowhead, while the reversevector 
> and doublevector form ymc are upright.  Would you agree that all 
> three  of them should be the same style (preferably upright)?

Agreed, so I'll probably add a matching vector accent to ymc.
 
> P.P.S.  Another one: The CM square brackets from punct.mf have 
> a width of 5u# (and relatively little side-bearings), while the
> floor/ceiling bracktes from symbol.mf have a width of 8u# (with 
> wider side-bearings and rounded corners at the end of strokes).
> Now the big square brackets have a width of 6u, 6.5u, 7u, 7.5u,
> while the big floor/ceilings have a width of 7u, 7.5u, 8u, 8.5u,
> and both of the share the same set of extensible modules.
> 
> Would it seem reasonable that all of them should have consistent
> widths or is there a good design reason why floors/ceilings are
> a little wider?  I suppose that even if we consider this a bug, 
> we will have to keep the old widths for metrics compatibility
> in the CM implementation, although it might also be interesting 
> to provide an alternative optimized version as well.  Opions?

What would a consistent setting be ? 
6u for the basic size floor/ceiling, I guess. Perhaps we will have
to create two sets of virtual fonts, one set with the old metrics
and one with improved metrics. On the other hand, perhaps we can
drop the whole idea of metric compatibility, as long as something
like my oldmath.sty is available. The old cm math fonts will always be
available... 


Regards, Matthias