Align V at F pos with asp

[cheuk879]

Except for combos with C open on the top-right (u16F16, u16F18, u16F1A, u16F3D) where asp is kerned/tucked, V at F pos needs to be aligned with asp variously as follows: i) default: LHS of V aligned with LHS of asp. ii) [sfm] & [ygp]: LHS of V aligned with RHS of asp (i.e., no kerning). Applies also to K pos for [sfm]. iii) [hmd] & [yna]: RHS of V aligned with RHS of asp. For VV, just tuck into C as far as possible.

It is understood that iii) entails additional complexities not feasible to implement in v1.0, but it would be appreciated if i) & ii) could be included, with the 3rd group adopting i).

Per build 245: i) [hmz], [lpo], & [ywqa] still have V at F tucked into C even when there's asp: ii) [sfm] & [ygp] still have V at K/F tucked under asp (see issue #32).

The behaviour exhibited in ii) in this build is actually what is needed for i).

[mhosken]

So you are saying:

1. for the basic positioning, if there is no aspiration, tuck the vowel, else align the vowel LHS to LHS of asp.
2. for sfm & ygp, if there is no aspiration, tuck. If there is aspiration then align LHS of V to RHS of asp.
3. for hmd & yna, if there is no aspiration, tuck. If there is more than one vowel and aspiration, tuck. Else for aspiration and one vowel, align RHS of V with RHS of asp.

I assume this applies to all positions below the aspiration (F, W, K). E might in theory, but is liable to clash.

We don't have code to align RHS of V with RHS of asp. So currently for 3 with asp and single V the alignment is LHS of V to LHS of asp. We can make this LHS to RHS of asp if preferred.

I hope you realise that this is the first we have heard of this and that we now have a lot of work to do to sort this out, particularly regarding K positions. All work has proceeded thus far assuming that positioning with and without an aspiration is the same.

[jvgaultney]

Status in build 258:

i) Still a problem for dflt, [hmz], [lpo], [ywqa]

ii) Still a problem for [sfm], [ygp]

iii) RHS to RHS not possible before v1.0. However VV tucking under might be possible for [yna], [hmd], which would be the same as default behaviour (for VV only)

[mhosken]

I know it's a pain, but saying after a complex discussion that something still "doesn't work" means I have to spend a long time working out precisely what that means. Please describe what the actual fault is, yet again. You can see it and it only takes 5s to type the extra sentence. It takes me multiple minutes to work it out and even then I'm not sure.

[cheuk879]

@mhosken : Sorry that this has been confusing. Cases w/o asp have been addressed in other issues, so I didn't specifically list them here. But for clarity, we can put them here as well:

In the description below:

• For cases w/o asp, behaviour applies to V+ at all pos (except H).
• For cases with asp, behaviour applies to V+ at F unless otherwise specified.
• RHS to RHS alignment applies to combos with C open on the bottom-right.

[hmd] No asp: tuck V+ into C. With asp: V at F: align RHS to RHS of asp; V at W & VV at W/F: tuck into C. [hmdd] No asp: no tuck (but tuck with 16F07, which is post-v1.0). With asp: LHS to LHS. [sfm] No asp: no tuck. With asp: LHS of V+ at E/K/F to RHS of asp. [hmz] No asp: tuck. With asp: V+ at W: tuck; V+ at F: LHS to LHS. [lpo] No asp: half tuck (post-v1.0; now: tuck). With asp: LHS to LHS. [ywqa] No asp: tuck. With asp: LHS to LHS (need user clarification). [ygp] No asp: no tuck. With asp: LHS of V+ to RHS of asp. [yna] No asp: tuck. With asp: V: align RHS to RHS of asp; VV: tuck into C.

You'll notice that behaviour for V at W was not mentioned in related issues before because it has been correct in all builds so far: V+ gets tucked into C no matter what. (Only [hmd] & [hmz] use it.)

The problem now is: a) [hmd] & [yna]: VV at F should tuck into C but is not; & asp is not kerned even when there's space. b) [sfm] & [ygp] still have V at K/F tucked under asp, but the LHS of V should be aligned to RHS of asp c) [hmz], [lpo], & [ywqa] still have V at F tucked into C, but V & asp should be LHS to LHS aligned

Now if the different behaviours for cases with asp vs w/o asp prove to be too complex for v1.0 given the time, we can keep it simple for now & just tuck V+ into C regardless of asp for all groups except [hmdd, sfm, ygp].

[mhosken]

At last!

Thank you. I can implement this now. Just checking that V+ means one or more Vs. No need to reply if I am right.

On Thu, 15 Aug 2019, 18:33 cheuk879, notifications@github.com wrote:

@mhosken https://github.com/mhosken : Sorry that this has been confusing. Cases w/o asp have been addressed in other issues, so I didn't specifically list them here. But for clarity, we can put them here as well:

In the description below:

• For cases w/o asp, behaviour applies to V+ at all pos (except H).
• For cases with asp, behaviour applies to V+ at F unless otherwise specified.
• RHS to RHS alignment applies to combos with C open on the bottom-right.

[hmd] No asp: tuck V+ into C. With asp: V at F: align RHS to RHS of asp; V at W & VV at W/F: tuck into C. [hmdd] No asp: no tuck (but tuck with 16F07, which is post-v1.0). With asp: LHS to LHS. [sfm] No asp: no tuck. With asp: LHS of V+ at E/K/F to RHS of asp. [hmz] No asp: tuck. With asp: V+ at W: tuck; V+ at F: LHS to LHS. [lpo] No asp: half tuck (post-v1.0; now: tuck). With asp: LHS to LHS. [ywqa] No asp: tuck. With asp: LHS to LHS (need user clarification). [ygp] No asp: no tuck. With asp: LHS of V+ to RHS of asp. [yna] No asp: tuck. With asp: V: align RHS to RHS of asp; VV: tuck into C.

You'll notice that behaviour for V at W was not mentioned in related issues before because it has been correct in all builds so far: V+ gets tucked into C no matter what. (Only [hmd] & [hmz] use it.)

The problem now is: a) [hmd] & [yna]: VV at F should tuck into C but is not; & asp is not kerned even when there's space. b) [sfm] & [ygp] still have V at K/F tucked under asp, but the LHS of V should be aligned to RHS of asp c) [hmz], [lpo], & [ywqa] still have V at F tucked into C, but V & asp should be LHS to LHS aligned

Now if the different behaviours for cases with asp vs w/o asp prove to be too complex for v1.0 given the time, we can keep it simple for now & just tuck V+ into C regardless of asp for all groups except [hmdd, sfm, ygp].

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/silnrsi/font-shimenkan/issues/72?email_source=notifications&email_token=ABLMO3NPSHKL5DHLYBEA64TQEU5JRA5CNFSM4IK2RCBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4LSO2Y#issuecomment-521611115, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLMO3OUDPBC7QJSGDKYP2DQEU5JRANCNFSM4IK2RCBA .

[jvgaultney]

Build 261 has many fixes. There are some things that are not quite clear in your summary - please clarify below. We still have a couple of bugs to fix (noted below), but except where mentioned I think that build 261 is doing what you want for 1.0.

[hmdd] No asp: no tuck (but tuck with 16F07, which is post-v1.0). With asp: LHS to LHS.

Most of this works, however an asp following a dotted glyph overlays the dot. I've added that as issue #76 and will fix it for 1.0.

[hmz] No asp: tuck. With asp: V+ at W: tuck; V+ at F: LHS to LHS.

The V at W is not tucking far enough. This is a design issue, as moving the AP in will definitely cause a collision in the bold weights. However that may not be as bad as leaving this not-quite-tucked. So I will move it for 1.0 and we can test the results and tweak after 1.0 - issue #77 .

This needs clarification, though: You say V+ at W should always tuck no matter what (with or without asp), but asp with V+ at F shouldn't. Really? That's inconsistent. If anything it should be the other way around, as there is more space to tuck at F than at W. Or is this only for VV? Are you sure about this? Wouldn't it be better to have it behave the same as F?

[ygp] No asp: no tuck. With asp: LHS of V+ to RHS of asp.

This is working, but there is a spacing problem, where extra space is added when a V is tucked under an asp. Issue #75 .

a) [hmd] & [yna]: VV at F should tuck into C but is not; & asp is not kerned even when there's space.

For [hmd] that directly contradicts what you just confirmed in issue #65. You said there that: "[hmd] has just confirmed that asp should tuck regardless of V position." For [yna] the asp is not tucking as you requested.

c) [hmz], [lpo], & [ywqa] still have V at F tucked into C, but V & asp should be LHS to LHS aligned

This is confusing. You said above that these langs should tuck V at F when there's no asp. Which is it?

So there's nothing more we need to do on this issue until you've answered the following questions:

• Does V+ mean single V, double VV, or both?
• [hmz] V+ tucking at W?
• [hmz], [lpo], [ywqa] Should V at F tuck or not?

[cheuk879]

Most of this works, however an asp following a dotted glyph overlays the dot.

