[smufl-discuss] Re: Next steps

classic Classic list List threaded Threaded
1 message Options
TW
Reply | Threaded
Open this post in threaded view
|

[smufl-discuss] Re: Next steps

TW
What does everyone think about setting up a Wiki that bundles the
discussion by topic so that you're not forced to dig through e-mail
archives to get the complete picture and the latest state of a
discussion?  In my personal experience, a Wiki is really useful for
capturing what is the state of a discussion, what are the solved
problems and which problems are still to be solved.  In my opinion it
would be helpful to have overview pages for each topic that represent
the current state of things (like codepoints, glyph metrics, stylistic
alternates, glyph origins, font meta information including glyph
bounding boxes and attachment points, organisation, aims and
strategies for SMuFL).  For each of those topics, a Wiki could provide
an overview of what has been agreed on, what suggestions have been
brought forward and what is still to be solved.  One could even think
about moving discussion from the mailing list to discussion pages on
such a Wiki to keep things together that belong together.

Alternatively, a forum or issue tracker might serve a similar purpose
of keeping a discussion together by topic, but by themselves, they are
not able to represent a current state as good as a Wiki can.  However,
they might be able to complement a Wiki by making the discussion on a
forum or issue tracker and summing up the current state of the
development in a Wiki.  Eventually, the content of the Wiki could be
developing towards a text for the official SMuFL specifications.

Platforms like Bitbucket, GitHub, Google Code or SourceForge all unify
Wikis and issue trackers on one platform and might be options to
consider.  The development of the specifications might then take place
using the version control system that each of them offer.

Have a nice week-end everybody
Thomas Weber



2013/6/21 Daniel Spreadbury <[hidden email]>:

> Mark wrote:
>
>> Now that the initial flurry of debate seems to have subsided,
>> I¹m wondering what your thoughts are for next steps.
>
> Apologies for the radio silence. I have been hard at work on a major expansion of SMuFL based on the feedback I have received both directly from this mailing list and through private contact. I anticipate that I will have something to share with the community within the next couple of weeks, which I expect will take the form of a revised version of the SMuFL document and a new version of Bravura that matches the specification. (It has been a relief that discussion has died down over the last couple of weeks as I have plenty of feedback to act upon!)
>
> I believe the main issues concerning the use of OpenType features have been resolved to the satisfaction of the community: no SMuFL-compliant font will be compelled to use OpenType features such as ligatures or stylistic alternates, since the recommendation will be to explicitly encode any such alternative characters at codepoints drawn from a pool of codepoints set aside for the purpose, at the discretion of each font developer.
>
> The current set of tasks I'm working on does not include the production of a complete set of recommendations for font metrics, glyph origins, etc., but that will be the next major task after this big revision has been completed. If anybody in the community wants to make a start on that job before I can get to it, that would of course be most welcome!
>
>> First off, how do you propose all the various issues that have been
>> raised be resolved?
>
> I hope we can reach consensus here on the list, rather than requiring formal votes on individual issues. With the exception of the issue concerning how identical glyphs at multiple sizes (e.g. clefs) should be handled, I believe every contentious issue to date has been solved by reaching consensus, and hopefully that will continue. (I consider the clefs issue still open, for what it's worth, though my own position on it remains unchanged.)
>
> I do think that we should give serious consideration to forming some kind of advisory board or steering group that can make tough decisions in the event of a lack of consensus, but working out who should be in such a group and what its decision-making processes should be is potentially a contentious issue itself!
>
> In the meantime, I hope we will be able to reach consensus, and that in the event we cannot, the community will trust me and my colleagues here at Steinberg to make good decisions on behalf of the community. This will have to evolve along with the standard itself, I think.
>
>> Have other potentially interested parties been reached out
>> to regarding this process?
>
> There are representatives from most of the currently active companies working in the field of music notation already signed up to the list, though they are generally staying quiet, and I don't think it would be polite for me to call them out. I hope that we will see greater participation from other vendors and interested parties in due course, though of course I am somewhat leery of the additional burden this will place on me, as I work both to maintain the standard, keep our own font(s) up to date, and do my day job of designing our new application.
>
>> Lastly, do you have a time frame in mind for completion of this process,
>> or do you see it as open-ended?
>
> I believe it will probably be somewhat open-ended, but my hope is that we will get to a "version 1.0" relatively quickly, and then perhaps the pace will slow and further change will be less radical and more incremental. For example, I am treating codepoint assignation as mutable at present (and indeed hundreds of them will be changing in the revision I am working on at present), but once we get to version 1.0 I think we should aim to limit changes to existing codepoints so as to reduce the burden on font developers and software vendors.
>
> All the best,
>
> Daniel
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany
> Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 | www.steinberg.net
> Managing Director: Andreas Stelling, Kazunori Kobayashi
> Registration Court: Hamburg HRB 86534
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>
> #############################################################
> This message is sent to you because you are subscribed to
>   the mailing list <[hidden email]>.
> To unsubscribe, E-mail to: <[hidden email]>
> To switch to the DIGEST mode, E-mail to <[hidden email]>
> To switch to the INDEX mode, E-mail to <[hidden email]>
> Send administrative queries to  <[hidden email]>
>

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
To switch to the DIGEST mode, E-mail to <[hidden email]>
To switch to the INDEX mode, E-mail to <[hidden email]>
Send administrative queries to  <[hidden email]>