Merging Contours — coordinate rounding

rui_abreu

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?

rui_abreu

I just tried removing overlaps with AFDK's checkoutlines script and it worked great. the point stayed where is should.

Alexis Luengas

One option is to work with a bigger UPM when doing contour operations, then rescale to 1000 UPM. If you want to reduce the rounding error, simply refine the grid.

Ben Blom

"One option is to work with a bigger UPM when doing contour operations, then rescale to 1000 UPM."

Scaling 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.

rui_abreu

that sounds like a good solution, although Font lab will do same operations it does on lower resolutions. Just on a finer scale. On this example the point end up on an ilogical place and it will do that on different UPM sizes.

Georg Seifert

Glyphs uses the Adobe FDK code to remove overlap, so if it did the job well, Glyphs will do so, too.

rui_abreu

But mathematically and logically (whatever) that point shouldn't be on that position. If fontlab merged outlines properly that point wouldn't be wrong. I guess there is no explanation. I'll just do it with AFDK. It rounds points logically, so I don't have to raise the UPM size. Thanks Ben & Alexis

rui_abreu

That's good to know Georg.

Deleted Account

"But mathematically and logically (whatever) that point shouldn't be on that position. "

I'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.

rui_abreu

David, the outline on the layer mask is the same, but before merging. Take a look at these to examples.

1. 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)

[Deleted User]

The user and all related content has been deleted.

rui_abreu

James, that position was a design decision. As for the point roundings on fontLab it's still a mystery to me. Thanks for your time anyway

Alexis Luengas

"As for the point roundings on fontLab it's still a mystery to me"

The coordinate rounding is not arbitrary. The point doesn't lie on the line because it can't, not because there's a calculation error.

The plane where the points may lie is discretized, i.e. every point must lie 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.

Jackson Showalter-Cavanaugh

Is the akfdo merged outline floating point?

rui_abreu

Luengas, you misunderstood my question. please see the pictures I shared at 5:18. I made two experiments of merging contours. In one of the cases the point snaps to the nearest absolute position on the grid, on the other case (fontlab's case) it goes to another position, instead of snaping to the logic position where the value would just be rounded to the nearest absolut value. I've explained this already.

rui_abreu

…Of course all points snap to a grid. thank you for the reminder.

rui_abreu

To make the question more simple. Can someone explain why the roundings were handled differently by FontLab and AFDK?

1. merged on Fontlab:
http://www.flickr.com/photos/abreurf/8680271441/

2. merged on AFDK:
http://www.flickr.com/photos/abreurf/8681381324/

(see line intersections)

Deleted Account

"David, the outline on the layer mask is the same, but before merging. "

Yes, 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.

rui_abreu

"Why? who knows. How, is another question. "

That'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.