|
|
| MakeMusic Forum > Public Forums > Finale - Macintosh - FORUM HAS MOVED! > 25 new free music fonts for Finale (Update 1.1 released today, 4 new fonts) | Forum Quick Jump
|
| 
jange
Registered Member
      
Date Joined Oct 2013
Total Posts : 53
| Posted 10/18/2016 3:36 AM (GMT -6) |   | As a result of an article I wrote on "Automatic Font Conversion" I have uploaded a font package of 21 music fonts made 100%-compatible with Maestro.
It can be found in the download section at Elbsound Music Font Package.
The music fonts include new versions of Bravura, Emmentaler, Euterpe, JazzyBasic, Haydn, Sebastiano, Improviso, Gootville, Haydn, Leipzig and many others. AFAIK some of them (Unifont Upper, Euterpe and FreeSerif) have never been made accessible for any notation program yet, so it's even a premiere for those.
The fonts are licensed under SIL OFL or GNU GPL and are available for MacOS (ttf) and Windows (otf/ttf).
Font annotation files are also included.
Jan Angermueller
elbsound.studio
Examples of all fonts from the free 100% Maestro-compatible Elbsound Music Font Package (plus Maestro):
(Higher quality PDF: All Symbols)
Examples of all symbols:
(Higher quality PDF: All Symbols)
(image artifacts or stems that look as though they don't to the noteheads are the result of the low dpi PDF->Image conversion,
in Finale and in PDF they connect correctly)
 Post Edited (jange) : 11/30/2016 3:39:44 AM (GMT-6) | | Back to Top | |
