> > Now, there are two ways to resolve this bug: > > > > 1.) Quick'n dirty. Simply replace FT_LOAD_TARGET_LIGHT in > > vcl/source/glyphs/gcach_ftyp.cxx by FT_LOAD_TARGET_NORMAL or > > FT_LOAD_TARGET_LCD or FT_LOAD_TARGET_LCD_V (if recompiling wouldn't take > > >8h on Opteron 242, it would be easy to test which gives best results). > > Hmm. Can't you do it as you know what you expect to have? :) > You don't need to do a full rebuild for every change ;-) - you only have to > build once (assume the default or with one of the changes), and then just > can do: > > 1) cd <whatever>/vcl > 2) . ../Linux<whatever>.sh > 3) build > 4) copy the lib into your install > 5) *try* > 6) repeat from 2)
The problem is that the system I'm building on is in the institute and I'm presently writing my thesis at home and I'm refusing to use my home system for such a long compile time (my temperature controlled fans will begin to make too much noise) ;) Additionally the build system is ro-mounted nfs-diskless, the build itself is in a nfs sid-chroot - installation is only possible to local tmp-disk storage. Lets see how well openoffice behaves with this installation. I will be in the institute tomorrow, but I don't know yet, if I will have time to care about this. > > > 2.) Take the latest patch from > > http://qa.openoffice.org/issues/show_bug.cgi?id=64508 and adjust it, so > > that it applies to openoffice-2.0.4. > > From the point of the user wishes and user config probably the best, but > > its clearly not a simple replace patch and might be buggy. > > > > Which one do you prefer? > > Given the timeframe and the maybe-riskyness of i64508 I'd prefer 1.) Ok, before I wanted to spend further (in principle not available) spare time on any of those two possibilities, I first wanted to know which solution you prefer :) Cheers, Bernd -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg
