search

keymanapp / keyman

Keyman cross platform input methods system running on Android, iOS, Linux, macOS, Windows and mobile and desktop web
https://keyman.com/
Other
394 stars 110 forks source link

feat(developer): manage shared fonts #11236

Open mcdurdin opened 6 months ago

mcdurdin commented 6 months ago

Fonts are currently difficult to manage in Keyman Developer projects, particularly because we want to share fonts between keyboards. The developer must either clone the entire keyboards repository, or else jump through convoluted hoops in order to properly use shared fonts.

Proposal, in short: allow packages to reference files from GitHub repos, not just local files. Then the compiler will download (and maybe cache) files. The keyboard author could reference, e.g. https://github.com/keymanapp/keyboards/blob/master/release/shared/fonts/aegyptus/Aegyptus.otf. (Query, should we use sha instead of branch names?)

Ideally, we can leverage an existing WSTech repository for this. Perhaps LFF. In theory, we could allow any URL in the .kps file. But we would probably want to have a whitelist for perf, stability, and security reasons for the keyboard repository.

This also resolves the single-keyboard-repo conundrum of how to share fonts.

It would be important to have a UI that helps keyboard devs to find the fonts as well.

mcdurdin commented 6 months ago

@DavidLRowe @LornaSIL @srl295 your thoughts appreciated. I think that this would go a long way towards addressing remaining font sharing issues and allow us to eventually deprecate having fonts in the Keyman keyboards repository itself.

Obviously this could be applied to more than just fonts but would like to limit the conversation here to the font puzzle.

LornaSIL commented 6 months ago

Proposal, in short: allow packages to reference files from GitHub repos, not just local files.

Yes, if that is possible it would be fine.

image

mcdurdin commented 6 months ago

What about referencing the Noto fonts online?

  • Use the embed code:

We couldn't use the embed code as that is a HTML/CSS construct, as we need to be able to download a .ttf directly for embedding into the package. That may be possible also, but it needs to be a stable URL, so I would lean towards requiring a GitHub repo that we control, or that has good stability guarantees.

  • What would we do about online help files needing fonts? Would we still need to add them to s.keyman.com? Or could we again use the github repo or LFF for display of the help files? Or use the embed code from Noto.

My thinking is we would automatically deploy all fonts found during the build to s.keyman.com. The primary problem would be if more than one package used the same font in different versions.

  • Or referencing LFF (that would mean we would need to include all the desired fonts on LFF).
  • There are fonts we don't really want in LFF (PUA encoded, hacked fonts, etc.) so the referencing the Keyman Github repo might be best.

We can certainly support more than one source, and it makes sense to make the mechanism generic for future extension, even if we limit the sources we will support in the keyboards repository. We can have LFF and other fonts in the keymanapp/keyboards repo or even in a separate keymanapp/keyboard-fonts repo to keep it clean.

Technical note

This would slow down the build, as it would now need to source online content. It also introduces some fragility relating to network availability. Caching of fonts could mitigate both of those concerns, but caching also adds complexity.

mcdurdin commented 1 month ago

Suggest we add a Source element to kps Package.Files.File. This would be:

Question on source of truth for filename of font. Preferable to use Source filename where possible I think. But then refs in OSKFont and DisplayFont elements are harder to determine (tooling makes this easier but raw edit of XML leads to inconsistency).

At the same time CopyLocation, Description, and FileType elements should be deprecated and totally ignored by the compiler. They are busydata.

This would bump Package.System.FileVersion to e.g. 18.0.

There would be no change to the corresponding .kmp file format.