OpenOfficeand LibreOffice have the ability to run macros. These macros can be written in a number of programming languages. The most common one is called OpenOffice Basic or LibreOffice Basic. For this language there is a built-in editor. It is also possible to record macros in Basic and edit them afterwards.
OpenOffice Basic or LibreOffice Basic is not standardized in the OpenDocument Format (ODF). ODF does not standardize on any programming language for use in the macros. In fact, in LibreOffice/OpenOffice, one can use Basic, Python, Java and JavaScript.
Macros can be embedded in documents and triggered from certain actions in the document. Many of the drawing and form elements of and ODF document can register listeners to triggers. In text, one can use or to trigger execution of a macro.
This means that a text/javascript is not an acceptable value. Also, using that value causes scripts to stop working in OpenOffice/LibreOffice; only the value ooo:script is used for all scripting languages. Both the Basic and the JavaScript version use the same value for the script language name.
Can we use this to add support for JavaScript macros in WebODF? Yes, but we would need to use a custom namespace to specify that we use JavaScript and this script would work in other ODF implementations. Even if we could use text/javascript there would be a problem, since there is no common API to access and modify the contents of ODF documents.
We have written a small example to set the value of a user variable from a toggle button. I will close this blog with the code for this toggle. Note that all of this is just one macro. Each macro needs its own file and JavaScript macros cannot import other JavaScript files. So if you have an additional toggle, you will need an additional JavaScript file which is 99% identical to the other one.
I have LO 7.0.1.2. I think the problem was that I first ran a sudo apt-get install libreoffice libreoffice-writer libreoffice-java-common jabref java-common to check whether the right java stuff was present. this command installed a LO 6 that interfered with the communication. When I purged LO and re-installed it, the problem was solved.
I tested with the versions of libreoffice in the ubuntu repos anche the upstream ppa, and they both work automatically, detecting the correct paths.
Check that the snap is not still lauched by running which libreoffice. That should return /usr/bin/libreoffice
I did a script to convert tables from Microsoft Excel (ods format), OpenOffice or LibreOffice documents to the MediaWiki syntax. I know such scripts are already available here and here and I know LibreOffice embbeds a wiki converter (but only for Writer)...
but in my case, I have the following requirements from my wiki users:
For Microsoft Windows users, you can download GNU Win32 gawk for Windows with this direct link. Then update your PATH env variable (probably with "C:\Program Files (x86)\GnuWin32\bin"). You may prefer to enter the following command before invoking the gawk script:
I have added the "stayed opened" feature to the Mediawiki CategoryTree extension. Now, when "my" users browse the wiki, the sidebar category tree stayed opened and it was the major "complaint" of my wiki users and they are very happy now :)
If you want to sort in a specific order, add a "sort key" in the related category (ie. "[[category:MyCatsort key]]", read more here). Articles will be sorted in increasing order of "sort key" only in the related category.
Based on the wonderful javascript code from User:קיפודנחש, I add the feature to highlight all areas in grey when the image is loaded so it helps users to know where are the inter-active areas without searching them by using the mouse everywhere on the image (of course, yellow-highlighted areas are still there) because some users prefer searching areas on the image instead of using titles below the image. IMPORTANT NOTE: This feature is only for my wiki users and be sure you need such feature before adding it to your wiki.
The following javascript source code allow the user to double-click on a "pre" content to select its content. This solution avoids flash and any complex "system based" solutions for clipboard copy because the user will the do "CTRL-C" :)
This week has had a rather exciting development that several people have been wanting for quite a long time. The 64-bit compatible versions of MG, MGPP and GDBM have been added to the main code, meaning that Greenstone 2 and 3 can now compile successfully on 64-bit systems. The reason this has taken a long time to be done is that the 32-bit and 64-bit versions of MG and MGPP produced seemingly different files when run over the same documents, which was a concerning for us as people might want to move their 32-bit MG/MGPP collections over to a 64-bit Greenstone installation and we suspected that this might not work given the different files. This week we discovered the cause of the difference and are now reassured that files from 32-bit and 64-bit installations can be interchanged without issue.
In general Greenstone 3 now handles paged-images much better. They are now properly displayed at the top of their specific sections. There is also an option to change between text-only, image-only and the default text and image modes, which is available in both the paged style collections as well as normal hierarchy style collections.
As well as working on security I have made various improvements to the document editor. Users can now edit documents directly on the document page, which allows users to very efficiently perform any basic (content and metadata) modifications. The previous document editor is still where more advanced edits (structure, document creation/deletion) can be performed.
One of the things we have been doing this week is deciding the best way to handle user authentication in Greenstone 3. We have a very basic system in place at the moment but we would like something more robust. At the moment we are investigating using the authentication system in the web-server we use for Greenstone 3 (Apache Tomcat). We need to make sure it has the flexibility we require so that collection administrators have the power to allow/prevent users access to the collection as well as (possibly) access to individual documents.
I have been continuing to assist the masters student I mentioned last week. We have been working on a way to download and replace parts of a collection via the web interface. We think that this functionality may be useful if you want to add/replace an image or run an image through your own OCR program for example.
My time this week has mostly been spent helping out one the masters students here in our lab. I have been helping her develop the ability to tag photos and text in the Greenstone 3 collection she is working on. This has resulted in us enhancing our Greenstone 3 (and also Greenstone 2) CGI capabilities at the same time to get this working correctly. This upgrade was needed so that we could save metadata to the index, archive and import directories easily from Javascript. Some of the functionality was already there but functionality like the ability to remove metadata from the import directory (for example) was missing.
One problem we had to get around was the fact that you cannot reliably specify the position of a piece of metadata that you want to change/delete in a metadata.xml file because of the way import metadata is handled in Greenstone. We decided that a good way to get around this is to have to specify the previous value of the piece of metadata that you want to change/delete. The only problem with this approach is if you have more than one identical piece of metadata, do we delete just one? or all of them? Most likely we will add an option to specify what to do in this situation.
In Greenstone we try very hard to make the modification of the look and feel of collections as easy as possible. Unfortunately this often requires knowledge of web standards like HTML, CSS and Javascript, and in the case of Greenstone 3 it is also helpful to have knowledge of XML and XSLT. We understand that many Greenstone users will have very little knowledge of these topics, so we are looking at incorporating a very simple way of changing the appearance of a Greenstone collection.
JQuery UI has a system called ThemeRoller that allows you to create your own visual theme via an easy to use web interface. You can then download the required files to use that theme in your own website. We are currently experimenting with making Greenstone 3 compatible with these themes (which are made up of a CSS file and some images). So far it is looking promising and will hopefully prove to be a welcome addition to Greenstone 3.
Continued on the problem that I thought had been almost resolved last week: getting the batch files in GS2 to handle not only spaces but also brackets in the Greenstone filepaths. The batch files were done, but the perl code needed some correcting too. After inspecting many files in order to see whether they needed correcting, the GS2 code seems to work well on Windows even where Greenstone is installed in a path containing brackets.
This week, I was able to finally return to the problem of jodconverter not interacting well with the LibreOffice on the Ubuntu 11 whereas the same worked perfectly against an OpenOffice on the CentOs machine. We decided that perhaps OpenOffice had different behaviour for the signals sent by jodconverter. Installing OpenOffice turned out harder than expected and I think I botched it. I ended up having to uninstall all openoffice files and libreoffice files and then reinstalled all of libreoffice. At this stage, upon trying jodconverter again, it was found to work fine each time. This seemed to confirm the suspicion that some updates to Ubuntu may have messed up some libraries or something, breaking LibreOffice a little.
For the last two weeks, I was mainly learning the practical side of how to handle the Greenstone translations. Mainly how to generate the spreadsheets for translators to use, though there was also the opportunity for learning to handle translated spreadsheets. Next to that, there were some questions on the mailing list that I had a go at answering and uploaded the updates to the ACKU and AREU collections.
3a8082e126