New to Typophile? Accounts are free, and easy to set up.
Create an account
Typophile RSS | More Feeds
I'm wondering if there is an easy way, or commercially available tool to get a simplified TT outline from Fontlab.
A PS outline...
Do these really have to be done by hand?
You can sometimes get cleaner conversions if you scale up the outlines by a factor of 10 first and then rescale them back down to the original size after the conversion. Ideally, the conversion routine would come with tolerance options, in the same way that bitmap tracing does, so one could say whether one wanted a tighter fit to the cubic bezier shape or a fewer number of off-curve points. A quadratic clean-up tool such as you describe would need to work the same way, I reckon, with user input on tolerances, so it might as well be part of the conversion routine. Note how, in your outline there are some curves that can have the number of off-curve points reduced by half with minimal loss of fidelity, while other curves require the same number of points as in the original conversion; this means that decisions need to be made about how much deviation from the original shape is permitted, i.e. tolerances.
Your scaling recommendation, does not work, it adds even more off curve points. Or perhaps I do not understand the procedure.
I'm wondering if there is an easy way, or commercially available tool to get a simplified TT outline from Fontlab
No: your TTF example is as elegant as TTF curves get...
I wonder if applying the RMX Harmonizer routines after conversion would be of any help, James? I don't know if it will but you might give it a try.
I know that here are proprietary tools that do this. Monotype has them as did/does Ascender. I'm sure Bitstream has something as well.
I'm just wondering what it would take to get this stuff available to all of us "boutique developers".
Maybe the TDC should do an annual fund-raiser and award the results to programmers like Erik, Tal, Karsten, Tim, and Fred to bring more tools to the field.
I hope you just prompted it to happen ;-)
If you're willing to go outside of FontLab, I've found that FontForge's converted TT outlines tend to have fewer off-curve points compared to FontLab. It also has a couple of Simplify commands, one of which provides some degree of control over the adjustment variables.
Chris, the RMX harmonizer has no effect, but thanks for the suggestion.
Thanks, James! It was worth a shot.
Yes, the RMX tools work only on cubic bezier outlines.
Sorry the scaling technique didn't help you, James. I think much depends on the curves in question, rather than a generic method that works the same way for all glyphs/fonts. I suspect scaling would be a good step to incorporate into an improved conversion routine, though, as it will enable better fidelity to the cubic bezier curves, especially smaller details where rounding during conversion at lower UPMs can cause really bad distortions.
With David Berlow's "simplify the editing by allowing only two off-curve points between two on-curve points", John Hudson's "deliberately minimise the use of on-curve points" and now Mr Montalbano's question, finally a conceptual pattern emerges.
We've recognized improving this functionality a priority for the next version of FontLab Studio which will be available this year.
I've just had an idea of how this problem could be addressed using a Python macro. I'll give you some feedback whether my idea worked later today.
…the next version of FontLab Studio which will be available this year.
Where have I heard that before?
>We've recognized improving this functionality a priority for the next version of FontLab Studio which will be available this year.
>I've just had an idea of how this problem could be addressed using a Python macro.
This must be "Python can do anything" week.
I've cleaned up hundreds of fonts now in an effort to give my clients the smallest most cuddly products with no help from any tool makers but me. It only takes day or two by hand James. The bright side is that the straight lines translate perfectly, right!?
The underlying problem is that T1 > TT is not mathematically trivial with 2 off curve points and no human interaction as a goal. TT > T1 is simple, but getting people to move their contour databases on to TT (ye olde magic bullet for this and other issues), is tough when the common tools are so neglectful of the basics for so long.
The underlying gold mine is that TT contours allow a fuller range of curves with just 2 off curve points than do T1 contours, (from a completely straight line between to on curve points, to a perfectly sharp apex). Start digging. ;)
It only takes day or two by hand James.
That is what I'm finding, and yes, that underlying gold mine you speak of is certainly worth the time. I was just hoping for a little help time-wise. Its only me here.
David: I've cleaned up hundreds of fonts now in an effort to give my clients the smallest most cuddly products with no help from any tool makers but me. It only takes day or two by hand
That suggests you have spent a minimum of two hundred days of your life doing this, and likely very much longer. Wouldn't you at least like to have a tool that does, say, 80% of that work for you, so that you only need to check most of the results and only edit a small proportion of the converted curves? Weren't computers supposed to make us more productive and increase our leisure time?
D.B. -- This must be "Python can do anything" week.
It is. And two years after you wrote that fewer TT segments are indeed more, I finally got it and agree. The key is to consider TT outlines as master and resist the temptation to mimick PS outlines. (Reminds me of trying to mimick IK outlines with PS outlines earlier.) The fewer segment, the easier it is to avoid quirky curves.
All that is needed is a good TT outline editor. I hope that FL has made some progress beyond just having "recognized improving this functionality a priority". :)
In addition to my earlier wishlist: Accepting the restriction that only two off-curve points are permitted, the TT editing behavior could almost entirely reflect PS editing behavior. Grant TT on-curve points "smooth" behavior too. And that non-horizontal & non-vertical off-curve points, via shortcut, retain their angle when moving them toward or away from the next on-curve point.
KL> All that is needed is a good TT outline editor. I hope that FL has made some progress...
I'ope so too. But when people have an effective TT editor, (which should behave identically to a T1 editor except for the "completeness of curves" mentioned above), together with the supposed TT hinting tools of FL, don't you think they'll want changes to the TT hinting tools? And when that's fixed up, they'll want a glyph instruction template and feature-to-Nyquist Limit "equalizer"? and then control point number-independent labels for glyph features? and then Yuri will be 86 years old, rocking a great-grand-child on his knee and wondering "Что эти сумасшедшие люди будут хотеть затем?", to one of his 200 assistants ;)
[Here is a tiny script. It aligns selected consecutive on- and off-curve TT nodes on a line defined by first and last selected node. For a sample see the PDF which is included.]
1. Open the PS font in FontForge
2. Change Layers from cubic to quadratic
3. Select All, Simplify
It does not appear to work. I think your expectations might be lower than required.
I don't think that this is it. While in some cases you get away with only one off-curve node per quarter-circle which is fine, in other cases you still end up with three of them – referring to the [top part of the] belly of the 'a' and assuming that on-curve nodes which are not extrema can be removed since they are halfway between two off-curve nodes.
Less is more?
That's still too few and too many.* :) Too few: Top left part of belly, outside contour, and bottom left part of belly, inside contour, each have but one off-curve node left – no way to edit the curve inbetween manually (move this single off-curve node and you destroy 'smoothness' at neighbor on-curve nodes). Too many: Top left part of belly, inside contour, in turn has an additional on-curve node which can not be deleted because it is not exactly halfway between the off-curve nodes.
Thing is that the method which both FontForge (via Error Limit) and FLS (via scaling the glyph up or down before conversion) use for achieving a requested precision is increasing the number of segments.** What (see D.B.'s premise) is asked for, however, is achieving sufficient precision while producing a fixed number (two) of off-curve nodes inbetween two on-curve nodes, which in turn asks for an alternative method to maintain precision that differs from that used by both FontForge and FLS. Put differently: Possibility to adjust a precision factor does not help if the precision factor feeds the wrong method.
Not bashing FontForge and FLS but pointing out that what they do and what type designer need do not coincide. An alternative method exists. (Did you find it, Adam?)
* Both 'too few' and 'too many' refer to a number of nodes ideal for manual editing.
** Now ironically, more nodes do not necessarily result in higher precision because of rounding errors. After all, coordinates will end up as integer numbers.
The conversion you show would be unacceptable and require a lot of hand adjustment. If that is the best that is available, I think I'll keep doing this by hand.
On another point, where did you get the outline to that a glyph?
Here a few additions to my FLS TT editing-behavior wishlist:
1) For editing off-curve nodes, offer an absolute-coordinates mode (like current TT editing-behavior) and a relative-coordinates mode (like current PS editing-behavior) regardless of outline format. Both modes can be useful at times.
2) When editing TT outlines, the "add corner node" and "add curve node" functions should do exactly that, add a single on- or off-curve node, rather than add on- and off-curve nodes as it does now.
3) The self-imposed TT outline restriction to two off-curve nodes between on-curve nodes would apply only to conversion of PS to TT outlines. It should still be possible to add more when needed, since such cases exist.
>On another point, where did you get the outline to that a glyph?
I assumed he was with you!
>...add more when needed, since such cases exist.
I have come across situations where 1 off curve between is enough, but needing three in between I've not found yet without a reverse of tangency occurring. Have you got an example, because a lot of UI things change when more than two are allowed, at all.
Karsten, is there any situation in which a curve could be described by three off-line points that could not also be described by adding an on-line point and maintaining the single or double off-line point rule? I don't think so.
Your "that could not also be described by adding an on-line point and maintaining the single or double off-line point rule" is the key I had not considered. In this case you can indeed get away with exactly two off-curve nodes.
At the same time, I like the possibility to save some on-curve nodes – and thereby avoid possible rounding errors when modifying the outline (manually and automatically). I would not like to miss this option entirely.
Having mentioned two editing modes: A rule could be that in relative mode, curves with >2 off-curve nodes cannot be edited except for shifting the entire segment or moving one of the on-curve nodes when the off-curve nodes inbetween them would be interpolated. To edit off-curve nodes individually one would need to switch to absolute mode. (Which I start to appreciate for some kinds of adjustments.)
It would seem that the transparent transition of the type 1 curves to TT curves should be well within the domain of computer software. It should be like the exchange rates among currencies. I hope that the above discussion will lead to development of some better tool to accomplish this without distortion. I will be the first to admit to my lack of knowledge in programming and software development so I am of no help in finding a better solution. It is good to see that many of the posters in this thread who are capable in the programming arena are addressing the problem.