View Issue Details

IDProjectCategoryView StatusLast Update
0002128ScribusFontspublic2017-04-19 11:50
ReporterringercAssigned Toavox  
PrioritylowSeverityfeatureReproducibilityalways
Status assignedResolutionopen 
Platformx86 LinuxOSFedora CoreOS Version3
Target VersionFuture Release - Nice to have 
Summary0002128: Cache font info for startup
DescriptionWe should be able to cache font information on start-up. Searching for fonts and loading the initial info (psfontname etc) takes a while with lots of fonts. On my system, if the disk cache is clean, it can take 20 or more seconds - and that's with fast disks and a fast CPU.

If we store a cache file containing psfontname and the other info we need, along with font path, mtime, and size, we can just stat() the file and load the cache if the info matches. If the font can't be found, we delete it from the cache.

I'm not quite sure what format the cache should take, since ideally it should be able to purge unused entries without a full re-write. BDB comes to mind, but .... eeeew.
Additional InformationCould've sworn I filed a bug for this ages ago.
TagsNo tags attached.
PatchNo

Relationships

related to 0012985 assignedavox Improve font-checking script: discards potentially dangerous fonts during launch 
related to 0005643 acknowledged Activation of freshly installed fonts without app restart 
related to 0002655 closedfschmid Startup font scan is very slow 

Activities

ringerc

2005-06-26 14:50

reporter   ~0005156

Looks like we'll need to cache, in random jumble notation:

Foi::FontFormat format;
Foi::FontType type;
QString family_name; // from FT_Face->family_name
QString style_name; // from FT_Face->style_name
Foi::FontType typeCode; // for some fonts types at least
QString psFontName;
int faceindex; // since we can have multiple fonts per file/resource
// whatever setBestEncoding does
QString encoding; // as chosen by the switch at scfonts.cpp:719

fschmid

2005-10-08 11:43

administrator   ~0006962

Implemented a first Version of that to fix bug 2655, could be improved to fix this bug too.

avox

2005-10-08 14:11

administrator   ~0006970

Looks as if Franz bet me to this :-)

Anyway, I'd like to extend this further:

* I plan to refactor class Foi to hide all FreeType operations from the rest of Scribus
* I think about using gtfont or something similar to describe the visible characteristics of a font (family, style, effects, weight, ...)
* We need a two-level cache, since one fontfile can contain many faces. the current cache only looks at files and the first face in that fontfile

So in my view the cached information would include:

Per fontfile:
* filepath, last mod time, maybe md5sum,
* fonttype, fontformat,
* number of faces

Per face:
* face index in fontfile
* PSName
* broken flag
* family, style, styleflags, size, global metrics
* SCName
* best charmap, encoding
* nr of glyphs, number of accessible glyphs, number of broken glyphs

Stuff I don't plan to cache:
* glyph paths
* kerning tables
* user choices: use / subset / embed (that's in preferences already)


I propose to have two levels of brokenness:

A) font file not readable, freetype can't open face, or face does not contain scalable font
B) Freetype can load face ok but can't load some glyphs

A implies use=false
B implies embed=subset=true (that is convert to glyph outlines is mandatory)

That way no broken fonts can make it into the final PS / PDF and no broken fonts are referenced from the final PS / PDF.

Sometime in the future I'd like to implement subsetting fonts by creating new CFF fonts from the outlines...

jo-hannes

2006-01-30 19:27

developer   ~0008502

avox, how far are you gone with this? can we resolve it?

avox

2006-01-30 19:39

administrator   ~0008504

not yet. I'll resolve it myself when it's done.

In fact I want to rewrite the whole fonts stuff, also enabling multiple copies of the same font, indexing glyphs directly, clean interface to FT, etc. That will take some time.

Kunda

2015-04-28 00:15

updater   ~0034978

This is still low priority but nevertheless assigning this to 'Future Release' so as to keep track of this.

Kunda

2015-09-17 17:58

updater   ~0036262

Avox is working on 'Font Stuff' in ScribusCTL (https://github.com/andreas-vox/ScribusCTL)
BTW, Where does this issue live in the source?

Issue History

Date Modified Username Field Change
2005-06-26 08:56 ringerc New Issue
2005-06-26 08:58 ringerc Status new => acknowledged
2005-06-26 14:50 ringerc Note Added: 0005156
2005-10-03 16:09 ringerc Relationship added related to 0002655
2005-10-03 16:26 avox Status acknowledged => assigned
2005-10-03 16:26 avox Assigned To => avox
2005-10-08 11:43 fschmid Note Added: 0006962
2005-10-08 14:11 avox Note Added: 0006970
2006-01-30 19:27 jo-hannes Note Added: 0008502
2006-01-30 19:39 avox Note Added: 0008504
2006-07-02 21:47 avox Relationship added child of 0003964
2007-03-22 23:04 avox Relationship deleted child of 0003964
2015-04-28 00:15 Kunda Patch => No
2015-04-28 00:15 Kunda Note Added: 0034978
2015-04-28 00:15 Kunda Product Version 1.3.0cvs => Future Release - Nice to have
2015-04-28 00:15 Kunda Product Version Future Release - Nice to have =>
2015-04-28 00:15 Kunda Target Version => Future Release - Nice to have
2015-09-17 17:58 Kunda Note Added: 0036262
2015-09-17 17:59 Kunda Tag Attached: MABs
2015-09-17 19:24 Kunda Relationship added related to 0012985
2016-12-01 22:03 Kunda Relationship added related to 0005643
2017-04-19 11:50 JLuc Tag Detached: MABs