Hi,

First post here.

I'm trying to solve the mis-positioning of one character in a font
which occurs only when it is turned into a Postscript file using
Finale "compile Postscript" command (Finale version 2007, Windows XP
Pro, tried on two machines).

Here are two sample images; the first is how it looks in the source
(Finale screen capture), and the second is the resulting Postscript
file displayed in Ghostscript.

http://maltedmedia.com/images/finale/hi-ay-good-orig.gif
http://maltedmedia.com/images/finale/hi-ay-bad-ps.gif

This font is TrueType, and was created with Font Creator 5.5 from
scanned text in old opera scores. I started at the Font Creator forum
and was referred to the Adobe forum by the programmer of FC, as he
examined the font and found no problems with it. Adobe's regulars
basically said "nothing to see here, move along.".

The font works properly in MSWord and in Postcript compiled there via
Ghostscript. Printing to PDF also works under any application (via
Acrobat Distiller or docPrint Pro). In Finale Postscript compilation,
it fails.

I have another font that has the same offset problem -- but in a
different glyph slot and with a different offset (offset left rather
than down) -- and it's also during Finale Postscript compilation.

It doesn't affect printing to a Postscript printer (even if printing
to file) from Finale, just when compiled to a Postscript or EPS file
within Finale.

I don't know where to look for additional positioning data in the font
that a PS compiler would be fooled by. It could be Finale's Postscript
compiler, but the compiler is the only real option; printing to
Postscript/PDF within Finale produces a very ugly screen display and
bulky document.

I need to solve this problem (it's holding up production of an opera
score for a client, who needs the font), and don't know where to ask.
I started by guessing the font was the issue, next went to Adobe, and
now am here. I will go to the even-badly-supported Finale tech support
as a last resort -- knowing they will never ever ever help. (Ever.)

I don't really care who's responsible for the problem. What I'm asking
is: where in a font's parameters can I find the likely cause of a
Postscript mis-compile of its placement? I'll fix it.

Thanks,
Dennis

Just some shooting in the dark here ... it certainly sounds like a
problem with Finale, but I understand your reluctance to try and get
help from there! And are you using the full version or the free
version of Finale, and what version? Have you tried with different
versions of Finale?

Does the problem occur at all sizes (maybe it's some strange hinting
problem)?

Did you trim down the FontCreator font (it normally creates hundreds
of unnecessary and empty glyphs, and maybe Finale is choking on the size)?

Have you (or anyone else) tried recompiling the font with FontLab or
some other more robust font editor?

Have you tried it with any other music notation software?

Have you tried a pragmatic solution rather than an æsthetically and
technically pleasing one? Specifically, open a new font and copy all
of the glyphs from the "bad" one into it and see if the new one then
exhibits the same problem.

If you could post a copy of the font(s) in question in might help.
(You could put it in the same directory as your sample images).

An immediate major problem that I see is that there is no 'null'
glyph, having been replaced by "not.def.00" and the "H" glyph is also
in the .notdef position in both of the fonts.

Beyond that, as others have said, there's nothing obviously different
about the "H" glyph by itself. I'm not sure how you'd fix the problem
in Font Creator.
There's a minor unrelated difficulty in the font names - both fonts
have the same "Full Name" of "Opera Lyrics" where all the other
internal font names have the complete names "Opera Lyrics Smooth" or
"Opera Lyrics OldStyle".

Another random thought I had was that there might be a problem in
converting the true-type outlines to postscript (Type 1) outlines.

You might also want to change the "vendor code" from HL (the makers of
FOnt Creator) to MM for maltedmedia

Since you're using Google Groups, which can't have attachments, I'll
send you a revised test version directly to your email (assuming that
the one shown here is valid). The revision deletes the characters
mentioned in the first paragraph above, changes the name entries as
indicated, deletes most of the empty glyphs, and is generated with
FontLab.

Character wrote:

Just some shooting in the dark here ... it certainly sounds like a
problem with Finale, but I understand your reluctance to try and get
help from there! And are you using the full version or the free
version of Finale, and what version? Have you tried with different
versions of Finale?


Yes, it's the full version. I've been a Finale user since 1992.

I have not tried the new font with different versions because Finale
2007 is the first version is which Postscript compilation actually
worked with 9-1/4 x 12-1/4 paper.

However, with the other font I mentioned the problem (one offset glyph)
exists in both Finale 2006 and 2007 during Postscript compilation.


Does the problem occur at all sizes (maybe it's some strange hinting
problem)?


I haven't tried all sizes, but it occurs when used at 12, 14 and 16
point.


Did you trim down the FontCreator font (it normally creates hundreds
of unnecessary and empty glyphs, and maybe Finale is choking on the size)?


It's gradually being trimmed. The resulting font is about 40K. The other
font is even small and has considerably fewer points.


Have you (or anyone else) tried recompiling the font with FontLab or
some other more robust font editor?


I only have Font Creator ... fits my budget. I don't know FontLab, but
will check if it has a demo version.


Have you tried it with any other music notation software?


No. But I have tried it in other applications, such as MS Word, and the
offset does not occur. Finale is unique as the only application that
offers the option of creating a Postscript listing from the program
rather than printing to a file. Its Postscript print-to-file function is
badly coded and produces ugly displays and bloated files in Windows (I
mean by a factor of ten to twenty). The Mac version works correctly.


Have you tried a pragmatic solution rather than an æsthetically and
technically pleasing one? Specifically, open a new font and copy all
of the glyphs from the "bad" one into it and see if the new one then
exhibits the same problem.


A good idea. I will try it. I did swap H and L to test, and the H still
was offset in its new position. But it was within the same font file.


If you could post a copy of the font(s) in question in might help.
(You could put it in the same directory as your sample images).


Thanks very much. I have done that. You'll find them at:
http://maltedmedia.com/images/finale/Opera-Lyrics-OldStyle.ttf
http://maltedmedia.com/images/finale/Opera-Lyrics-Smooth.ttf

The first is the characters as scanned and trimmed, the second is a
working font with the glyphs gradually being smoothed.

Thanks again,
Dennis

On Mar 27, 8:42 pm, Character <C...@cters.old.style> wrote:


Another random thought I had was that there might be a problem in
converting the true-type outlines to postscript (Type 1) outlines.


Does the Postscript compiler do that?

You might also want to change the "vendor code" from HL (the makers of
FOnt Creator) to MM for maltedmedia :)


I haven't found the vendor code change yet. Still hunting.

Since you're using Google Groups, which can't have attachments, I'll
send you a revised test version directly to your email (assuming that
the one shown here is valid). The revision deletes the characters
mentioned in the first paragraph above, changes the name entries as
indicated, deletes most of the empty glyphs, and is generated with
FontLab.


Thanks very much. Both emails I've been using are good. The bathory/
bathory/org one is better in general.

Character,

Your font revision worked fine -- not only that, but your font
revision then revised and run through Font Creator *also* worked fine.

I just posted this over at the Font Creator forum. Perhaps they'll
have some ideas as to what's happened.

Many thanks for the kind attention ... very much appreciated. Now I
get back to work on the actual opera engraving project!

Dennis

Here are the final results that I can produce.

http://maltedmedia.com/images/finale/hi-jay-bad.gif
http://maltedmedia.com/images/finale/hi-jay-good.gif

The first was produced with the Font Creator-originated font, with all
its parameters changed to match the FontLab-modified font.

The second was produced with the FontLab-modified font, after being
run through Font Creator.

Here are the two fonts:
Font Creator: http://maltedmedia.com/images/finale/Opera-Lyrics-Smooth.ttf
FontLab: http://maltedmedia.com/images/finale/OperaLyricsSmoothTest02.ttf

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? Smile

Many thanks,
Dennis

Character,

Quick note. A person on the Font Creator forum found the problem.
There are two validation modes in FC -- "global" and "local". I don't
know what the differences mean ... yet; they're not discussed in the
manual, and the font validation dialog doesn't indicate which one is
being used to validate the font. The default validation is "global",
and I'd carefully removed every error it found -- without knowing
there was another validation mode.

It turns out the "local" validation finds more (or other?) errors,
including a glyph starting point that is out of range. Fixing that
point also fixed the placement of the letter.

Now I gotta do some more reading about what points belong to what. :)

Many thanks,
Dennis