View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002128 | Scribus | Fonts | public | 2005-06-26 08:56 | 2017-04-19 11:50 |
| Reporter | Assigned To | avox | |||
| Priority | low | Severity | feature | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Platform | x86 Linux | OS | Fedora Core | OS Version | 3 |
| Target Version | Future Release - Nice to have | ||||
| Summary | 0002128: Cache font info for startup | ||||
| Description | We 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 Information | Could've sworn I filed a bug for this ages ago. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
|
|
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 |
|
|
Implemented a first Version of that to fix bug 2655, could be improved to fix this bug too. |
|
|
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... |
|
|
avox, how far are you gone with this? can we resolve it? |
|
|
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. |
|
|
This is still low priority but nevertheless assigning this to 'Future Release' so as to keep track of this. |
|
|
Avox is working on 'Font Stuff' in ScribusCTL (https://github.com/andreas-vox/ScribusCTL) BTW, Where does this issue live in the source? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-06-26 08:56 |
|
New Issue | |
| 2005-06-26 08:58 |
|
Status | new => acknowledged |
| 2005-06-26 14:50 |
|
Note Added: 0005156 | |
| 2005-10-03 16:09 |
|
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 |
