[metapost] Feature Request: Get envelope of path stroked with arbitrary pen

[Kevin Keith]

> Among other issues, the envelope of a path defined by cubic splines is not
> itself a cubic spline, so you need to do some approximation, and coming
up
> with rules for how close the approximation needs to be, that cover all
cases,
> is difficult.

Of course, but how does Metapost output pen strokes to eps or svg as it is?
Surely
it must already have a mechanism to approximate these higher-order splines
with
cubic bezier curves?

> I can think about it, but first I need a small set of significant
> examples (quite unlikely that I will implement something new for the
> next texlive,  btw) .

I'll give you the main issue I've run into: say I'm trying to design a font
which
is composed of pen strokes, but I want them to be joined smoothly. This is
a rather
contrived example, but I've put together an illustration of what I mean:
https://i.stack.imgur.com/pzy8e.png


On 8 February 2018 at 20:02, luigi scarso <luigi.scarso at gmail.com> wrote:

> On Fri, Feb 9, 2018 at 1:36 AM,  <mskala at ansuz.sooke.bc.ca> wrote:
> > On Thu, 8 Feb 2018, Kevin Keith wrote:
> >> It would be of immense use if it were possible to get the path of the
> >> outline of some arbitrary pen stroke.
> >> Since metapost already outputs bezier curves, instead of bitmaps, it
> would
> >> seem that the machinery to compute the envelope is already in place, so
> it
> >> shouldn't be too difficult to expose this as an operator in the language
> >> itself.
> >
> > I agree this would be nice.  However, I don't think it's so easy to do.
> > METATYPE1 (used by the Latin Modern project and my own Tsukurimashou) has
> > an implementation in Metapost macros; it usually works, but requires
> > handholding, and when it fails it's difficult to debug.  FontForge also
> > has an implementation of a similar feature, which has always been buggy
> > and a cause of user complaints.  If it were to be a Metapost language
> > feature, I hope that the implementation would be at the standard of
> > quality and non-bugginess that we expect of "engine" code in the TeX
> > ecosystem - and I think algorithms to actually achieve that on the
> "expand
> > stroke" problem may be an open research problem.  Among other issues, the
> > envelope of a path defined by cubic splines is not itself a cubic spline,
> > so you need to do some approximation, and coming up with rules for how
> > close the approximation needs to be, that cover all cases, is difficult.
> >
> > --
> > Matthew Skala
> > mskala at ansuz.sooke.bc.ca                 People before principles.
> > http://ansuz.sooke.bc.ca/
> > --
> > http://tug.org/metapost/
>
> I can think about it, but first I need a small set of significant
> examples (quite unlikely that I will implement something new for the
> next texlive,  btw) .
>
> --
> luigi
>



-- 
Thanks,
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/metapost/attachments/20180208/e4a34101/attachment-0001.html>