opengisch / QField-docs

Documentation for the QField ecosystem

Home Page:https://docs.qfield.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

JinIgarashi opened this issue · comments

When we select Japanese or Chinese language, social image's font has an issue.

https://docs.qfield.org/assets/images/social/get-started/concepts.ja.png

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.

I asked a question in their repo for this issue.

squidfunk/mkdocs-material#5704

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

- 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?

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.

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

commented

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