Finale SmartMusic
  Home | Log In | Register | Search | Help
   
MakeMusic Forum > Public Forums > Finale - Macintosh - FORUM HAS MOVED! > The new notation program?  Forum Quick Jump
 
You cannot post new topics in this forum. You cannot reply to topics in this forum. Printable Version
70 posts in this thread.
Viewing Page :
 1  2  3 
[ << Previous Thread | Next Thread >> | Show Newest Post First ]

N. Grossingink
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to N. GrossinginkAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2002
Total Posts : 3991
 
   Posted 11/7/2016 12:50 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
Thanks, John.

I hope users that use other fonts are prepared for the switchover to SMuFL. I would save a "Maestro Font Default" that is un-SMuFLized and a number of template formats with the current font mapping. Otherwise, your 3rd party font aint gonna work anymore on the new setup.

N.


OSX El Capitan 10.11.6
Finale 2011c, 2012c for production work

Finale 2014.5, not used by my clients

(Finale v25 - not interested yet)

TgTools, Patterson Plugins, JW Change and Staff Polyphony, QuicKeys 4
Mac Mini 2.4 Ghz Intel, 8GB RAM
New Belgium Fat Tire Ale

Back to Top

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/8/2016 1:38 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
As Wiggy described somewhere, it is possible to have Maestro SMuFL-compatible AND to have it working for old files. The question is if MM or Avid want to make their property fonts SMuFL compatible. I don't think they want. Personally I have very mixed feeling for SMuFL.

BTW, no one is talking about MuseScore 2 and v3. It has more features than Dorico and many other features that I would like to see implemented in Finale. It is a greatly designed software.




Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAM

Back to Top

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/8/2016 3:59 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
As a font designer, I can't for the life of me figure out why SMuFL is controversial. It's primary objective is to standardize glyph mapping for any musical symbol in the literature, which surely benefits both software designers and users.

SMuFL does not stipulate any mandatory glyphs; it only recommends them, so the scope of a SMuFL font is entirely optional. It is true that it can be very hard to find a single symbol in a huge SMuFL font. However, the mapping is entirely systematic; the glyphs are sorted in categories and follows an entirely standardized naming scheme which facilitates the implementation of improved search and navigation functionality within the software itself.

Beyond glyph mapping and naming, SMuFL includes an extended set of glyph metadata, including registration, spacing, bounding box coordinates and coordinates for stem connections, optical centering of dynamics and cutouts in accidentals and other shapes. This metadata set eliminates the need for font annotation files and application specific stem connections, and may be used by software developers to improve an application's placement and spacing functionality.

The SMuFL specification is a joint effort, initiated by Steinberg, developed and maintained by the W3C Music Notation Community Group and chaired by Michael Good (MakeMusic), Joe Berkowitz (Noteflight) and Daniel Spreadbury (Steinberg).


13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3

Back to Top

Robert P.
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Robert P.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2004
Total Posts : 1691
 
   Posted 11/8/2016 5:55 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
++1
Back to Top

tisimst
Registered Member



Email Address Not AvailableClick to visit tisimst's website.Send a Private Message to tisimstAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2015
Total Posts : 18
 
   Posted 11/8/2016 12:56 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
+++1! A couple of thoughts as the topic of SMuFL has come up...

Knut said...
As a font designer, I can't for the life of me figure out why SMuFL is controversial. It's primary objective is to standardize glyph mapping for any musical symbol in the literature, which surely benefits both software designers and users.

I personally agree with you, Knut, but I can see how management/developers who are trying to find ways of keeping market share would not want to get away from their own model/format/encoding. "Why would I make it easier for someone to use it on the other guy's software?" I'm only guessing this is really the line of thinking, but it's a possibility. The other logical issue is code refactoring to using a different font encoding. This is no small task. I can understand some hesitancy there. And what about backward-compatibility with program versions that don't support SMuFL? That can be another tricky feat to tackle smoothly.

Knut said...
Beyond glyph mapping and naming, SMuFL includes an extended set of glyph metadata, including registration, spacing, bounding box coordinates and coordinates for stem connections, optical centering of dynamics and cutouts in accidentals and other shapes. This metadata set eliminates the need for font annotation files and application specific stem connections, and may be used by software developers to improve an application's placement and spacing functionality.

At first I wondered if SMuFL would catch on, but I think it has become clear it is here to stay. The more I think about it, the more I realize SMuFL is heaven-sent for us designers. It makes font maintenance MUCH easier and gives us the ability to better support each application and more users, making more elaborate fonts available for everyone! I am a huge fan of SMuFL.

N. Grossingink said...
That's likely to be a big/impossible hurdle for publishers and individuals who favor a custom or 3rd party font.

Maybe big, definitely not impossible. There are a good handful of us that have experience working with 3rd-party fonts and what's involved in converting them to/from the SMuFL encoding. Publishers and individuals can always reach out to one of us if they need help doing that.
Back to Top

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/9/2016 12:20 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
I am not against SMuFL, as said, I have mixed feelings. What you all say above I agree with.

On the contrary, the main SMuFL problems I myself see is the following:
- zero compatibility with old files;
- not developed by community in the strict sense - as long as you have the leaders who are interested in their commercial product, it is not. It is not like Debian - no commercial interest by a company. I see here a strong interest from Steinberg/Dorico;
- extreme ranges - unless it is developed a "music"-language keyboard, it is very hard to use it outside of one product (Dorico); very hard to use in Word, or Sibelius etc.
- repetitive symbols found over again;
- a monster size font table, imitating Unicode of everything possible, but hey - who will ever use g clef with 0?
- the border between musical and non musical symbols is not clear;
- how will other types of notation be used, such as indian, byzantine? What software?
- as an engraver or composer you will perhaps need one symbol that is not found in SMuFL: you can apply for that symbol to SMuFL, if rejected (very possible) you need one font MORE to use in your music, or tweak already existing font;

- The Main Question: why do we need only ONE font file to cover all music symbols, and why do we need these Unicode ranges? Why cannot f be typed as a keystroke f?

I know that Daniel S is coming from Sibelius where they struggled with symbols spread across many fonts, but this, is in my opinion, as well extreme.

Another feeling about just Bravura: it is not a balanced and well designed font. Some symbols are very beautiful another are just plain ugly. It is my personal opinion.




Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAM

Post Edited (OCTO.) : 11/9/2016 12:34:29 AM (GMT-6)

Back to Top

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/9/2016 3:57 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
OCTO. said...
- zero compatibility with old files;


That's true, but it doesn't prevent you from keeping your old fonts installed, so this argument seems irrelevant to me.

OCTO. said...
- not developed by community in the strict sense - as long as you have the leaders who are interested in their commercial product, it is not. It is not like Debian - no commercial interest by a company. I see here a strong interest from Steinberg/Dorico;


Which industry standards are, really? I'm not an expert in the tech field, but my impression is that the vast majority of software and hardware industry standards are fueled by some kind of commercial interest and developed by either established or entrepreneurial entities. As I've stated previously, SMuFL is a joint effort between a large community of engravers, publishers and software developers, lead by representatives from MakeMusic, Noteflight and Steinberg.

OCTO. said...
- extreme ranges - unless it is developed a "music"-language keyboard, it is very hard to use it outside of one product (Dorico); very hard to use in Word, or Sibelius etc.


If SMuFL indeed is widely adopted, this is a passing issue that quickly will be solved by software developers. Any software which supports SMuFL needs to provide the means of symbol selection from any supported glyph categories. As the need for these means become apparent, this issue will likely take care of itself.

OCTO. said...
- repetitive symbols found over again;


This seems to be a recurring argument whenever this topic is discussed. As I've said before, duplicate symbols in SMuFL is the natural result of it's structure, and is also closely related to concerns about accessibility. One example is microtonal accidentals, which has been represented in many different ways at different times and by different composers. There really isn't one single system which has caught on enough to exclude all others. Yet, very few of these systems are entirely unique; they usually build on the traditional accidentals or some other related system, which means that many of the symbols will be the same across different systems. How, then, should a font be structured if not by category? And if no duplicate symbol was allowed in a font, in which category should common symbols reside?

Of course, any font designer is free to exclude any duplicate symbol if so inclined. Bravura has to include them, though, to fulfill it's purpose of being a showcase for the entire SMuFL range.

OCTO. said...
- a monster size font table, imitating Unicode of everything possible, but hey - who will ever use g clef with 0?


How would you suggest going about symbol selection if not by their presence in the literature?

OCTO. said...
- the border between musical and non musical symbols is not clear;


How so?

OCTO. said...
- how will other types of notation be used, such as indian, byzantine? What software?


At this point, who knows. For SMuFL to be a viable standard it needs to be suited for the future needs of software developers.

OCTO. said...
- as an engraver or composer you will perhaps need one symbol that is not found in SMuFL: you can apply for that symbol to SMuFL, if rejected (very possible) you need one font MORE to use in your music, or tweak already existing font;


I'm not sure what you're basing this statement on. If the symbol you're requesting is to be found in any published work, I highly doubt that it will be rejected, since this is basically the sole requirement for inclusion.

OCTO. said...
- The Main Question: why do we need only ONE font file to cover all music symbols, and why do we need these Unicode ranges? Why cannot f be typed as a keystroke f?

I know that Daniel S is coming from Sibelius where they struggled with symbols spread across many fonts, but this, is in my opinion, as well extreme.


From my perspective as a font designer I can tell you that this is a no brainer, and even as a user of Sibelius, I've found it quite a hassle to deal with numerous different fonts for musical symbols, seemingly without any means of categorization except 'common', 'special' and 'extra special', which isn't very useful at all.


13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3

Post Edited (Knut) : 11/9/2016 3:02:49 AM (GMT-6)

Back to Top

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/9/2016 6:28 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
Knut said...
OCTO. said...
- zero compatibility with old files;


That's true, but it doesn't prevent you from keeping your old fonts installed, so this argument seems irrelevant to me.

...Not being able to reply to all other, this is very relevant. Guess that in 5 years the "New Finale" will support ONLY SMuFL. How will you open your old files if the old Finale is not installable on the current system?




Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAM

Post Edited (OCTO.) : 11/9/2016 5:31:15 AM (GMT-6)

Back to Top

Dr. Wiggy
Early music: modern methods



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Dr. WiggyAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jun 2006
Total Posts : 12628
 
   Posted 11/9/2016 6:59 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
OCTO. said...
Guess that in 5 years the "New Finale" will support ONLY SMuFL. How will you open your old files if the old Finale is not installable on the current system?


1. It's possible that a SMuFL-compatible Maestro might also be "Maestro-compatible", like November2.
2. Loading a Library that maps the old character glyphs to the new ones should solve most issues. Or perhaps a round-trip through MusicXML.

However, there may come a time when backwards compatibility presents such an obstacle to future progress, that a clean break needs to be made with .mus files (as opposed to .musx). As I posted elsewhere, how many other apps can open 20-year old files? Quark XPress can't. InDesign CC can't open PageMaker files. Even ancient Illustrator files may change the text (position, outlining) and other elements on opening.


Finale v.25.1, 2012 MacMini; 2012 MacBook Pro (10.11.6 / 10.12.1)
Edirol FA-66; Roland A-49, HP Laserjet 5200 DTN
Ancient Groove Music www.ancientgroove.co.uk

Post Edited (Dr. Wiggy) : 11/9/2016 6:02:26 AM (GMT-6)

Back to Top

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/9/2016 7:27 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
Dr. Wiggy said...
OCTO. said...
Guess that in 5 years the "New Finale" will support ONLY SMuFL. How will you open your old files if the old Finale is not installable on the current system?


1. It's possible that a SMuFL-compatible Maestro might also be "Maestro-compatible", like November2.
2. Loading a Library that maps the old character glyphs to the new ones should solve most issues. Or perhaps a round-trip through MusicXML.

However, there may come a time when backwards compatibility presents such an obstacle to future progress, that a clean break needs to be made with .mus files (as opposed to .musx). As I posted elsewhere, how many other apps can open 20-year old files? Quark XPress can't. InDesign CC can't open PageMaker files. Even ancient Illustrator files may change the text (position, outlining) and other elements on opening.


+1


13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3

Back to Top

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/9/2016 8:08 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
OK, I give up! Not because I don't agree with you about SMuFL, but because I do now agree. You have convinced me! :)
Particularly you who work with the music font design - simply I must trust you.

BTW, back to the topic, check MuseScore 2 - really a good software.




Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAM

