Re-create font cache?

[southwindows]

I made some changes to a font and re-installed it.  Windows programs other than Scribus 1.5.3 are using it OK.

File/Preferences/Fonts shows that Scribus is using the old version.  I know that it's supposed to check for changed fonts on startup but somehow it's not picking up this change.  Is there a way to force it to re-create the font list?  Or some other way way to deal with this, short of uninstalling/reinstalling the program?

[a.l.e]

uninstalling/reinstalling scribus is the solution to no known problem.

i personally, don't know how to get the fontcache to be rebuild on windows, but what you can do is:

- close scribus
- delete the settings
- start scribus

now, you have to find out how to remove the settings in your version of windows...

[a.l.e]

p.s.:

On Windows 8 and Windows 10 there is a Scribus directory in the AppData directory.

The prefs140.xml file probably is in C:\Users\<username>\AppData\Roaming\Scribus.
Rename this file to force Scribus to create a fresh one (as it does when you first run it).

[southwindows]

Thank you very much for these suggestions.  Early this morning, before I read your post, I uninstalled Scribus, restarted Windows, then reinstalled.  Obviously uninstalling Scribus did not wipe out the font cache, since the new version did not take any time to search for fonts as it did when originally installed.  And, indeed, the old version of the font is still shown in Preferences/Fonts.

The weird thing is that when I update a font, the initial screen says "New font found" and it takes a moment to process, but the new font is not placed into Scribus' own font list.  My fonts are all in the normal Windows/Fonts folder, and Scribus in fact uses that path to point to an outdated font that doesn't exist any longer in Windows/Fonts!

You are correct about the location of the preferences file.  I took a quick look and that file does not have the font list nor any link (that I saw) to one.  I'll try deleting it and see what happens.  If that doesn't work I'll uninstall Scribus and then manually wipe all Scribus directories rather than relying on Windows' uninstall feature.  There is a Scribus directory in Programs(x86) -- this is a Win 7 machine -- but I see nothing there that looks like a font cache.

[southwindows]

Update: just deleted preferences.  Scribus complained (as expected) that it couldn't load preferences and loaded the defaults.  The old font file is still shown in Preferences/Fonts. 

[GarryP]

From what I remember, the prefs140.xml file has nothing to do with fonts (in this context anyway).
To get Scribus to rebuild its list of fonts you need to rename/delete the checkfonts.xml file instead.

NOTE: Uninstalling Scribus doesn't remove the C:\Users\<username>\AppData\Roaming\Scribus folder so a re-install will just re-use whatever is there and nothing will have changed.

NOTE: Scribus doesn't check for fonts that no longer exist (as far as I know). If you remove a font from the system, Scribus still thinks it's there until you manually delete the relevant line from checkfonts.xml (not recommended) or rename/delete the file and get Scribus to re-build the list from scratch.

[southwindows]

Thank you GarryP.  Unfortunately, this doesn't solve the problem.

I looked at checkfonts150.xml and found twelve versions of my font.  The first one (the oldest) is what is displayed in Preferences/Fonts.

I renamed checkfonts150.xml to checkfonts150.old and restarted Scribus.  It recreated the font list and all the old versions were still there in the new checkfonts150.xml!

So I took the plunge and carefully edited the XML file, restarted Windows (just in case the font list was still in memory somehow, not that I would expect this).  Guess what?  All the old fonts showed up again!   

I doublechecked Windows and the the Fonts directory has only the most recent version, unless Windows itself is somehow hiding old ones somewhere.  That's a problem I've never encountered in years of fond development, though.

There must be some other location where this is being stored.  Any ideas?

[GarryP]

Hmm... Not sure what's going on there.

Is there any chance you can share your checkfonts.xml file? We would also need to know which font you're having trouble with.

Also, open Scribus and close all documents, then go to "Preferences / Fonts / Additional Paths" and see what's there.

And check that the folder your document is in has no font files as they could be "interfering" with things.

EDIT: You could try renaming both checkfonts.xml and scribus140.rc and see what happens. Just make sure you only rename them in case something goes wrong so you can rename them back.

[Nermander]

My guess is that Scribus (or rather the font libraries it uses) does not correctly handle if an already installed font is edited, and I can fully understand why (because that is a situation that does not happen in normal computers). Maybe the edited font is considered "damaged" and ignored because of that?

My suggestion would be to either install the edited font with an alternative name, or maybe install the old font and reinstall the edited version.

[southwindows]

Sorry for the slow reply on this.

Is there any chance you can share your checkfonts.xml file?

Yes, if you wish; but see the screen shot in my most recent post below; maybe that's enough.

