Apache OpenOffice (AOO) Bugzilla – Issue 27259
Opening document with formulas is extremely slow in some cases
Last modified: 2005-02-04 19:33:42 UTC
Opening the attached document on an Athlon XP 1800 machine with 512mb of RAM running Fedora Core 1 freezes the openoffice UI for several minutes, and when the document does open attempts to scroll again cause freezes. Strace shows many calls to read/write/mmap, and seems to be creating many temporary files: open("/usr/java/j2sdk1.4.2_04/jre/lib/fonts/LucidaTypewriterBold.ttf", O_RDONLY) = 28 open("/tmp/svp29.tmp", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 28 open("/tmp/svp29.tmp/svp6l.tmp", O_RDWR) = 28 open("/tmp/svp29.tmp/svp6l.tmp", O_RDWR) = 28 open("/tmp/svp29.tmp", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 29 open("/tmp/svp29.tmp/svp6m.tmp", O_RDWR) = 29 open("/tmp/svp29.tmp/svp6m.tmp", O_RDWR) = 29 open("/tmp/svp29.tmp", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 28 open("/tmp/svp29.tmp/svp89.tmp", O_RDWR) = 28 open("/tmp/svp29.tmp/svp89.tmp", O_RDWR) = 28
Created attachment 14226 [details] Openoffice writer document with many equations, created under previous OpenOffice release.
works fine here with 1.1.1rc3 on SuSE 9.0
>> open("/usr/java/j2sdk1.4.2_04/jre/lib/fonts/LucidaTypewriterBold.ttf", >> O_RDONLY) The path looks very suspicous, because normally one doesn't install font files into the java directory. Did you install it there or is this maybe an unhappy result of OOo-setup?
The fonts are actually there. rpm -q -l j2sdk finds them in the java rpm, so I assume they came from sun. The java install is j2sdk-1_4_2_04-linux-i586.rpm downloaded from java.sun.com in the last few weeks. I've just tried reinstalling OO and telling it not to use a JRE, but it doesn't seem to change the behaviour.
hi mstevens, thanks for using and supporting OpenOffice.org... Opening your document on Solaris and windows went fine...
Confirming.
HI->FME: Include Math objects.
SBA+US: ...but in this case, HDU is the winner. On my LINUX machine (JDS), we found this with gdb (using Build srx645_m38-1_01.8770): in OutputDevice::GetTextBoundRect(Rectangle&, String const&, unsigned short, unsigned short, unsigned short) const () from /[PATH]./program/libvcl645li.so Note: Target set to OOo 1.1.3 as it's unclear if the effort and risk fits the timeline for 1.1.2.
*** Issue 21304 has been marked as a duplicate of this issue. ***
*** Issue 26003 has been marked as a duplicate of this issue. ***
SBA: This one is younger but (hopefully) almost "nailed down". Please take the cases of issue 21304 and issue 26003 into account. I adjusted the title because the findings seem to have platform dependencies.
*** Issue 28015 has been marked as a duplicate of this issue. ***
I debugged this issue on JDS and the problem is that - there are characters involved, that are not available in the selected font so glyph fallback is attempted - some of the fonts in the glyph fallback list are X11 fonts with a good coverage e.g. Dotum - especially on Western systems just "opening an X11 font" which contains many glyphs freezes the X11 server for a while because the X11 server waits for the font server, which renders all the glyphs even though this is not requested by the application - distributions targeted for Asian markets use a different X11 font server, which uses different heuristics which work much faster To confirm this can you please check that when you open the document and the system seems to hang that not the application soffice.bin is eating all the CPU but either the X server or the X font server? Another method of confirming this hypothesis is to open the "xfontsel" application and go through all the available font families. I'm quite sure on your system you will notice for some font families (especially east asian ones) the system seems to freeze for a couple of seconds. Other than that I think that one of the Win98 tasks issue 21304 and issue 26003 should be reopened, because the X11 font server freeze does not apply there.
Here is a link which quantifies the performance problem of the XServer when CJK fonts come into play: http://x-tt.sourceforge.jp/documentation.html This page also offers a solution for systems which show this problem.
Would it be a good idea to have an option in the "Tools/Options" dialog that allows the user to customize this?
I don't think making this customizable will help much. The much easier alternative is already there: Use a font that has the required glyphs. The remainder of the task is to reduce the glyph fallback to X11 fonts by using them only when non-X11 fonts have already be tried.
scheduled to 1.1.4.
Retargeting as agreed with SBA and US. Even with the suggested fix of delaying the use of X11 fonts for glyph fallback after all other directly accessible font files have been tried, the problem would still show up on systems with fonts insufficient to the text's requirements. Workarounds on the X11 server: use the xtt font module instead of the freetype module to avoid the "rastering a huge X11 font" induced delays.
As mentioned above the problem cannot completely be solved if we still want glyph fallback, because sometime only X11 fonts have the required glyphs. When a non-xtt module is used for X11 font support the extremely slow response is designed in... Though the general problem is unsolvable from the OOo perspective I put a fix into the CWS vcl29, which tries highest quality fonts first. Since X11 only fonts are being evaluated low quality they are only tried if the better font alternatives have been used up. So the problem does not disappear completely, but it will be triggered with a lower probability...
reopening for reassignment
reassigning
HDU->US: please verify in CWS vcl29 Testing hints: this is a little difficult to test... just make sure things don't get worse and that client side fornts are used for glyph fallback fonts are before the X11 fonts.
> just make sure things don't get worse and that client side fornts are used for glyph fallback > fonts are before the X11 fonts In fact I seem to have a problem with glyph fallback when CTL (hebrew in this case) is involved.
us->hdu: pls. contact me, so that we can have a look at the newly glyph fallback problem together. System is fedor core 3 - JDS is fine though. Btw. the performance has improved dramatically. Thx. for that.
Interesting aspect: the libvcl s (on tausch volume) you provided at our latest debugging seesion work fine for me. Only the cws does not. Buil problem on cws?
Well, the fix for the original problem is to reorder the fonts used for the glyph fallback feature. The fonts are now sorted to get "highest quality fonts first", pushed the font that was previously successful for that particular bugdoc ("LucidaTypewriter") out of the list of glyph fallback fonts. Increasing the number of slots in that list from 8 to 12 fixes the particular problem you are seeing. On the other hand the higher this number of slots is the worse is the worst case performance in the glyph fallback case... and the performance impact of this case triggered the original issue report...
HDU->US: please verify in the respin of CWS vcl29
Verified in respin of CWS vcl29.
Verified in MWS m77.