Back to Top

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/9/2016 8:13 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
OCTO. said...
OK, I give up! Not because I don't agree with you about SMuFL, but because I do now agree. You have convinced me! :)
Particularly you who work with the music font design - simply I must trust you.

BTW, back to the topic, check MuseScore 2 - really a good software.


Hooray! :-)

You are a class act, OCTO!


13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3

Back to Top

MikeHalloran
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to MikeHalloranAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Oct 2001
Total Posts : 217
 
   Posted 11/9/2016 8:54 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
OCTO. said...
...BTW, back to the topic, check MuseScore 2 - really a good software.


Are you kidding?

No real time note entry. Mouse entry is convoluted at best. No video support. PDF export is unwieldy and bloated. MusicXML export and import barely works.

Oh yea, it's free—and worth every penny as far as I'm concerned.


Finale 25.1, 2014.5, 2011c, SmartScore X Pro II, Encore 5.07, GPO 5
2010 iMac i7, 32G RAM, 2T SSD, Late 2013 MacBook Air, OS 10.12.1
MOTU Digital Performer 9.12, 9.02, Logic Pro X 10.2.4

Back to Top

Vaughan
Registered Member

Click to send Vaughan email.Personal Homepage Not AvailableSend a Private Message to VaughanAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jun 1999
Total Posts : 4984
 
   Posted 11/9/2016 10:27 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
I had fleeting experience with MuseScore v2 because a colleague did a rather large project using it. While I appreciate the open source aspect of it, as well as certain aspects of its interface and the willingness of the makers to listen to and give assistance to users, it wasn't even close to being able to produce consistently professional results. Having said that, they're working hard on v3 which is supposed to have a large number of improvements and refinements, like an equivalent to Sibelius' magnetic spacing. It's about time Finale had something similar and it would surprise me if MM weren't working on it.


Vaughan

Finale 3.2 - 25, Sibelius 4 - 7
Patterson's plugins, Tobias' plugins, full version, waiting for Jari's plugin update
MacOS 10.12
MacPro (2016) 16 GB, MacBookPro (2011) 8 GB

Amsterdam

Back to Top

tisimst
Registered Member



Email Address Not AvailableClick to visit tisimst's website.Send a Private Message to tisimstAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2015
Total Posts : 18
 
   Posted 11/9/2016 12:00 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
Sorry to get back to this, but I thought I'd share a couple of last thoughts...

OCTO. said...
- repetitive symbols found over again;

Part of this is compliance with Unicode itself. There are a few locations within Unicode where musical symbols are already expected to be. So, SMuFL (or rather, Bravura) copies glyphs to those code points as well in case someone is using those to access music symbols.

OCTO. said...
why do we need only ONE font file to cover all music symbols, and why do we need these Unicode ranges?

Why not? Sure it makes it slightly less convenient to access the glyphs outside of the ASCII range, but that's true for almost every text font as well. So, what have word-processors and the like done? They've created ways to make accessing the glyphs easier for users. I'd much rather have everything in a single file. It's much easier to manage (at least for me).

OCTO. said...
Why cannot f be typed as a keystroke f?

This has long puzzled me as well. Good news is, it's not hard for font designers to do (and maybe *should* do) and makes a lot of sense to me to at least have a copy of the dynamic letters also available in the normal ASCII code points.


Music Typeface Designer & Engraver - LilyPond | Sibelius | Finale | Dorico | SMuFL | Inkscape | FontForge
leighverlag.blogspot.com | www.musictypefoundry.com

Back to Top

Dr. Wiggy
Early music: modern methods



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Dr. WiggyAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jun 2006
Total Posts : 12628
 
   Posted 11/9/2016 1:17 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
tisimst said...
OCTO. said...
Why cannot f be typed as a keystroke f?

This has long puzzled me as well.