|
jange
Registered Member
Date Joined Oct 2013
Total Posts : 53
| Posted 10/18/2016 12:26 PM (GMT -6) | | >Ideally, both TrueType and openType fonts should be cross-platform.
Yes, but I encountered a problem in Finale's current font handling which only occurs on MacOSX.
In Fin2014.5 and Fin25 (don't know about 2014) I didn't find any unicode music font that uses a fully readable encoding which
1.) includes all symbols in the slots 32-255
AND
2.) unicode symbols above 255.
The goal was to be fully Maestro-compatible and have all original unicode elements (most converted fonts are unicode fonts), e.g. to have a Bravura-port ("Aruvarb") that is 100% Maestro-compliant AND gives access to the full SMuFL range.
But to be fully Maestro-compatible you need to have the full range from 32-255.
All fonts I tested on MacOSX (10.11) (including the commercial November2 from Finale's German Distributor Klemm!) with Finale 2014.5 and Finale 25 had either the characters 32-255, but no unicode symbols OR the characters 32-128, 133, 160-255 and unicode symbols.
It was not possible to have the character slots 129-132,134-159 filled with symbols AND have access to the unicode symbols above 255.
This is only possible on Windows (Finale 2014, 2014.5 and 25).
So if you require 32-255 and unicode, cross-platform is not possible anymore - at least in Fin2014.5/Fin25.
I have attached a screenshot from the MacOS November2 symbol dialog that shows the problem.
On Windows the slots 129-159 are not empty.
That's why the Mac/Windows fonts were encoded differently and only the MacOS fonts require an addition to MacSymbolFonts.txt.
The unicode sections in the MacOS fonts were made invisible for Finale to have full compatibility to Maestro.
And yes, I could have created OTF fonts for MacOS too.
But AFAIK they are not really necessary on MacOS as it has a very smooth font handling anyway - compared to Windows.
If there is a demand for the MacOS OTF fonts, I can add them in the next release.
I am still waiting for a solution from MakeMusic and Klemm. Maybe they will come with something ?
If so, I will update the MacOS fonts and then they probably will be compatible with Windows.
But I don't expect it, as November2 hasn't been fixed since 2014.5 is out.
BTW, I only have 2014.5 and v25 installed on MacOS, not 2014.
A beta-tester told me that in 2014 the 129-159 problem did not occur.
Unfortunately I couldn't reproduce it without 2014, but maybe it changed indeed in 2014.5 when MakeMusic updated the Finale font handling.
JanPost Edited (jange) : 10/18/2016 12:49:49 PM (GMT-5)
Image Attachment :
Nov2.png 402KB (image/png)This image has been viewed 779 time(s). | | | |
| | Back to Top | |
|
jange
Registered Member
Date Joined Oct 2013
Total Posts : 53
| Posted 10/18/2016 2:33 PM (GMT -6) | | Of course, Dr. Wiggy, they were NOT added to the MacSymbolFonts.txt, otherwise I could not have produced the screenshot I attached above.
There you can see symbols above 255, but not the symbols 129-159 (except 133), although they were used and are available on Windows.
>If the fonts are Unicode, you must not add them to MacSymbolFonts.txt.
Depends on what you call "Unicode": Unicode encoding (ISO 10646-1) OR character slots above 255 used ?
In the first case, you can put it to MacSymbolFonts.txt and might not notice a difference if less than 255 slots were used.
In the second case the symbols above 255 will be cut off.
Once more the problem is:
Finale 2014.5 and v25 seem to not support unicode fonts that use the character slots 129-159. The slots will be empty if such a font is used in Finale.
But these are necessary for compatibility with Maestro. Even the characters 129-159 in November2 are not available in Finale 2014.5/v25.
So if the first priority is to have 100% compatibility with Maestro, I must drop the unicode parts and only use the standard 32-255 slots
-> that is achieved by using a slightly different encoding than in the unicode fonts AND adding the font to the MacSymbolFonts.txt.
Nevertheless: in other programs the unicode symbols are still available, it's only Finale where they are not available.
If you have a music font where the slots 129-159 are available and any slot above 255 also appears in the Fin25 symbol dialog on MacOS, it would be great if you could send it me. I tested more than 100 published fonts and none worked. So AFAIK they do not exist and it is a probably a bug in Finale as it only occurs on MacOS when you use the same settings as on Windows.
Otherwise I would probably have gotten a solution from MakeMusic or Klemm for November2.
JanPost Edited (jange) : 10/18/2016 2:41:21 PM (GMT-5) | | Back to Top | |
|
jange
Registered Member
Date Joined Oct 2013
Total Posts : 53
| Posted 10/19/2016 8:50 AM (GMT -6) | | | |
|
Mike Halloran
Registered Member
Date Joined Jun 2009
Total Posts : 105
| Posted 10/19/2016 2:18 PM (GMT -6) | | A lot to digest. Thanks!
Mike Halloran
Finale 25 & 2014.5, SmartScore X Pro II, Encore 5.0.7
2010 iMac 2.93G i7 Quad w/ OWC eSATA mod, 20G RAM, OS 10.12, 2T SSD
DP 9.1, 8.07, 7.24, Logic Pro X 10.2.4, DSP-Quattro, PSP, IK, NI, Eventide, Izotope & Antares plugins
G4 running OS 10.4.11 & 9.2 with legacy apps | | Back to Top | |
|
jange
Registered Member
Date Joined Oct 2013
Total Posts : 53
| Posted 10/21/2016 4:45 AM (GMT -6) | | | You can convert it. The download includes the font description file (.sdf) for FontForge where you convert it to otf/ttf. | | Back to Top | |
|
jange
Registered Member
Date Joined Oct 2013
Total Posts : 53
| Posted 10/21/2016 11:22 AM (GMT -6) | | Eric, the "129-159 problem" is actually problem in Finale that can appear in different forms.
Usually it has to do with wrong encoding settings which many fonts use (especially commerical 3rd party fonts).
This can be usually be fixed very easy by changing the encoding and resaving the fonts.
Sometimes it also only appears on Mac or on Windows.
The problem I described above is unfixable at the moment (and was confirmed by MakeMusic).
Only unicode fonts that use 129-159 AND a slot above 255 are affected - and only on MacOS.
AFAIK this affects only the commercial November2 font and my fonts above.
All other fonts for Finale are either <255 only or unicode only or unicode with 129-159.
Jan | | Back to Top | |
|
jange
Registered Member
Date Joined Oct 2013
Total Posts : 53
| Posted 11/28/2016 1:27 PM (GMT -6) | | | |
|
Robert P.
Registered Member
Date Joined Apr 2004
Total Posts : 1691
| Posted 11/28/2016 3:02 PM (GMT -6) | | jange said...
MakeMusic has confirmed today that there is indeed the bug I described above where the 129-159 symbols disappear on MacOSX.
And according Mark Adler, who tested it himself, this a bug that dates back to Fin2012 and no one had complained yet.
Hi Jan,
First, congrats for your fonts!
I tested November 2 with Finale 2012 and Finale 2014 - both fine! So the problem definitely dates back to Finale 2014.5.
That said, each symbol in the 'legacy' range [32-255] - this is how I call it in regard to SmuFl  - has its equivalent somewhere in the upper Unicode/SmuFl range.
So despite this Finale 2014.5 Mac-only bug, there is always a solution (this is a bit painful, I agree)
As far as the encoding, November 2's is unquestionable, I do believe. I am about to release a November 2.1 (free) update, but there won't be any change here, since the bug's not mine...
The ball is definitely in MakeMusic's court!
jange said...
MakeMusic has confirmed today that there is indeed the bug I described above where the 129-159 symbols disappear on MacOSX.
And according Mark Adler, who tested it himself, this a bug that dates back to Fin2012 and no one had complained yet.
A signal that third party fonts seem to be not very popular in Finale, otherwise more users would have complained (...)
I tend to disagree. To the contrary: November 2, for instance, has been very popular.
Robert
2.66 GHz Intel Core 2 Duo MacBook Pro, 8GB RAM
Mac OS X 10.8.4 / [Win 7/8 under WMWare]
| | Back to Top | |
|
jange
Registered Member
Date Joined Oct 2013
Total Posts : 53
| Posted 11/28/2016 3:54 PM (GMT -6) | | Hi Robert,
thanks for your response !
I tried to get in contact with you several times last year via Klemm.
But I don't know if they forwarded my emails to you.
I had sent them/you a list of about 50 bugs and documentation things from November 2.0
that I noticed during the creation of my comprehensive Music Font Comparison which was done in Finale and also included November2.
I also asked Klemm last month about the 129-159 bug in November 2/Finale 2014.5 and they didn't know about it, although they should have when Onttonen had also contacted them.
>That said, each symbol in the 'legacy' range [32-255] - this is how I call it in regard to SmuFl - has its equivalent somewhere in the upper Unicode/SmuFl range.
>So despite this Finale 2014.5 Mac-only bug, there is always a solution (this is a bit painful, I agree)
Yes, it's the same with my fonts, the symbols are there, but not in the 32-255 slots.
That's why I can't call them 100% Maestro-compatible on MacOS. "Set Default Music Font" doesn't fully replace Maestro then.
I could reduce the fonts to 32-255 only which I did in the v1.0 release: this still works fine in Finale/MacOS, but then I would lose the upper unicode symbols.
For example, I added a "Maestro section" to the Bravura font which works more or less like what you did with November 2 (the new font is called "Aruvarb").
And all free LilyPond fonts I used, still have the original LilyPond section at U+E100...
BTW, did you also look at my report on "Automatic Font Conversion" where I describe the "automatic" creation of the 25 fonts ?
What do you think of it regarding an automatic conversion to SMuFL ?
My font database currently holds about 1200 music symbols from 450 music fonts for Finale,
so the metric transformation is no problem anymore (as can be seen in the 25 music fonts above).
Currently I am working on a transformation of the same fonts to the Sibelius standard which is a bit more challenging.
For SMuFL the main addition would probably be the automatic calculation of the bounding box cut-outs which shouldn't be too difficult either.
My conversion plugin already works directly on the glyph coordinates from the ttf font files.
Jan | | Back to Top | |
|
Robert P.
Registered Member
Date Joined Apr 2004
Total Posts : 1691
| Posted 11/28/2016 6:00 PM (GMT -6) | | Hi Jan,
Yes Klemm did forward me your messages! Sorry for having been unresponsive, but I have taken your remarks into account (mostly the documentation bugs) for 2.1.
Regarding the non-perfect compatibility with Maestro's map, actually what I had in mind was the font map of November 1.0 (which differs a bit from Maestro's).
In the 2.0 doc I said:
"Switching from November (1.0), or Maestro, Petrucci etc. to November2 in your files is particularly easy as the first range [32…255] of characters is shared between November2 and other Finale-compatible fonts"
Now in 2.1:
"as the first range [32...255] of characters is very similar in November2 and in other Finale-compatible fonts"
I think is closer to the truth!
>> Yes, it's the same with my fonts, the symbols are there, but not in the 32-255 slots.
Well not quite: in November 2, they are all sitting kindly there except in the range [129-159] - that's Finale 2014.5+ bug.
>> BTW, did you also look at my report on "Automatic Font Conversion" where I describe the "automatic" creation of the 25 fonts ?
What do you think of it regarding an automatic conversion to SMuFL ?
Technically I think that's absolutely brillant! You are using FontForge scripting capabilities at its full power.
That said, be aware that tweaking a font that is not yours, even though the original is 'free', might lead to copyright infringement. Perhaps you have already done so, but you should definitely contact each font developer before releasing your package and even before bringing any remapping to a font.
Robert
2.66 GHz Intel Core 2 Duo MacBook Pro, 8GB RAM
Mac OS X 10.8.4 / [Win 7/8 under WMWare]Post Edited (Robert P.) : 11/28/2016 5:34:47 PM (GMT-6) | | Back to Top | |
|
jange
Registered Member
Date Joined Oct 2013
Total Posts : 53
| Posted 11/29/2016 3:25 AM (GMT -6) | | >> Yes, it's the same with my fonts, the symbols are there, but not in the 32-255 slots.
>Well not quite: in November 2, they are all sitting kindly there except in the range [129-159] - that's Finale 2014.5+ bug.
That's what I meant.
>That said, be aware that tweaking a font that is not yours,
I would be rather suicidal to publish 25 fonts and not to clear the rights.
Of course, everything was cleared. The license texts are in the fonts and in the zip file.
And that brought some restrictions.
Most of the original fonts were either released under the GNU GPL+FE or the SIL OFL license.
As these licenses aren't compatible you cannot combine glyphs from both license types.
That's why incomplete SIL OFL fonts (like the LilyPond fonts) use Bravura as a fallback font for the missing glyphs,
while incomplete GNU GPL fonts use Musica or Symbola as a fallback font.
And indeed there are some right owners from whom I haven't got an "ok" yet or who didn't allow the reproduction for Finale.
That is:
- Ircam, for the open Music fonts (BTW, Robert, aren't you at Ircam ? I had asked them why they chose the general GNU GPL license instead of the GNU GPL+FE license which was made especially for fonts, but didn't get an answer.)
- Capella, for the very many free capella fonts by Andreas Herzog (Andreas Herzog himself allowed the reproduction, but only for his own symbols, not for the original Capella symbols)
- Sibelius, for the usage of the exclusive Sibelius symbols in its subfonts (that's why I currently don't make much progress on the Sibelius conversion)
Robert, how did you calculate the bounding box cut-outs in November 2.0 ?
Did you use any software ?
JanPost Edited (jange) : 11/29/2016 3:43:52 AM (GMT-6) | | Back to Top | |
| Forum Information | Currently it is Tuesday, December 19, 2023 7:22 PM (GMT -6)
There are a total of 403,820 posts in 58,165 threads.
In the last 3 days there were 0 new threads and 0 reply posts. View Active Threads
|
Forum powered by dotNetBB v2.42EC SP3
dotNetBB © 2000-2023 |
|
|