Re: How to Add Beams to Notes

[Philippe Verdy via Unicode]

Consider also that the BMP is almost full, the remaining few holes are kept
for isolated characters that may be added to existing scripts, or
permanently reserved to avoid clashes with legacy softwares using simple
code remappings between distinct blocks, or to perform simple case
conversions (e.g. in Greek) for internal purposes (these positions are not
interoperable and may clash with future versions of the UCS and I18n
tools/libraries like ICU)

You should abstain using any currently unassigned positions in the existing
Unicode blocks: use PUA if you have nothing else; there are plenty of space
available, in the BMP (most common usage in fonts that need to map
additional glyphs) or in the two last planes. The PUA block in the BMP is
large enough for most apps and almost all fonts that need private glyphs
for internal purposes, or for still unencoded characters or for your own
encoded variants such as slanted symbols, rotated symbols, inverted
symbols, or symbols with multiple sizes, or at different positions on the
musical score, or using distinct styles (e.g. between different players or
singers, or various symbols for percusive instruments or specific
intruments, or extra annotations).

Many new symbols have been encoded first as PUAs in early fonts used to
create proposals (then rendered to a PDF, or embedded fonts in a rich text
document, or webfonts loaded from static versioned URLs on a repository
like GitHub or on a public cloud). Later the proposal passed the early
steps for reviewing the repertoire and choosing more relevant positions,
then characters were encoded and standardized and these fonts were updated
to map their glyphs to not just their existing PUAs but also the nex
standard positions (or encoded variants)

2017-05-02 2:27 GMT+02:00 Richard Wordingham via Unicode <
unicode@unicode.org>:

> On Mon, 1 May 2017 23:03:53 +
> Michael Bear via Unicode  wrote:
>
> > “Rather than using "unused code positions", I would always recommend
> > to use some of the Private Use code points.” Consider it done.
> >
> > “What is the intended usage of your font? Music score
> > applications? others?” I am simply going to make a series of full
> > Unicode fonts (which, due to the 65,535-character limit in fonts,
> > each of the 3 fonts covers different planes: The first font does the
> > BMP,
>
> How much margin do you have for the BMP?  There are a fair few
> variation sequences, on top of all the contextual forms and conjuncts.
>

Re: How to Add Beams to Notes

[Richard Wordingham via Unicode]

On Mon, 1 May 2017 23:03:53 +
Michael Bear via Unicode  wrote:

> “Rather than using "unused code positions", I would always recommend
> to use some of the Private Use code points.” Consider it done.
> 
> “What is the intended usage of your font? Music score
> applications? others?” I am simply going to make a series of full
> Unicode fonts (which, due to the 65,535-character limit in fonts,
> each of the 3 fonts covers different planes: The first font does the
> BMP,

How much margin do you have for the BMP?  There are a fair few
variation sequences, on top of all the contextual forms and conjuncts.

Richard.

Re: How to Add Beams to Notes

[John W Kennedy via Unicode]

> On May 1, 2017, at 3:12 PM, Michael Bear via Unicode  
> wrote:
> 
> I am trying to make a music notation font. It will use the Musical Symbols 
> block in Unicode (1D100-1D1FF), but, since that block has a bad rep for not 
> being very complete, I added some extra characters in the unmapped positions 
> of that block (e.g. U+1D127 inverts the stem of the previous note, U+1D1E9 is 
> a ledger line, U+1D1EA is the "TAB" clef, U+1D1F0-U+1D1FC position the note 
> along the staff, etc.) I've had no problem so far, but now I need to do 
> beamed notes. The Unicode block has control characters for beginning and 
> ending a series of beamed notes (U+1D173 and U+1D174, respectively), but I'm 
> not really sure how to add beams to the notes while keeping the pitch intact. 
> I know I'll obviously need OpenType for this. Slanted beams would be 
> preferred, but straight beams are acceptable. It will need to support beams 
> added on for longer notes. Can someone help me with this?
>  
> I had asked this on a High Logic Font Creator forum (here), and someone said 
> to subscribe to your mailing list and ask you guys. So here I am! Anyway, 
> help, please?

You might want to acquaint yourself with http://www.smufl.org

Re: abstract characters, semantics, meaningful transformations ... Was: Tibetan Paluta

[David Starner via Unicode]

On Mon, May 1, 2017 at 7:26 AM Naena Guru via Unicode 
wrote:

> This whole attempt to make digitizing Indic script some esoteric,
> 'abstract', 'semantic representation' and so on seems to me is an attempt
> to make Unicode the realm of the some super humans.
>
Unicode is like writing. At its core, it is a hairy esoteric mess; mix
these certain chemicals the right ways, and prepare a writing implement and
writing surface in the right (non-trivial) ways, and then manipulate that
implement carefully to make certain marks that have unclear delimitations
between correct and incorrect. But in the end, as much of that is removed
from the problem of the user as possible; in the case of modern
word-processing system, it's a matter of hitting the keys and then hitting
print, in complete ignorance of all the silicon and printing magic going on
between.

Unicode is not the realm of everyone; it's the realm of people with a
certain amount of linguistic knowledge and computer knowledge. There's only
a problem if those people can't make it usable for the everyday programmer
and therethrough to the average person.

> The purpose of writing is to represent speech.
>
Meh. The purpose of writing is to represent language, which may be
unrelated to speech (like in the case of SignWriting and mathematics) or
somewhat related to speech--very few forms of writing are direct
transcriptions of speech. Even the closest tend to exchange a lot of
intonation details for punctuation that reveals different information.

> English writing was massacred when printing was brought in from Europe.
>
No, it wasn't. Printing made no difference to the fact that English has a
dozen vowels with five letters to write them. The thorn has little impact
on the ambiguity of English writing. The problem with printing is that it
fossilizes the written language, and our spellings have stayed the same
while the pronunciations have changed. And the dissociation of sound and
writing sometimes helps English; even when two English speakers from
different parts of the world would have trouble understanding each other,
writing is usually not so impaired.

RE: How to Add Beams to Notes

[Michael Bear via Unicode]

“Rather than using "unused code positions", I would always recommend to use 
some of the Private Use code points.”
Consider it done.

“What is the intended usage of your font? Music score 
applications? others?”
I am simply going to make a series of full Unicode fonts (which, due to the 
65,535-character limit in fonts, each of the 3 fonts covers different planes: 
The first font does the BMP, the second one does the SMP, and the third one is 
all the other planes, which are vacant enough to fit in one font) that will 
have the necessary OpenType features of every script. And I thought “Hey, maybe 
I should do full OT for the music block that no one has really done yet! How 
awesome would that be?” So I made a test font to work it out, but I ran into 
this one pothole. That’s when I came here.

Sent from Mail for Windows 10

Re: How to Add Beams to Notes

[Stötzner Signographie via Unicode]

Bad news, I’m afraid.
What is the intended usage of your font? Music score applications? others? The 
overall problem with musical notation is, there is no comprehensive character 
encoding standard and no generally working text and layout composing method 
established. In the light of that fact it is hopeless to make fonts for this. 
The fonts are not the problem (yes they are, there is no solid encoding scheme 
available), but the lack of composing syntax is the crux you’ll hardly overcome.
If you need to cater for a specific usage scenario you’ll end up with a 
complete hack anyway (however it may look like, doesn’t matter). 
Good luck!

A. Stötzner
(Musical notation project)


Am 01.05.2017 um 21:12 schrieb Michael Bear via Unicode:

> I am trying to make a music notation font. It will use the Musical Symbols 
> block in Unicode (1D100-1D1FF), but, since that block has a bad rep for not 
> being very complete, I added some extra characters in the unmapped positions 
> of that block (e.g. U+1D127 inverts the stem of the previous note, U+1D1E9 is 
> a ledger line, U+1D1EA is the "TAB" clef, U+1D1F0-U+1D1FC position the note 
> along the staff, etc.) I've had no problem so far, but now I need to do 
> beamed notes. The Unicode block has control characters for beginning and 
> ending a series of beamed notes (U+1D173 and U+1D174, respectively), but I'm 
> not really sure how to add beams to the notes while keeping the pitch intact. 
> I know I'll obviously need OpenType for this. Slanted beams would be 
> preferred, but straight beams are acceptable. It will need to support beams 
> added on for longer notes. Can someone help me with this?
>  
> I had asked this on a High Logic Font Creator forum (here), and someone said 
> to subscribe to your mailing list and ask you guys. So here I am! Anyway, 
> help, please?
>  
> Sent from Mail for Windows 10
>  

___

Andreas Stötzner  Gestaltung Signographie Fontentwicklung
 
Haus des Buches 
Gerichtsweg 28, Raum 434
04103 Leipzig
0176-86823396

Re: How to Add Beams to Notes

[Asmus Freytag via Unicode]

  
  
On 5/1/2017 12:12 PM, Michael Bear via
  Unicode wrote:


  
  
  
  
I am trying to make a music notation font.
  It will use the Musical Symbols block in Unicode
  (1D100-1D1FF), but, since that block has a bad rep for not
  being very complete, I added some extra characters in the
  unmapped positions of that block (e.g. U+1D127 inverts the
  stem of the previous note, U+1D1E9 is a ledger line, U+1D1EA
  is the "TAB" clef, U+1D1F0-U+1D1FC position the note along the
  staff, etc.) I've had no problem so far, but now I need to do
  beamed notes. The Unicode block has control characters for
  beginning and ending a series of beamed notes (U+1D173 and
  U+1D174, respectively), but I'm not really sure how to add
  beams to the notes while keeping the pitch intact. I know I'll
  obviously need OpenType for this. Slanted beams would be
  preferred, but straight beams are acceptable. It will need to
  support beams added on for longer notes. Can someone help me
  with this?
 
I had asked this on a High Logic Font
  Creator forum (here),
  and someone said to subscribe to your mailing list and ask you
  guys. So here I am! Anyway, help, please?
 
Sent from 
Mail for Windows 10
 
  

Just an aside: rather than using "unused
code positions", I would always recommend to use some of the Private
Use code points. That way, whatever you work on would remain usable
when Unicode inevitably adds some characters that would fill
those "unused" positions.
A./
  
  

How to Add Beams to Notes

[Michael Bear via Unicode]

I am trying to make a music notation font. It will use the Musical Symbols 
block in Unicode (1D100-1D1FF), but, since that block has a bad rep for not 
being very complete, I added some extra characters in the unmapped positions of 
that block (e.g. U+1D127 inverts the stem of the previous note, U+1D1E9 is a 
ledger line, U+1D1EA is the "TAB" clef, U+1D1F0-U+1D1FC position the note along 
the staff, etc.) I've had no problem so far, but now I need to do beamed notes. 
The Unicode block has control characters for beginning and ending a series of 
beamed notes (U+1D173 and U+1D174, respectively), but I'm not really sure how 
to add beams to the notes while keeping the pitch intact. I know I'll obviously 
need OpenType for this. Slanted beams would be preferred, but straight beams 
are acceptable. It will need to support beams added on for longer notes. Can 
someone help me with this?

I had asked this on a High Logic Font Creator forum 
(here), and someone said 
to subscribe to your mailing list and ask you guys. So here I am! Anyway, help, 
please?

Sent from Mail for Windows 10

Re: abstract characters, semantics, meaningful transformations ... Was: Tibetan Paluta

[Naena Guru via Unicode]

A little humor is very good.

sarasvaþi was a sweet girl, I am sure, so much so that when she died, I 
think, those who were imagining about her beyond practical, made her 
rise up, up and fly away. Now you watch what happens to Elizabeth when 
she dies. They narrowly failed making one such with Hillary Clinton as 
she is suspected of having Parkinson's which condition her daughter says 
has an anecdotal remedy with MaryJane. Hmmm... Who went to her 
daughter's house instead of to the doctor when they suddenly fell?


As for Thoth, he is okay. Don't worry. Egyptian man => demi-god => god 
has not much of a consequence in the West dominated culture of this day.



On 5/1/2017 8:55 PM, Richard Wordingham via Unicode wrote:

On Mon, 1 May 2017 19:49:27 +0530
Naena Guru via Unicode  wrote:


The purpose of writing is to represent speech. It is not some secret
that demi-gods created 

Sarasvati and Thoth would be offended at being called mere demi-gods.


sound => letter that is the basis for writing.

"=>" is not a particularly phonetic notation.  It took quite a while
for letters to become the primary part of writing anywhere, and they
are not a universal phenomenon.

Richard.
Okay, Richard. Your probably have knowledge of how writing evolved in 
the whole world. Tell us how it was in South Asia. Was it like I said, 
sound => letter? I assume only to know about English and Indic in this 
respect.

Re: abstract characters, semantics, meaningful transformations ... Was: Tibetan Paluta

[Alastair Houghton via Unicode]

On 1 May 2017, at 15:19, Naena Guru via Unicode  wrote:
> 
> This whole attempt to make digitizing Indic script some esoteric, 'abstract', 
> 'semantic representation' and so on seems to me is an attempt to make Unicode 
> the realm of the some super humans.

No.  It’s important so that the standard Unicode algorithms function acceptably 
for Indic languages.  The design of Unicode is such that, compatibility 
characters and other some special cases aside, it encodes semantics as opposed 
to graphic representations.

> The purpose of writing is to represent speech.

Yes, and Unicode is intended to give us a representation of speech *that is 
amenable to machine processing*.

The other extreme is what used to happen on many Chinese and Japanese websites, 
namely “representing speech” by way of an image - if you want to process the 
text in one of those images, well, good luck with that (you’ll want to start 
with some kind of OCR).

Perhaps part of the problem here is that Unicode sits at the intersection 
between linguistics and software engineering; the discussion of both sides of 
this is likely to be quite technical, some of the vocabulary used might well 
seem like “mumbo jumbo”, just as some of the design decisions might not make 
sense if your expertise is mainly on one side or mainly on the other (or, for 
that matter, if you have little exposure to other languages or the challenges 
inherent in encoding or rendering them).  However, for all that it might 
*sound* like “mumbo jumbo” to you, it is not.

Kind regards,

Alastair.

--
http://alastairs-place.net

Re: abstract characters, semantics, meaningful transformations ... Was: Tibetan Paluta

[Richard Wordingham via Unicode]

On Mon, 1 May 2017 19:49:27 +0530
Naena Guru via Unicode  wrote:

> The purpose of writing is to represent speech. It is not some secret 
> that demi-gods created 

Sarasvati and Thoth would be offended at being called mere demi-gods.

> sound => letter that is the basis for writing.

"=>" is not a particularly phonetic notation.  It took quite a while
for letters to become the primary part of writing anywhere, and they
are not a universal phenomenon.

Richard.

abstract characters, semantics, meaningful transformations ... Was: Tibetan Paluta

[Naena Guru via Unicode]

This whole attempt to make digitizing Indic script some esoteric, 
'abstract', 'semantic representation' and so on seems to me is an 
attempt to make Unicode the realm of the some super humans.


The purpose of writing is to represent speech. It is not some secret 
that demi-gods created that we are trying to explain with 'modern' 
linguistic gymnastics. sound => letter that is the basis for writing. 
English writing was massacred when printing was brought in from Europe. 
A similar thing is happening to Indic by all this mumbo-jumbo.


I call out to NATIVE users of Indic to explain what apparently Europeans 
or Americans are discussing here.



On 5/1/2017 10:47 AM, Philippe Verdy wrote:



2017-04-29 21:21 GMT+02:00 Naena Guru via Unicode >:


Just about the name paluta:
In Sanskrit, the length of vowels are measured in maaþra (a
cognate of the word 'meter'). It is the spoken length of a short
vowel. In Latin it is termed mora. Usually, you have only single
and double length vowels. A paluþa length is like when you call
out somebody from a distance. Pluta is a careless use of spelling.
Virama and Halanta are two other terms loosely used.

Anyway, Unicode is only about DISPLAYING a script: There's a shape
here; Let's find how to get it by assembling other shapes or by
creating a code point for it. What is short, long or longer in
speech is no concern for Unicode.


Wrong. Unicode is absolutely not about how to "display" any script 
(except symbols and notational symbols). Unicode does not encode 
glyphs. Unicode encodes "abstract characters" according to their 
semantics, in order to assign them properties allowing meaningful 
transformations of text and in order to allow perfoirming searches 
(with collation algorithms). What is important is their properties 
(something that ISO 10646 does not care when it started the UCS in a 
separate project, ignoring how it would be used, focusing too much on 
apparent glytphs (and introducing lot of "compatiblity characters" 
that would not have been encoded otherwise, and creating some havoc in 
logical processing.


Anyway Unciode makes some exceptions to the logical model only for 
roundtrip comptaibility with other standards that used another 
encoding model widely used, notably in Thai: these are the exception 
where there are "prepended" letters. There was some havoc also for 
some scripts in India because of roundtrip compatiblity with an Indian 
standard (criticized by many users of Tamil and some other Southern 
Indic scripts that don't follow directly the paradigm created for 
getting some limited transliteration with Devanagari: that initial 
desire was abandoned but the legacy Indic scripts in India were 
imported as is to Unicode)

Unicode is more than shapes (was: Tibetan Paluta)

[Richard Wordingham via Unicode]

On Mon, 1 May 2017 07:17:05 +0200
Philippe Verdy via Unicode  wrote:

> 2017-04-29 21:21 GMT+02:00 Naena Guru via Unicode
> :

> > Anyway, Unicode is only about DISPLAYING a script: There's a shape
> > here; Let's find how to get it by assembling other shapes or by
> > creating a code point for it. What is short, long or longer in
> > speech is no concern for Unicode.

When there is considerable variation in shape, describing the function
of a character can be of great help in determining the character code
to enter for some relatively obscure character.
 
> Wrong. Unicode is absolutely not about how to "display" any script
> (except symbols and notational symbols). Unicode does not encode
> glyphs. Unicode encodes "abstract characters" according to their
> semantics, in order to assign them properties allowing meaningful
> transformations of text and in order to allow perfoirming searches
> (with collation algorithms).

Of course, display is a very important transformation process!  However,
for many applications, an important part of display is knowing when to
split text between lines, and in easy cases that can be done using
knowledge of character properties.  In hard cases, the user has to
insert line-breaking permissions and even prohibitions.  There are
special characters for these functions.

It's somewhat misleading to say that searches use collation
algorithms.  What is true is that folding can use enough of the same
computational processes that much of the code for collation may be
re-used for search.  Different data tables are frequently appropriate.

> Anyway Unciode makes some exceptions to the logical model only for
> roundtrip comptaibility with other standards that used another
> encoding model widely used, notably in Thai: these are the exception
> where there are "prepended" letters.

What "logical" model?  I don't think you know how Thai works.  The key
feature is that the Indic consonant stack has no delimiter in Thai,
which makes the phonetic placement of preposed vowels ambiguous.  In
some of the other relevant features that I am aware of, Lao works quite
differently.  Tai Viet was encoded in visual order.

You forget one other change.  New Tai Lue switched from phonetic
order to visual order because it hadn't been worth Microsoft's while
to implement the simple rendering engine.  The Universal Shaping Engine
(USE) should prevent this happening again with straightforward
complex scripts, but good intentions (namely, replacing the working
renderer from HarfBuzz and thus Firefox, Chrome and LibreOffice with an
emulation of the USE) may unintentionally repeat the process with 'Old
Tai Lue'.  Using phonetic order in Tai Tham distinguishes homographs
(if I may use the term here) that would usually be collated
differently. 

> There was some havoc also for
> some scripts in India because of roundtrip compatiblity with an
> Indian standard (criticized by many users of Tamil and some other
> Southern Indic scripts that don't follow directly the paradigm
> created for getting some limited transliteration with Devanagari:
> that initial desire was abandoned but the legacy Indic scripts in
> India were imported as is to Unicode)

The havoc is because half-forms are a north Indian innovation, not an
ancient Indic feature.  Tamil suffered from the ISCII conflation of
combining and merely having no vowel, the Unicode virama.  Tibetan and
Khmer led the way in splitting the concepts, and the Unicode virama
in the Myanmar script was disunified into an invisible stacker and a
pure killer.  Many of the Tamil complaints arise because the implicit
vowel is ill-suited to Tamil, but an attempt to move away from that
system about two thousand years ago did not persist.

Richard.