LadybirdBrowser
LibCore+LibGfx: Rely on fontconfig(if enabled) for font directory resolution
first timer here.
i run a rather obscure linux and none of the fallback fonts that are listed in update_generic_fonts are present on my system. my initial clue was to try to enable fontconfig, but result was fruitless. eventually after a bunch of printf (or in this case outln) debugging i figured out that the issues was that ladybird was not able to load the fonts that fontconfig was resolving because ladybird was not trying look into directories in which fontconfig has found fonts.
this might be related to #4601
i moved font_directories from StandardPaths to FontDatabase because it didn't seem like it would be appropriate to call to fontconfig funcs from within the LibCore (based on my brief observations of how everything is structured). i'm not 100% confident that FontDatabase is the correct place.. but seems okay?
besides issue with fonts it was a rather straightforward sailing, getting to build the whole thing. thanks for your efforts.
Thanks for the PR! I tried to tackle this issue more fully in https://github.com/LadybirdBrowser/ladybird/pull/4291, where the idea is to create a FontConfigFontProvider that will lazily cache the fonts needed by the WebContent process by loading the bytes directly from fontconfig.
Simply adding the fontconfig global directories didn't occur to me as a partial solution. I think if we accept this partial solution, we probably want to only look in fontconfig's directories if we're using fontconfig? Rather than looking there and in $XDG_DATA_HOME/fonts.
This still has the issue that once we know about these directories, we try to load every single font into memory at once. That's what 4291 was really trying to solve.
I tried to tackle this issue more fully in https://github.com/LadybirdBrowser/ladybird/pull/4291, where the idea is to create a FontConfigFontProvider that will lazily cache the fonts needed by the WebContent process by loading the bytes directly from fontconfig.
nice to see an the effort in that direction! it doesn't sit quite right that ladybird is greedily loading every font it can discover, but at the moment it is what it is i suppose.
This still has the issue that once we know about these directories, we try to load every single font into memory at once. That's what 4291 was really trying to solve.
indeed! this pr does not address that issue. if you don't mind sharing - what was the challenge for finalizing the changes that you were making / what were the problems that you faced?
we probably want to only look in fontconfig's directories if we're using fontconfig? Rather than looking there and in $XDG_DATA_HOME/fonts.
right, absolutely. is there anything else you think needs to be changed here?
indeed! this pr does not address that issue. if you don't mind sharing - what was the challenge for finalizing the changes that you were making / what were the problems that you faced?
We have three places that define what the enum values for slope/weight/etc are: LibGfx, Skia, and fontconfig. I'm not convinced that I got it remotely correct in how to translate between them. It doesn't help that all our APIs use int instead of actual enum types.
When I plugged in the FontConfigFontProvider, I found that the CSS StyleComputer was never hitting my cache. It would always pass through to directly call fontconfig for every font lookup.
And a few tests started failing.
Hello!
One or more of the commit messages in this PR do not match the Ladybird code submission policy, please check the lint_commits CI job for more details on which commits were flagged and why.
Please do not close this PR and open another, instead modify your commit message(s) with git commit --amend and force push those changes to update this PR.
re https://github.com/LadybirdBrowser/ladybird/pull/4830#issuecomment-2899449595
I see, interesting.. thanks for the info!
heads up, ci failure appears to be caused by timeout or something:
The hosted runner lost communication with the server. Anything in your workflow that terminates the runner process, starves it for CPU/Memory, or blocks its network access can cause this error.