Apache OpenOffice (AOO) Bugzilla – Issue 18620
RMB context menu extremely slow when lots of fonts are installed
Last modified: 2007-04-05 10:13:59 UTC
Today one can find an astonishing amount of free fonts on the InterNet (e.g. at www.1001freefonts.com and elsewhere), so I tried what happenes if you download a thousand and install them all in OpenOffice (using spadmin). The good news is that OO 1.1rc2 (unlike 1.0*) generally behaves well when that much fonts are installed, everything works fine except for one thing: When you press the right mouse button to get a context menu (e.g. in sw), it will take ridiculously long before the menu is rendered, meanwhile, the application doesn't react on anything. The reason for this is simply that part of the context menu is a list of available fonts to choose from, and while this isn't a sane way for choosing a font when you have thousands of them anyway, each time you press RMB an enormous time is spent on rendering the menu. I propose not to fill this context menu with more than about a hundred font names - the other methods available for choosing fonts are much more comfortable with many fonts anyway. Will attach a patch below.
Created attachment 8720 [details] very simple patch to keep OO RMB context menu usable with many fonts installed
SBA->CD: As discussed with JA (and MBA)... In your area and subject to undergo changes in the near future anyway. The scenario "install a thousand" keeps me from regarding this as a "performance defect" yet. On the other hand, Performance is an important issue (for further info, talk to MHU...) Reassigned to Carsten.
Independent from any major redesigns planned for OO 2.x - what speaks against applying my extremely tiny and simple patch to at least keep OO 1.x usable in "many-fonts-installed" scenarios meanwhile?
CD->CJ: Please take over and decide if this is a valid way to go.
If more Font list is longer than the destop window is high, OO.o shall provide a "More Fonts..." entry in the Font menu instead of scrolling the content. The illustration below shows an example: Fonts > More Fonts... > More Fonts... > etc. ------------- ------------- Font 1 Font n+1 Font 2 Font n+2 Font 3 Font n+3 ... ... Font n Font n+x This should reduce our perf issue because only the number of fonts which fit into the menu has to be read at a time.
Created attachment 17456 [details] Example of the menu
This is more a defect
.
mba: retargetted due to heavy workload
Seems to be dup of http://www.openoffice.org/issues/show_bug.cgi?id=61775. Closing this one because 61775 has got votes and dups against it already. Please vote for 61775. *** This issue has been marked as a duplicate of 61775 ***
Closing.