Moving music symbols out of the ASCII range means that a music font could also include a useful text font. This is particularly useful with regard to something like Bravura Text, which is designed to accommodate music symbols within a text environment. (But not actually Bravura Text, which doesn't have ASCII chars. :p) Also, for Unicode compliance, "if it's not the letter A, it shouldn't go in the letter A's slot".

The dynamic letters are only fmrspz. You would either have to make an entire italic face to match these highly stylised forms, or just negate the idea of reserving that range for ASCII symbols.

Furthermore, a decent music notation package should be able to provide easy keyboard entry of high-order Unicode symbols. In Finale, you can program an expression meta-tool to use F for forte and P for piano, if you'd prefer, instead of the number row.


Finale v.25.1, 2012 MacMini; 2012 MacBook Pro (10.11.6 / 10.12.1)
Edirol FA-66; Roland A-49, HP Laserjet 5200 DTN
Ancient Groove Music www.ancientgroove.co.uk

Post Edited (Dr. Wiggy) : 11/9/2016 12:20:29 PM (GMT-6)

Back to Top

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/9/2016 2:36 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
tisimst said...
Sorry to get back to this, but I thought I'd share a couple of last thoughts
OCTO. said...
why do we need only ONE font file to cover all music symbols, and why do we need these Unicode ranges?

Why not? Sure it makes it slightly less convenient to access the glyphs outside of the ASCII range, but that's true for almost every text font as well. So, what have word-processors and the like done?


Well, not completely. Do you have one font that covers roman, italic, semibold, bolditalic, semicondensed......? No.
That was my point. I would simply organize the font family. Clefs, noteheads, flags.... everything is grouped in families.
And than you could have NUMEROUS variants under the flag style, and not limited, you could also expand it by yourself. So when one wants to change a flag, goes to font menu - flag family and choose the symbol. That would be more smart than one large endless font file, with limited flags.
And now, there is Bravura Text. Well...
But I go with SMuFL as it is. I just need to accommodate.

The problem with Sib is not able to add any number of fonts. Also Opus Std doesn't mean so much.




Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAM

Back to Top

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/9/2016 4:49 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
OCTO. said...
tisimst said...
Sorry to get back to this, but I thought I'd share a couple of last thoughts
OCTO. said...
why do we need only ONE font file to cover all music symbols, and why do we need these Unicode ranges?

Why not? Sure it makes it slightly less convenient to access the glyphs outside of the ASCII range, but that's true for almost every text font as well. So, what have word-processors and the like done?


Well, not completely. Do you have one font that covers roman, italic, semibold, bolditalic, semicondensed......? No.
That was my point. I would simply organize the font family. Clefs, noteheads, flags.... everything is grouped in families.
And than you could have NUMEROUS variants under the flag style, and not limited, you could also expand it by yourself. So when one wants to change a flag, goes to font menu - flag family and choose the symbol. That would be more smart than one large endless font file, with limited flags.
And now, there is Bravura Text. Well...
But I go with SMuFL as it is. I just need to accommodate.

The problem with Sib is not able to add any number of fonts. Also Opus Std doesn't mean so much.


I can see your point, OCTO, but I don't think you can compare the concept of separate font styles to separate musical symbol categories. Text font styles like regular, italic and bold are separated into different files because they're stylistically different representations of the same character set. This would not be the case with separating each symbol category into different files, which, in regards to the full scope of SMuFL would result in over 100 different files! Some of these could be easily combined into larger categories, but the number of files you'd have to deal with if you wanted to install a complete SMuFL font would still be very high.

By this principle, if I wanted to create an alternate version of a SMuFL font specifically designed for smaller staff sizes, it would indeed make sense to separate this stylistic alternate version into a dedicated font file, but parsing an entire font into different files by category would be contrary to what most people would expect a font to work. It would be more like separating a text font into upper and lower case latin letters, numerals, latin diacritics, cyrillic letters etc. Very cumbersome indeed.


13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3

Back to Top

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/9/2016 9:43 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
Hm.. I understand you Knut. And trusts you as well. :)
My knowledge about fontt "engines" is limited, and I am perhaps a bit naive in my ideas.... :(




Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAM

Back to Top

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/10/2016 7:44 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
I wouldn't say naive. After all, this isn't necessarily something you have to think about unless you're designing fonts.

Anyway, I totally agree that it can be a drag to deal with a font with a huge number of glyphs, but I think it's better than the alternative, not least for software developers to help improve the situation.


13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3

Back to Top
You cannot post new topics in this forum. You cannot reply to topics in this forum. Printable Version
70 posts in this thread.
Viewing Page :
 1  2  3 
   
Forum Information
Currently it is Friday, December 4, 2020 10:51 AM (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