Re: Release Objectives
Kristof Bastiaensen <[email protected]>
| Newsgroups | gmane.comp.fonts.fontforge.devel |
|---|---|
| Message-ID | <[email protected]> |
On 20-06-14 14:30, [email protected] wrote: > On Fri, 20 Jun 2014, Kristof Bastiaensen wrote: >> I see. Couldn't you avoid joining closed paths in the same point when >> stroking paths? In the worst case this should give a few unnecessary >> control points, but not crash the program. > Not really. If I have two paths to stroke that join at a point and I > change them so that they no longer join, then the change will be visible > as a nick in the outline in the final font. I don't think that's > acceptable. It's also very difficult to require such a condition on all > external sources of font data, when I might be working with a font I > didn't create. If the necessary changes to make a font suitable for > "Remove Overlaps" cannot be done by scripts, FontForge becomes even less > useful. And the cases that the current code cannot handle are not > well-understood enough that we could write a document accurately telling > users what they're not allowed to do, anyway. > > I want to have a "Remove Overlaps" that *really* works, not only when > common special-case situations fail to occur. > Well, what I meant was to use a single closed path, rather than two closed overlapping paths. This way the stroking algorithm would take care of that special case. I agree that the code must work in every case, my point was that the worst that would happen is to have more control points than necessary. That would be a less critical problem that could be solved later. ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems