[Libreoffice-commits] core.git: sc/source
sc/source/ui/view/tabvwsha.cxx |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit f1ff9375184607b86ae8807d7cf1220962425b51
Author: Dag Wieers
Date: Sun Mar 13 22:09:55 2016 +0100
Related: tdf#42629 Improve the readability of the status bar functions
Currently there is no spacing between functions in the status bar.
Which makes it hard to read. E.g.
Average=4.5;Count=8;Max=8;Sum=36
I think spacing and using colons works out better:
Average: 4.5; Count: 8; Max: 8; Sum: 36
Change-Id: I866bd06519bf03bbe146eee47128a476aff06ba1
diff --git a/sc/source/ui/view/tabvwsha.cxx b/sc/source/ui/view/tabvwsha.cxx
index ce8b41c..9d34f76 100644
--- a/sc/source/ui/view/tabvwsha.cxx
+++ b/sc/source/ui/view/tabvwsha.cxx
@@ -110,7 +110,7 @@ bool ScTabViewShell::GetFunction( OUString& rFuncStr,
sal_uInt16 nErrCode )
SCTAB nTab= rViewData.GetTabNo();
aStr = ScGlobal::GetRscString(nGlobStrId);
-aStr += "=";
+aStr += ": ";
ScAddress aCursor( nPosX, nPosY, nTab );
double nVal;
@@ -141,7 +141,7 @@ bool ScTabViewShell::GetFunction( OUString& rFuncStr,
sal_uInt16 nErrCode )
bFirst = false;
}
else
-rFuncStr += (";" + aStr);
+rFuncStr += ("; " + aStr);
}
}
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
Dag Wieërs license statement
All of my past & future contributions to LibreOffice may be licensed under the MPLv2/LGPLv3+ dual license. -- Dag ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Compilation problem, pnglibconf.h exists but not detected ?
Hi, When building LibreOffice on my RHEL6 system, it successfully passed configure, however after lots of compiling I still get: CC cairo-png.lo In file included from cairo-png.c:46: /home/dag/home-made/libreoffice/workdir/unxlngx6.pro/UnpackedTarball/png/png.h:434:27: error: pnglibconf.h: No such file or directory cairo-png.c: In function ‘write_png’: cairo-png.c:248: error: implicit declaration of function ‘png_set_packswap’ cairo-png.c:248: warning: nested extern declaration of ‘png_set_packswap’ cairo-png.c:268: error: implicit declaration of function ‘png_set_bKGD’ cairo-png.c:268: warning: nested extern declaration of ‘png_set_bKGD’ cairo-png.c:273: error: implicit declaration of function ‘png_convert_from_time_t’ cairo-png.c:273: warning: nested extern declaration of ‘png_convert_from_time_t’ cairo-png.c:274: error: implicit declaration of function ‘png_set_tIME’ cairo-png.c:274: warning: nested extern declaration of ‘png_set_tIME’ cairo-png.c:284: error: implicit declaration of function ‘png_set_write_user_transform_fn’ cairo-png.c:284: warning: nested extern declaration of ‘png_set_write_user_transform_fn’ cairo-png.c:287: error: implicit declaration of function ‘png_set_filler’ cairo-png.c:287: warning: nested extern declaration of ‘png_set_filler’ cairo-png.c:287: error: ‘PNG_FILLER_AFTER’ undeclared (first use in this function) cairo-png.c:287: error: (Each undeclared identifier is reported only once cairo-png.c:287: error: for each function it appears in.) cairo-png.c: In function ‘stdio_write_func’: cairo-png.c:319: error: implicit declaration of function ‘png_error’ cairo-png.c:319: warning: nested extern declaration of ‘png_error’ cairo-png.c: In function ‘read_png’: cairo-png.c:562: error: implicit declaration of function ‘png_read_info’ cairo-png.c:562: warning: nested extern declaration of ‘png_read_info’ cairo-png.c:574: error: implicit declaration of function ‘png_set_palette_to_rgb’ cairo-png.c:574: warning: nested extern declaration of ‘png_set_palette_to_rgb’ cairo-png.c:579: error: implicit declaration of function ‘png_set_expand_gray_1_2_4_to_8’ cairo-png.c:579: warning: nested extern declaration of ‘png_set_expand_gray_1_2_4_to_8’ cairo-png.c:587: error: implicit declaration of function ‘png_set_tRNS_to_alpha’ cairo-png.c:587: warning: nested extern declaration of ‘png_set_tRNS_to_alpha’cairo-png.c:590: error: implicit declaration of function ‘png_set_strip_16’ cairo-png.c:590: warning: nested extern declaration of ‘png_set_strip_16’ cairo-png.c:593: error: implicit declaration of function ‘png_set_packing’ cairo-png.c:593: warning: nested extern declaration of ‘png_set_packing’ cairo-png.c:599: error: implicit declaration of function ‘png_set_gray_to_rgb’ cairo-png.c:599: warning: nested extern declaration of ‘png_set_gray_to_rgb’ cairo-png.c:603: error: implicit declaration of function ‘png_set_interlace_handling’ cairo-png.c:603: warning: nested extern declaration of ‘png_set_interlace_handling’ cairo-png.c:605: error: ‘PNG_FILLER_AFTER’ undeclared (first use in this function) cairo-png.c:627: error: implicit declaration of function ‘png_set_read_user_transform_fn’ cairo-png.c:627: warning: nested extern declaration of ‘png_set_read_user_transform_fn’ cairo-png.c:657: error: implicit declaration of function ‘png_read_image’ cairo-png.c:657: warning: nested extern declaration of ‘png_read_image’ cairo-png.c:658: error: implicit declaration of function ‘png_read_end’ cairo-png.c:658: warning: nested extern declaration of ‘png_read_end’ make[3]: *** [cairo-png.lo] Error 1 make[2]: *** [all] Error 2 make[1]: *** [/home/dag/home-made/libreoffice/workdir/unxlngx6.pro/ExternalProject/cairo/build] Error 1 make: *** [build] Error 2 Even when pnglibconf.h exists in the tree: [dag@moria libreoffice]$ find . -name pnglibconf.h ./libpng/configs/pnglibconf.h Known problem ? -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: --headless broken with --enable-headless
On Fri, 7 Sep 2012, Riccardo Magliocchetti wrote: i have libreoffice crashing early when running unoconv [1] test suite (cd tests && make). Attached gdbtrace.log Libreoffice from yesterday master configured: ./autogen.sh --without-java --enable-headless and started: /usr/local/lib/libreoffice/program/soffice --backtrace "--accept=socket,host=localhost,port=2002;urp;" Does anyone have a clue what can be broken? Does anyone can give it a try with a build without --enable-headless please? Compiling latest master right now. I would recommend using the master branch (which was recently released as v0.6) it contains a fix for random segmentation faults: https://github.com/dagwieers/unoconv/commit/781ccca3a928f10e38eaea294af1c294e82efd9f Since this fix unoconv is amazingly reliable ! This is something that should be fixed in the UNO python-bindings though. Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] [ANN] LibreOffice 3.4.6 RC2 test builds available
On Wed, 14 Mar 2012, Rainer Bielefeld wrote: Fridrich Strba schrieb: for 3.4.6 RC2, we're now uploading builds to a public (but non-mirrored - so don't spread news too widely!) place, as soon as they're available. Grab them here: If you've a bit of time, please give them a try& report *critical* bugs not yet in bugzilla here, we had exactly 0 reports for 3.4.6 RC1, and I doubt that anybody will do systematic tests with RC2 (I won't do either). I do systematic tests on every RC release, albeit very specific to my use-cases (python, UNO, filters/conversions) and with a limited set of documents. The fact that these releases can easily co-exist using RPM packages is priceless ! So it's hard to quantify what 0 reports means, no regressions or no user-testing ? We still have 45 unfixed regressions compared to 3.3, Lifecycle of 3.4 will end with 3.4.6(?), so this version is more or less useless for most (or at least very many) 3.3 or 3.4 users. Who would want to test a car when he knows that still 1 tire is flat and never will be repaired? Although 3 tires have been repaired, that car will be completely useless forever. It's my belief that we will have to rethink our release concept. Please excuse me that I can't tell anything more enthusiastic. If you want to improve a situation, the hard truth is better than a soft lie ;-) I wondered myself whether the split between 3.4, 3.5 and 3.6 is sustainable in the long run. At some point the cost of splitting the userbase is more expensive than the gains from fast release cycles. I would expect at that point we would more likely have a slower release cycle with a longer acceptance phase for QA/testing/regression fixing and less releases. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [ANN] LibreOffice 3.5.1 RC1 available
On Sun, 26 Feb 2012, Thorsten Behrens wrote: The list of fixed bugs relative to 3.5.0 is here: http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffice-3-5-1-release-3.5.1.1.log So playing with the areas touched there also greatly appreciated - and validation that those bugs are really fixed. I experienced a problem installing 3.5.1 RC1 using the RPM packages on RHEL6.2 64bit: file /opt/libreoffice3.5/ure/lib/libstdc++.so.6 conflicts between attempted installs of libreoffice3.5-stdlibs-3.5.1-101.x86_64 and libreoffice3.5-ure-3.5.1-101.x86_64 and opened a bug here: https://bugs.freedesktop.org/show_bug.cgi?id=46658 Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Need help (mentor) while fixing an issue
Hi, I found a bug in LibreOffice causing style:rel-width and style:rel-height not to accept "scale" as a possible value. In fact the behavior seems to be to default to 100% if anything except percentages are provided. https://bugs.freedesktop.org/show_bug.cgi?id=45884 I reported the bug, but wanted to investigate this issue. However in opengrok any queries for style:rel-width, scale or a combination give very few results and nothing I was really expecting. Can someone point me to where I should start debugging this ? Thanks in advance, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] Issues with 3.5.0 - ready for release ...
On Wed, 8 Feb 2012, Markus Mohrhard wrote: 2012/2/8 Caolán McNamara : On Tue, 2012-02-07 at 22:05 +0100, Markus Mohrhard wrote: But keep in mind that this is nothing that will be fast. I needed around one week to check a bit more than 4000 files My times are dramatically faster than this for .doc files in writer at least. I can load 4000 .doc files *under valgrind* overnight in about 10 hours. So apparently mileage varies quite a bit depending on hardware and file format and debugging level. That only works if you have no crashs or looping documents. Especially looping is a big problem in calc. Then if we want to be fast using a debug/dbgutil build is the wrong way but then we loose the advantages of gcc's safe iterators. So I think 4000 known good documents can be easily tested in one day or even faster with a "decent" machine but taking 4000 random documents from bugzilla needs some manual interaction and therefore will need more time. As mentionend in the last mail, I think we could speed that up by copying the test code and the makefile several times and run the test in parallel. That way we could use more cores and would be more reliable against crashs. ( we should of course not commit this stuff then) I would investigate in what cloudooo is doing, they already monitor the process and detect a runaway/memory-leaked process, or intervene when a conversion is spending more time than we would expect. If we simply implement his logic in a small python tool and make it work on a directory of documents, we could run this command every night using the latest snapshot and record/log any debug output (in parallel if need be). And if we use the same (growing) set of documents we also test for regressions by having a directory of files that never failed, and a directory with files that have failed, and have the tool move the files around. And in the same time the robustness of the UNO python bindings is tests ;-) PS I would add cloudooo logic to unoconv, but I prefer to keep workarounds out of unoconv, as I prefer such errors to be reported rather than hide them from users. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] Issues with 3.5.0 - ready for release ...
On Tue, 7 Feb 2012, Cor Nouws wrote: But the quick look I had at the rough list in the train this morning, showed crashes and such but as far as I could judge with special documents. Great issues to solve for the next release(s) ... I can demonstrate issues with some filters during conversions, and when generating (incorrect) Flat ODF have had crashes too (reported). Do we have tests doing automated QA (conversions) to test export filters and are we using fuzzing techniques to test our import filters ? The conversion problems have not been reported yet, but I am sure if we throw more example documents (maybe from Google ?) at it we'll find a lot more problems in an automated fashion. I remember at the LibreConference that Gabriel Monnerat of cloudooo fame was reporting the same problems and reported 10% conversion errors (LibO crashes and filter errors) on a set of 100.000 internet documents. Gabriel implemented various techniques to make his setup more resillient (killing run-away and memory-leaked instances, restarting on crashes and filter instabilities) bringing this number down to 1.1%. Which proves that the majority of these issues are not necessarily reproducable. I am interested in this, both because it helps making unoconv a better tool, but also because it will learn me how to report such issues and who to address them to. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibO 3.5RC2: terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException'
On Mon, 6 Feb 2012, Petr Mladek wrote: Stephan Bergmann píše v Pá 03. 02. 2012 v 22:10 +0100: Petr, the best approach might be to build the "official" Linux LO installation sets with explicit --with-system-stdlibs, so that the installation sets do not bring along their own libgcc_s.so.1 and libstdc++.so.6. If the installation sets are built on a sufficiently old baseline system, it should be a pretty safe bet that each box on which they are installed bring along sufficiently new versions of those libs as part of the system. Hmm, I am a bit scared to do such change at this stage. I am not sure if the stdlibs are 100% backward compatible, it there are not disabled some features on some crazy systems. Note that we already have 3.5.0-rc3 which is supposed to be final. One possibility would be to try system stdlibs in daily builds. Ask people for testing. If we do not get any complains, we could try this with 3.5.1`bug fix release that should get release 4 weeks from now. People could remove the libs in 3.5.0 as a workaround. How does that sound? Maybe, we should discuss this on TSC. My preference is to have this fixed in 3.5.0, obviously, but I have no idea what the impact could be. If it won't be fixed in 3.5.0, I'd prefer if the release notes mention the problem with the workaround. But the issue deserves a bugzilla entry, so here it is: https://bugs.freedesktop.org/show_bug.cgi?id=45696 I took the liberty to add it to the "Most annoying bugs" list and the Release Notes. Thanks for your help ! -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibO 3.5RC2: terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException'
On Fri, 3 Feb 2012, Stephan Bergmann wrote: The secret is that the LO installation sets available from <http://www.libreoffice.org/download> are built with implicit --without-system-stdlibs, so they bring along ure/lib/libgcc_s.so.1 and ure/lib/libstdc++.so.6 (which the programs in the LO installation, like program/soffice.bin and program/python.bin, pick up at runtime). For reasons that still escape me, this causes exception-handling trouble for LO 3.5 program/python (which happens to set LD_LIBRARY_PATH, maybe that makes a difference), but apparently not for LO 3.5 program/soffice, nor reportedly for LO 3.4 program/python (as reported by Dag). Right, loading the uno module using /opt/libreoffice3.5/program/python.bin works. (Except it fails in other ways that require LD_LIBRARY_PATH, e.g. /opt/libreoffice3.5/program/pyuno.so: undefined symbol: PyUnicodeUCS2_GetSize) Removing /opt/libreoffice3.5/ure/lib/libgcc_s.so.1 and /opt/libreoffice3.5/ure/lib/libstdc++.so.6 made the problem go away for me on Fedora 16 x86_64. Petr, the best approach might be to build the "official" Linux LO installation sets with explicit --with-system-stdlibs, so that the installation sets do not bring along their own libgcc_s.so.1 and libstdc++.so.6. If the installation sets are built on a sufficiently old baseline system, it should be a pretty safe bet that each box on which they are installed bring along sufficiently new versions of those libs as part of the system. Would that be possible before the 3.5 release ? Apart from that, Dag, the only safe solution, in principle, is to use a version of LO that is specificially built for the machine it is run on (i.e., use a LO installation provided by the respective distro). I agree, up to the point that I am mostly interested in RHEL5 and RHEL6 and that would mean... ... OpenOffice 3.1.1 or 3.2.1 :-/ But in general the official RPM packages work fine, and I think there's a benefit in keeping this working (if practical possible). Thanks for your insights ! PS I am at FOSDEM and missed you twice at the booth. Can I offer a free beer for your help ? :) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: redhat-menu*.rpm missing in 3.5.0 rc3 ?
On Fri, 3 Feb 2012, Jean-Baptiste Faure wrote: Is it expected that there is no *redhat-menus*.rpm file in desktop-integration for LO 3.5.0 rc3 ? readme file says that this package has to be installed. It was merged with the freedesktop. I can attest that the freedesktop works fine on RHEL, although Flat ODF file integration is not working because the mime-types are missing. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibO 3.5RC2: terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException'
On Fri, 3 Feb 2012, Petr Mladek wrote: Dag Wieers píše v Pá 03. 02. 2012 v 11:52 +0100: This issue still exist in the LibO 3.5RC3 RPM builds, making the python UNO interface unusable :-/ I have tried to send documents via E-mail using "Tool/Mail Merge Wizard..." with LO-3.5.0-rc3 on SLED11-SP1-x86_64. It works well. This functionality is written in python, so it kind of works. I am a bit mixed by your description of the problem. How do you exactly call the pyuno stuff? Could you please provide a simple script that could be used to reproduce it? I run it exactly as described in the mail. The only thing performed was: import uno after which it crashes. This does not happen on the same system with the LibO 3.4.5 installation and hasn't happened on previous installations either. (Going back to OpenOffice 3.2.0) Here is a very simple example without influencing the environment: [dag@moria ~]$ /opt/libreoffice3.5/program/python Python 2.6.1 (r261:67515, Feb 1 2012, 15:06:46) [GCC 4.2.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. import uno terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException' Aborted (core dumped) Doing this for LibO 3.4.5 works as expected: [dag@moria ~]$ /opt/libreoffice3.4/program/python Python 2.6.1 (r261:67515, Jan 3 2012, 18:08:21) [GCC 4.2.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. import uno print dir(uno) ['Any', 'Bool', 'ByteSequence', 'Char', 'Enum', 'Type', '__builtin__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '_g_ctx', '_g_delegatee', '_impl_extractName', '_uno_extract_printable_stacktrace', '_uno_import', '_uno_struct__eq__', '_uno_struct__getattr__', '_uno_struct__init__', '_uno_struct__repr__', '_uno_struct__setattr__', '_uno_struct__str__', 'absolutize', 'createUnoStruct', 'fileUrlToSystemPath', 'generateUuid', 'getClass', 'getComponentContext', 'getConstantByName', 'getCurrentContext', 'getTypeByName', 'invoke', 'isInterface', 'pyuno', 'setCurrentContext', 'socket', 'sys', 'systemPathToFileUrl'] It cannot be demonstrated more simple than that. [dag@moria ~]$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.2 (Santiago) [dag@moria ~]$ uname -a Linux moria.gent.wieers.com 3.2.2-0.el6.elrepo.x86_64 #1 SMP Fri Jan 27 12:37:49 EST 2012 x86_64 x86_64 x86_64 GNU/Linux Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibO 3.5RC2: terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException'
On Thu, 2 Feb 2012, Dag Wieers wrote: I have a problem using the python UNO interface as shipping with LibO 3.5RC2, I do not have the same problem using LibO 3.4.5 or previous versions (going back to OpenOffice 3.2.1). When running the shipped python binary with the shipped modules/libraries, python bails out with: terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException' Aborted (core dumped) This does not happen on Windows, but it does happen on a RHEL6 64bit using the provided RPM packages. This issue still exist in the LibO 3.5RC3 RPM builds, making the python UNO interface unusable :-/ -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] LibO 3.5RC2: terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException'
Hi, I have a problem using the python UNO interface as shipping with LibO 3.5RC2, I do not have the same problem using LibO 3.4.5 or previous versions (going back to OpenOffice 3.2.1). When running the shipped python binary with the shipped modules/libraries, python bails out with: terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException' This does not happen on Windows, but it does happen on a RHEL6 64bit using the provided RPM packages. Here is the complete environment used: python=/opt/libreoffice3.5/program/python.bin python-version=2.6.1 (r261:67515, Jan 24 2012, 18:36:41) [GCC 4.2.4] URE_BOOTSTRAP=vnd.sun.star.pathname:/opt/libreoffice3.5/program/fundamentalrc UNO_PATH=/opt/libreoffice3.5/program PATH=/opt/libreoffice3.5/program:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/dag/bin PYTHONHOME=/opt/libreoffice3.5/program/python-core-2.6.1 PYTHONPATH=/opt/libreoffice3.5/program/python-core-2.6.1/lib:/opt/libreoffice3.5/program/python-core-2.6.1/lib/site-packages:/opt/libreoffice3.5/program/python-core-2.6.1/lib/lib-tk:/opt/libreoffice3.5/program/python-core-2.6.1/lib/lib-dynload:/opt/libreoffice3.5/program LD_LIBRARY_PATH=/opt/libreoffice3.5/program:/opt/libreoffice3.5/ure-link/lib:/opt/libreoffice3.5/program:/opt/libreoffice3.5/ure-link/lib terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException' Aborted (core dumped) The problem starts immediately after doing the 'import uno'. Doing the same on LibO 3.4.5, it works fine. The environment used for LibO 3.4 is: python=/opt/libreoffice3.4/basis-link/program/python.bin python-version=2.6.1 (r261:67515, Jan 3 2012, 18:08:21) [GCC 4.2.4] URE_BOOTSTRAP=vnd.sun.star.pathname:/opt/libreoffice3.4/program/fundamentalrc UNO_PATH=/opt/libreoffice3.4/basis-link/program PATH=/opt/libreoffice3.4/program:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/dag/bin PYTHONHOME=/opt/libreoffice3.4/basis-link/program/python-core-2.6.1 PYTHONPATH=/opt/libreoffice3.4/basis-link/program/python-core-2.6.1/lib:/opt/libreoffice3.4/basis-link/program/python-core-2.6.1/lib/site-packages:/opt/libreoffice3.4/basis-link/program/python-core-2.6.1/lib/lib-tk:/opt/libreoffice3.4/basis-link/program/python-core-2.6.1/lib/lib-dynload:/opt/libreoffice3.4/basis-link/program LD_LIBRARY_PATH=/opt/libreoffice3.4/basis-link/program:/opt/libreoffice3.4/basis-link/ure-link/lib:/opt/libreoffice3.4/basis-link/program:/opt/libreoffice3.4/basis-link/ure-link/lib Office base location: /opt/libreoffice3.4 Office binary location: /opt/libreoffice3.4/basis-link/program LibreOffice listener successfully started. (pid=14183) Beware that the environment is quite different due to the fact that basis-link/ (or basis/) has been removed from the directory structure. Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] LibreOffice 3.5RC2 installation on Windows
Hi, When installing LibreOffice 3.5RC2 on Windows 7 with LibreOffice 3.4.4 already installed. The installer checks the system before initiating the installation and then complains about a LibreOffice or LibreOffice Quickstart instance running (possibly by another user) and advises to close any LibreOffice 3.4 instances. However no LibreOffice instances are running at all. And there are no other users on this test system anyway. So the check is doing an incorrect test. Even Sysinternals Process Explorer does not see any LibreOffice or unidentified processes, so I am pretty sure the installer is making the wrong conclusion, or providing me with an incorrect error message. After uninstalling the LibreOffice 3.4.4, the 3.5RC2 installer does not complain and proceeds with the installation as expected. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Flat ODF usage in Git [Was: concept for c++ based subsequenttests]
On Tue, 24 Jan 2012, Michael Meeks wrote: On Mon, 2012-01-23 at 15:27 +0100, Michael Stahl wrote: unfortunately this would have less benefits than you imagine, because of the way xmloff writes automatic styles: they are generated anew on every export, in a non-deterministic order Wow - how non-deterministic ? randomly shuffled or ... ? ;-) , which results in huge spurious diffs... (at least for Writer) Interesting; the order is really not based on the order that the different intersection of styles appear in the document ? I suspect this is something that a number of people will want to improve for all those funky "store flat odf in git" things :-) It's a worthy goal, but I can imagine that those people capable of using git might want to write documentation/text in a lightweigth markup language instead, like AsciiDoc and convert it to ODF when producing final output. E.g. http://github.com/dagwieers/asciidoc-odf Now that we have native (embedded) SVG support in 3.5, the toolchain becomes a lot more interesting, considering there are some nice ascii-to-image conversion plugins that create nice diagrams and charts from asciiart. So that changes to images become humanly parseable too ;-) E.g. http://code.google.com/p/asciidoc-ditaa-filter/ http://code.google.com/p/asciidoc-plantuml/ http://code.google.com/p/asciidoc-aafigure-filter/ http://volnitsky.com/project/mplw/ http://code.google.com/p/asciidoc-mscgen-filter/ http://powerman.name/asciidoc/ Also the way LibreOffice is naming styles by default is suboptimal, not using internal names but instead using the visible name and converting e.g. spaces to _20_. This will get you ugly names for: Heading 1 -> Heading_20_1 Text body -> Text_20_body ODF does support internal names that are different than the visible representation so there's no need to retain the space in the internal name. Although I can see why it was implemented like this, I personally don't really like it. I wonder what other ODF producers do in this case though. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice file type associations for Flat ODF files
On Tue, 6 Dec 2011, Jan Holesovsky wrote: On 2011-12-02 at 23:32 +0100, Dag Wieers wrote: The installation of Libreoffice 3.4.4 still does not set the necessary file type associations to make flat ODF files work with LibreOffice out of the box (in e.g. Gnome on RHEL6 using the official RPM packages). There is a bug report about this since November 2010. https://bugs.freedesktop.org/show_bug.cgi?id=31624 What is required to make this part of the 3.5 release ? First - I'd try a daily build: http://dev-builds.libreoffice.org/daily/ to see if it works in master. If no, probably you have to dig around the mimetype registration: http://cgit.freedesktop.org/libreoffice/core/tree/sysui/desktop/mimetypes and other desktop files: http://cgit.freedesktop.org/libreoffice/core/tree/sysui/desktop/menus Interestingly I see the .fod* file types there, see eg.: http://cgit.freedesktop.org/libreoffice/core/tree/sysui/desktop/mimetypes/oasis-text-flat-xml.desktop http://cgit.freedesktop.org/libreoffice/core/tree/sysui/desktop/menus/writer.desktop Can you check if they are installed, used, etc.? On 3.5RC2 the former is not installed, the later is installed fine. But I am not sure wether I added the relations myself, or not. So I just tested on a clean RHEL6: 3.4.4 -> Does not work 3.4.5 -> Does not work 3.5RC2 -> Does not work The default relation is firefox (I guess because it is deemed an XML file), other associations are: gedit, Google Chrome en gvim :-/ On LibO 3.4 I installed the desktop-integration RPM for redhat, for LibO 3.5 this was merged with the freedesktop RPM, but still does not make a difference :-( The RPM does execute update-desktop-database and update-mime-database, but the associations are not there. It's obvious that the mimetypes are missing, the RPM does install /usr/share/mime/packages/libreoffice3.5.xml, but it does not include the flat-xml or .fod? mimetypes :-( -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Writing a book w/F16?
On Sat, 10 Dec 2011, NOSpaze wrote: On Sat, 2011-12-10 at 10:17 -0700, Craig White wrote: I was wrong... in that case, I will answer. sgml has long been used for professional publishing ( see adobe framemaker). The idea is that you can use fast/simple editors such as vi or emacs and put in your own markup tags and save the processing (ie, generate toc/footnotes/end notes/appendix/etc.) for later. Thanks for the suggestion. I'll read how to do a TOC, footnotes and commenting/tagging paragraps, summarizing in vim. If you can suggest any link, TIA. "your own markup tags"... I wouldn't use sgml/xml, but i'll wait for any links on how to apply them effectively. Try AsciiDoc: http://www.methods.co.nz/asciidoc/ It's a lightweight markup language that maps to DocBook. And you can still use LibreOffice for formatting and styling your document, or to convert to PDF or DOC by using the ODF backend: http://github.com/dagwieers/asciidoc-odf A shameless plug ? Yes, I know, but I can use more testers :) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] LibreOffice file type associations for Flat ODF files
Hi, The installation of Libreoffice 3.4.4 still does not set the necessary file type associations to make flat ODF files work with LibreOffice out of the box (in e.g. Gnome on RHEL6 using the official RPM packages). There is a bug report about this since November 2010. https://bugs.freedesktop.org/show_bug.cgi?id=31624 What is required to make this part of the 3.5 release ? Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] text:class-names and nested text:span/text:style-name
On Thu, 24 Nov 2011, Dag Wieers wrote: Case 1: Using text:class-names bold text:class-names="strong blue">blue bold No syles seem to have been applied. Case 2: Using nested text:span/text:style-name bold text:style-name="blue">blue bold Bold is bold. Blue is blue, but not bold ! After more experiments I found that Case 2 does work when the styles are defined inside instead of . Which I believe is a bug in LibreOffice. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] text:class-names and nested text:span/text:style-name
Hi, Since I don't know if I am doing something wrong, or whether LibreOffice simply doesn't support text:class-names or nested text:span styles. Can someone verify that LibreOffice incorrectly process the following two cases ? The following two styles exists in And attached is a very basic example .fodt to experiment with yourself. Case 1: Using text:class-names bold blue bold No syles seem to have been applied. Case 2: Using nested text:span/text:style-name bold blue bold Bold is bold. Blue is blue, but not bold ! PS If there is a better venue to ask ODF related questions, let me know. Thanks in advance, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] Case 1: bold blue bold Case 2: bold blue bold ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] xmllint problem validating using ODF RelaxNG
Hi, There is a (known) problem when using xmllint with the ODF RelaxNG schema, that causes xmllint to fail with error message: Unimplemented block at relaxng.c:8948 This was bothering us for the asciidoc-odf development. I reported it to Red Hat and Daniel Veillard fixed this promptly in libxml2. https://bugzilla.redhat.com/show_bug.cgi?id=752393 The reason is that xmllint did not implement the RelaxNG optional element. In case you have had this problem, you can patch your libxml2 implementation: http://git.gnome.org/browse/libxml2/commit/?id=7dd0d916c6a92ca4a398b8bc56fb0d7f98df00b6 PS I am hoping that this is backported to RHEL6 (and hopefully RHEL5 too), but in the meantime I plan to provide packages fixing this problem in RPMforge's Extras repository for RHEL/CentOS. Thanks to Daniel for the excellent support :-) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Python on Windows
On Thu, 20 Oct 2011, Stephan Bergmann wrote: (c) pyuno as run from an external python process might no longer work. An easy way to test that is to start the interactive python executable from the LibO program directory and execute "include uno" (and/or "include pyuno"; not sure right now which one is the more interesting, but if both work I'd guess that's good). The solution we implemented for this for unoconv (a python tool) is to try to load the pyuno.so with the system's python, on failure it looks for an existing LibO python and swaps itself in memory with the LibO python and tries again. That works quite well in practice. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Unexpected failures (eg. segfaults) using PyUNO and LibreOffice/OpenOffice
On Thu, 20 Oct 2011, Jan Holesovsky wrote: On 2011-10-19 at 10:17 +0200, Dag Wieers wrote: to test each of the versions. Of course if you have a large collection of documents you can have unoconv convert those in batch. Below is some example failure output from a single run, LibreOffice does seem a bit more stable than OpenOffice though. Glad to hear LibreOffice is more stable :-) I'll say anything to get your help ;-) What would help most is that you'd run your tests with the most recent LibreOffice from 'master' (ideally built yourself with dbgutil & symbols - reporting against 3.2.1 does not make too much sense, too much has happened in the meantime). First try to reproduce the crash directly from LibreOffice (opening the offending file from the file dialog, instead of calling from ooconv). If it is possible to reproduce, run LibreOffice from gdb (or attach gdb to the running process), and produce a backtrace. More here: http://wiki.documentfoundation.org/BugReport#How_to_get_backtrace_.28on_Linux.29 Since I'd like to involve my users in the debugging process (ie. make it as straight-forward as possible so they can report as much as possible), who should I talk to to have debuginfo RPM packages ? When you cannot reproduce it from LibreOffice itself, it will be harder - try to attach gdb to the LO running the conversion, or something. I may not be able to reproduce an existing case, but they happen so often that it doesn't really matter. I can do those batch conversions over and over again with gdb attached until it crashes. Unless you expect gdb to influence the behaviour ? I am sure in the end you'll end up with just few classes of errors, with backtraces - that will help us a lot to fix them; or maybe you'll be able to fix it then yourself (with our help)? Don't overestimate a sysadmins skills :) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Styles cleanup & removing option page std fonts
On Thu, 20 Oct 2011, Astron wrote: On the whole, I like your plans, but... One of the ideas I think would be great, is having a small LibreOffice logo on the default document somewhere on the lower-right of the page. Or in the default footer. The logo is stylish and non-obtrusive. This sounds like the LibreOffice version of the infamous "Sent from my iPhone" signature. As such, I think it's a really bad idea /for the default template/. No one needs to be informed so rudely about how you created your document. (Anyone who cares can still include a LibO icon in their documents, of course.) I think there's a difference, in that I would make it small and the logo just looks like a document. But I see why you would object to an iphone style ad :) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Styles cleanup & removing option page std fonts
On Wed, 19 Oct 2011, Cor Nouws wrote: Michael Meeks wrote (19-10-11 17:19) Are you volunteering ? (and it's worth checking the result with the ux-advise guys too of course). Dag, would you or shall I ;-) Serious: I am willing to play a role in this. But even more serious: if a few people make a sort of plan, and do some coordination, it must be possible to attract some people from e.d. users@. Any remarks/suggestions/tips at this stage? Can we collect some ideas and/or examples on the wiki somewhere ? For the admonitions (note, tip, important) I have some examples I really like from other Open Source documentation that I'd like to refer to. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Styles cleanup & removing option page std fonts
On Wed, 19 Oct 2011, Michael Meeks wrote: On Wed, 2011-10-19 at 16:19 +0200, Dag Wieers wrote: It would make using OpenOffice by default more attractive without the need to look for existing templates and/or mess around with styles. I know one can already do this for themselves, but normal users shouldn't be exposed to it for basic usage. The current default styles just don't cut it :-/ Quite - of course, all we need is one heroic volunteer here to update them, and to work at creating some attractive default styles. Luckily this doesn't even require any programming experience: just mail some document templates with the new style information ;-) Are you volunteering ? (and it's worth checking the result with the ux-advise guys too of course). I am willing to help there, certainly ! But I'd rather have someone with some design skills come up with a generic color palette and styles that can be reused throughout documents, presentations and spreadsheets. If you let me do it, I would go with the default styles of AsciiDoc which I am reimplementing in ODF. They are not the most attractive, but certainly better than what is now the default. I am sure a stylist can come up with something better looking though ! One of the ideas I think would be great, is having a small LibreOffice logo on the default document somewhere on the lower-right of the page. Or in the default footer. The logo is stylish and non-obtrusive. PS I was very impressed with the default presentation stylesheet for the conference. And maybe green is a nice color for the default. Who did design that template ? -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Styles cleanup & removing option page std fonts
On Wed, 19 Oct 2011, Cedric Bosdonnat wrote: On Tue, 2011-10-18 at 18:03 +0200, Cor Nouws wrote: Interest caught by your presentation in Paris, I saw your patch in cgit: 359d0fbd03a68d9131e8fb25e7dac9f19ddf6dcb I understand the idea to remove default paragraph styles such as list, list1, list1 cntd, list2 end etc etc But I do not understand what the link is with removing the option page std fonts (Tools > Options > Writer > Basic fonts (& CTL, Asian) I mean, the option for List fonts indeed can be missed, but what about the other 4? Could you pls explain? This option page does exactly the same than changing the values in the style directly. In a not-so-far future, I'ld like to have this all configured through a default template instead of what we have... and removing that option page is on the way to this goal. (Maybe this was already discussed before.) It would be nice if the default template that ships with LibreOffice would ship with visually attractive styles, and paragraph styles for commonly used blocks or admonitions, eg. listing-block, literal-block, note, tip, important, ... It would make using OpenOffice by default more attractive without the need to look for existing templates and/or mess around with styles. I know one can already do this for themselves, but normal users shouldn't be exposed to it for basic usage. The current default styles just don't cut it :-/ Not just for Writer, but also for Calc, Impress, etc... -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Unexpected failures (eg. segfaults) using PyUNO and LibreOffice/OpenOffice
($sourceBaseURL, 'meta.x...}:
Variable $sourceBaseURL has not been declared
Error at xsl:if on line 376 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/common/styles/style_collector.xsl:
XPST0008: XPath syntax error at char 23 on line 376 in
{$onlyStyleOutputEnabled}:
Variable $onlyStyleOutputEnabled has not been declared
Error at xsl:when on line 595 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/common/styles/style_collector.xsl:
XPST0008: XPath syntax error at char 23 on line 595 in
{$onlyStyleOutputEnabled}:
Variable $onlyStyleOutputEnabled has not been declared
Error at xsl:for-each on line 694 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/common/styles/style_collector.xsl:
XPST0008: XPath syntax error at char 23 on line 694 in
{document($stylesFileURL)}:
Variable $stylesFileURL has not been declared
Error at xsl:if on line 70 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/xhtml/header.xsl:
XPST0008: XPath syntax error at char 13 on line 70 in {$debugEnabled}:
Variable $debugEnabled has not been declared
Error at xsl:if on line 75 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/xhtml/header.xsl:
XPST0008: XPath syntax error at char 13 on line 75 in {$debugEnabled}:
Variable $debugEnabled has not been declared
Error at xsl:if on line 80 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/xhtml/header.xsl:
XPST0008: XPath syntax error at char 13 on line 80 in {$debugEnabled}:
Variable $debugEnabled has not been declared
Error at xsl:call-template on line 545 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/common/styles/style_collector.xsl:
XTSE0650: No template exists named convert2pt
Error at xsl:call-template on line 551 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/common/styles/style_collector.xsl:
XTSE0650: No template exists named convert2pt
Error at xsl:call-template on line 619 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/common/styles/style_collector.xsl:
XTSE0650: No template exists named start-main
Error at xsl:call-template on line 624 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/common/styles/style_collector.xsl:
XTSE0650: No template exists named start-main
Error at xsl:call-template on line 629 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/common/styles/style_collector.xsl:
XTSE0650: No template exists named start-main
Error at xsl:call-template on line 338 of
file:/usr/lib64/openoffice.org/basis3.2/share/xslt/export/common/styles/style_mapping_css.xsl:
XTSE0650: No template exists named convert2cm
unoconv: UnoException during conversion in (Error 3088)
Kind regards,
--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, i...@dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] pyuno problems
On Fri, 1 Apr 2011, Jan Holesovsky wrote: On 2011-04-01 at 13:42 +0200, Dag Wieers wrote: I am the author of a tool called unoconv. It's a tool that uses the pyuno bindings to allow non-interactive conversions using OpenOffice import/export filters. http://dag.wieers.com/home-made/unoconv/ I plan to support and track LibreOffice development in the future, but I currently am having difficulties using the provided python binary and the provided pyuno.so. Thank you very much for adding LibreOffice support! Just one note - LibreOffice can convert between various formats itself from the command line, see the LibreOffice's -help: -infilter= Force an input filter type if possible Eg. -infilter="Calc Office Open XML" -convert-to output_file_extension[:output_filter_name] [-outdir ouput_dir] files Batch convert files. If -outdir is not specified then current working dir is used as output_dir. Eg. -convert-to pdf *.doc -convert-to pdf:writer_pdf_Export -outdir /home/user *.doc Is there anything missing that unoconv can support? Would you be interested in extending this mechanism, so that it has the unoconv features? [Eg. we cannot expand wildcards on Windows, if I am not mistaken.] That's cool. It should have been like this from the start :-) Having to start our own listener for communicating with UNO has been problematic from the start, mostly because it's not very stable. The differences I see: - Remote conversions (only with shared storage) - No need to know the internal filter names - Possibility to provide filter options to filters - Possibility to apply styles/formats (from templates or other documents) during conversion - Output to stdout I am not a C programmer, so I don't think I can be very useful. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] pyuno problems
Hi, I am the author of a tool called unoconv. It's a tool that uses the pyuno bindings to allow non-interactive conversions using OpenOffice import/export filters. http://dag.wieers.com/home-made/unoconv/ I plan to support and track LibreOffice development in the future, but I currently am having difficulties using the provided python binary and the provided pyuno.so. As you can see from the following test: [dag@moria unoconv]$ /opt/libreoffice/basis-link/program/python.bin -c 'import sys; sys.path.insert(0, "/opt/libreoffice/basis-link/program"); import uno' Traceback (most recent call last): File "", line 1, in File "/opt/libreoffice/basis-link/program/uno.py", line 29, in import pyuno SystemError: dynamic module not initialized properly Since some of my users complain about having difficulties making unoconv work because they use the distribution's native python with the OpenOffice/LibreOffice pyuno.so, I have started to implement a work-around. Unoconv now searches for a matching python binary and execv()'s that one instead. This should work, but doesn't on my own RHEL6 test-system using the latest LibreOffice 3.3.2 release (64bit RPM). Is it possible this is a mistake with the release ? Because it doesn't seem to work manually either :-( PS If there is a better venue for this question, I'd like to know. Because apart from this problem, we have identified many bugs in import and export filters (both coredumps as well as programming errors) that we can demonstrate with both LibreOffice as well as OpenOffice. I would like to document where to report such problems. Thanks in advance, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
