bugFree UCS Outline Fonts - Bugs: bug #52572, Musical combining marks overlap...

 
 

bug #52572: Musical combining marks overlap the following glyph

Submitter:  David Corbett <dscorbett>
Submitted:  Fri 01 Dec 2017 07:27:53 PM UTC
   
 
Category:  individual character(s) Severity:  3 - Normal
Item Group:  letter positioning poor Status:  Proceeding
Privacy:  Public Assigned to:  Stevan_White
Open/Closed:  Open Release:  * development
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 19 Dec 2017 06:07:48 PM UTC, comment #10: 

This is much better! I don’t think it is wrong; it doesn’t violate OpenType or Unicode, if that’s what you meant.

The sprechgesang stem needs just a bit more space after it. Currently, it just grazes a following barline. This should be an easy fix.

The combining tremolos need more space after them. This may be less straightforward.

Re augmentation dots, I suggest the following. Remove augmentation_dot.cmb. Make mus_augmentation_spacing be the nominal glyph for U+1D16D. Create a 'curs' lookup to position dots following a rest.

There is still the problem of U+1D1AD and other marks above when they follow U+1D16D. I have not found a solution to that yet.

David Corbett <dscorbett>
Tue 19 Dec 2017 01:50:04 PM UTC, comment #9: 

Here are some examples

data:text/html;charset=utf-8,<div style="font: 50pt FreeSerif">%F0%9D%85%98%F0%9D%85%A5 %F0%9D%85%98%F0%9D%85%A6 %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%A9 %F0%9D%85%A1%F0%9D%85%A7 %F0%9D%85%A0%F0%9D%85%A8 %F0%9D%85%98%F0%9D%85%AD %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%AD %F0%9D%85%A1%F0%9D%85%AD %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%AF%F0%9D%85%A7 %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%AE%F0%9D%85%A8 %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%AF%F0%9D%85%AD %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%AE %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%AF %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%B0 %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%B1 %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%B2 %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%B2%F0%9D%85%A7 %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%B0%F0%9D%85%BB%F0%9D%85%AD %F0%9D%85%9D%F0%9D%85%BB %F0%9D%85%A0%F0%9D%85%AD%F0%9D%85%AD%F0%9D%85%BB

Steve White <Stevan_White>
Group administrator
Tue 19 Dec 2017 01:34:09 PM UTC, comment #8: 

I had to bend a lot of things to make several things work as we're imagining them.

Augmentation dot following rests still probably overlaps following letters.  Not sure what to do about this.

-- overrode the OT Glyph Class for several groups of glyphs, so they could be spacing, and horizontal kerning could be applied.  This includes note stems and flags.

-- to make the augmentation dot spaccing, but position it vertically on rests, had to replace it with a spacing auxiliary when it follows any of the stuff associated with noteheads.

Then defined kerning tables to position stems to notes, flags to stems, and augmentation notes to stems or flags (ignoring other mark glyphs).

Seems a bit excessive, and probably wrong.

Steve White <Stevan_White>
Group administrator
Sun 17 Dec 2017 10:50:42 AM UTC, comment #7: 

There are technical complications and confusions, besides the question of how the combinations should look in given circumstances.

The augmentation dot and the stem and flag glyphs all have positive advance width, but they are combining characters.  Like other combining characters, I have implemented the combining using mark anchors.  This unfortunately causes the renderer to ignore the advance width.

I could implement the combination, say, with horizontal positioning (kerning), and fudge the vertical component (in the case of notes, the note heads evidently aren't meant to move vertically, so maybe that's OK).  Then the advance width is preserved.

And then, what happens if there are intervening marks... also not positioned by mark positioning?  Man it's hard to see how anything could be done robustly.

Just in the case of combination of note heads, one could imagine kerning stems to notes, flags to stems, and augmentation dots to notes, flags, stems, and other augmentation dots.  But then there are other marks -- tremolos and accents etc, which can intervene.  I could spend a lot of time trying and find that it won't work (and I'm running out of time right now.)

A definitive guide to how these marks were meant to be used and implemented would be very useful.

Steve White <Stevan_White>
Group administrator
Sat 16 Dec 2017 01:15:46 AM UTC, comment #6: 

https://archive.org/stream/mclaughlin#page/17/mode/1up has an example in section 84: “⸦double-dotted quarter note⸧ is equal to a ⸦quarter note⸧ and a ⸦eighth note⸧ and a ⸦sixteenth note⸧ tied.” Note that the distance between the stem of the double-dotted quarter note and the next letter is wider than the distance between the stem of the plain quarter note and its next letter: that is because the dots are spacing. Note also that the same difference is true between the quarter note and the eighth note: that is because the flag is spacing.

The problem is that, in FreeSerif, these marks are not spacing, so they encroach upon the following glyphs.

data:text/html;charset=utf-8,<div style="font: 100px FreeSerif">%F0%9D%85%98%F0%9D%85%A5%F0%9D%85%AD%F0%9D%85%AD is %F0%9D%85%98%F0%9D%85%A5 and %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%AE and %F0%9D%85%98%F0%9D%85%A5%F0%9D%85%AF <i>tied.</i></div>

