New Prosper issue: Winding Directions

David Kerkhoff

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!

David Kerkhoff

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)

André Simard

David Kerkhoff said:

[…] (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.

David Kerkhoff

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é Simard

Thank you David. I will take a close look at my values and see if my problem is the same as yours.

André Simard

I changed my values and downloaded again on Prosper. Problem does not solve. I will check with Myfonts. 

Thomas Phinney

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.

André Simard

Thomas Phinney said:

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.

David Kerkhoff

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)

David Kerkhoff

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. 

Stuart Sandler

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 Espinoza

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]

André Simard

To all of you and your comments or advices I finally found the right values. Everything seems accepted by Myfonts. Many thanks.

LeMo aka PatternMan aka Frank E Blokland

In case one wants to check and/or change certain metrics or, for example, alter name tables, without having to regenerate the fonts in question, DTL OTMaster (OTM) can come in handy.

John Savard

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?

Thomas Phinney

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.

Vasil Stanev

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é Simard

Vasil Stanev said:

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.

Vasil Stanev

A big thanks, André!

Michael Rafailyk

André Simard said:

Vasil Stanev said:

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 Phinney

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 Rafailyk

Thomas Phinney said:

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 Phinney

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 Simonson

Glyphs even allows you to attach TT hints to PS outlines destined for TTF output. Pretty neat trick, IMO.

Thomas Phinney

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 Simonson

Awesome.