PDF import needs ages (building font cache)

> In most cases 99% of the installed system fonts are not necessary for importing PDFs correctly

How do you come to this conclusion? Inkscape does not make use of embedded fonts in PDF files - it compares the font names of the embedded fonts from the PDF files with installed fonts on the local system, to try to find the best matches.

> When I try to import in Inkscape 0.48 some pdf files, it needs at least 30 seconds
> until the preview panel is displayed.

Could you attach sample PDF files to allow comparing performance on different systems?

Nevermind my earlier comment:

> (…) Inkscape does not make use of embedded fonts in PDF files (…)

The preview image shown in the import dialog is rendered via cairo-poppler (which likely outlines the embedded fonts). The actual import (conversion) of the PDF file uses different internal import routines (during which embedded fonts are replaced with closest-matching fonts found among the installed fonts of the local system).

Well, looking deeper into the problem it looks as Inkscape is building a fontconfig/cache in the temporary directory. If this folder is present the preview is shown immediately. If it doesn't, opening any pdf takes all those disk reads until the preview is shown.
It turned actually out that I got this observation the first time (only the first) with a new clean Inkscape version (of course), but every time I started with the portableapps.com version. It looks that that portable version removes the cached font directory every time after closing the program.

Looking at the new facts there remain two open questions:
- Can you improve the bad first time experience? Maybe by building the font index at the first startup, indicating that the font-cache is being read. At least you should indicate that time-consuming process somehow
- How are those portableapps.com versions generated? According to http://es.dev.inkscape.org/download/ they seem to be kind of "official" builds

@Chris - subscribing you to this bug report. If you still read notification emails from the bug tracker, maybe you could comment on the questions raised in the comments about the portable version for Windows:

On 06/07/2012 19:55, Daniel Kaneider wrote:
> Well, looking deeper into the problem it looks as Inkscape is
> building a fontconfig/cache in the temporary directory. If this
> folder is present the preview is shown immediately. If it doesn't,
> opening any pdf takes all those disk reads until the preview is
> shown.

> It turned actually out that I got this observation the first time
> (only the first) with a new clean Inkscape version (of course), but
> every time I started with the portableapps.com version. It looks that
> that portable version removes the cached font directory every time
> after closing the program.
>
> Looking at the new facts there remain two open questions:
>
> - Can you improve the bad first time experience? Maybe by building
> the font index at the first startup, indicating that the font-cache
> is being read. At least you should indicate that time-consuming
> process somehow
>
> - How are those portableapps.com versions generated? According to
> http://es.dev.inkscape.org/download/ they seem to be kind of
> "official" builds

Tested on vist 64 bit.

Tested with r11358:
- Inkscape loads within 11 seconds. File > Import and selecting an 8 MB graphically heavy PDF just takes one second for the preview to be shown.
- removing the directory C:\Users\MyUserName\AppData\Local\Temp\fontconfig (where MyUserName is my windows account name). Subsequently starting Inkscape takes 30s, selecting the same PDF for import needs also just a second for the preview to be shown. (the file in the fontconfig directory is in use and hence can not be removed during Inkscape operation)

The portable apps download:
- does not seem to remember any preferences (does not load the locale, while it is extracted on disk): corresponds with the portable apps idea
- loading takes 11-12 seconds
- Help > About Inkscape reports 0.48.2 r9819
- Selecting the 8 MB graphically heavy PDF for importing needs roughly 25 seconds for the preview to be shown. The font cache file of above is left untouched.
- In the same instance: reselecting the 8 MB graphically heavy PDF for importing needs just one second
- Removing the fontconfig directory of above does not have any influence on the portable app

So, font "cache" is build on first startup in current trunk and has no influence on pdf preview. The portable app builds the font cache on first pdf import.

Regarding comment 4: seeing the above: if a new portable app would be build when Inkscape 0.49 is out, it should build the cache immediately. I do not know who builds them and how. I actually did not know about the portable app. If I need to use Inkscape "portable" I just copy the Inkscape directory from "c:\program files (x86)\Inkscape" to a USB stick and this works without an issue (issue reported above does not happen). If used on a "new" PC, Inkscape saves its settings in the normal place (C:\Users\MyUserName\AppData\Roaming\inkscape). If that's a problem (in the idea of a portable app that leaves no traces on the PC), then I'm afraid there is no alternative and you need to wait for ages on importing a PDF ...

This is the PDF I used for testing:
http://www.provant.be/binaries/ANTenne_20112_april-juni_LR_tg_tcm7-126693.pdf

Remains the feature request that it would be handy to have a progress bar showing the progress on building the font cache. Wondering about bug priority: if it was only this feature request according to our guidelines it should be low, but I also see the need to shorten the time for building the font "cache".

I speak for Inkscape Portable as its developer and maintainer. Inkscape Portable is an officially supported build of Inkscape. I cannot speak of Inkscape itself and how it does it, but I agree that it certainly shouldn't require a long operation. How does the GIMP do it? Does it have a long delay?

Inkscape Portable keeps a clean TEMP directory; this means that the font cache is lost every time you run it. This is standard behaviour for PortableApps.com apps and is probably still desirable in this case as the font cache is going to be machine-dependant. (Would it use a stale/invalid font cache if you moved machines? I don't know. But that could be a worse problem than the slowness.)

If you wish to try it with leaving the font config behind on the host machine (so that it will only need to generate it once per machine you use), modify InkscapePortable\App\AppInfo\Launcher\InkscapePortable.ini: in the [Launch] section, add a line CleanTemp=false. You will need to do this for every new release, though, as I do not intend to change the behaviour. Note that setting CleanTemp=false will also have the effect of leaving anything else Inskcape puts in the TEMP directory behind, which could include personally identifiable information in rare cases.

There's also the option of adding [DirectoriesMove]:fontconfig=%TEMP%\fontconfig to InkscapePortable.ini; this would keep the fontconfig directory in InkscapePortable\Data\fontconfig. Before attempting anything like that, though, we'd need to verify its behaviour with switching machines. I don't believe it's likely to work well. At the best, I expect it would throw away the cache every time you tried to hit it on a new machine, and so it would only benefit you as long as you continued using it on the one machine. It's also possible that I/O performance could be a problem.

Possibly related discussion on the fontconfig mailing list:
<http://thread.gmane.org/gmane.comp.fonts.fontconfig/4738>

Related report (wrt to regular Windows package, i.e. not specific to Inkscape Portable):
- Bug #1196373 “Change fontconfig cache folder location on Windows”
  <https://bugs.launchpad.net/inkscape/+bug/1196373>

This issue is "fixed" by the fact that font cache is built upon start of Inkscape now (therefore no delays when importing PDFs).
See bug 1528629 for the inevitable delay that occurs on startup when building the font cache.

Good news is that this delay should only occur once (see bug 1196373 for details) since the cache is now stored in a non-temporary location.

For portable versions of Inkscape this means, that the location of <cachedir> in "share/etc/fonts/fonts.conf " should be adjusted, though. Otherwise the file will be created in "%LocalAppdata%\fontconfig".