@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
@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 es.dev. inkscape. org/download/ they seem to be kind of
> (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://
> "official" builds