On 11/03/12 16:50, Thorsten Behrens wrote: > Michael Stahl wrote: >> like several previous incarnations of the same idea, it bootstraps >> an office, loads all documents in a directory and prints them to >> files. >> > Hehe, you rock - just, FWIW, there's this in the old build repo: > > > http://cgit.freedesktop.org/libreoffice/build/tree/bin/oodocdiff.sh?h=libreoffice-3-4 > > (seems it wasn't moved over to solenv/bin), > > which relies on the rather new-fangled batch-conversion / > batch-printing options of the office binary: > > --print-to-file [-printer-name printer_name] [--outdir output_dir] files > Batch print files to file. > If --outdir is not specified then current working dir is used as > output_dir. > Eg. --print-to-file *.doc > --print-to-file --printer-name nasty_lowres_printer --outdir > /home/user *.doc
oh, those are so new-fangled i never heard of them :) >> it is based on a handful of general purpose classes to setup connections >> to an soffice process in a robust way that could be useful for writing >> UNO API tests in Python. >> > Which is lovely - just, for the sake of orthogonality, we (back in > the day) opted to only test document printing, and not the (somewhat > flaky) remote UNO on top. ;) for me it turned out that the problems of remote UNO are completely dwarfed by the un-reliability of our awful office code; e.g. i did not succeed once in printing ~120 specific ODT documents with a single soffice process in some hours of trying, always crashing with a different non-reproducible stack, and thus added a connection mechanism that starts a new soffice process for every document (plus retries), which worked much better. working with an un-reliable soffice is a requirement for this kind of tool, because you may want to compare against older OOo versions which are, if anything, even worse. (of course this is also a really simple use case of remote UNO, it only calls load, print, close in a loop so the usual race conditions don't have that much opportunity to manifest) oh, and after loading 1000 documents (it doesn't seem to crash as often if you don't print) soffice.bin has >1G of resident memory, though i don't remember if it went away after terminating the remote process, so maybe that is actually caused by the remoting, but i'd guess it's not. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
