Re: Overlap removal

I agree that adding these as options to the generate dialog would be good.
Even having then as default.

But when developing fonts I often want to make a binary to test without
messing with anything, and expect malformed rendering... So good to have
the option of that.
On 29 Jun 2014 13:20, <[email protected]> wrote:

> On Sun, 29 Jun 2014, Kristof Bastiaensen wrote:
> > Since extrema and no-overlap are file format requirements,
> > why not make it a default operation before converting to
> > a font file?
>
> Because it produces incorrect results that look bad.  :-)  I'm also not
> sure overlap removal (as opposed to extrema) really is a file format
> requirement; many fonts in the wild have not had it done and they don't
> seem to cause problems for people.
>
> Also, these operations require a fair bit of computation (possibly minutes
> on a large font), and because they can change the number of spline
> segments in a contour, they can screw up external data that may be
> depending on the exact arrangement of where all the points are.  If we
> load a file, save it, with no editing in between, and the result has a
> different number of spline segments from what was in the original, it's
> guaranteed we'll get a complaint from someone like Ilyaza about how we
> have "corrupted" the font.
>
> There are also some small advantages in a script context to having tight
> control over exactly when overlap removal happens.  For instance, in
> Tsukurimashou I assemble dozens of small fonts into each single large
> font, and I do the overlap removal on the small fonts in a separate script
> that only does that, because that way I can do many of them at once on a
> parallel machine instead of having to wait to remove overlaps in a
> single thread on the large font later; combined with on-demand (and only
> on-demand) updates of the small fonts, this makes a noticeable difference
> in the latency of my overall development cycle.
>
> Nonetheless, at such time as FontForge's overlap removal and
> extrema-adding are trustworthy, I would be in favour of making them happen
> during "generate" of file formats that require it, even as a default,
> provided it can be turned off by the user.  There is precedent in our
> current (optional, but turned on by default) invocation of auto-hinting
> during save, which remains a trap for the unwary.
>
> --
> Matthew Skala
> [email protected]                 People before principles.
> http://ansuz.sooke.bc.ca/
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Fontforge-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fontforge-devel
>

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft

_______________________________________________
Fontforge-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fontforge-devel