QField-docs
QField-docs copied to clipboard
[bug] font issue of og image in Chinese and Japanese language
When we select Japanese or Chinese language, social image's font has an issue.
- Japanese https://docs.qfield.org/assets/images/social/get-started/concepts.ja.png
- Chinese https://docs.qfield.org/assets/images/social/get-started/concepts.zh.png
According to the documentation, there is a way to set font family in mkdocs.yml, but I am not sure how we can change font family dynamically according to the language of content.
- official document https://squidfunk.github.io/mkdocs-material/setup/setting-up-social-cards/#choosing-a-font
I asked a question in their repo for this issue.
https://github.com/squidfunk/mkdocs-material/discussions/5704
@m-kuhn Do you have access to Material for Mkdocs Insiders version? I saw you are setting MKDOCS_INSIDERS_TOKEN
in Github action.
https://github.com/opengisch/QField-docs/blob/9db751f91aa55b55c8ccc5703cd76cd9719ad08d/.github/workflows/gh-pages.yml#L31-L34
See the below documentation of typography. Looks like insiders version can solve this issue by adding font family and font style for each markdown file. https://squidfunk.github.io/mkdocs-material/setup/setting-up-social-cards/#typography
If QField can use insiders version of the module, this can be solved easily. I think you can insert the following YAML into each ja.md
and zh.md
file programatically.
size: { width: 1200, height: 630 }
layers:
- font:
family: Noto Sans JP or Noto Sans SC
style: Bold
Could you try this?
I got response from material for mkdocs author.
https://github.com/squidfunk/mkdocs-material/discussions/5704#discussioncomment-6435923
maybe you can try insiders version. I can’t do it since I have no access to insiders.
@why-not-try-calmer looks like this bug is still not solved
@why-not-try-calmer looks like this bug is still not solved
I now realize that:
It's currently not supported to scope the application of metadata through .meta.yml files based on file extension (source)
Unfortunately this repository is structured in a way that requires this unsupported method for using metadata based on file extension. In other words, solving this issue requires that either upstream supports using metadata based on file extension, or that we change the file structure. Not really promising :(