mkdocs-material: Social plugin: can't find fonts on Windows
Context
I am attempting to setup social cards for the first time in Windows. Have searched for solutions but it appears that loading fonts is not working as expected
Bug description
Enable social plugin in mkdocs.yml via adding the following lines:
`plugins:
- info
- social ` Results in the following error:
INFO - Building documentation... INFO - Cleaning site directory INFO - Documentation built in 0.28 seconds INFO - [23:48:15] Watching paths for changes: 'docs', 'mkdocs.yml' INFO - [23:48:15] Serving on http://127.0.0.1:8000/ INFO - [23:48:16] Browser connected: http://127.0.0.1:8000/ INFO - [23:48:21] Detected file changes INFO - Building documentation... Traceback (most recent call last): File "C:\Programming\materialtest\venv\Lib\site-packages\mkdocs\livereload\__init__.py", line 193, in _build_loop func() File "C:\Programming\materialtest\venv\Lib\site-packages\mkdocs\commands\serve.py", line 67, in builder build(config, live_server=None if is_clean else server, dirty=is_dirty) File "C:\Programming\materialtest\venv\Lib\site-packages\mkdocs\commands\build.py", line 277, in build config = config.plugins.on_config(config) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Programming\materialtest\venv\Lib\site-packages\mkdocs\plugins.py", line 527, in on_config return self.run_event('config', config) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Programming\materialtest\venv\Lib\site-packages\mkdocs\plugins.py", line 507, in run_event result = method(item, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^ File "C:\Programming\materialtest\venv\Lib\site-packages\material\plugins\social\plugin.py", line 160, in on_config self.font = self._load_font(config) ^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Programming\materialtest\venv\Lib\site-packages\material\plugins\social\plugin.py", line 462, in _load_font font[style] = self._resolve_font(name, style) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Programming\materialtest\venv\Lib\site-packages\material\plugins\social\plugin.py", line 476, in _resolve_font self._fetch_font_from_google_fonts(family) File "C:\Programming\materialtest\venv\Lib\site-packages\material\plugins\social\plugin.py", line 537, in _fetch_font_from_google_fonts font = ImageFont.truetype(temp.name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Programming\materialtest\venv\Lib\site-packages\PIL\ImageFont.py", line 807, in truetype return freetype(font) ^^^^^^^^^^^^^^ File "C:\Programming\materialtest\venv\Lib\site-packages\PIL\ImageFont.py", line 804, in freetype return FreeTypeFont(font, size, index, encoding, layout_engine) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Programming\materialtest\venv\Lib\site-packages\PIL\ImageFont.py", line 244, in __init__ self.font = core.getfont( ^^^^^^^^^^^^^ OSError: cannot open resource
Related links
Reproduction
9.5.18-social-plugin-windows.zip
Steps to reproduce
- Add the following lines to minimal reproduction mkdocs.yml `plugins:
- info
- social `
- Run mkdocs serve
Browser
No response
Before submitting
- I have read and followed the bug reporting guidelines.
- I have attached links to the documentation, and possibly related issues and discussions.
- I assure that I have removed all customizations before submitting this bug report.
- I have attached a .zip file with a minimal reproduction using the built-in info plugin.
About this issue
- Original URL
- State: closed
- Created 2 months ago
- Comments: 16 (6 by maintainers)
Commits related to this issue
- fix: social plugin fonts on Windows (squidfunk #7085) — committed to alexvoss/mkdocs-material-fork by alexvoss 2 months ago
- Fixed social plugin crashing on Windows when downloading fonts (#7085) (#7117) * fix: social plugin fonts on Windows (squidfunk #7085) * fix: managed to edit in material instead of src * added ... — committed to squidfunk/mkdocs-material by alexvoss 2 months ago
I created a pull request with code based on @kamilkrzyskow’s suggestion of using
ByteIO
, which works just fine. I tested against the Material for MkDocs documentation as well as the reproduction posted by @Aazih.Seems a nice rare case where fixing a problem that affects only one OS led to a reduction in code size as well as, presumably, a speedup since we are writing to only one file now. Will do the equivalent for the Insider Edition tomorrow - unless @squidfunk beats me to it or anyone spots a problem.