bibleget-i-o / bibleget-openoffice

BibleGet I/O Project plugin for Open Office

bibleget-openoffice

BibleGet I/O Project plugin for Open Office

Description

Insert Bible quotes into your document using standard notation for Bible Quotes (see https://en.wikipedia.org/wiki/Bible_citation). This plugin uses the BibleGet service endpoint (https://query.bibleget.io) to retrieve bible quotes. The user can choose the version or versions of the Bible to retrieve the quotes from based on their availability on the server. More versions in various languages are being added all the time. You can contribute to translating the user interface into other languages here: https://poeditor.com/join/project/5bkVxO5qsq

Inserisci citazioni della Bibbia nel tuo documento usando la notazione biblica standard. Questa estensione utilizza il servizio web di BibleGet (https://query.bibleget.io) per reperire le citazioni. L'utente può scegliere la versione biblica dalla quale trarre la citazione, in base alle versioni disponibili sul server. Nuove versioni in varie lingue vengono aggiunte in continuazione. Puoi contribuire a tradurre l'interfaccia in altre lingue qui: https://poeditor.com/join/project/5bkVxO5qsq

Introduzca citas de la Biblia en su documento utilizando la notación bíblica estándar. Esta extensión utiliza el servicio web BibleGet (https://query.bibleget.io) para obtener citas bíblicas. El usuario puede elegir la versión bíblica de la cual extraer la cita, de acuerdo a las versiones disponibles en el servidor. Nuevas versiones en varios idiomas se agregan constantemente. Puedes ayudar con la traduccion de la interfaz aqui: https://poeditor.com/join/project/5bkVxO5qsq

Entrez citations bibliques dans votre document en utilisant la notation biblique standard. Cette extension utilise le service Web BibleGet (https://query.bibleget.io) pour obtenir les citations. L'utilisateur peut choisir la version biblique dont tirer la citation, selon les versions disponibles sur le serveur. Nouvelles versions en différentes langues sont ajoutés en permanence. Pouvez aider avec la traduction de l'interface dans autres langues ici: https://poeditor.com/join/project/5bkVxO5qsq

Geben biblische Zitate in Ihrem Dokument mit dem biblischen Standard-Notation. Diese Erweiterung nutzt die Web-Service-BibleGet (https://query.bibleget.io), die Anführungszeichen zu bekommen. Der Benutzer kann die Version, die das biblische Zitat ziehen, abhängig von der auf dem Server verfügbaren Version. Neue Sprachversionen werden laufend hinzugefügt. Du kannst helfen, übersetzen Sie die Schnittstelle in anderen Sprachen Hier: https://poeditor.com/join/project/5bkVxO5qsq

Installation

The latest release can be downloaded from the Open Office Extensions website at:

• https://extensions.openoffice.org/en/project/bibleget-io
• a Java Runtime Environment is required for this plugin to function correctly. A minimum of JRE 1.8 (32bit version) is required and can be obtained either from https://www.oracle.com/java/technologies/javase-jre8-downloads.html or from https://developers.redhat.com/products/openjdk/download (JDK includes JRE). Please note that a 64bit JRE will not work. You can install both a 64bit and a 32bit JRE, but OpenOffice can only handle a 32bit JRE (on Windows in any case).

Developers

Anyone interested in contributing to the development of this plugin should first setup the environment for Apache Open Office plugin development. Please take a look at the wiki page on this repository.

Changelog

v2.8 (March 3rd, 2019)

This release of the plugin or extension for Open Office resynchronizes the plugin code with the 2.8 version of the plugin for LibreOffice. The preceding 2.6 release had been published first for OpenOffice, and then published as v2.7 for LibreOffice seeing that this last platform needed a few adaptations.

I had pushed the code for the extension to github when releasing the 2.6 version (year 2015) to keep it publicly accessible to the open source community. In the meantime, because of some technical difficulties with the computer I used for developing, I lost the local copy of the extension code. In order to proceed with this release, I retrieved the code from github (mainly the 2.7 release for LibreOffice). And I'm not entirely sure the code on github was actually 100% up to date with the actual 2.7 release because it seemed to have some bugs which didn't appear when testing for the 2.7 release; either the github code wasn't 100% up to date or there were some changes in some of the Java libraries used between releases which made for some bad bugs. In any case, these were all ironed out for the current 2.8 release.

After the recent BibleGet Project server updates which set HSTS headers enforcing the usage of the https protocol throughout the domain, including the query.bibleget.io service endpoint, it was necessary to use the https protocol in the extension web connections to the service endpoint. However the BibleGet.io domain uses Let's Encrypt certificates. Let's Encrypt certificates should be accepted in JRE 1.8 keystores which should trust the "DST Root CA X3" certificate used to sign Let's Encrypt certificates. However the keystore on my development machine didn't trust this certificate even though a Java 1.8 runtime was installed, and so the Let's Encrypt certificate was still causing an SSLHandShake exception to be thrown. In order to make sure untrusted certificates would not cause SSLHandShake exceptions which would have impeded the correct functioning of the extension, the DST Root CA X3 certificate was included in the extension resources and forcefully made to be trusted during plugin execution.

I'm guessing with there were some changes in updated Java libraries used for the extension, or perhaps in JRE itself, which changed the behaviour of javax.json . Not sure if this was because of code that was not pushed to github for the 2.7 release or because of updated libraries that acted differently since the 2.7 release, because the 2.7 release didn't have any problems with this as far as I can tell. In any case, the built json objects are now correctly passed into JsonObject variables which are then returned, instead of directly returning the JsonBuilder once it was built.

Another issue handled in the current release was that of UTF-8 encoded resource strings not being handled correctly, and the localized string translations were not being retrieved. I added a utf-8 control class to correctly read utf-8 encoded string resources.

• use https protocol for web connections
• the root CA certificate included and forcefully added to the trusted certificates on runtime to make sure https connections don't throw SSLHandShake exceptions
• fixed bugs with options not being correctly loaded, this was depending on how JsonBuilders were behaving
• JsonValues which are string values are now explicitly cast to JsonStrings and the string value is obtained with JsonString.getString
• new utf-8 control class to handle retrieval of utf-8 encoded strings from resources
• use Java Runtime 1.8 (x86) to build the extension, along with the 32bit Open Office 4.1.6 SDK. This requires using a 32 bit JRE rather than 64 bit. In any case a minimum JRE of 1.8 is now required
• some resource strings were updated

v2.6 (September 17th, 2015)

This release contains a bugfix for setting the background colors for the inserted Scripture quotes (there seems to be a kind of bug in the OpenOffice software but we have provided a workaround for the time being).

It also contains a fix for the NABRE text's tag which was not yet supported in the last release. For now the tag has a fixed formatting of bold text with a space before and after and a background color of Light Gray. If anyone finds the fixed formatting not according to their needs please let me know and I can create more options for customizing the formatting of the speaker tag (examples of this tag can be found in <Song of Songs 2> for example, it represents the person currently speaking in the poetic dialog).

There is also an enhancement for the formatting of the poetic texts in the NABRE version, between correct newlines and correct indents... The indents can perhaps be enhanced even more, but for now it's acceptable.

v2.5 (August 22nd, 2015)

This release contains a series of bugfixes and of enhancements. Must update.

• bugfix: quote was not being inserted at current cursor position
• bugfix: chapter limit and verse limit warning messages were not returning valid values
• bugfix: inserted text was not able to be formatted
• feature addition: added option to ovveride internal formatting for biblical texts that have internal formatting
• feature addition: support for New American Bible - Revised Edition with it's internal formatting
• bugfix: fix automatic refresh when renewing metadata from the BibleGet server
• bugfix: fix unicode font rendering for Asian languages
• feature addition: added German, French and Spanish translations of the interface (might need some fine-tuning)

v2.0 (March 9th, 2015)

This is a major release. Much of the code has been updated to make it compatible with the second version of the BibleGet I/O engine. This means that the extension can now handle multiple versions of the Bible, as well as detect which versions are available on the BibleGet I/O server and which languages are supported by the BibleGet engine for the recognition of the books of the Bible. Also index information for each version of the Bible is handled, to check whether chapters and verses requested are valid. The extension interface has also been internationalized with this release. The interface is translated into both English and Italian in full, and only partially into Spanish and French. Users can contribute translations for the extension interface at this project url: https://www.transifex.com/accounts/profile/bibleget.io/ . You can create an account and request access to the BibleGet project translations.

Questo aggiornamento di versione è un rilascio importante. Molto del codice è stato modificato e aggiornato per renderlo compatibile con la seconda versione del motore di BibleGet I/O. Questo significa che l'estensione ora può gestire multiple versioni della Bibbia, e può rilevare quali sono le versioni disponibili sul server BibleGet I/O e rilevare quali sono le lingue supportate dal motore BibleGet per il riconoscimento dei libri della Bibbia. Inoltre, informazioni di indice per ogni versione biblica vengono conservate in locale dal server BibleGet, per verifiche sulla validità dei capitoli e dei versetti nelle richieste di citazioni. L'interfaccia dell'estensione è stata anche internazionalizzata con questo aggiornamento. L'interfaccia è disponibile per intero in Inglese e in Italiano, e solo parzialmente in Spagnolo e in Francese. Gli utenti possono contribuire a tradurre l'interfaccia in varie lingue a questo indirizzo: https://www.transifex.com/accounts/profile/bibleget.io/ . Puoi creare un account a questo indirizzo e richiedere accesso alle traduzione del progetto BibleGet.

Cette mise à jour est une version majeure. Une grande partie du code a été mis à jour pour le rendre compatible avec la deuxième version du moteur BibleGet I/O. Cela signifie que l'extension peut maintenant gérer de multiples versions de la Bible, ainsi que détecter les versions que sont disponibles sur le serveur et détecter quelles sont les langues supportées par le moteur BibleGet pour la reconnaissance des livres de la Bible. Également des informations d'index pour chaque version de la Bible est traitée, pour vérifier si les chapitres et les versets demandées sont valables. L'interface de l'extension a également été internationalisé. L'interface est traduite en italien et en anglais dans son intégralité, et seulement partiellement en espagnol et en français. Les utilisateurs peuvent contribuer les traductions de l'interface de l'extension à ce url: https://www.transifex.com/accounts/profile/bibleget.io/. Vous pouvez créer un compte utilisateur et demander l'accès aux traductions de projets BibleGet.

Esta actualización es una versión principal. Gran parte del código se ha actualizado para ser compatible con la segunda versión del motor BibleGet I/O. Esto significa que la extensión puede ahora gestionar múltiples versiones de la Biblia, y puede identificar las versiones biblicas que están disponibles en el servidor y detectar cuales idiomas son apoyadas del motor BibleGet por el reconocimiento de los libros de la Biblia. También la información de índice para cada versión de la Biblia es descargada en local para comprobar si los capítulos y versículos requeridos son válidos. La interfaz de l'extensión también se ha internacionalizado. La interfaz está traducida al italiano e al Inglés en su totalidad, y sólo parcialmente en español y francés. Los usuarios pueden contribuir traducciones de la interfaz de l'extensión a esta url: https://www.transifex.com/accounts/profile/bibleget.io/. Pueden crear una cuenta de usuario y solicitar el acceso a las traducciones de los proyectos BibleGet.

v1.0 (December 7th, 2014)

First release, after a 3 month development process with testing and debugging.

bibleget-openoffice's Issues

differentiate builds

Since OpenOffice on Windows is only 32bit, until now I have only built a 32bit version of the plugin, using 32bit Java.
But I wonder, would it perhaps be useful to build a 64bit version for Linux and MacOS, if users on these platforms are using the 64bit version of OpenOffice? That way we don't oblige them to install a 32bit JRE, they can stick with a 64bit JRE.

Especially if we start implementing JCEF, which not only has 32bit and 64bit versions, but also different builds for different platforms. Instead of releasing a single build, maybe we'll have to start building for different architectures and different platforms, and release multiple builds...

figure out how to package and distribute JCEF native libraries and make available to java.library.path

Now that the functionality for JCEF is created and tested and pretty much complete, we have to move to the next phase of figuring out how to package and distribute the JCEF native libraries and make them available to the java.library.path.

about this plugin menu item in the wrong place

ever since the new "search for verses by keyword" menu item was added, the "about this plugin" menu item is showing in the wrong place. I'm not sure why that is, because I didn't move it in the source code, I simply added the new "search" menu item where it should go... this needs to be looked into

JTextField uneditable when JCEF present, until JFrame loses focus

This is the weirdest thing. The JFrame contains:

• a JPanel with form fields (among which are some JTextFields)
• and a JInternalFrame that contains the JCEF component

The JCEF component only fully initializes when the JFrame becomes visible.
And the JTextFields are then uneditable, unless the JFrame loses and regains focus (click outside of the JFrame and then inside again, or close and open seeing that I don't fully dispose them, they keep their state when I close them).

So we need to find a way to make sure the JTextFields are editable when opening a frame with a JCEF component for the first time. Maybe a callback on JCEF initialized that makes the JFrame lose and regain focus automatically?

I opened a stackoverflow post here: https://stackoverflow.com/q/64622736/394921

implement JCEF

Currently, the Preferences window of the plugin for OpenOffice uses a JTextEditor with HTMLEditorKit provided by swing in order to provide a real time preview of the text formatting of the Bible quotes in HTML+CSS, based on the options selected in the preferences window.

This works kind of ok, but it has a lot of drawbacks. HTMLEditorKit is old technology now. It only supports HTML version 3.2 and CSS2, and it doesn't seem to be getting any new updates any time soon, looking at it's history.
Currently, the preview area is not capable of previewing line-height . It doesn't support either CSS3 or HTML5.

In the meantime I have updated the Google Docs plugin and the Microsoft Word plugin adding an HTML5 canvas element to the preview area which draws out a simulation of the document ruler, in order to preview the right and left indent tabs. This is a nice touch to the preview area. However it is impossible to implement with HTMLEditorKit, which has no support for HTML5.

I'm thinking that maybe the Jave Chrome Embedded Framework could solve this issue. If JCEF can be used in place of HTMLEditorKit, then all of the best web technologies should be available through the components it provides.

Now, OpenOffice on Windows is only 32 bit, so at least for this we would need to use JCEF 32 bit I believe. Which means the OpenOffice plugin builds should probably be differentiated once JCEF is implemented, seeing that JCEF is also platform dependent (different builds for different platforms). So we would have:

1. BibleGet for OpenOffice Win-32, built with JDK 1.8 x86 and JCEF Win32
2. BibleGet for OpenOffice Linux-32, built with JDK 1.8 x86 and JCEF Linux32
3. BibleGet for OpenOffice Linux-64, built with JDK 1.8 x64 and JCEF Linux64
4. BibleGet for OpenOffice MacOS-64, built with JDK 1.8 x64 and JCEF MacOS64

I initially created a JCEF branch in order to test development on this, which has been merged into the master and development branches in the meantime. Development continues on the development branch.

---

ready made builds of JCEF

https://github.com/jcefbuild/jcefbuild

How to load custom html using a data URI

https://magpcss.org/ceforum/viewtopic.php?f=17&t=14956

use png's instead of bmp's

In my latest tests, PNG image files with transparency are supported in the latest Open Office (currently 4.1.7). I wouldn't know how long this has been the case, but we can certainly do away with the BMPs now which use that terrible hack of magenta keying. This should reduce the size of the plugin and avoid artifacting on the menu icons.

translate new strings

A number of new UI components and message strings have been added for the upcoming 2.9 release. They need to be localized.

disable context menu on JCEF component

Probably wouldn't be a bad idea to disable the context menu on the JCEF component. No need to "print" or "view source" in these scenarios. Actually we want to avoid direct access to the source to help protect copyright etc...

Linux x64 build failing

so here's what we've got so far for a Linux build:

• the JCEF linux x64 build was built with JDK 11, so trying to use JDK 8 (1.8) will not work, the build will not succeed. Using JDK 11 works but introduces new problems: in order to dynamically load the JCEF native libraries at runtime we can use a reflection hack to reset the System user path and make sure that the path to the JCEF native libraries are in the user path and reset the java.library.path with this new path. However this hack only works with JDK 8, not with JDK 11. For JDK >= 9 there is however another approach using Lookup and MethodHandles (see https://stackoverflow.com/questions/15409223/adding-new-paths-for-native-libraries-at-runtime-in-java). This seems to be working, however the JCEF component is not being initialized...

• studying the sample application provided by the JCEF build for Linux x64 I can see that the LD_LIBRARY_PATH environment variable also needs to be set with the path to the JCEF native libraries. The plugin code is dynamically downloading the JCEF build from a github release and saving it to this folder: System user path + '/.BibleGetPluginOpenOffice/JCEF' . So this path is needed in the LD_LIBRARY_PATH environment variable. Perhaps this is all that is needed to get the JCEF component to work? So how do we set this environment variable? Can we reset it at runtime?

• For testing purposes I tried exporting the LD_LIBRARY_PATH variable in my Ubuntu 20.04 instance (I'm using WSL2 on Windows 10, and using X11 forwarding in order to be able to launch graphical interfaces = Netbeans, Apache OpenOffice...), and I added a System.out.println() in the code to see the value of the LD_LIBRARY_PATH variable. This shows me that the variable now contains paths that weren't in the variable before on the terminal, but it does not contain the path to the JCEF native libraries. So I'm guessing the Ant script in Netbeans is maybe overwriting this variable during the build? So next step to test a solution is perhaps to figure out how to set this variable in the Ant script? Or find a way to overwrite it again at runtime? I tried using the same method used to reset the java.library.path, to try and reset the LD_LIBRARY_PATH variable, but didn't succeed, it seems to generate an exception. And I don't believe it's a recommended approach, environment variables really should be set in the environment before launching a Java runtime and the JDK releases after JDK 8 have been discouraging overwriting these variables at runtime, they started showing warnings to discourage people from using this approach...

synchronization of threads

Issue #18 can almost be closed. However there is this one issue that needs to be dealt with first. There seems to be some trouble in synchronizing threads when issuing bash commands using ProcessBuilder and ExecutorService. The output of the bash command never completes in the StreamGobbler thread, which is unable to operate on the BibleGetIO.sysPkgsNeeded ArrayList in the main thread. How to deal with this? (more details of who, when, where and what coming soon)

detect libreoffice installation

when installing on linux where LibreOffice is already installed, OpenOffice might not be able to overwrite the soffice soft link in /usr/bin/soffice. In that case, perhaps we should give user feedback and give the choice of redirecting the soft link to openoffice (which is necessary in face for the BibleGet plugin for OpenOffice to work, since we create our own symlink to a launch script...

check for dependencies returning multiple strings

when checking the system for installed dependencies, sometimes more than one line is returned for each package, one line contains "installed" and one doesn't, resulting in a number of "not installed" "installed" consecutive strings.
In my current tests, the "installed" string is returned first, which means that the package would already have been removed from the array. So we can check against the array, if the package exists or not...

recreate cleanly the build environment

Building on my home laptop has succeeded since I started writing the plugin. Since until now I was the only one involved, I hadn't worried too much about recreating the build environment. However this is useful not only for community collaboration, but also in case the laptop breaks down and I need to recreate the build environment. So I started writing a Wiki page on the repo to document the process.

However, I am actually having trouble not so much getting the build to complete, as I am getting the plugin to run correctly once it's built, on my work PC, when following the steps I'm documenting in the wiki page. This will need to be addressed, the issue needs to be pinned down, before effectively being able to open to any kind of community collaboration!

allow any kind of dash in query

Other than regular dashes, any other kind of dash should be accepted so as to avoid unexpected errors (for example when someone copy/pastes a reference query that has an emdash in it).

This has been done already for the Microsoft Word add-on: 055a6e70c6f14d96ba7ffcf9d72b5152edcd2c0a.

And in the API endpoint engine: b658fa93a1f662d7dc61e538395d253504e0580f.

Implement Gradle

In order to make for a cleaner and reproducible build environment, it would be desirable to use some dependency management workflow such as Maven or Gradle, in order to be sure that all dependencies are met correctly for each release.

Once the build environment is recreated in a clean and sure manner (see #3 ), we will have to look into implementing a similar toolkit.

I have created a branch to deal with this change.