You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following is a list of keyboards where the font declared in the .kvks file (which is intended only for design-time use as of Keyman v18.0) differs from the font declared for the On Screen Keyboard in the .kps file. This matters because Keyman for Windows still uses the font spec from the .kvks file in v17.0, but in v18.0, the package compiler rewrites the .kvk file to use the font spec from the .kps file, so all Keyman apps will get the Package font spec.
From my reading of this report, in most (all?) cases this is exactly the kind of update we want -- the package font looks to be more 'correct' than the source .kvks font. The .kvks font data becomes unimportant in the future (apart from design-time and author debugging use).
However, importantly, this change will not filter down until packages are rebuilt with the v18.0 compiler -- and rebuilt packages are not deployed until a version bump. So this issue is here (a) to document the change, and (b) to give an opportunity to address any packages where this is considered to be a problem.
For v18.0 (due out in under 2 months), a version bump is sufficient to get the package font version. If we want to change things with the v17.0 compiler (as currently used in this repo), the .kvks font spec would need to be updated alongside the version bump.
This one himyarit_musnad | SultanMusnad | Noto Naskh Arabic is interesting because the SultanMusnad font needs to be in the .kvks and OSK. But I guess the Noto Naskh Arabic font is needed for the hints in the mobile layout. I'm not sure how/where the hints get addressed in this structure.
Following is a list of keyboards where the font declared in the .kvks file (which is intended only for design-time use as of Keyman v18.0) differs from the font declared for the On Screen Keyboard in the .kps file. This matters because Keyman for Windows still uses the font spec from the .kvks file in v17.0, but in v18.0, the package compiler rewrites the .kvk file to use the font spec from the .kps file, so all Keyman apps will get the Package font spec.
From my reading of this report, in most (all?) cases this is exactly the kind of update we want -- the package font looks to be more 'correct' than the source .kvks font. The .kvks font data becomes unimportant in the future (apart from design-time and author debugging use).
However, importantly, this change will not filter down until packages are rebuilt with the v18.0 compiler -- and rebuilt packages are not deployed until a version bump. So this issue is here (a) to document the change, and (b) to give an opportunity to address any packages where this is considered to be a problem.
For v18.0 (due out in under 2 months), a version bump is sufficient to get the package font version. If we want to change things with the v17.0 compiler (as currently used in this repo), the .kvks font spec would need to be updated alongside the version bump.
This emerges from keymanapp/keyman#13087. Hope this all makes sense!
The text was updated successfully, but these errors were encountered: