- 3.6K All Categories
- 20 Introductions
- 2.9K Typeface Design
- 535 Font Technology
- 890 Technique and Theory
- 401 Type Business
- 368 Type Design Critiques
- 454 Type Design Software
- 29 Punchcutting
- 89 Lettering and Calligraphy
- 52 Technique and Theory
- 37 Lettering Critiques
- 334 Typography
- 228 History of Typography
- 87 Education
- 19 Resources
- 397 Announcements
- 62 Events
- 86 Job Postings
- 120 Type Releases
- 128 Miscellaneous News
- 208 About TypeDrawers
- 45 TypeDrawers Announcements
- 86 Suggestions and Bug Reports

rui_abreu
Posts: **20**

Hi Everyone. My first time posting here. Glad to join you guys.

The rounding of point coordinates on FontLab as always puzzled me, and that becomes an issue on big families, since I can't obviously trust the coordinate roundings.

Of course, when merging contours, the resulting intersection points have to fall in a certain pair of coordinates. What puzzles me is how FontLab does this. In the picture below you can see a case where the intersection point was dislocated almost one unit to the side. And it happened to be on an almost exact coordinate already. Why did FontLab choose to round the x coordinate like that. Why didn't it just stay where it should.

Doe anyone know if there is more reliable way to merge the Contours? Is Glyphs better at this?

The rounding of point coordinates on FontLab as always puzzled me, and that becomes an issue on big families, since I can't obviously trust the coordinate roundings.

Of course, when merging contours, the resulting intersection points have to fall in a certain pair of coordinates. What puzzles me is how FontLab does this. In the picture below you can see a case where the intersection point was dislocated almost one unit to the side. And it happened to be on an almost exact coordinate already. Why did FontLab choose to round the x coordinate like that. Why didn't it just stay where it should.

Doe anyone know if there is more reliable way to merge the Contours? Is Glyphs better at this?

1

## Comments

2036250Scaling up and down in FontLab might, in itself, produce rounding errors. When scaling down, the rounding errors will be minimal when scaling down to one third. So, if the UPM is 1000, scale the UPM up to 3000 to do contour operations, and scale the UPM down to 1000 when done.

206442020739I'm not positive of that. Looking at the background image closely, it looks like the long diagonal that's intersecting, is not on the same line as the diagonal in the foreground. If that's the case then I think the overlap removal is correct to indicate a need for the designer to check the results.

In addition, the place you seem to want to locate the continuation of the diagonal, without any optical correction, might make it appear too dark in all but the larger uses, IMHO.

201. merged on Fontlab:

http://www.flickr.com/photos/abreurf/8680271441/

2. merged on AFDK:

http://www.flickr.com/photos/abreurf/8681381324/

(I had to remove the images from my server)

9552036can't, not because there's a calculation error.The plane where the points may lie is discretized, i.e. every point

mustlie on the grid. Therefore, if your UPM size is small, then the grid is coarse, hence there are less coordinates at which the points may be placed. If you draw a diagonal across a 1pt-by-1pt-square and then try to place a new point on the diagonal you will soon discover it will always snap to the nearest grid vertice. The same phenomenon happens when intersecting contours.5392020201. merged on Fontlab:

http://www.flickr.com/photos/abreurf/8680271441/

2. merged on AFDK:

http://www.flickr.com/photos/abreurf/8681381324/

(see line intersections)

739Yes, I know. An issue I see from your first illustration, is that the tangent point where the serif begins above the overlap removal is exactly on the mask. The next point, added in the overlap removal, is not on the mask exactly, being very slightly x negative relative to the mask.

This is the same in both AFDK and FL. Then, AFDK puts the next point, added in the overlap removal exactly on the mask, FL does not. Why? who knows. How, is another question.

Neither of them are "right", IMHO, which FL "tells" you, and AFDK does not.

20That's right David. That "How" is what I was wondering. Because to me, in both cases the points added should be in the same position if the x position of the new point is simply rounded. But I guess that depends on how they both handle the math behind the lines. But overall AFDK adds these intersection points in a more predictable way.