[bug] font issue of og image in Chinese and Japanese language

[JinIgarashi]

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

[JinIgarashi]

I asked a question in their repo for this issue.

squidfunk/mkdocs-material#5704

[JinIgarashi]

@m-kuhn Do you have access to Material for Mkdocs Insiders version? I saw you are setting MKDOCS_INSIDERS_TOKEN in Github action.

QField-docs/.github/workflows/gh-pages.yml

Lines 31 to 34 in 9db751f

	- name: Install Python requirements insiders
	run: pip install -r requirements-insiders.txt
	env:
	MKDOCS_INSIDERS_TOKEN: ${{ secrets.MKDOCS_INSIDERS_TOKEN }}

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?

[JinIgarashi]

I got response from material for mkdocs author.

squidfunk/mkdocs-material#5704 (reply in thread)

maybe you can try insiders version. I can’t do it since I have no access to insiders.

[JinIgarashi]

@why-not-try-calmer looks like this bug is still not solved

[why-not-try-calmer]

@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 :(