@durian:
please add information concering your OS, Platform.

Sorry, I thought the bug reporting system grabbed some of the automatically. 
 
FreeBSD-6.x, x.org - 6.9, KDE - 3.5.1, 512 MB memory, AMD Athlon(tm) XP 2800+ 
 
OOo, X and KDE are all built from the ports collection. 
 
Those are the main items I think might be relevant. 
 
mike 

.

I ran ktrace/kdump over OOo while it was starting and noticed that OOo is 
reading fonts that I have not configured as part of my FontPath 
in /etc/X11/xorg.conf.  In particular, OOo is reading fonts from every 
directory it finds under /usr/X11R6/lib/X11/fonts, even if some of those 
directories are not configured into the font path. 
 
For the sake of argument, I'm going to use 'find dir -type f -print | wc -l' 
to count fonts in a directory.  This isn't correct because there are other 
files in the directories too, include '.' and '..', but it should be close 
enough. 
 
I've got about 8800 fonts in my font path, but there are 14200 fonts in 
sub-directories off of /usr/X11R6/lib/X11/fonts.  The significant portion of 
my OOo start-up time is spent reading all these fonts I don't have configured. 
 
No in all fairness, I'm not positive something else (KDE) hasn't expanded my 
font path.  'xset' only seems to allow you to change the font path, not 
display it.  So maybe OOo is doing the right thing and is only reading fonts 
specified in the FontPath and some other entity is bloating the FontPath. 
 
At any rate, this data should help an OOo expert check to see if OOo is 
erroneously reading fonts outside the FontPath or not. 
 
mike 

reassign issue to pl.

OOo is supposed to  read those fonts once (on first startup of a user). After
that it should only check the directories to check if they were changed (in
which case it will read the fonts ion the changed directories again). Can you
confirm that the actual font files are read on every startup ?

If OOo is already running, then a new copy starts quickly.  If no other 
copy is running it is taking 1 minute 40 to launch.  My natural inclination 
is to close applications I am not using, so I see this delay often unless I 
manage to catch myself and leave OOo running. 
 
pl, I appologize if I have misunderstood your response, but it looks like 
you are saying OOo's behavior of ignoring the font path and 
loading every font it can find is a designed behavior.  This is not meant 
to be a personal attack, but I think this behavior (if I understand it 
correctly, and maybe I don't) is not ideal for the following reasons: 
 
1) Principle of Least Astonishment (POLA).  The X windowing system has a 
well defined method for selecting which fonts should be used: the font path. 
This can be configured prior to starting X or after it has started using 
xset(1).  That OOo does not use this method creates much astonishment. 
 
2) OOo's method of scanning for files directly does not work if X is 
configured to use a font server.  This means there is not a single method 
for adding fonts when OOo is running under X (either add fonts to a 
directory under /usr/X11R6/lib/X11/fonts or use spadmin to add fonts). 
 
3) If OOo must go its own road, there should at least be an easy method of 
overriding the default search method so unwanted directories can be excluded 
and other directories added.  I just checked the spadmin (which did take a 
long time to load even with another OOo application already running) and 
it only lists about 20 fonts - much fewer than the number OOo has scanned. 
Since the fonts aren't listed, I can't use spadmin to remove them. 
 
 
I must have an unusual usage pattern, as I haven't seen others complaining 
about font related start up time.  Perhaps most people only have a minimal 
set of fonts installed under /usr/X11R6/lib/X11/fonts and don't close OOo 
when they are done using it.  However, I've got a feeling most people still 
only commonly use a small subset of their installed fonts.  Even with my 
excessive font set (even if we ignore the thousands of fonts OOo scans that 
are not in my font path) I regularly use only a small number of them. 
The others are "on tap" for their rare usage. 
 
If we assume most people have more fonts installed than they normally use, 
might it not make more sense to postpone loading every font until they 
are actually needed?  Instead of taking a big hit at start-up time, couldn't 
OOo take more, smaller hits later?  It might not be as efficient overall, 
but it might give the impression that OOo is more responsive. 
 
mike 

You indeed misunderstood, what i tried to say is that OOo looks in every
directory of the fontpath once, then on subsequent startups does not. BTW: the X
fontpath is not of very high importance anymore since the RENDER extension is
almost used exclusively by applications to render text. Since version 2.0 OOo
does use fontconfig to find its fonts like do e.g. all KDE applications.

However since you mentioned the X font path issue i have now an idea what may be
your problem: could it be that your fontconfig installation cache data is out of
date ? This would cause fontconfig to rebuilt the fontconfig every time OOo
starts up and queries the font list from fontconfig. If this were to be the
case, then one run of "fc-cache -f" as root (as write permission to thge system
font directories is required) might solve your problem.

That helps.  I did not realize fontconfig had completely superceded the X 
font path. 
 
I did as you recommends and reran fc-cache.  I also edited my local 
fonts.config file and made use of the rejectfont element.  This has 
reduced my start-up time from 1:40 to 0:30.  Well, 0:30 the first time 
I measured it.  On repeated measurements (after exiting OOo completely), 
it has now dropped to 0:07.  Is this due to memory and file system caching, 
or is OOo doing something? 
 
This is much more tolerable. 
 
mike 

Starting the first time OOo fills its own caches (we cache some things about
fonts that fontconfig does not), which is why OOo accesses all fonts it finds
via fontconfig, the X font path and in its own private directory on the first
startup - of course this prolongs the first startup quite some. Then on
subsequent startups this procedure can be omitted if the OOo's cache is up to
date. The cache is considered up  to date if the font directories have not been
modified since the last cache update.