It doesn’t matter what characters may follow these combinations: they should always be spacing. These marks are like U+093E DEVANAGARI VOWEL SIGN AA, which, though a combining character, does not overstrike the following glyph.

A solution could be to use a single adjustment GPOS lookup to unconditionally add advance width to these glyphs. I am not sure that works for mark glyphs though.

David Corbett <dscorbett>
Fri 15 Dec 2017 11:49:44 AM UTC, comment #5: 

Hi David,

Again here, the intended use of these combinations isn't clear to me from the standards.  In your examples, you follow marks directly with U+1D100 "single barline", which they then overlap. The inclusion of a space character resolves the immediate problem.

I might be able to employ a horizontal positioning.  But the question of which characters might follow a combination.  I could swat around at different combinations, but I will not know what I'm doing.

It's not clear what is a problem and what the goal is.

I would be glad to entertain any ideas.

Steve White <Stevan_White>
Group administrator
Thu 14 Dec 2017 11:23:00 PM UTC, comment #4: 

This has been marked with “Fix posted”, but all the examples in the original report still look wrong. Combining marks are, as you say, meant to overlap other characters; but only their base characters: it is wrong for a flag, an augmentation dot, etc. to overlap the following note or barline.

David Corbett <dscorbett>
Sat 02 Dec 2017 08:38:54 AM UTC, comment #3: 

But... I think combining marks are meant to be used only in combinations with other charcters, with which they are meant to overlap...

And one issue, which may or may not be a concern, is to make the letters do something sensible on systems where positioning isn't working as expected.  Something similar is done with the general combining diacritcs range.

The only characters I found that are spacking and combining, which haven't implemented as such are:

U+1D165 MUSICAL SYMBOL COMBINING STEM
U+1D166 MUSICAL SYMBOL COMBINING SPRECHGESANG STEM
U+1D16D MUSICAL SYMBOL COMBINING AUGMENTATION DOT

I'll correct these to be spacing, and not to overlap.

The tremolos probably don't space becase, as you have porinted out, they are re-ordered to come before stems and flags that are meant to attach to the same notehead.

Steve White <Stevan_White>
Group administrator
Fri 01 Dec 2017 11:43:52 PM UTC, comment #2: 

It would not make sense for them to behave that way. If musical symbols overlapped each other, they would be hard to read. See my first example, where a note is in one bar but its augmentation dots are in the next. To draw an analogy with Latin, the letters in ⟨ťl⟩ are further apart than the letters in ⟨tl⟩ because otherwise the mark would overlap the second letter; musical marks may similarly require extra space.

It goes against Unicode’s implicit recommendation in the character properties. Most of these marks have General_Category=Spacing_Mark. The tremolos don’t, presumably because they only sometimes require extra space.

It makes the font self-inconsistent. In the sequence ⟨U+1D158 U+1D165 U+1D16F⟩, the flag overlaps the following character, whereas its canonically equivalent precomposed form U+1D160 does not overlap.

David Corbett <dscorbett>
Fri 01 Dec 2017 10:05:37 PM UTC, comment #1: 

Hi,

How do we know these combining marks shouldn't behave this way?

Steve White <Stevan_White>
Group administrator
Fri 01 Dec 2017 07:27:53 PM UTC, original submission:  

Some musical combining marks can overlap the following glyph in FreeSerif.

U+1D166 MUSICAL SYMBOL COMBINING SPRECHGESANG STEM
U+1D167 MUSICAL SYMBOL COMBINING TREMOLO-1
U+1D168 MUSICAL SYMBOL COMBINING TREMOLO-2
U+1D169 MUSICAL SYMBOL COMBINING TREMOLO-3
U+1D16D MUSICAL SYMBOL COMBINING AUGMENTATION DOT
U+1D16E MUSICAL SYMBOL COMBINING FLAG-1
U+1D16F MUSICAL SYMBOL COMBINING FLAG-2
U+1D170 MUSICAL SYMBOL COMBINING FLAG-3
U+1D171 MUSICAL SYMBOL COMBINING FLAG-4
U+1D172 MUSICAL SYMBOL COMBINING FLAG-5

data:text/html;charset=utf-8,<div style="font: 100px FreeSerif">%F0%9D%85%98%F0%9D%85%A5%F0%9D%85%B0%F0%9D%85%AD%F0%9D%85%AD%F0%9D%85%AD%F0%9D%84%80<br>%F0%9D%85%98%F0%9D%85%A6%F0%9D%84%80<br>%F0%9D%85%98%F0%9D%85%A5%F0%9D%85%A9%F0%9D%84%80

David Corbett <dscorbett>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by Stevan_White (Posted a comment)
  • -email is unavailable- added by dscorbett (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-12-15 Stevan_White StatusFix posted Proceeding
    2017-12-14 Stevan_White StatusProceeding Fix posted
    2017-12-02 Stevan_White StatusNeed info Proceeding
    2017-12-01 Stevan_White StatusNone Need info
        Assigned toNone Stevan_White

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code