PDF import needs ages (building font cache)

Bug #1021815 reported by Daniel Kaneider
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Medium
Patrick Storz

Bug Description

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

The windows task manager shows, that Inkscape does about 2GB of IO reads (on a new program instance). Analyzing the problem further with ProcessMonitor, it turned out that every file in the Windows Font folder was read. In most cases 99% of the installed system fonts are not necessary for importing PDFs correctly.

Revision history for this message
su_v (suv-lp) wrote :

> 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.

tags: added: importing pdf performance
Revision history for this message
su_v (suv-lp) wrote :

> 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?

Revision history for this message
su_v (suv-lp) wrote :

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).

Revision history for this message
Daniel Kaneider (kaneiderdaniel) 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

su_v (suv-lp)
tags: added: fonts win32
removed: importing pdf
summary: - PDF import needs ages
+ PDF import needs ages (building font cache)
Revision history for this message
su_v (suv-lp) wrote :

@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

Revision history for this message
Kris (kris-degussem) wrote :

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 ...

Revision history for this message
Kris (kris-degussem) wrote :
Changed in inkscape:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Kris (kris-degussem) wrote :

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".

Revision history for this message
Chris Morgan (chris.morgan) wrote :

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.

Revision history for this message
su_v (suv-lp) wrote :

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

Revision history for this message
su_v (suv-lp) wrote :

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>

Revision history for this message
Patrick Storz (ede123) wrote :

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".

Changed in inkscape:
assignee: nobody → Eduard Braun (eduard-braun2)
status: Confirmed → Fix Committed
jazzynico (jazzynico)
Changed in inkscape:
milestone: none → 0.92
Bryce Harrington (bryce)
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.