New Prosper issue: Winding Directions

So..... Still trying to upload a font to Myfonts using Prosper. I managed to upload one, faking all WinAscent and WinDescent values. Now I have a brush font that won't upload because the 'winding directions are incorrect':

I get this message (and a big red cross):

"To ensure proper functionality for customers, the paths in your glyphs must have correct winding directions. Wrong path directions can mess up counters. Paths need to be oriented counter-clockwise, counters need to be oriented clockwise."

Any idea how to solve this one? I have never ever heard of this and it never ever was a problem before. I can't find a lot about it on the internet, so any help will be appreciated!


  • Ok. Found the problem. It seems I had forgotten to hit contour/paths/set ps direction... The font was accepted (but I still had to fake the metrics values)

  • […] (but I still had to fake the metrics values)

    Could you please show us which fake metrics values you used to be accepted by Myfonts. I'm facing the same problem? Thanks in advance.
  • Well, I looked for the glyph with the highest accent (Scaron), then the glyph with the lowest accent (Gcommaaccent), turned these values into neat numbers and added them to WinAscent and WinDescent.

    This is the original setting:

    WinAscent=897, WinDescent= -193

    I turned them into these values:

    It works. Prosper even gave me a blue 'kudos' sign for my trouble!
  • André SimardAndré Simard Posts: 144
    edited October 2019
    Thank you David. I will take a close look at my values and see if my problem is the same as yours.

  • André SimardAndré Simard Posts: 144
    edited October 2019
    I changed my values and downloaded again on Prosper. Problem does not solve. I will check with Myfonts. 
  • Presumably the glyph with the highest or lowest value is something other than what you thought it was, André.

    Why not see what the results are of letting FontLab generate a value automatically? At least that could give you some clues, and perhaps let you choose less extreme values.
  • Why not see what the results are of letting FontLab generate a value automatically? At least that could give you some clues, and perhaps let you choose less extreme values.
    I tried to let Fontlab VI generate the values itself. This does not change the final result. Myfonts still rejected my font. I found which glyphs had the highest values, however I'm not able to find which one have the lowest values. I continue to work on that. Thanks Thomas.
  • If you let Fontlab generate the values (i.e. use the 'diamond'), then it doesn't work. With my font the Scaron had the highest value and the Gcommaaccent had the lowest. But it could be your Icircumflex is higher and your Ccedilla is lower. Just go through the glyphs and check. You can increase those values till you get a nice round number (for example 1100 instead of 1062)
  • It could also be that you placed your diacritics higher; I place them just above the x-height line with an anchor, so they're always below the ascender line. 
  • FWIW, there's a little script in Glyphs that would likely work with some tweaks in FLAB that simply locates the highest ascent and lowest descent metrics of any glyph in the font and fills in these fields.
  • Ramiro EspinozaRamiro Espinoza Posts: 753
    edited October 2019
    Here is a little Python script I made some time ago to find and complete these values in FL5. It analyses all open fonts so you can check a whole family.
    #FLM: ReType Complete Real Asc/Desc V 2.0
    # Find and fill real asc and desc values in all open fonts
    import operator
    from import AllFonts

    max_Y_values = {}
    min_Y_values = {}

    for font in AllFonts():
    for x in font:
    if != 'Aringacute':
    max_Y_values[ + " in " +] =[3]
    min_Y_values[ " in " +] =[1]

    WinAscend = max(max_Y_values.iteritems(), key=operator.itemgetter(1))[1]
    WinDescend = min(min_Y_values.iteritems(), key=operator.itemgetter(1))[1]
    Ascender =
    Descender =
    Gap = (Ascender + abs(Descender)) - (WinAscend + abs(WinDescend))

    for font in AllFonts(): = WinAscend = abs(WinDescend) = Ascender = Descender = WinAscend = -abs(WinDescend) = 0 = abs(Gap)

    print "In all open fonts:"
    print "The maximun Y value is: " + str(WinAscend) + " from " + max(max_Y_values.iteritems(), key=operator.itemgetter(1))[0]
    print "The minimum Y value is: " + str(WinDescend) + " from " + min(min_Y_values.iteritems(), key=operator.itemgetter(1))[0]
    print "TypoLineGap is: " + str(abs(Gap))perator.itemgetter(1))[0]
  • To all of you and your comments or advices I finally found the right values. Everything seems accepted by Myfonts. Many thanks.
  • I remember from the TrueType standard that the winding direction is used to distinguish between the "inside" and "outside" of a character, the inside being where the ink goes. As I don't see this mentioned too often these days, perhaps modern font formats use a different method?
  • If you have relatively simple glyphs, rasterizers can make reasonable assumptions and get good results. But even then, at least same vs different winding direction must be usable as a clue to the rasterizer. Contour A is entirely inside exterior Contour B. Should "A" be filled or unfilled?

    As soon as you get overlapping paths (not just one inside another, but overlapping), winding direction can cause you trouble in some formats and rasterizers, either in general or at least at some sizes (see below).

    Add in also some interior counters and possibly wrap it in a variable font (or fonts derived from variable fonts) where at some points in the design space a contour may effectively be a placeholder ... then even a pretty smart rasterizer could have difficulty determining what is supposed to be black and what is not. This is where the designer needs to have the option to have a contour entirely inside another, but both be filled.

    Also, be aware that with some environments and formats, you might get different rasterizers in the same app depending on UPM, background color, and other variables. For example, last time I knew for sure, the core rendering engine used by most Adobe apps (including Acrobat and InDesign) would exhibit at least FOUR different rendering modes at different ppem sizes on screen. PostScript similarly has multiple rendering modes.

    IIRC, predicting which rendering you would get was not always practical, as in some cases it could depend on available memory.
Sign In or Register to comment.