The one on the left is PS and the one on the right is TT.
The RoboFont solution is interesting and clever. It mimics the behavior of PS curves by (in effect) pairing up two TT curve segments with an implied on-curve point connecting them. The trick is that, in TT, if a sequence of off-curve point, on-curve point and on-curve point all fall in a straight line, the on-curve point can be omitted (implied). It doesn't appear possible to work with TT segments that don't follow this pattern, which means you can't open and edit existing TT fonts that have them without some conversion. Which I guess wouldn't be a problem if you're not trying to work with older existing TT font data.
Not exactly, and exactly the point of the illustration. RF mimics the interface, but not the curves.
The trick you speak of, I have no idea what you are trying to say. Which point can be omitted? Draw a picture? No, it is not possible to edit TT not in this form, there is no interface, but the one true interface.
With older existing data, converting and editing can be very quick. E.g. all the glyphs of straight segments and kerning convert in a wooosh. But as so many know, TT patents, hints, and curves are all fraught with danger. Indy type designers, even if they could get their hands on the tools, don't stand a chance and shouldn't even bother trying.
Right, I meant that it mimics the UI of PS curve drawing, not the curve itself.
In RoboFont, when drawing with TT curves, if you connect the two off-curve points with a straight line, it will always touch the curve at a tangent. The point at which it touches the curve is the implied/omitted on-curve point. TT curves don't have to be constructed this way, but they may, and doing it this way is what allows the UI to mimic PS curve drawing.
Looking at figure 3, it seems like it's not quite truthful. I think the omitted on-curve point has to be exactly halfway between the two off-curve points for it to work. Figure 3 shows p2 much closer to p1 than to p3. Not sure how p2 could be reconstructed as the text says in this case.
RoboFont always appears to put the implied point exactly halfway. FWIW, FontLab does the same thing with this arrangement of points when in TT curve drawing mode.
It seems to me that drawing TT curves in this way it might be possible to end up with roughly the same number of points as with PS curves. (As opposed to drawing in PS curves and converting to TT, wherein you end up with significantly more points.)
Ah, but TT allows overlaps, so if you draw in TT and convert to T1, viola! you end up with significantly more points in the T1. Trying to convert the other way, and demerging contours, well, that's a gift no apps got yet.
"(As opposed to drawing in PS curves and converting to TT, wherein you end up with significantly more points.)"
Now though, with RF, in the Font Info, under Robofont, there is an option to keep the same points when converting, so you can convert without splitting curves, so TT and T1 can come out of the tool equal size, with overlaps or not being the only difference in size.
I've seen you say this a couple of times recently, that Type 1 and PS curves "do not allow" overlaps. Where is that coming from? Is it an issue where at certain sizes some rasterizers will reverse the overlapped area?
I remember being told when I started at Adobe that it was considered a matter of bad form to have overlaps in a finished output glyph, simply because if somebody every applied an outline effect to the final glyph, it would create a bad effect, and there was no telling what somebody would do with your final font. But that "rule" was applied to TT fonts as well, and I am not recalling it being mentioned as a format issue. But I may have forgotten something in here.
One thing I have noticed is that, if I generate an OpenType/CFF font that has overlaps, there will be holes in the glyphs where the overlaps occur in InDesign at smaller sizes. Zoom in and it looks okay, and printing to my PostScript printer is okay. Another thing I seem to recall is that Illustrator will not print documents containing an OpenType/CFF font that has overlaps.
PS curves "do not allow" overlaps. Where is that coming from?
1. PS1.0 had a bug that when two properly wrapped (black) contours overlapped, they made a white hole. (I remember sitting in John Collins' office in the mid-80's just looking at the floor, shaking my head). No explicit documentation, that I'm aware of from Adobe, ever said PS1 allows overlaps, does it? Show me?
2. ... that 'that "rule"' was applied to TT fonts as well", is just sayin', "Adobe doesn't think anyone should allow overlaps", even though the TT spec allowed it. So, Adobe could make a non-format issue into a format issue by their acts, and but not by the specs.
3. as I've demonstrated previously for you and others, Indesign, e.g. does the right thing with overlapping TT glyphs with outline and fill treatments, dramatically changing the contour from the original. Why would Adobe not publicize that?
(Just my opinion)...Because the fewer things Adobe can find acceptable about TT, the better, and it'll be that way 'till Adobe or TT is gone, it seems. For, if it's the composition app's job to create the final contour, and I'm all for it, then instead of stumblin' around on overfickenlaps, asymmetrical rendering and one version of Optima for high res and another for low res, why not progress on that. Why drag TT backwards to the lowest common denominator for all users. And why spend millions and millions of dollars per year, committing with each buck to spend millions more supporting a dying format, on life support due solely to compression of the font format?
I'm pissed, not at Adobe or you, but 'cause I have to make lots of special versions of lots of faces for lots of the web, until this nonsense stops, and my (our) tools are just revving up to the fact.
Comments
The RoboFont solution is interesting and clever. It mimics the behavior of PS curves by (in effect) pairing up two TT curve segments with an implied on-curve point connecting them. The trick is that, in TT, if a sequence of off-curve point, on-curve point and on-curve point all fall in a straight line, the on-curve point can be omitted (implied). It doesn't appear possible to work with TT segments that don't follow this pattern, which means you can't open and edit existing TT fonts that have them without some conversion. Which I guess wouldn't be a problem if you're not trying to work with older existing TT font data.
The trick you speak of, I have no idea what you are trying to say. Which point can be omitted? Draw a picture? No, it is not possible to edit TT not in this form, there is no interface, but the one true interface.
With older existing data, converting and editing can be very quick. E.g. all the glyphs of straight segments and kerning convert in a wooosh. But as so many know, TT patents, hints, and curves are all fraught with danger. Indy type designers, even if they could get their hands on the tools, don't stand a chance and shouldn't even bother trying.
In RoboFont, when drawing with TT curves, if you connect the two off-curve points with a straight line, it will always touch the curve at a tangent. The point at which it touches the curve is the implied/omitted on-curve point. TT curves don't have to be constructed this way, but they may, and doing it this way is what allows the UI to mimic PS curve drawing.
Looking at figure 3, it seems like it's not quite truthful. I think the omitted on-curve point has to be exactly halfway between the two off-curve points for it to work. Figure 3 shows p2 much closer to p1 than to p3. Not sure how p2 could be reconstructed as the text says in this case.
RoboFont always appears to put the implied point exactly halfway. FWIW, FontLab does the same thing with this arrangement of points when in TT curve drawing mode.
Now though, with RF, in the Font Info, under Robofont, there is an option to keep the same points when converting, so you can convert without splitting curves, so TT and T1 can come out of the tool equal size, with overlaps or not being the only difference in size.
The wait is over
I've seen you say this a couple of times recently, that Type 1 and PS curves "do not allow" overlaps. Where is that coming from? Is it an issue where at certain sizes some rasterizers will reverse the overlapped area?
I remember being told when I started at Adobe that it was considered a matter of bad form to have overlaps in a finished output glyph, simply because if somebody every applied an outline effect to the final glyph, it would create a bad effect, and there was no telling what somebody would do with your final font. But that "rule" was applied to TT fonts as well, and I am not recalling it being mentioned as a format issue. But I may have forgotten something in here.
Regards,
T
2. ... that 'that "rule"' was applied to TT fonts as well", is just sayin', "Adobe doesn't think anyone should allow overlaps", even though the TT spec allowed it. So, Adobe could make a non-format issue into a format issue by their acts, and but not by the specs.
3. as I've demonstrated previously for you and others, Indesign, e.g. does the right thing with overlapping TT glyphs with outline and fill treatments, dramatically changing the contour from the original. Why would Adobe not publicize that?
(Just my opinion)...Because the fewer things Adobe can find acceptable about TT, the better, and it'll be that way 'till Adobe or TT is gone, it seems. For, if it's the composition app's job to create the final contour, and I'm all for it, then instead of stumblin' around on overfickenlaps, asymmetrical rendering and one version of Optima for high res and another for low res, why not progress on that. Why drag TT backwards to the lowest common denominator for all users. And why spend millions and millions of dollars per year, committing with each buck to spend millions more supporting a dying format, on life support due solely to compression of the font format?
I'm pissed, not at Adobe or you, but 'cause I have to make lots of special versions of lots of faces for lots of the web, until this nonsense stops, and my (our) tools are just revving up to the fact.