cheating horizontal episemus height

[eroux]

In the following example:

it would be important to be able to make the second set of horizontal episemus (on ter) be on the exact same height as the one before (gis). I think detecting this automatically is just too complex, so I propose a notation to be able to "cheat" horizontal episemus placing. For example here ter(ixg[hh:f]hi) would make the horizontal episemus placing algorithm think the first note is an f and thus place the whole episemus on the correct position... What do you think?

[henryso]

How about just [f]?

[eroux]

Hmm this seems a bit too generic, who knows what other [xx] kinds we'll need in the future... Anyways, the whole request was to be able to put both in the middle of the line, not shifted up or down... We can do it in two separate steps, but I thought it would help if it was known from the beggining. I'm a bit puzzled about the best way to specify that though... maybe [hh:f*] could make the C code remember that the episemus should not be shifted?

[henryso]

Well, we could delimit elements that would extend the "look around" when determining glyph height extrema, as in gis([hh{]f_h)ter(ixg_j_i_>[hh}]).

[eroux]

Oh, that's a good idea! A bit more difficult to explain, but certainly better once understood.

How do you think you would deal with the centering of the episemus (not shifted lower no higher than the middle)? We can implement it later, but maybe it's best to know how it will be noted in gabc?

[henryso]

I'll admit I don't understand "not shifted lower no higher than the middle"?

[eroux]

In the first picture, the episemus on gis is not right in the middle of the line, it's slightly lower, and the episemus on ter is not in the middle of the line, it's slightly higher. The idea would be to make them both on the middle, for balance.

[henryso]

That would make things pretty complicated, as the heights of the horizontal episemata are current fixed to a pitch (+ above vs. below), and this would be between pitches. Let me think more about the notations. Do you have anything to suggest?

[eroux]

