You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Pascal Burkhardt <pa...@mail.de> on 2015/10/20 15:49:00 UTC
Speedup Font Cache
Hi,
i upgrade from 1.8.10 to 2.0.0-RC1.
When i start to create a pdf with pdfbox 2.0.0-RC1 now the log-message
appears: "WARNING: Building font cache, this may take a while". To
Create a Font Cache it takes quite a long time...(2-3sec.). To create a
simple pdf-page this is quite long...
Is there a way to disable the font cache or to speed up this process?
Can i load the font cache on startup of my application, so that when a
user requests a pdf it renders quickly (and do not have to init the
cache?) or is there another possibility?
Thanks,
Pascal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Speedup Font Cache
Posted by Tilman Hausherr <TH...@t-online.de>.
Am 22.10.2015 um 02:30 schrieb Roberto Nibali:
> Hi Tilman
>
> On Wed, Oct 21, 2015 at 7:24 PM, Tilman Hausherr
> <THausherr@t-online.de <ma...@t-online.de>> wrote:
>
> Am 21.10.2015 um 18:43 schrieb Maruan Sahyoun:
>
> Hi,
>
>
> Could it be that 1) you installed new stuff on your
> computer, 2) that MacOS has many of its fonts in .ttc
> files? In Windows there are only 10.
>
> on my OS X I have 92 ttc files (out of 384) :-)
>
>
> Oh. I forgot to mention why I asked that. My last change ignores
> ttc files in the cache, even deletes them, because the cache is
> one file => one ttf font, this resulted in ttf fonts being ignored
> the second time. So these ttc files would be parsed each time.
>
>
> I reckon you're referring to this part:
>
> Inline image 1
Image doesn't appear
>
> I have some files ending in .TTC, which would only be omitted with the
> following code:
>
> if (path.toLowerCase().endsWith(".ttc"))
>
> There is another one:
>
> @surimacpro:~/$ ack "path.endsWith"
> examples/src/main/java/org/apache/pdfbox/examples/lucene/IndexPDFFiles.java
> 201: if (path.endsWith(".PDF"))
>
> pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FileSystemFontProvider.java
> 269: if (path.endsWith(".ttc"))
>
> Maybe you can amend those, though this has nothing to do with the
> issue at hand.
Thanks, fixed.
However for you, if you don't use any "exotic" fonts, the best would be
to revert that file to 1691110 until a better version of the cache is
written (that uses a list of FontInfo objects instead of one object for
the file key)
Tilman
Re: Speedup Font Cache
Posted by Roberto Nibali <rn...@gmail.com>.
Hi Tilman
On Wed, Oct 21, 2015 at 7:24 PM, Tilman Hausherr <TH...@t-online.de>
wrote:
> Am 21.10.2015 um 18:43 schrieb Maruan Sahyoun:
>
>> Hi,
>>
>>
>>> Could it be that 1) you installed new stuff on your computer, 2) that
>>> MacOS has many of its fonts in .ttc files? In Windows there are only 10.
>>>
>> on my OS X I have 92 ttc files (out of 384) :-)
>>
>
> Oh. I forgot to mention why I asked that. My last change ignores ttc files
> in the cache, even deletes them, because the cache is one file => one ttf
> font, this resulted in ttf fonts being ignored the second time. So these
> ttc files would be parsed each time.
I reckon you're referring to this part:
[image: Inline image 1]
I have some files ending in .TTC, which would only be omitted with the
following code:
if (path.toLowerCase().endsWith(".ttc"))
There is another one:
@surimacpro:~/$ ack "path.endsWith"
examples/src/main/java/org/apache/pdfbox/examples/lucene/IndexPDFFiles.java
201: if (path.endsWith(".PDF"))
pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FileSystemFontProvider.java
269: if (path.endsWith(".ttc"))
Maybe you can amend those, though this has nothing to do with the issue at
hand.
Cheers
Roberto
Re: Speedup Font Cache
Posted by Roberto Nibali <rn...@gmail.com>.
Addendum (fixed my one-liner):
And no pfb fonts:
$ shopt -s nocasematch; tot=0; pfb=0; ttf=0; otf=0; ttc=0; while read line;
do let tot+=1; case "${line##*.}" in ttf) let ttf+=1;; otf) let otf+=1;;
ttc) let ttc+=1;; pfb) let pfb+=1;; esac; done < <(gfind /Library/Fonts
/System/Library/Fonts ~/Library/Fonts -type f \( -iname "*.ttf" -o -iname
"*.ttc" -o -iname "*.otf" -o -iname "*.pfb" \) 2>/dev/null -printf "%f\n")
&& printf "\nTotal fonts=%s: ttf=%s otf=%s ttc=%s pfb=%s\n" "$tot" "$ttf"
"$otf" "$ttc" "$pfb"
Total fonts=447: ttf=296 otf=63 ttc=88 pfb=0
Cheers
Roberto
On Thu, Oct 22, 2015 at 1:15 AM, Roberto Nibali <rn...@gmail.com> wrote:
> Hi guys
>
> Well, a quick look revealed the following stats:
>
> $ ttf=0; otf=0; ttc=0; while read line; do shopt -s nocasematch; case
> "${line##*.}" in ttf) let ttf+=1;; otf) let otf+=1;; ttc) let ttc+=1;;
> esac; done < <(gfind /Library/Fonts /System/Library/Fonts ~/Library/Fonts
> -type f \( -iname "*.ttf" -o -iname "*.ttc" -o -iname "*.otf" \)
> 2>/dev/null -printf "%f\n") && printf "ttf=%s otf=%s ttc=%s\n" "$ttf"
> "$otf" "$ttc"
>
> ttf=296 otf=63 ttc=88
>
> So, not that many fonts that ought to be parsed by pdfbox. Since I
> currently cannot verify an older version of pdfbox svn, may I ask what
> could cause such a change? I have certainly installed new patches and
> software to my MacOSX 10.9.
>
> Cheers
> Roberto
>
>
> On Wed, Oct 21, 2015 at 7:24 PM, Tilman Hausherr <TH...@t-online.de>
> wrote:
>
>> Am 21.10.2015 um 18:43 schrieb Maruan Sahyoun:
>>
>>> Hi,
>>>
>>> Am 21.10.2015 um 18:40 schrieb Tilman Hausherr <TH...@t-online.de>:
>>>>
>>>> Am 21.10.2015 um 14:10 schrieb Roberto Nibali:
>>>>
>>>>> Hi John
>>>>>
>>>>> On Wed, Oct 21, 2015 at 12:35 AM, John Hewson <jo...@jahewson.com>
>>>>> wrote:
>>>>>
>>>>> Yes, I’m able to replicate that issue on Windows. It’s apparently
>>>>>> related
>>>>>> to administrator ownership of that registry key’s parent node. Looks
>>>>>> like
>>>>>> it’ll be necessary to log in as admin and create that key with user
>>>>>> access.
>>>>>> I guess that’s far from ideal?
>>>>>>
>>>>>>
>>>>>> The whole issue also happens on MacOSX. When you introduce this
>>>>> on-disk
>>>>> cache a couple of months back, it worked fine, however one of the
>>>>> recent
>>>>> changes to SVN must have wrecked the initially intended functionality.
>>>>> Not
>>>>> only is the font caching setup 5-10 times as long as it used to be, it
>>>>> also
>>>>> does not seem to persist it anymore. Version used:
>>>>>
>>>>> $ svn info | grep -i changed
>>>>> Last Changed Author: tilman
>>>>> Last Changed Rev: 1709647
>>>>> Last Changed Date: 2015-10-20 19:04:02 +0200 (Tue, 20 Oct 2015)
>>>>>
>>>>> Running my test tool indicates:
>>>>>
>>>>> Oct 21, 2015 2:08:29 PM
>>>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider loadCache
>>>>> WARNING: New fonts found, font cache will be re-built
>>>>> Oct 21, 2015 2:08:29 PM
>>>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider <init>
>>>>> WARNING: Building font cache, this may take a while
>>>>> Oct 21, 2015 2:08:39 PM
>>>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider saveCache
>>>>> WARNING: Finished building font cache, found 654 fonts
>>>>> [INFO, ctx=./ccalt.pdf]: Opening Source ./ccalt.pdf
>>>>> [INFO, ctx=./ccalt.pdf]: Opening Template ./cctemp.pdf
>>>>> [INFO, ctx=./ccalt.pdf]: Writing Output ./ccmig.pdf
>>>>> [INFO, ctx=./ccalt.pdf]: Completed in 15037.02ms
>>>>>
>>>>> This used to be anything between 1200ms and 2300ms and once it was
>>>>> persisted onto disk, it was rather fast in subsequent calls.
>>>>> Unfortunately,
>>>>> SVN does not provide the handy tool of "git bisect" to quickly find out
>>>>> which change actually caused this regression.
>>>>>
>>>> There were only 4 changes since then, so it might be worth a try to
>>>> just revert that file.
>>>>
>>>> (I can't help; for me, it has always been slow.)
>>>>
>>>> Could it be that 1) you installed new stuff on your computer, 2) that
>>>> MacOS has many of its fonts in .ttc files? In Windows there are only 10.
>>>>
>>> on my OS X I have 92 ttc files (out of 384) :-)
>>>
>>
>> Oh. I forgot to mention why I asked that. My last change ignores ttc
>> files in the cache, even deletes them, because the cache is one file => one
>> ttf font, this resulted in ttf fonts being ignored the second time. So
>> these ttc files would be parsed each time.
>>
>> Tilman
>>
>>
>>
>>> BR
>>> Maruan
>>>
>>> Tilman
>>>>
>>>>
>>>> Let me know if you need any further input.
>>>>>
>>>>> Cheers
>>>>> Roberto
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
>
Re: Speedup Font Cache
Posted by Roberto Nibali <rn...@gmail.com>.
Hi guys
Well, a quick look revealed the following stats:
$ ttf=0; otf=0; ttc=0; while read line; do shopt -s nocasematch; case
"${line##*.}" in ttf) let ttf+=1;; otf) let otf+=1;; ttc) let ttc+=1;;
esac; done < <(gfind /Library/Fonts /System/Library/Fonts ~/Library/Fonts
-type f \( -iname "*.ttf" -o -iname "*.ttc" -o -iname "*.otf" \)
2>/dev/null -printf "%f\n") && printf "ttf=%s otf=%s ttc=%s\n" "$ttf"
"$otf" "$ttc"
ttf=296 otf=63 ttc=88
So, not that many fonts that ought to be parsed by pdfbox. Since I
currently cannot verify an older version of pdfbox svn, may I ask what
could cause such a change? I have certainly installed new patches and
software to my MacOSX 10.9.
Cheers
Roberto
On Wed, Oct 21, 2015 at 7:24 PM, Tilman Hausherr <TH...@t-online.de>
wrote:
> Am 21.10.2015 um 18:43 schrieb Maruan Sahyoun:
>
>> Hi,
>>
>> Am 21.10.2015 um 18:40 schrieb Tilman Hausherr <TH...@t-online.de>:
>>>
>>> Am 21.10.2015 um 14:10 schrieb Roberto Nibali:
>>>
>>>> Hi John
>>>>
>>>> On Wed, Oct 21, 2015 at 12:35 AM, John Hewson <jo...@jahewson.com>
>>>> wrote:
>>>>
>>>> Yes, I’m able to replicate that issue on Windows. It’s apparently
>>>>> related
>>>>> to administrator ownership of that registry key’s parent node. Looks
>>>>> like
>>>>> it’ll be necessary to log in as admin and create that key with user
>>>>> access.
>>>>> I guess that’s far from ideal?
>>>>>
>>>>>
>>>>> The whole issue also happens on MacOSX. When you introduce this on-disk
>>>> cache a couple of months back, it worked fine, however one of the recent
>>>> changes to SVN must have wrecked the initially intended functionality.
>>>> Not
>>>> only is the font caching setup 5-10 times as long as it used to be, it
>>>> also
>>>> does not seem to persist it anymore. Version used:
>>>>
>>>> $ svn info | grep -i changed
>>>> Last Changed Author: tilman
>>>> Last Changed Rev: 1709647
>>>> Last Changed Date: 2015-10-20 19:04:02 +0200 (Tue, 20 Oct 2015)
>>>>
>>>> Running my test tool indicates:
>>>>
>>>> Oct 21, 2015 2:08:29 PM
>>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider loadCache
>>>> WARNING: New fonts found, font cache will be re-built
>>>> Oct 21, 2015 2:08:29 PM
>>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider <init>
>>>> WARNING: Building font cache, this may take a while
>>>> Oct 21, 2015 2:08:39 PM
>>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider saveCache
>>>> WARNING: Finished building font cache, found 654 fonts
>>>> [INFO, ctx=./ccalt.pdf]: Opening Source ./ccalt.pdf
>>>> [INFO, ctx=./ccalt.pdf]: Opening Template ./cctemp.pdf
>>>> [INFO, ctx=./ccalt.pdf]: Writing Output ./ccmig.pdf
>>>> [INFO, ctx=./ccalt.pdf]: Completed in 15037.02ms
>>>>
>>>> This used to be anything between 1200ms and 2300ms and once it was
>>>> persisted onto disk, it was rather fast in subsequent calls.
>>>> Unfortunately,
>>>> SVN does not provide the handy tool of "git bisect" to quickly find out
>>>> which change actually caused this regression.
>>>>
>>> There were only 4 changes since then, so it might be worth a try to just
>>> revert that file.
>>>
>>> (I can't help; for me, it has always been slow.)
>>>
>>> Could it be that 1) you installed new stuff on your computer, 2) that
>>> MacOS has many of its fonts in .ttc files? In Windows there are only 10.
>>>
>> on my OS X I have 92 ttc files (out of 384) :-)
>>
>
> Oh. I forgot to mention why I asked that. My last change ignores ttc files
> in the cache, even deletes them, because the cache is one file => one ttf
> font, this resulted in ttf fonts being ignored the second time. So these
> ttc files would be parsed each time.
>
> Tilman
>
>
>
>> BR
>> Maruan
>>
>> Tilman
>>>
>>>
>>> Let me know if you need any further input.
>>>>
>>>> Cheers
>>>> Roberto
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
Re: Speedup Font Cache
Posted by Tilman Hausherr <TH...@t-online.de>.
Am 21.10.2015 um 18:43 schrieb Maruan Sahyoun:
> Hi,
>
>> Am 21.10.2015 um 18:40 schrieb Tilman Hausherr <TH...@t-online.de>:
>>
>> Am 21.10.2015 um 14:10 schrieb Roberto Nibali:
>>> Hi John
>>>
>>> On Wed, Oct 21, 2015 at 12:35 AM, John Hewson <jo...@jahewson.com> wrote:
>>>
>>>> Yes, I’m able to replicate that issue on Windows. It’s apparently related
>>>> to administrator ownership of that registry key’s parent node. Looks like
>>>> it’ll be necessary to log in as admin and create that key with user access.
>>>> I guess that’s far from ideal?
>>>>
>>>>
>>> The whole issue also happens on MacOSX. When you introduce this on-disk
>>> cache a couple of months back, it worked fine, however one of the recent
>>> changes to SVN must have wrecked the initially intended functionality. Not
>>> only is the font caching setup 5-10 times as long as it used to be, it also
>>> does not seem to persist it anymore. Version used:
>>>
>>> $ svn info | grep -i changed
>>> Last Changed Author: tilman
>>> Last Changed Rev: 1709647
>>> Last Changed Date: 2015-10-20 19:04:02 +0200 (Tue, 20 Oct 2015)
>>>
>>> Running my test tool indicates:
>>>
>>> Oct 21, 2015 2:08:29 PM
>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider loadCache
>>> WARNING: New fonts found, font cache will be re-built
>>> Oct 21, 2015 2:08:29 PM
>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider <init>
>>> WARNING: Building font cache, this may take a while
>>> Oct 21, 2015 2:08:39 PM
>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider saveCache
>>> WARNING: Finished building font cache, found 654 fonts
>>> [INFO, ctx=./ccalt.pdf]: Opening Source ./ccalt.pdf
>>> [INFO, ctx=./ccalt.pdf]: Opening Template ./cctemp.pdf
>>> [INFO, ctx=./ccalt.pdf]: Writing Output ./ccmig.pdf
>>> [INFO, ctx=./ccalt.pdf]: Completed in 15037.02ms
>>>
>>> This used to be anything between 1200ms and 2300ms and once it was
>>> persisted onto disk, it was rather fast in subsequent calls. Unfortunately,
>>> SVN does not provide the handy tool of "git bisect" to quickly find out
>>> which change actually caused this regression.
>> There were only 4 changes since then, so it might be worth a try to just revert that file.
>>
>> (I can't help; for me, it has always been slow.)
>>
>> Could it be that 1) you installed new stuff on your computer, 2) that MacOS has many of its fonts in .ttc files? In Windows there are only 10.
> on my OS X I have 92 ttc files (out of 384) :-)
Oh. I forgot to mention why I asked that. My last change ignores ttc
files in the cache, even deletes them, because the cache is one file =>
one ttf font, this resulted in ttf fonts being ignored the second time.
So these ttc files would be parsed each time.
Tilman
>
> BR
> Maruan
>
>> Tilman
>>
>>
>>> Let me know if you need any further input.
>>>
>>> Cheers
>>> Roberto
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Speedup Font Cache
Posted by John Hewson <jo...@jahewson.com>.
> On 21 Oct 2015, at 09:43, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
>
> Hi,
>
>> Am 21.10.2015 um 18:40 schrieb Tilman Hausherr <TH...@t-online.de>:
>>
>> Am 21.10.2015 um 14:10 schrieb Roberto Nibali:
>>> Hi John
>>>
>>> On Wed, Oct 21, 2015 at 12:35 AM, John Hewson <jo...@jahewson.com> wrote:
>>>
>>>> Yes, I’m able to replicate that issue on Windows. It’s apparently related
>>>> to administrator ownership of that registry key’s parent node. Looks like
>>>> it’ll be necessary to log in as admin and create that key with user access.
>>>> I guess that’s far from ideal?
>>>>
>>>>
>>> The whole issue also happens on MacOSX. When you introduce this on-disk
>>> cache a couple of months back, it worked fine, however one of the recent
>>> changes to SVN must have wrecked the initially intended functionality. Not
>>> only is the font caching setup 5-10 times as long as it used to be, it also
>>> does not seem to persist it anymore. Version used:
>>>
>>> $ svn info | grep -i changed
>>> Last Changed Author: tilman
>>> Last Changed Rev: 1709647
>>> Last Changed Date: 2015-10-20 19:04:02 +0200 (Tue, 20 Oct 2015)
>>>
>>> Running my test tool indicates:
>>>
>>> Oct 21, 2015 2:08:29 PM
>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider loadCache
>>> WARNING: New fonts found, font cache will be re-built
>>> Oct 21, 2015 2:08:29 PM
>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider <init>
>>> WARNING: Building font cache, this may take a while
>>> Oct 21, 2015 2:08:39 PM
>>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider saveCache
>>> WARNING: Finished building font cache, found 654 fonts
>>> [INFO, ctx=./ccalt.pdf]: Opening Source ./ccalt.pdf
>>> [INFO, ctx=./ccalt.pdf]: Opening Template ./cctemp.pdf
>>> [INFO, ctx=./ccalt.pdf]: Writing Output ./ccmig.pdf
>>> [INFO, ctx=./ccalt.pdf]: Completed in 15037.02ms
>>>
>>> This used to be anything between 1200ms and 2300ms and once it was
>>> persisted onto disk, it was rather fast in subsequent calls. Unfortunately,
>>> SVN does not provide the handy tool of "git bisect" to quickly find out
>>> which change actually caused this regression.
>>
>> There were only 4 changes since then, so it might be worth a try to just revert that file.
>>
>> (I can't help; for me, it has always been slow.)
>>
>> Could it be that 1) you installed new stuff on your computer, 2) that MacOS has many of its fonts in .ttc files? In Windows there are only 10.
>
> on my OS X I have 92 ttc files (out of 384) :-)
Yep, OS X uses ttc much more heavily than Windows and some of those are big Asian fonts which PDFBox parses relatively slowly.
— John
> BR
> Maruan
>
>>
>> Tilman
>>
>>
>>>
>>> Let me know if you need any further input.
>>>
>>> Cheers
>>> Roberto
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org <ma...@pdfbox.apache.org>
> For additional commands, e-mail: users-help@pdfbox.apache.org <ma...@pdfbox.apache.org>
Re: Speedup Font Cache
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
> Am 21.10.2015 um 18:40 schrieb Tilman Hausherr <TH...@t-online.de>:
>
> Am 21.10.2015 um 14:10 schrieb Roberto Nibali:
>> Hi John
>>
>> On Wed, Oct 21, 2015 at 12:35 AM, John Hewson <jo...@jahewson.com> wrote:
>>
>>> Yes, I’m able to replicate that issue on Windows. It’s apparently related
>>> to administrator ownership of that registry key’s parent node. Looks like
>>> it’ll be necessary to log in as admin and create that key with user access.
>>> I guess that’s far from ideal?
>>>
>>>
>> The whole issue also happens on MacOSX. When you introduce this on-disk
>> cache a couple of months back, it worked fine, however one of the recent
>> changes to SVN must have wrecked the initially intended functionality. Not
>> only is the font caching setup 5-10 times as long as it used to be, it also
>> does not seem to persist it anymore. Version used:
>>
>> $ svn info | grep -i changed
>> Last Changed Author: tilman
>> Last Changed Rev: 1709647
>> Last Changed Date: 2015-10-20 19:04:02 +0200 (Tue, 20 Oct 2015)
>>
>> Running my test tool indicates:
>>
>> Oct 21, 2015 2:08:29 PM
>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider loadCache
>> WARNING: New fonts found, font cache will be re-built
>> Oct 21, 2015 2:08:29 PM
>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider <init>
>> WARNING: Building font cache, this may take a while
>> Oct 21, 2015 2:08:39 PM
>> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider saveCache
>> WARNING: Finished building font cache, found 654 fonts
>> [INFO, ctx=./ccalt.pdf]: Opening Source ./ccalt.pdf
>> [INFO, ctx=./ccalt.pdf]: Opening Template ./cctemp.pdf
>> [INFO, ctx=./ccalt.pdf]: Writing Output ./ccmig.pdf
>> [INFO, ctx=./ccalt.pdf]: Completed in 15037.02ms
>>
>> This used to be anything between 1200ms and 2300ms and once it was
>> persisted onto disk, it was rather fast in subsequent calls. Unfortunately,
>> SVN does not provide the handy tool of "git bisect" to quickly find out
>> which change actually caused this regression.
>
> There were only 4 changes since then, so it might be worth a try to just revert that file.
>
> (I can't help; for me, it has always been slow.)
>
> Could it be that 1) you installed new stuff on your computer, 2) that MacOS has many of its fonts in .ttc files? In Windows there are only 10.
on my OS X I have 92 ttc files (out of 384) :-)
BR
Maruan
>
> Tilman
>
>
>>
>> Let me know if you need any further input.
>>
>> Cheers
>> Roberto
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Speedup Font Cache
Posted by Tilman Hausherr <TH...@t-online.de>.
Am 21.10.2015 um 14:10 schrieb Roberto Nibali:
> Hi John
>
> On Wed, Oct 21, 2015 at 12:35 AM, John Hewson <jo...@jahewson.com> wrote:
>
>> Yes, I’m able to replicate that issue on Windows. It’s apparently related
>> to administrator ownership of that registry key’s parent node. Looks like
>> it’ll be necessary to log in as admin and create that key with user access.
>> I guess that’s far from ideal?
>>
>>
> The whole issue also happens on MacOSX. When you introduce this on-disk
> cache a couple of months back, it worked fine, however one of the recent
> changes to SVN must have wrecked the initially intended functionality. Not
> only is the font caching setup 5-10 times as long as it used to be, it also
> does not seem to persist it anymore. Version used:
>
> $ svn info | grep -i changed
> Last Changed Author: tilman
> Last Changed Rev: 1709647
> Last Changed Date: 2015-10-20 19:04:02 +0200 (Tue, 20 Oct 2015)
>
> Running my test tool indicates:
>
> Oct 21, 2015 2:08:29 PM
> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider loadCache
> WARNING: New fonts found, font cache will be re-built
> Oct 21, 2015 2:08:29 PM
> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider <init>
> WARNING: Building font cache, this may take a while
> Oct 21, 2015 2:08:39 PM
> org.apache.pdfbox.pdmodel.font.FileSystemFontProvider saveCache
> WARNING: Finished building font cache, found 654 fonts
> [INFO, ctx=./ccalt.pdf]: Opening Source ./ccalt.pdf
> [INFO, ctx=./ccalt.pdf]: Opening Template ./cctemp.pdf
> [INFO, ctx=./ccalt.pdf]: Writing Output ./ccmig.pdf
> [INFO, ctx=./ccalt.pdf]: Completed in 15037.02ms
>
> This used to be anything between 1200ms and 2300ms and once it was
> persisted onto disk, it was rather fast in subsequent calls. Unfortunately,
> SVN does not provide the handy tool of "git bisect" to quickly find out
> which change actually caused this regression.
There were only 4 changes since then, so it might be worth a try to just
revert that file.
(I can't help; for me, it has always been slow.)
Could it be that 1) you installed new stuff on your computer, 2) that
MacOS has many of its fonts in .ttc files? In Windows there are only 10.
Tilman
>
> Let me know if you need any further input.
>
> Cheers
> Roberto
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Speedup Font Cache
Posted by Roberto Nibali <rn...@gmail.com>.
Hi John
On Wed, Oct 21, 2015 at 12:35 AM, John Hewson <jo...@jahewson.com> wrote:
> Yes, I’m able to replicate that issue on Windows. It’s apparently related
> to administrator ownership of that registry key’s parent node. Looks like
> it’ll be necessary to log in as admin and create that key with user access.
> I guess that’s far from ideal?
>
>
The whole issue also happens on MacOSX. When you introduce this on-disk
cache a couple of months back, it worked fine, however one of the recent
changes to SVN must have wrecked the initially intended functionality. Not
only is the font caching setup 5-10 times as long as it used to be, it also
does not seem to persist it anymore. Version used:
$ svn info | grep -i changed
Last Changed Author: tilman
Last Changed Rev: 1709647
Last Changed Date: 2015-10-20 19:04:02 +0200 (Tue, 20 Oct 2015)
Running my test tool indicates:
Oct 21, 2015 2:08:29 PM
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider loadCache
WARNING: New fonts found, font cache will be re-built
Oct 21, 2015 2:08:29 PM
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider <init>
WARNING: Building font cache, this may take a while
Oct 21, 2015 2:08:39 PM
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider saveCache
WARNING: Finished building font cache, found 654 fonts
[INFO, ctx=./ccalt.pdf]: Opening Source ./ccalt.pdf
[INFO, ctx=./ccalt.pdf]: Opening Template ./cctemp.pdf
[INFO, ctx=./ccalt.pdf]: Writing Output ./ccmig.pdf
[INFO, ctx=./ccalt.pdf]: Completed in 15037.02ms
This used to be anything between 1200ms and 2300ms and once it was
persisted onto disk, it was rather fast in subsequent calls. Unfortunately,
SVN does not provide the handy tool of "git bisect" to quickly find out
which change actually caused this regression.
Let me know if you need any further input.
Cheers
Roberto
Re: Speedup Font Cache
Posted by John Hewson <jo...@jahewson.com>.
Yes, I’m able to replicate that issue on Windows. It’s apparently related to administrator ownership of that registry key’s parent node. Looks like it’ll be necessary to log in as admin and create that key with user access. I guess that’s far from ideal?
— John
> On 20 Oct 2015, at 07:41, Pascal Burkhardt <pa...@mail.de> wrote:
>
> Hi John,
>
> thanks for reply.
>
> It sounds like there is a problem to read from the saved file, because this log-message is previous: "java.util.prefs.WindowsPreferences <init> - WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5."
>
> I run the app from eclipse during development.
>
> Thanks so far,
> Pascal
>
>
>
> Am 20.10.2015 um 16:15 schrieb John Hewson:
>> Hi, Pascal,
>>
>> There’s no way to disable the cache as PDFBox needs to examine each font on the system before it can perform font substitution. However, the cache should be saved to disk but it if you’re seeing that message each time you’re running PDFBox then it sounds like either the cache write has failed or you’re running in an ephemeral environment, such as a Docker container. Are either of these likely to be true?
>>
>> Just to provide a little more detail: the cache contains metadata for every font on the system and is persisted to disk precisely because it’s too slow for PDFBox to examine every system font every time its initialised. If the cache is not persisted, you pay that full time cost each time you use PDFBox.
>>
>> — John
>>
>>> On 20 Oct 2015, at 06:49, Pascal Burkhardt <pa...@mail.de> wrote:
>>>
>>> Hi,
>>>
>>> i upgrade from 1.8.10 to 2.0.0-RC1.
>>>
>>> When i start to create a pdf with pdfbox 2.0.0-RC1 now the log-message appears: "WARNING: Building font cache, this may take a while". To Create a Font Cache it takes quite a long time...(2-3sec.). To create a simple pdf-page this is quite long...
>>>
>>> Is there a way to disable the font cache or to speed up this process? Can i load the font cache on startup of my application, so that when a user requests a pdf it renders quickly (and do not have to init the cache?) or is there another possibility?
>>>
>>> Thanks,
>>> Pascal
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
Re: Speedup Font Cache
Posted by Pascal Burkhardt <pa...@mail.de>.
Hi John,
thanks for reply.
It sounds like there is a problem to read from the saved file, because
this log-message is previous: "java.util.prefs.WindowsPreferences <init>
- WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs
at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5."
I run the app from eclipse during development.
Thanks so far,
Pascal
Am 20.10.2015 um 16:15 schrieb John Hewson:
> Hi, Pascal,
>
> There’s no way to disable the cache as PDFBox needs to examine each font on the system before it can perform font substitution. However, the cache should be saved to disk but it if you’re seeing that message each time you’re running PDFBox then it sounds like either the cache write has failed or you’re running in an ephemeral environment, such as a Docker container. Are either of these likely to be true?
>
> Just to provide a little more detail: the cache contains metadata for every font on the system and is persisted to disk precisely because it’s too slow for PDFBox to examine every system font every time its initialised. If the cache is not persisted, you pay that full time cost each time you use PDFBox.
>
> — John
>
>> On 20 Oct 2015, at 06:49, Pascal Burkhardt <pa...@mail.de> wrote:
>>
>> Hi,
>>
>> i upgrade from 1.8.10 to 2.0.0-RC1.
>>
>> When i start to create a pdf with pdfbox 2.0.0-RC1 now the log-message appears: "WARNING: Building font cache, this may take a while". To Create a Font Cache it takes quite a long time...(2-3sec.). To create a simple pdf-page this is quite long...
>>
>> Is there a way to disable the font cache or to speed up this process? Can i load the font cache on startup of my application, so that when a user requests a pdf it renders quickly (and do not have to init the cache?) or is there another possibility?
>>
>> Thanks,
>> Pascal
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Speedup Font Cache
Posted by John Hewson <jo...@jahewson.com>.
Hi, Pascal,
There’s no way to disable the cache as PDFBox needs to examine each font on the system before it can perform font substitution. However, the cache should be saved to disk but it if you’re seeing that message each time you’re running PDFBox then it sounds like either the cache write has failed or you’re running in an ephemeral environment, such as a Docker container. Are either of these likely to be true?
Just to provide a little more detail: the cache contains metadata for every font on the system and is persisted to disk precisely because it’s too slow for PDFBox to examine every system font every time its initialised. If the cache is not persisted, you pay that full time cost each time you use PDFBox.
— John
> On 20 Oct 2015, at 06:49, Pascal Burkhardt <pa...@mail.de> wrote:
>
> Hi,
>
> i upgrade from 1.8.10 to 2.0.0-RC1.
>
> When i start to create a pdf with pdfbox 2.0.0-RC1 now the log-message appears: "WARNING: Building font cache, this may take a while". To Create a Font Cache it takes quite a long time...(2-3sec.). To create a simple pdf-page this is quite long...
>
> Is there a way to disable the font cache or to speed up this process? Can i load the font cache on startup of my application, so that when a user requests a pdf it renders quickly (and do not have to init the cache?) or is there another possibility?
>
> Thanks,
> Pascal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>