[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MF hackery (arrow kit)
- To: math-font-discuss@cogs.susx.ac.uk
- Subject: Re: MF hackery (arrow kit)
- From: Ulrik Vieth <vieth@thphy.uni-duesseldorf.de>
- Date: Mon, 3 Nov 1997 14:16:57 +0100
> Ulrik, I have applied your patches to ymearr.mf and added some more.
> The diff below is against pristine 0.54.
Thanks, I'll have a closer look at your changestonight at home.
[ zero_width chars ]
> I have tried |zero_width|, but that did not correctly center the
> glyph. Now I use an explicit |adjust_fit| to cancel the width.
Should be fine, if it solves the problem. However, it would be
interesting to find out why |zero_width| didn't work as expected.
>> * The gaped squiggly arrows produce some stray pixes within the
>> are that should be erased. Anyone knows how to fix this???
> Instead of |unfill|ing a box, I now calculate the intersection point
> and draw a shorter spline. This eliminates the stray pixels and gives
> correctly rounded endings.
This sounds like a better approach. Too bad that Metafont doesn't
have MetaPost's |cutafter| and |cutbefore| macros.
>> * There are still a few remaining inconsistencies as to when
>> points are positioned at hround(w-u) or hround(w-u-eps), etc.
> I have ignored these for now.
Maybe I'll have another look at these. There should be some simple
guiding principle when to use them if you look closely enough.
[ dot_sep in dotted arrows ]
> This turned out to be a bit tricky. We cannot guarantee uniform
> spacing between the dots without sacrificing device-independence,
> so I increased the space between the dots a bit, making the
> nonuniformity much less prominent. This is only a problem for
> low resolutions, it was quite noticeable at 300dpi, but invisible
> at 900dpi.
OK, as I see that you've used 6 dots per 12u, which makes 9 dots
per 18u, of which 3 dots would be deleted in the gapped versions.
Sounds reasonable. Remaining question: Is it the right approach
to have dotted arrows rather than dashed ones in the first place?
>> * 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.
> I haven't done anything about this.
I'll also have a look at these.
> All |italcorr| statements have been removed.
Seems reasonable for an unslanted symbol font.
[ CM square bracktes ]
> I was surprised by the difference between the mf programs for the
> brackets and floors in punct.mf and symbol.mf. While the brackets
> are very sophisticated, the floors are almost trivial. Is this
> because the brackets are designed for text fonts, while the floors
> are not ?
I suppose so. Maybe we should leave the text brackets alone and
design new math brackets based on the design of floors/ceilings.
So long, Ulrik.
P.S. At the moment I have a couple of projects in the pipeline,
none of which is ready for distribution yet, but the following
is upcoming. Please don't rush the next release.
* A `mmaptm' installation kit (similar to `mathptm') for the
old encodings using Times with Mathematica symbol fonts.
(Documentation still being written.)
* An incomplete Times/Mathematica installation of MC/MSP/MS1/MS2.
(Some .mtx files need updating to account for missing glyphs.)
* Revised .etx files mostly based on .afm symbol names from the
Blue Sky CM/AMS fonts. (This will require changes to some of
the glyph names in the ym[acd].mf sources as well. In addition,
it may be useful to have .mtx files to handle the difficiult
cases when the Blue Sky names and Lucida names don't agree.)
* Some reshuffling of symbols in MC and MSP/MS1 to better take
advantage of the symbols available in Mathematica fonts.
* Several unfinished discussion papers.