So it would seem that everything works as designed; unless there is another
problem we could close this issue.

Regarding startup times: the startup times are bad, yes. Not all of that (unless
one has thousands of fonts like you :-) ) is due to font discovery, second
startup also profits tremendously from file system caching in that the whole
libraries are already in memory and need not be read from disk again.

Alas, startup time cannot be fixed easily since there is not one big issue that
hinders us; there is symbol resolution involved, too much code is run on
startup, there are too many libraries, ... . Sadly there is no silver bullet to
make OOo's startup snappy, we can only improve it a bit at a time. This is an
ongoing effort.

I ran another ktrace/kdump today after a reboot - so I know the file system 
cache doesn't contain the font files.  Start up was pretty slow again 
(I'm sure the ktrace was adding some over-head). 
 
I'm a little confused on what "first startup" means.  My typical usage 
pattern is to run OOo when I need it (to view a Word email attachment 
for example) and then exit when I'm done.  Does this mean every time 
I run OOo, it is a "first startup"?  Or does running OOo only count as 
a first startup if the font cache is out of date? 
 
My kdump shows the first 5-6 seconds are spent loading shared libraries, 
java stuff and reading the font cache files.  Then it spends 55 seconds or 
so reading every font file (this has sped up because of the rejectfont 
element I added to my fonts.conf file). 
 
If "first startup" is something that happens when OOo is run without another 
OOo image in memory, then I guess the behavior is as intended - but 
very painful.  In that case, I guess my report is arguably not a bug, but 
rather a change request. 
 
Perhaps OOo's additional font cache information can be stored on disk?  That 
way the font reading penalty would only happen when the font config cache 
changes, not on every OOo start up?  Or, as I mention earlier, maybe the font 
caching can be done on demand, instead of at start-up? 
 
For the sake of research, I could send you the largest font directory 
I have configured.  It contains 3300 true-type fonts and is about 350MB 
worth of data.  You'd need to point me to an FTP server though, as emailing 
350MB isn't very practical. 
 
mike 

"First startup" means first starup for a user. At the same time you get the
dialogue that shows the license and offers to enter user data. Font cache
information is stored on disk - wouldn't make much sense having a font cache
else. The file is <user installation>/user/psprint/pspfontcache where <user
installation> is per default a directory beneath your home directory (e.g.
$HOME/.ooo-2.0).

But if fc-cache -f does not work permanently, then i fear this is rather a
fontconfig issue than a OOo issue. You can verify that by attaching gdb to OOo
during those 55 seconds an repeatedly stop it an get a stacktrace to see what it
does. If it does indeed spend that time inside libfontconfig, then there is not
much that i can do.

Currently i'm installing a large font collection (and isn't the KDE font
installer a dumb tool when it comes to installing many fonts at once :-(, 7
files out of 2200 in half an hour). Then i will see if i can reproduce the problem.

I think we're on to something here.  In fact, I think this problem is 
related to another bug I've filed: 49251. 
 
The pspfontcache file isn't getting saved.  OOo goes through the process 
of creating it, but it can't save it and thus tries to recreate it each 
time OOo is run. 
 
pspfontcache isn't saved because ~/.openoffice.org2/user/psprint 
directory doesn't exist. 
 
I have tried removing .openoffice.org2 such that it would get recreated 
with the proper psprint subdirectory (I tried doing this to fix the 49251 
bug), but for some reason it won't create psprint. 
 
I have just created the psprint directory by hand.  I'm going to see if 
the font cache gets created.  That did it.  The font cache gets created 
and OOo now starts much faster. 
 
Maybe OOo needs to check for a complete user directory structure and 
create missing directories if it determines any are missing? 
 
Anyway, it looks like this PR can be closed. 
 
Thanks, 
mike 

That's not exactly a duplicate, though it has the same reason. If you don't mind
i'll keep this one, also, and fix both for 2.0.3. I wonder though, why there
would be no psprint directory in your user directory.

Let me know if you want me to run any tests.  My <user installation>/user 
directory contains (including the psprint directory I made by hand): 
 
autocorr        config          gallery         store 
autotext        database        psprint         uno_packages 
basic           fonts           registry        wordbook 
 
I don't know what is supposed to be there, so I can't tell if anything else 
is missing. 

After only 3 days kfontinstaller actually finished addinbg 2000 fonts (a really
bad idea running fc-cache after each and every font if you ask me). I did a
clean install, removed all traces of user directories and had OOo start up.
First startup was slow (as expected for there was no pspfontcache yet). After
first startup there was a new $HOME/.openoffice.org2/user/psprint/pspfontcache
in my newly created user directory and consequently the second startup was
around 5 seconds or so.

Now i don't think this would be a FreeBSD issue (should work the same on all
Unix flavours), but there must be something different between your and my
installation. For the record i used a flat 680m157 install and did the same with
a flat OOo2.0.1.

Do you have a test you would like me to run? 
Would telling OOo to copy over user information from a 1.1.5 install 
have any impact on psprint getting created? 
 
mike 

Good question. I'll try.

No, that didn't reproduce the problem either. I'll have to try something else.

Perhaps this will be fixed with issue 49251 after all; at least when CWS vcl56
is merged in to the master then the <user>/user/psprint directory will be tried
to create.

target

adjusting target due to limited resources

Reset assignee on issues not touched by assignee in more than 2000 days.

Configuration (In reply to durian from comment #2)
> FreeBSD-6.x, x.org - 6.9, KDE - 3.5.1, 512 MB memory, AMD Athlon(tm) XP
> 2800+ 
This configuration is obsolete now.
But I wonder why install 5,000 fonts on a system.