[metapost] Trying to use MT1 to make outline fonts... (again)

[mskala at ansuz.sooke.bc.ca]

On Wed, 20 Jun 2012, Shriramana Sharma wrote:
> It seems you are implying they (Berry and Yanai) used MT1 to get the
> envelopes (as vectors of course). However their article (in
> http://www.tug.org/TUGboat/tb11-4/ -- the individual chapter link is
> broken so you'll have to download in full) indicates that they
> actually directly modified MF to add a backend MF2PS to output
> postscript outlines.

I see.  It's true, I hadn't read Berry and Yanai and thought they were
talking about MT1.  From that article it's not clear to me how MF2PS gets
its outlines.  It almost sounds like it's actually exporting the path and
pen shapes in the Postscript Type 3 output and thus asking the Postscript
rasterizer to solve the problem (the Postscript rasterizer is in a better
position to be able to do it).  But I don't know for sure that that's what
it's doing.

> method to produce outline fonts from MF programming? After all it is
> supposed to store *the* envelopes (as vectors) produced by MF in
> postscript form!? All others (MT1 included) only approximate those
> outlines.

It's hard for me to believe that METAFONT really has the outlines of the
stroked paths in a clean vector form; I don't think that's how its
algorithm works, and if true it would mean that Knuth had already solved
in the 1980s a problem that others familiar with his work are still
struggling to solve themselves in the 2010s.  Is he that much smarter than
the rest of us?

> published only in 2001 whereas Malyshev already
> (www.tug.org/TUGboat/tb16-1/tb46malyPT.pdf p 4) in 1995 said that by
> removing overlaps one can produce Type1 output from Berry and Yanai's
> method (i.e. MF2PS), I wonder why MF2PS was not perpetuated? I mean,
> all that complaint about MT1 not having a regular pen stroking
> algorithm would be avoided, right?

That sounds right, so my feeling is that there must be something important
missing.

>
> I also note that Kinch (www.tug.org/TUGboat/tb19-3/tb60kinch.pdf) in
> 1998 said he was "tantalizingly close" (the phrase occurs twice) to
> perfecting the stroking algorithm, but no news seems to have been

My reading of Kinch's article is that he's rendering to bitmap (even if
it's not ever written out as a file) and then tracing vectors from the
bitmap coordinates - a similar endeavour to what mftrace does - and he's
tantalizingly close to having *a tracing algorithm* (not an overlap
remover or stroke expander) that will work.

On the overlap removal issue, it'd be interesting to look at FontForge,
which I'm using for overlap removal on MT1's output.  It can also do
"simplification," removing extra unnecessary points along curves and so
on, so that even if the outlines coming from some other system are a bit
messy (and lack things like points at extrema) they can be turned into
something that looks like good Postscript.  It works pretty well - better
than any of the purely-Knuthian systems I've looked at - but is not perfect.

> success of MT1. is there any difference between the two feature-wise
> that would create a separate userbase for mf2pt1 over MT1?

Well, if mf2pt1 allows the use of METAFONT-style "pen" operations, even if
it's imperfect in some other way, I think that'd be the difference right
there.  Lots of people want to be able to take code written for bitmap
METAFONT and generate vector fonts from it without rewriting in the way
needed by MT1.
-- 
Matthew Skala
mskala at ansuz.sooke.bc.ca                 People before principles.
http://ansuz.sooke.bc.ca/