New Prosper issue: Winding Directions
David Kerkhoff
Posts: 17
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!
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!
0
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)
0 -
David Kerkhoff said:[…] (but I still had to fake the metrics values)0
-
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!
;-)))0 -
Thank you David. I will take a close look at my values and see if my problem is the same as yours.
0 -
I changed my values and downloaded again on Prosper. Problem does not solve. I will check with Myfonts.0
-
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.
0 -
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.0
-
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)1
-
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.0
-
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.0
-
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]3 -
To all of you and your comments or advices I finally found the right values. Everything seems accepted by Myfonts. Many thanks.0
-
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.5
-
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?
0 -
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.4 -
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?0
-
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?
And save your vfc. This should completely solve the problem.0 -
A big thanks, André!0
-
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?
And save your vfc. This should completely solve the problem.0 -
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.1 -
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.
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.0 -
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.2 -
Glyphs even allows you to attach TT hints to PS outlines destined for TTF output. Pretty neat trick, IMO.
1 -
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.1 -
Awesome.0
Categories
- All Categories
- 40 Introductions
- 3.7K Typeface Design
- 793 Font Technology
- 1K Technique and Theory
- 609 Type Business
- 443 Type Design Critiques
- 536 Type Design Software
- 30 Punchcutting
- 135 Lettering and Calligraphy
- 82 Technique and Theory
- 53 Lettering Critiques
- 478 Typography
- 300 History of Typography
- 113 Education
- 65 Resources
- 494 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 161 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports