search

silnrsi / font-shimenkan

Fonts for the Miao script
Other
3 stars 1 forks source link

[sfm] K needs lowering &/or box-centre attachment #67

Closed cheuk879 closed 5 years ago

cheuk879 commented 5 years ago

Per Build 222, K position is too high so that it looks like W esp for tall chars like 16F5C, 16F5E, 16F5F: plrd-sfm-tones-ambig-16f5c plrd-sfm-tones-ambig-16f5e plrd-sfm-tones-ambig-16f5f It looks like the final is being attached at its box base rather than box centre. Is it feasible to use the box centre of the final instead? Or should K be lowered a bit? (See Issue #53 for reference heights.)

mhosken commented 5 years ago

Not sure how you created this and whether there is an issue. This from libreoffice ShimenkanTest:lang=x-hbotSFM Screenshot from 2019-07-26 14-30-54 This shows K, W and E positions (With W default language)

jvgaultney commented 5 years ago

The issue here is that those three vowels/finals all extend above the 'box' that is used to center-align the vowels at K. In the first set of examples below a vowel that fits completely within the 'box' shows the expected progression through F, K, E, S positions, as in #53. The second set shows the vowels you mention and some fully-in-the-box vowels all at K position. When viewed out of context, the taller vowels can seem to be too high. But they are properly aligned with all the other vowels.

The key point here is that for W, E, and K we center-align to the 'box', not to the visual center of each individual vowels bounding box.

image

We could change the alignment for K and E to center on the visual center of the vowel. However the problem would be that some vowels extend so low that they would be confused with those at F level. Since [sfm] does not use W, but does use F, it would seem that changing this would cause more confusion.

Are you satisfied with this explanation?

cheuk879 commented 5 years ago

Thanks for the explanation. On further testing it appears the root of the problem is having 4 tones on the right. The images in the first comment were taken from the project window of PT8 with font set at 14 pt (which is ~12.5 pt in LO). The ambiguities begin to resolve when we set the font size to 18 pt (~16 pt): plrd-test-tones-k-pt8 0 100 83-18pt-16f5e-ok plrd-test-tones-k-pt8 0 100 83-18pt-16f5f-ok plrd-test-tones-k-pt8 0 100 83-18pt-16f5c-ok So I think there isn't much we can do in the font here. In fact, in the beginning I clearly explained to the users such ambiguities would likely arise in handwriting & at regular font sizes. The only thing we can do now is to tell them to use large sizes. Am closing the issue for now.