A problem has come up twice over the past few years: the mis-positioning of one character in a font, but only when it is turned into a Postscript file with certain applications.
Here are two sample images; the first is how it looks in the source, and the second is the Postscript file as viewed with Ghostscript. (It’s the same in Distiller; Ghostscript is just faster.)
I’ve moved the character into other slots to test it; it’s just the one character, not the slot. I’ve tried modifying the character, and when moving it, I was sure only to marquee the character, in case there was something outside the creation frame.
It compiles Postscript properly in MSWord and printing to PDF works. In Finale, it fails.
I’ve used custom fonts from many folks, and it’s only happened with two fonts created in Font Creator.
It’s not much to go on, but where would I start? (This is a font-in-progress based on old opera score texts.)
I’ve investigated your font (Opera-Lyrics.ttf), but I can’t find any problems there. So I assume it is an issue with the conversion to PostScript, done by external applications. You might want to try to reduce the complexity of the glyph (e.g. remove some points). Let us know your results.
I sent another font (RevereFinale) and PDF sample along with my new scanned one, and it has the same offset problem – but in a different glyph slot and with a different offset (offset left rather than down). It has many fewer points. It’s just a 16th-note flag and stem; similar and more complex glyphs in the same font (such as a 32nd-note flag) work fine.
Can you point me to the factors (other than boundaries, which seem correct) that might throw off a Postscript compiler? Even as I clean up the “H” in the Opera-Lyrics font, reducing the points, the offset doesn’t change.
As I say, it doesn’t affect printing to a Postscript printer (even if printing to file), just when compiled to a Postscript file. I need a real Postscript file to produce clean PDF or EPS files in Finale.
I don’t know where to begin looking for other positioning data that a PS compiler would use.
The problem occurs (so far) in just two fonts, both created with FC.
In the first (Opera Lyrics), the character is offset down (to the bottom of its baseline); in the second (RevereFinale), it is offset left (to the left of its bearing). Some other fonts I’ve done in FC are just decorative elements, and I’ve never used them in Finale.
I posted the whole question yesterday over at comp.fonts, and one person has had a look at the font. Other than finding a few minor errors (I left off the Macintosh naming), he’s not found anything, but reprocessed the font in FontLab. I’ll run a test on it today – install, change lyrics font in Finale, compile PS.
Then I’ll report back here.
Thanks for the kind words on the font. The credit really belongs to those metal font designers in the 1880s at G. Schirmer, where these characters were on individual steel striking dies that embossed metal plates. (On the Henle publishing site, there’s a great video of metal plate engraving, which is still done there on some special editions.)
The font reprocessed in FontLab does not exhibit the character shift problem during Postscript compilation.
I altered the old font in Font Creator using the same steps the person did in FontLab: included the Macintosh naming, deleted glyphs above $00FF, changed the vendor code to “mm”, deleted the default box in the $0000 position, and reinstalled. No change. The FontLab version works while Font Creator version does not.
Now I’m going to open them side by side in Font Creator and see if there are any other differences.
I have tweaked every parameter I could find in the Font Creator-originated font to match the FontLab-revised font (which, as I say, was run through Font Creator just to kind of scrub it with whatever Font Creator does).
Suggestions welcome, as I’d hate to run into this problem again on a short deadline. Dick? Erwin?
Good to know you have find a solution, too bad it didn’t work with FontCreator . I’ll be more than happy to look into this, and generate a couple of slightly modified versions of the fonts for you to test. Do let me know if you are willing to put some effort into this, so I can start with making those changes.
Yes, Erwin, I’m happy to test. As you know, I’ve been using Font Creator for a long time and found it perfect for the little bits and pieces of work that needed a font rather than an image.
This has tripped me up twice, and it seems it might be specific to FC-originated fonts. Maybe even something in the default font file?
I’m leaving for three weeks residency in Portugal followed by a week in the Netherlands, and will be able to give it my attention in mid-May … so no rush. (I’ll buy you a Duvel when I’m in town – I’m staying with friends in Utrecht Centrum from April 29-May 7, which means you’re nearby in De Bilt. I hope to enjoy Koninginnendag again, too!)
One obvious thing to try is Font, Validate, to remove off-curve extremes, but since these exist in both fonts, I don’t think it will solve the problem.
One odd thing about the fonts that I noticed is the extreme kerning of C and hyphen, which is due to the unusually high position of the hyphen. Automatic kerning has shifted the hyphen inside the bowl of the capital “C”. I would recommend clearing the kerning, and trying again with automatic kerning from file. There are lots of very odd kerning pairs.
The Fontlab font uses Trimmed Table Mapping, instead of Byte Encoding Table for Macintosh Platform, and adds a Unicode 2.0 mapping. Again, I don’t know if this will make any difference, but it might be something to investigate. Format, Mappings to change to Trimmed Table mapping, and Format Platform Manager to add the Unicode 2.0 and onwards, BMP only platform.
The FontLab font contains some extra tables due to automatic hinting. Again, I don’t see how this could affect the position of the capital “H”.
Fonts were both already valid (no off curves, etc.). That’s the very first thing that I made sure of. And the person that converted the font didn’t touch the characters themselves.
I noticed the kerning, but a C-hyphen combo is not likely to appear in an opera libretto.
The change to Trimmed Table Mapping has been made, but the resulting font is still problematic. (I should mention again that this is the second font originated from a Font Creator blank template that has a misplaced character.)
The default validation is “global”. I didn’t even know about the local validation because it’s not indicated in the Font->Validate window itself.
How are they different? This is not explained in the manual. I thought I had fixed all of these, but clearly there are hundreds more errors of a different kind.
What did it? Running the font validation or moving the First Node? It might help Erwin to know which.
The local off-curve extreme is outside its adjacent on-curve point, but not outside all on-curve points.
Local Off-curve Extreme.png
Any off-curve extremes on inner (anti-clockwise) contours will not be caught by global validation. I don’t know why that is the default — perhaps it is quicker and good enough for most cases. Apparently not good enough for your particular font and the way that you are using it.
Yes, changing the node did it. I don’t use the auto-fix part of validate because it’s done some heavy-handed cleanup in the past to commercial fonts I wanted to adjust – not FC’s fault, just some carelessly designed fonts.
This opera lyrics font was created by scanning and loading into FC, and I guess that process doesn’t do anything to create valid points.
I’m a composer and music engraver, and not a font designer or programmer (anymore!), so I don’t know enough about points and curves to understand what makes something outside or not outside. When I see red, I move it.
I wasn’t able to generate any outlines with invalid points by pasting screen grabs of several glyphs from your font. I’m not too sure if I ever had the same problem with my own fonts. I wonder what method and settings you are using to get invalid nodes from FontCreator’s autotrace?
I don’t know enough about points and curves to understand what makes something outside or not outside.
Outside the bounding box, or outside the orthogonal lines from adjacent on-curve points.
I wonder what method and settings you are using to get invalid nodes from FontCreator’s autotrace?
They’re coming in from various scan sizes. I just tried it. The scans are traced into valid images, but the resulting characters are not the needed size as traced. Shift-click-drag resize adds errors.
And of course then made it worse because I was in “global” mode. I deleted swaths of points that defined the rough edges of the characters, and then pushed red dots until they turned black – and thought I was fine.
As for points outside orthogonal lines, I might know the what, but not the why. In other words (and this question is rhetorical, because you don’t need to take valuable time to answer) why can’t I just pull the off-curve point as steeply as I want? I’ll learn this for myself, though.
I see, the original font contains a “H” with a contour that has an off-curve start point. This is allowed by the TrueType specifications, so it shouldn’t be a problem. If you are able to confirm this, I might add a “Make sure all contours start on an on-curve point” feature to the Transform wizard as well as a similar Validation warning. So could you please open your original font (the one that produces wrong results) and set the start point of the “H” to an on-curve point and test if this solves the issue?
Ps. I - although the “Add on-curve extremes” button on the Validation toolbar does fix the problem, it has nothing to do with it. The algorithm behind the scene, first sets the start point to the nearest on-curve point, before it proceeds with adding on-curve extremes.
P.s. II - The difference between local and global validation is explained in the user manual.
P.s. III - I do like Belgium beer, and Utrecht Centrum is only 10 minutes from where I live…
. I’ll be more than happy to look into this, and generate a couple of slightly modified versions of the fonts for you to test. Do let me know if you are willing to put some effort into this, so I can start with making those changes.