16F5F not centered in head position

[kienwt]

Raw text raw-not-centered-head-position.txt

As displayed in LibreOffice

[cheuk879]

Per build 222, all but [hmdd] still render it off-centre:

[mhosken]

This behaviour was added in response to issue #43. Which way would you like us to jump?

[cheuk879]

Issue #43 is an adjustment that only applies to 16F63..16F64. The latter is only used by [hmd], & the former is not currently used by any group, but [hmd] requested that it be treated like the latter in case it would be used later.

The current issue here is a defect in the position of 16F5F that affects all langs but [hmdd]. Centring is the correct behaviour, but per build 233 it is still off-centre as above.

[mhosken]

Is this what you want? committed dcf4b19a

[cheuk879]

Yes. 16F5F confirmed to be centred per build 242. However, 16F63..16F64 are clashing with asp: Asp should move left.

[cheuk879]

No clashing per Build 244: However, in the rightmost column, V is almost touching the asp & can use just a little bit shift to the right. And for those in red, the asp is a bit too far away from the base char & can use a bit more shift to the left.

[jvgaultney]

I'd agree that something odd is happening with the position of the asp, and the problem is in the OT code.

[mhosken]

Dear all,

The aspiration is set first. So any adjustment is to the vowel, which I guess aligns it's centre with the RHS of the aspiration. If you give me an AP on the vowel to say where the RHS of the aspiration goes, I would use that. If we want to move the aspiration too, then we have to change the maths. Which we can do. But I suggest this is post 1.0

GB, Martin

On Fri, 9 Aug 2019, 18:28 Victor Gaultney, notifications@github.com wrote:

I'd agree that something odd is happening with the position of the asp, and the problem is in the OT code.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/silnrsi/font-shimenkan/issues/50?email_source=notifications&email_token=ABLMO3OU5QWHKHGTWIP2EO3QDVIFHA5CNFSM4HPYATCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD36M5EI#issuecomment-519884433, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLMO3K4UTKDC347OZ4WLATQDVIFHANCNFSM4HPYATCA .

[jvgaultney]

Apologies - this does seem to be related to glyph widths (and APs). The _HD AP on the .mark vowels should be attaching to the HD AP on the asp. That may actually be happening correctly and I just need to move the APs around a bit.

The inconsistency in the asp position related to the cons is related to glyph width (which in turn defines certain AP locations). There's normally more width for letters that have a straight stem on the right hand side of letter (such as 1E) than those that have a lot of white space on the lower right (such as 0A). If I make the right side of them mathematically identical then it will visually look inconsistent when at text size, and certain vowels at F will look disconnected. However I may have the difference too great for some weights. It's a really tricky balance, and I couldn't fine tune it until all the many many issues around dots, asp, flush right, etc. were finalized.

I will try to fine-tune both the asp+vowel APs and the glyphs widths, however that will very likely need to wait until after 1.0 because we're running out of time. (Remember that unless we release v1.0 very soon we'll miss the window time I have available and it will all have to wait until November or so.)

[cheuk879]

If timing is an issue then yes pls focus on releasing 1.0 first.

[jvgaultney]

Actually the main problems here are OT related. Here is a composite image from an updated issues.htxt test files at three weights in build 275. Note that there are no space characters in these strings:

There are a number of problems here.

1) Space is being added to the right side of any combination that involves u16F63 or u16F64 at head position, even without an asp.

2) More space is then added when adding asp to those combos (but only if u16F63 or u16F64 are present).

3) The alignment of asp and V is inconsistent - they collide even more with u16F28 than with others. However u16F28 isn't likely to be the cause, as it's working fine with only asp. (Note that the right sidebearing of u16F28 is a little larger than other letters, but only a tiny amount - much smaller than the collision difference.

I can't figure out which AP on asp is being used to position the V in these cases. The head alignment of these vowels at head position in general could probably still be improved by adjusting APs, but I can't do that until these odd bugs are fixed.

[mhosken]

The HD AP on a vowel is used, and is aligned to the righthand of the asp bounding box. A bug with the U+16F28 (I shape) has been fixed that should bring the asp back and spacing fixed, I hope.

[jvgaultney]

Spacing bugs confirmed to be fixed in build 279. Further testing and improvement of alignments for these overhanging vowels will need to wait until after 1.0.

[jvgaultney]

A spacing problem has returned as a result of the Windows fix for #82. Spacing is being added when an asp that is positioned after is followed by V@H. Affects [ygp] (and presumably [sfm, yna] too), but is OK for other languages for which the asp is tucked.

[ygp] (ygp_issues.htxt):

default (issues.htxt):

If possible it would be good to fix this for 1.0.

[jvgaultney]

Extra space now confirmed to be removed in build 292:

However spacing remains inconsistent with vs. without asp. Oddly with asp is the 'correct' spacing according to the glyph metrics. That needs fixing, but then the without asp will need to be reviewed. With and without should have identical right sidebearings.

These adjustments can wait until after 1.0.

[cheuk879]

Issue #43 is an adjustment that only applies to 16F63..16F64. The latter is only used by [hmd], & the former is not currently used by any group, but [hmd] requested that it be treated like the latter in case it would be used later.

Other groups don't use them, so we don't need to worry about them. For [hmd], everything looks fine in LO 6.3.0.4 per build 293:

It's only that Word 365 somehow messes up the special logic for these 2 chars: It's likely that its OpenType support is still inadequate.