Merging Contours — coordinate rounding

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?

image

Comments

  • rui_abreurui_abreu Posts: 23
    I just tried removing overlaps with AFDK's checkoutlines script and it worked great. the point stayed where is should.
  • 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 BlomBen Blom Posts: 250
    edited April 2013
    "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_abreurui_abreu Posts: 23
    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.
  • Glyphs uses the Adobe FDK code to remove overlap, so if it did the job well, Glyphs will do so, too.
  • rui_abreurui_abreu Posts: 23
    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_abreurui_abreu Posts: 23
    That's good to know Georg.
  • "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_abreurui_abreu Posts: 23
    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)
  • The user and all related content has been deleted.
  • rui_abreurui_abreu Posts: 23
    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
  • "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.
  • Is the akfdo merged outline floating point?
  • rui_abreurui_abreu Posts: 23
    edited April 2013
    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_abreurui_abreu Posts: 23
    …Of course all points snap to a grid. thank you for the reminder.
  • rui_abreurui_abreu Posts: 23
    edited April 2013
    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)
  • "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_abreurui_abreu Posts: 23
    edited April 2013
    "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.
Sign In or Register to comment.