Also, open Scribus and close all documents, then go to "Preferences / Fonts / Additional Paths" and see what's there.

'Additional Paths' has nothing in it.

And check that the folder your document is in has no font files as they could be "interfering" with things.

No, no fonts in the document folders.

[southwindows]

Thank you, Nermander.

My guess is that Scribus (or rather the font libraries it uses) does not correctly handle if an already installed font is edited,

A reasonable guess.  When I reinstall an edited font, the Scribus startup screen displays "New font found" so it seems that everything should be OK, but it's clearly not.  Does Scribus use the same font libraries as LibreOffice?  I have no issues with that suite.  There may also be Windows issues involved; see next post.

My suggestion would be to either install the edited font with an alternative name, or maybe install the old font and reinstall the edited version.

I'll try the alternative name strategy, which will probably get things working at least to the point where I can test the OT features in my font once.  I'm not sure what you mean by the second sentence -- did you mean to type "uninstall"?  I did try uninstalling the font before putting in the new version, which did not help.

[southwindows]

Here's my thinking over the last couple of days.  First, I'm attaching a screenshot of the relevant portion of checkfonts.xml.  You can see that there are multiple versions of the font installed.  Bizarre.

I just uninstalled Scribus and then manually deleted the Scribus directory from Appdata/Roaming.  Then I reinstalled, Scribus recreated the font cache, and it looks exactly the same as before (with the multiple font instances).  Even more bizarre.  I can think of only two explanations for this.

1. Scribus itself is somehow storing font information in a way that survives a complete reinstall with the old checkfonts.xml removed.  This seems very unlikely.

2. Windows stores font data somehow when fonts are edited or removed.  This sounds weird but I have had intimations in the past that Windows does funny things behind the scenes with fonts.  For instance, a couple of times it has renamed font files when I reinstall them.  In the Windows/Fonts folder all one sees is the most recent version, though. 

Also, I do not believe all the font versions seen in the screen shot were ever installed in Scribus.  I experimented a bit with 1.5.2 about a year ago, then in the last 2-3 weeks have been playing with 1.5.3 svn.  If Scribus was remembering the font data, the xml file would show one or versions from a year ago and a couple from recent weeks, but not all the intervening ones.  This points (as far as I can figure out) to a Windows problem, perhaps made worse by a bug in Scribus' font handling.

I was trying to test the OT features in my font and found that Scribus behaved differently on Win 7, Win 10, and OS X.  It now seems that the immediate cause is that Scribus was using outdated font versions on Windows (different on the two machines), so it's no surprise that that the font didn't work as expected.  (The oldest versions don't have the OT features at all, and more recent versions were experimental in terms of how I set up the features.)  Scribus and the font play nicely with OS X, where (I think) it is actually using the current font version.  The underlying cause is perhaps a bug in Scribus.  Does that make sense?  I have never had this kind of problem with any program other than Scribus, and I have done a lot reinstalling fonts as I edit them

[attachment deleted by admin]

[southwindows]

OK, I just went into my font editor and changed the name of the font from FaliscanCDS to FaliscanRenamed (how imaginative . . . ).  I installed this version and everything works.  This confirms that Scribus' handling of OT features on Windows (ver. 7 but I expect ver. 10 will work the same) is fine and that the font is correctly built.  The problem is that Scribus was using an old version of the font.

[utnik]

hi southwindows

my guess is, that you really have installed multiple versions of the same font.
windows may have different font folders (at least one for system wide use and one for every user) – and scribus checks them all...

utnik

[GarryP]

I have a strong feeling that Scribus itself isn't maintaining a font cache but is using "fontconfig" to do so.

This would make sense as, since fontconfig stores its data completely separately from Scribus (on Windows in, AppData/Local/fontconfig/cache), uninstalling Scribus makes no difference.

If this is true then the problem could either be with fontconfig or the way that Scribus is using it. Either way I don't think there's anything a normal user can do about it.

I have no idea what deleting/renaming the cache folder - or the files within - would do, but I'm guessing nothing good would come from it. Desperate times sometimes call for desperate measures but, personally, I would only think about doing this as a near-to-last resort.

I think it would be a good idea for Scribus to include a function - somewhere in Preferences - where the user can press a button to tell Scribus to tell fontconfig - if that is indeed what's being used for this kind of thing - to destroy its current cache and re-build it from scratch.

This would be useful, not just in cases like this, but also when a user has deleted fonts that they no longer need. Basically, give Scribus a "scrub the cache and give me a shiny new one" function.

For an application like Scribus, where fonts are its "bread and butter", I don't think this is asking for too much.