The two are mutually exclusive.

You say V+ at W should always tuck no matter what (with or without asp), but asp with V+ at F shouldn't. Really? That's inconsistent.

I had the same response when they first replied me! So I asked them twice more, each time asking more specifically & from a somewhat different angle, & each time they said yes. This is what I sent them per build 194: In the end they confirmed that everything shown was correct, & that's what I recorded in the planning doc. Even though I still don't quite understand it, I respect their preference.

This is working, but there is a spacing problem, where extra space is added when a V is tucked under an asp.

Not only that, but with asp, VV is tucked into C, whereas VV should be right of asp.

a) [hmd] & [yna]: VV at F should tuck into C but is not; & asp is not kerned even when there's space.

For [hmd] that directly contradicts what you just confirmed in issue #65. You said there that: "[hmd] has just confirmed that asp should tuck regardless of V position." For [yna] the asp is not tucking as you requested.

Oops! When you work till 4-5am your mind won't quite function! I should have moved the 2nd clause into another bullet, which applies only to [hmd], thus: d) [hmd]: Asp is not kerned even when there's space, but it should.

c) [hmz], [lpo], & [ywqa] still have V at F tucked into C, but V & asp should be LHS to LHS aligned

This is confusing. You said above that these langs should tuck V at F when there's no asp. Which is it?

At least this one I did write what I meant ;) Indeed, w/o asp, V+ at F should tuck, but the case here is with asp: V+ & asp should be LHS to LHS aligned, but V+ is still tucked into C (rf. images of build 258 above).

Does V+ mean single V, double VV, or both?

One or more V's.

[hmz] V+ tucking at W?

Yes.

[hmz], [lpo], [ywqa] Should V at F tuck or not?

W/o asp: yes. With asp: LHS of V+ aligned to LHS of asp. (As noted for [ywqa], user clarification is still pending, but we'll take it as the default LHS to LHS for now.)

[jvgaultney]

Thanks for the clarifications.

d) [hmd]: Asp is not kerned even when there's space, but it should.

This is working:

At least this one I did write what I meant ;) Indeed, w/o asp, V+ at F should tuck, but the case here is with asp: V+ & asp should be LHS to LHS aligned, but V+ is still tucked into C (rf. images of build 258 above).

This is also working:

It sounds like what still needs to be done is:

1) [hmz] Make asp+V@W (only) tuck. Currently:

2) [ygp] Make asp+VV@F like asp+V@F, with V coming after the asp. Currently:

[cheuk879]

Thanks for the first 2 fixes! Yes, the last 2 are outstanding items to fix here.

[jvgaultney]

1. [hmz] Make asp+V@W (only) tuck.

This is now fixed in build 271, however the fix broke the alignment of asp+V@F:

asp+V should tuck only at W.

2. [ygp] Make asp+VV@F like asp+V@F, with V coming after the asp.

Fixed in build 271:

[jvgaultney]

Fixed in build 273:

[cheuk879]

Many thanks for your hard work @mhosken ! It looks quite nice now per build 282. The only hiccups I can see are for [hmd] shown below:

• The V in red is aligned LHS to LHS with asp, but it should be RHS to RHS like those in rows 2-3. However, space on the left may not be enough, as this particular V is quite wide, but still tucking in as much as possible is desired.
• The V in blue seems to be noticeably further away from asp than those in the next 2 rows. This may belong to another issue, though.

If these are relatively easy to fix, then making it for v1.0 would be appreciated; otherwise, post-1.0 is ok.

[jvgaultney]

What I think you're seeing in your blue example is a result of tiny variations in rendering on screen. When I generate a PDF (in results see tests/pdfs/hmd_issues_pdfs_ot_DFLT_shimenkantest-regular_ot_DFLT.pdf) and zoom in, I don't see as much of a gap between C, asp, and V:

The first combo, with V@H, also looks very different when you print it out or zoom in enough on screen. Try printing out your test and see if it looks better on paper.

As for the red example: Getting the V to tuck in only 'as much as possible' is rather difficult. To avoid a collision you would need calculate both the RHS to RHS position and the fully tucked position and choose whichever was furthest right. That's not impossible, but will definitely need to wait until some later time.

Reopening this but only for post 1.0.

[mhosken]

Addressed in 5993d4f0d14740a22e594c8e1f0a999b67a2600f I've added a v1.0 branch at the commit before this, in case we don't want to take this yet. It does make the font significantly bigger. But it only affects hmd and yna.

[jvgaultney]

And the fix worked (see I knew he could do it)! Build 288.