After releasing Hunspell 1.7 with several improvements, including the fast and better spelling suggestion, I publish the extended version of my presentation at LiboCon, Tirana: LibreOffice Language Technology – News & Best practices. I suggest checking its content especially for members of native language groups. I have listed several ideas, examples and code pointers to improve the support of your language in LibreOffice, helping your LibreOffice users.
Our success story in a nutshell and on 54 slides (extended version of my presentation at LiboCon, Tirana) : fixing more than 30 serious interoperability and usability problems of LibreOffice during 3 months, gallery of our nice results and introduction of our mentoring program with the secret sauce: Building a LibreOffice development team.
On LibreOffice Cambridge Hackfest and the days after it I hacked on exporting custom shapes to DrawingML. (The “Part 2” in title indicates that there is a Part 1, the work I did on FOSDEM Hackfest, earlier this year.)
It was drawn to my attention, that my commits caused “regression” in the sense that the wrong export became even worse in some cases (e.g. tdf#90338). I was also aware of some imperfections.
Screenshots worth a thousand words, so here is the result of my recent work.
On the FOSDEM 2015 LibreOffice Hackfest I tried to improve DrawingML export of custom shapes.
Before my work DrawingML custom shape export handled only custom shapes which were imported from OOXML. In that case the equations of the custom shape are created in a way that the actual modifiers are the same for both the ODF and OOXML equations.
When the original shape is not from OOXML, then taking the adjustments without modification no longer works. Full conversion of all ODF equations back to OOXML would have been more work, not for 2 days of the hackfest, but I improved the export by exporting “non-OOXML shapes with adjustments” as polypolygons. This gave the correct view result in many cases.
Here is the result of my work. Not all shapes are correct, but there are big improvements, for example arrows, stars, and many other shapes look good now in OOXML export. This is good for now, until the real solution – full ODF <-> DrawingML conversion of shape equations – is implemented.
LibreLogo.org is a new portal dedicated to the easy, Logo-like programming environment of LibreOffice for turtle vector graphics. Main topics: introduction of LibreLogo (see here), development news, education, graphic design and free culture. A short illustrated list of the recent English language articles:
In large organizations there is a need for central configuration management of desktops, including LibreOffice deployments. The new Windows registry configuration backend allows integration of LibreOffice into Windows Server environments. LibreOffice can be configured with Group Policy Objects. Under Linux, configuration packages can be managed with Remote Root, which is an easy to use, new open source central management solution for Linux (or other package based) systems. You can download my slides of my FOSDEM2014 talk.
NOTE: this development had some regressions temporarily and removed from LibreOffice 4.2.5 (except the hard hyphen related fix) on 2014-05-29, but later it was fixed for LibreOffice 4.3 (2014-07-30).
Hyphenation is for better text layout. Ironically, LibreOffice’s hyphenation sometimes did the opposite. It seems, changing to ICU’s line breaking algorithm and allowing words with hyphen characters in spell checking have resulted a double regression in the hyphenation of OpenOffice.org. I believed, that the first problem (often missing hyphenation of words with ending punctuation) is only related to the Graphite layout, see my old bug report with typesetting examples: https://sourceforge.net/p/silgraphite/bugs/37/. I recognized and fixed the last problem (competing libhyphen and ICU based line breaking) in LibreOffice a few years ago on a very tricky way (hyphen replacement by the hyphenator), but not so later I had to remove this patch to fix a new problem raised in the French hyphenation (https://bugs.freedesktop.org/show_bug.cgi?id=43931 Unwanted behaviors due to Hyphen 2.8.3 (French hyphenation)). A few weeks ago I began to fix these problems, and now at the LibreOffice conference hackathon I have successfully solved them. The associated bug (https://bugs.freedesktop.org/show_bug.cgi?id=56392) contain the test document of the following screenshots (before-after). Many thanks to bug reporter “stfhell”, bug tracker contributors, LibreOffice conference and hackathon organizers and the sponsor of the conference hackathon, CloudOn.
Note: From LibreOffice 4.2.5, the wildchard character sequence is .* (dot asterisk) instead of the plain * (asterisk) – 2014-06-04.
A new patch of Autocorrect feature allows the text replacement before or after arbitrary affixes depending on the starting or ending wildcard character * in the Autocorrect Replace pattern. This is a small, but useful enhancement in word processing, especially for affix rich languages, but I will show a nice improvement for French typography, too, using this feature.
For example, with the “i18n*” → “internationalization” item Autocorrect will find and replace i18ns with internationalizations, too. Hungarian spelling dictionary handles two thousand suffixes of a given noun, dozens of them are quite frequent, simply exceeding the limitations of the old Autocorrect feature. With the new patch and the modified Autocorrect list LibreOffice will be able to handle all forms of serious misspellings and common abbreviations, that is a real innovation for Hungarian and similar languages. But the following examples help the word processing in English and other languages, too:
- Typographic correction of ellipses (with the precomposed ellipsis character U+2026): *… → …, eg. word… → word… (see below on the screenshot)
- The same combined with quotation marks: “…* → “… and *…” → …”, eg. “…and a quote…” → “…and a quote…”
- Simplified input for special symbols: *%o → ‰, eg. 7%o → 7‰
- French punctuation. LibreOffice has got only a poor man’s input method for French typography, inserting full long (“typewriter”) spaces before question and exclamation marks, colon and semicolon, and before and after guillemets (only Graphite fonts Linux Libertine G and Biolinum G support French typography well). With the new Autocorrect patch and with the following replacements, it’s possible to get better spaces in the case of Unicode fonts with narrow no-break space (U+202F): *! → ! (U+202F !), * ! → ! (a replacement for the same sequence to avoid multiple insertion of narrow no-break space) etc. It seems, this could be a general method, because missing narrow no-break spaces are replaced by normal spaces (like in the recent poor man’s method). But fonts with narrow no-break spaces, like DejaVu Serif, Liberation Sans and Serif, Linux Libertine and Biolinum (also not Graphite versions) give better French typography (to use the new method, switch the French poor man’s method off in the Localized options of Autocorrect settings):
Miklos Vajna has blogged about Free Software Conference and Exhibition 2013 already. This annual conference organized by FSF.hu, held in Budapest, Hungary usually has 5-600 visitors. In addition to Miklos’ presentation and workshop there were two more LibreOffice related presentations in the programme. Andras Timar presented the new features of LibreOffice 4.1 with an emphasis on the work of Hungarian contributors. László Németh shared many tips and tricks about desktop publishing and typography in LibreOffice Writer. So in total there were 3 LibreOffice presentations, a workshop and a booth with stickers and LibreLogo manuals.