View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0016838||Scribus||User Interface||public||2022-08-28 19:52||2022-08-29 20:05|
|Summary||0016838: Cache prerendered fonts for text properties selection dropdown|
|Description||[This is more wishful thinking than a feature request.]|
Fontconfig/Freetype are pretty slow in generating a list of font previews, which makes initial style selection or live adaptions somewhat tedious. (It's even more of an annoyance for Inkscape, TBH.)
So anyway, it would be awesome if there was a way to generate and reuse some prerendered/cached previews of installed fonts.
Since it's only mapping the default font names to rendered font previews, it really just pertains text properties or the story editor.
I'm assuming this would be a massive effort. Probably requires creating a bunch of PNGs for all installed fonts.
Not sure how much work it would realistically incur extending the dropdown CellRenderer. (And if ever, this should probably remain an optional feature.)
And yes, I realize that's likely why the font browser exists.
|Steps To Reproduce||1. Text properties [font selection⏷]|
2. Scroll down
3. Wait 3 seconds.
4. Resume scrolling...
|Additional Information||http://www.fifi.org/doc/libfreetype6/reference/ft2-cache_subsystem.html#FTC_ImageCache doesn't look like a worthwhile avenue.|
|Tags||caching, fontconfig, fonts, libfreetype|
This is clearly related to the number of fonts installed. In my case, getting rid of the barrage of Noto* fonts (Ubuntu setup) did alleviate the performance issue.
It's not gone, but very much in the realm of tolerable - with 0000233:0000400 fonts remaining (instead of a 1000 or so).
Thus the whole topic might pertain just DTP users with a high variance of installed or used fonts; instead of the average user.
Nonetheless, an alternative to convoluted font preview caching/storing/display, might be some form of nested dropdown. Specifically coalescing font family names, such as [Noto �] or [Roboto �] and similar such.
That's unlikely to be any less implementation overhead, and it's really just compensating for fontconfigs inability to alias fonttype serializations into common lookup names. (Doesn't look like it's feasible to combine <rejectfont> with <charset>-matches and <alias> there.)
|2022-08-28 19:52||prof_milki||New Issue|
|2022-08-28 19:52||prof_milki||Tag Attached: caching|
|2022-08-28 19:52||prof_milki||Tag Attached: fontconfig|
|2022-08-28 19:52||prof_milki||Tag Attached: fonts|
|2022-08-28 19:52||prof_milki||Tag Attached: libfreetype|
|2022-08-29 20:05||prof_milki||Note Added: 0049753|