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!

Comments

  • 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: 185
    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: 185
    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: 839
    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 robofab.world import AllFonts

    max_Y_values = {}
    min_Y_values = {}

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

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

    for font in AllFonts():
    font.info.openTypeOS2WinAscent = WinAscend
    font.info.openTypeOS2WinDescent = abs(WinDescend)
    font.info.openTypeOS2TypoAscender = Ascender
    font.info.openTypeOS2TypoDescender = Descender
    font.info.openTypeHheaAscender = WinAscend
    font.info.openTypeHheaDescender = -abs(WinDescend)
    font.info.openTypeHheaLineGap = 0
    font.info.openTypeOS2TypoLineGap = abs(Gap)

    print
    print "In all open fonts:"
    print
    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.
  • John SavardJohn Savard Posts: 1,088
    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.
  • I got the same Prosper issue. Only some of the glyphs seem to have incorrect contours. How can I fix contours globally in FontLab 7, and make all overlaps removed on export to TTF and OTF?
  • André SimardAndré Simard Posts: 185
    edited February 2020
    I got the same Prosper issue. Only some of the glyphs seem to have incorrect contours. How can I fix contours globally in FontLab 7, and make all overlaps removed on export to TTF and OTF?
    I hope I understand which issue you've gotten. Run Tools > Actions > Set Contours Direction for all glyphs in the font:


    And save your vfc. This should completely solve the problem.
  • A big thanks, André! :)
  • Michael RafailykMichael Rafailyk Posts: 141
    edited May 2021
    I got the same Prosper issue. Only some of the glyphs seem to have incorrect contours. How can I fix contours globally in FontLab 7, and make all overlaps removed on export to TTF and OTF?
    I hope I understand which issue you've gotten. Run Tools > Actions > Set Contours Direction for all glyphs in the font:


    And save your vfc. This should completely solve the problem.
    First option is correct for the export of OTF with PostScript, but for TTF with TrueType I need to choice second option. Am I right?
  • Thomas PhinneyThomas Phinney Posts: 2,732
    Only if you are editing TrueType outlines.

    Usually, one keeps outlines in one or the other format,

    When converting to TrueType, FontLab will reverse the contour direction, as a standard part of that. So, if you are editing the contours with PostScript-style outlines, and only exporting as TrueType, you keep the PostScript direction in your file.
  • Michael RafailykMichael Rafailyk Posts: 141
    edited May 2021
    Only if you are editing TrueType outlines.

    Usually, one keeps outlines in one or the other format,

    When converting to TrueType, FontLab will reverse the contour direction, as a standard part of that. So, if you are editing the contours with PostScript-style outlines, and only exporting as TrueType, you keep the PostScript direction in your file.
    Thank you Thomas, it is clear for now!
    By default FL7 using PostScript outlines, so in this case, the right way is to using PostScript direction. Just figured out that I never used TrueType outlines, may be because Illustrator has PostScript-style handles and it is more familiar.
  • Thomas PhinneyThomas Phinney Posts: 2,732
    It’s not just you. TrueType outlines are harder to edit and work with.

    So even if TrueType is the primary or sole output format, most type designers still use PostScript outlines well into editing, at least—and often even as the permanent source format.
  • Mark SimonsonMark Simonson Posts: 1,652
    edited May 2021
    Glyphs even allows you to attach TT hints to PS outlines destined for TTF output. Pretty neat trick, IMO.
  • Thomas PhinneyThomas Phinney Posts: 2,732
    As does FontLab, for quite some years now.

    Outline format and hinting approach are independent in FontLab. You can do TT-style hints on PS outlines or vice versa. The outlines can be converted at export time.
  • Mark SimonsonMark Simonson Posts: 1,652
    Awesome.
Sign In or Register to comment.