Closed kreuzberger closed 1 year ago
OTF fonts do lead to the same problem as before - not used/printed in PDF Output
According to my comment above i dont know what is wrong with the rendering, but this should be checked by experts before savely.
Argh, testing on windows seems to become more and more important.
As far a I know, Windows should be able to deal with OTF founds. The defined this standard together with Adoobe. Therefore I'm supprised, that only the TTF fonts seem to work on windows.
I have no problem with adding windows specific CSS. But I'm currently unable to test it easily, as I have only access to Linux machines.
I will try to work on our CI and add some windows-specific tests, or at least render the demo-pdf on windows as well.
I hope I find some time soon, to test this PR on linux
Ohh, forgot the most important point:
Thanks for the PR :+1:
One last question, when your are talking about "building on windows". Is it pure windows or do you use WSL?
Hi! Currently the Fonts normaly use are FiraSans*.otf work on windows, output is shown normally. Why the literal-blocks / monospace fonts do not work i do not know, but from my background i am no html/css developer, so i just reverted it to get it running.
Regarding your last questions: I Build pure Windows (10) without WSL.
I haven't found any issues with this configuration on my Linux build. So it got merged. Thanks for it.
Using sphinx-simplepdf on Windows leaded to missing monospace text in pdf output (e.g in codeblocks or inline directives). This could be fixed by adding a (free) monospace font to the font-face entries in the scss for fonts.
Due to my domain i am not sure if the font configuration is right (maybe due to font-weight configuration and so on). Please check before acception.
Building demo was not possible due to "old" sphinx_needs configuration (renamed from sphinxcontrib_needs). This is also fixed now cause "offical" released on pypi.org