precisely... so maybe [hh{] could do what you said, and [hh:f*:{] would center? ([hh:e*:{] would have the same output). There will be many complex edge cases here, like (g_[hh{] g_1 g_0 i_[hh}])... I'm not sure how to handle them...

[henryso]

I think it might be better to allow the episema to be nudged by specifying a dimension: [hh:0.2mm{] or [hh:-0.2mm{]. Too complicated? Also, we would need to be able to adjust both the low and the high episema. So maybe lh and hh.

[eroux]

That seems good, though I think the value should be scaled by grefactor to be consistant... Well, maybe not, we don't do it for horizontal length, which could be too... se let's not do that. About lh and hh why not... it will just procude more strange cases... Like for instance how would you do if gis in the initial image was gis(d)? It's one a high and once a low one... Not an easy case...

[henryso]

lh would affect the low episema computation and hh would affect the high episema computation. So if gis(d_), which is a high episema, if there were a low-nudge, it wouldn't affect the episema on d_ unless it's (d_1).

[eroux]

Hmm, I think I see better what you mean now, sorry, I think my question was kind of stupid... let's just detail the algorithm a bit.

in the case gis(d_)ter(g_h_i_>), what you propose is that the user inputs gis(d_[hh:-0.2mm{])ter(g_h_i_>[hh:}]), if I understand you correctly, this will mean that all following episema (before the [hh:}]) that are between the 1st and 2nd line will have the same height, which is the height of the normal episemus on d minus 0.2mm? If it's what you're proposing, then I think it's ok, if not, tell me where I'm wrong!

[henryso]

Not exactly. gis(d_)ter(g_h_i_>) would have a high episema on d and a low episema on ghi. Specifying gis(d_[hh:-0.2mm{])ter(g_h_i_>[hh}]) would mean:

• for d and ghi, compute the high height extremum as if it were one glyph, so the the high note would be i across the entire range, meaning that the high episema on d would appear as if there were an i in the glyph
• because the high offset dimension is -0.2mm, the high episema on d would be nudged down 0.2mm
• the hh specification would not affect the low episema on ghi

What you probably want for your case is gis(d_0[lh:-0.2mm{])ter(g_h_i_>[lh}]), which would mean:

• for d and ghi, compute the low height extremum as if it were one glyph, so the low note would be d across the entire range, meaning that the high episemata on both d and ghi would appear as if there were a d in the glyph
• because the low offset dimension is -0.2mm, the low episemata on both d and ghi would be nudged down 0.2mm
• the lh specification would not affect any high episemata, of which, in this case, there are none.

Does that make clear what I'm suggesting?

[eroux]

Ok, but it means that the problem is not solved... the idea in the gis(d_)ter(g_h_i_>) case would be to have both the (high) episemus on gis and the (low) episemus on ter on the same height... How would you do that?

[henryso]

Ah, now I understand why you were saying there are complex edge cases, which is very true... and I don't know how to deal with it properly.

[eroux]

Thinking back about it, the gis(d_)ter(g_h_i_>) case would be doable by hand with gis(d_[hh:-0.2mm])ter(g_[lh:-0.2mm]h_i_>)... So the best could be to make the final { optional, and, if absent, to apply the [hh:x] just on one note. What do you think?

[eroux]

Or maybe better, have a [xhp:y] where

• x is l or h
• y is l to make it low in the interline, c to make it right in the center, h to make it high

?

[henryso]

I will implement [xh:yzw] where

• x is l or h
• y is optional and is l for low in the space, m for middle of the space, h for high in the space (I'm imitating HTML/CSS in using "middle" rather than "center" for vertical positioning)
• z is an optional nudge and must start with + or -
• w is optional and may be { to start a range or } to end a range.
• at least one of y, z, or w must be provided
• if y and z are omitted, so should the : may be omitted
• y and z (and the :) are not permitted when w is }

How does that sound?

[eroux]

That's a bit complex, but it provides all fine tuning possibilities users might want, now and in the future, so I think it's perfect!

[rpspringuel]

Unless it really screws up the parser, I wouldn't prohibit the : when y and z are omitted.

[henryso]

Ok.

[henryso]

The position in the space is different depending on whether the episema is above the note or below it, so even using this new feature, in the gis(d_)ter(g_h_i_) example, the lines will not line up because the position above the d is slightly different than the position below ghi. If I change this positioning, it will break anything using horizontal episemas in whichever case (or both?) that we decide to change.

Thoughts?

[eroux]

How many kinds of positions are there? I thought there was:

• bottom for f_0 and g_1
• top for g_0 and f_1

or are these four different?

[henryso]

Those are the four cases, and all have different offsets.

[eroux]

Ok I see... not counting the offsets for very high or very low notes... Well, why not

• t for g_0
• t2 for f_1
• m
• b for g_1
• b2 for f_0

? Or maybe * instead of 2?

[henryso]

Ok, that sounds doable. Although I was using h(igh) and l(ow), because it's not actually at the top/bottom of the space. That said, what should I use for m. The midpoint between h and l is different than that between h2 and b2. As this is a new position, we can fudge it a little or use m2. What do you think?

[henryso]

As you can see here, the midpoints are close, but slightly different.

[eroux]

Sorry yes, use h and l! I think the midpoint should be the very middle of the line, not taking into account the other values. As the episemus height varies according to the font, I think just a new height (adapted to greciliae by default, custom fonts will have to tune it) is just fine

[eroux]

(what I mean by new height is: no need to compute the exact middle by computing the height of the episemus, etc.)

[henryso]

Should I make the other four offsets tunable via dimensions? If so, what in the world should I call them that would make sense to a user?

[eroux]

How incredible, I really couldn't believe my eyes when I saw they were not in gsp-default already... So yes, definitely! Maybe hepisemusvshiftaboveinterline, hepisemusvshiftbelowline, etc.?

[eroux]

(oh, and vertical episemus and punctum mora shifts should be tunable too!)

[henryso]

Would it be better to draw the horizontal episema in the font such that it is centered correctly so that these offsets need not be tuned per font?

[eroux]

that makes perfect sense indeed!

[eroux]

If it helps, I can change the font to make the horizontal episemus centered in height and also make the spacings tunable, tell me

[henryso]

I am in the code that does the shifting, so if you could make the font changes and let me know what the new shift values should be for the 5 cases, I can take care of putting it into gsp-default and getting the glyphraise calculation macro working.

[henryso]

I'm also considering the following:

[xh:yzw] where

• x is o and u (for over and under, which has precedent; i.e., oslur)
• y is optional and is
  • l for low in the space (chooses ol or ul depending on x)
  • m for middle of the space
  • h for high in the space (chooses oh or uh depending on x)
  • ol for low in the space as if the episema were over the note
  • oh for high in the space as if the episema were over the note
  • ul for low in the space as if the episema were under the note
  • uh for high in the space as if the episema were under the note
• z is an optional nudge and must start with + or -
• w is optional and may be { to start a range or } to end a range.
• at least one of y, z, or w must be provided
• if y and z are omitted, the : may be omitted
• y and z are not permitted when w is }

[eroux]

You can shift them all by -7600 sp * \gre@factor

[eroux]

The new syntax looks good! Where should I push the change in the fonts?

[henryso]

a new branch in the main repository is perfect.

[eroux]

Sorry, it's 8000, not 7600!

[eroux]

done

[henryso]

Thanks. It will take me a few hours tonight to make these changes, so I should have something tomorrow.

[eroux]

Perfect, thanks a lot!