Többször is volt szó a LibreOffice.hu-n a TDF és a LibreOffice fejlesztésével kapcsolatban kiadott statisztikai tájékoztatókról (lásd itt). Aki pedig „rendszeresen” szerette nyomon követni – statisztikailag – a LirbeOffice fejlesztését, azok számára eddig is rendelkezésre állt az OpenHub statisztikai oldala. A statisztika szerelmesei azonban most még tovább örülhetnek…
A TDF bejelentette, hogy a LibreOffice fejlesztését „kívülről figyelők” számára egy átlátható weboldallal teszi egyszerűbbé a kódváltozás nyomon követését. Az élő statisztika a http://dashboard.documentfoundation.org/ weboldalon keresztül érhető el.
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.
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.
Hyphenation in cells and shapes was fixed a few days ago for Catalan (for example, paral·lel » paral-lel, instead of parall-lel), Hungarian (eg. asszonnyal » asz-szony-nyal instead of az-szoy-nyal) and Dutch (eg. omaatje » oma-tje instead of omaa-atje, cafeetje » café-tje instead of cafeét-je). Swedish, Norwegian and partly Dutch need only hyphenation dictionary extension to support non-standard hyphenation in LibreOffice, Greek and Dutch need also Writer and Calc/Draw (editeng) development to support the alternation after the hyphenation break. More information: bug 63711 (closed), bug 42383 (open), Hyphen library (see tests/unicode.* example for non-standard hyphenation patterns of Dutch, Greek, Norwegian and Swedish).
I would like to show you two recent improvements in local help system of LibreOffice.
Indentation and syntax highlighting of Basic code examples
Basic code examples were hard to read in LibreOffice help, because code blocks were not indented. Also, people got used to syntax highlighting in editors.
By LibreOffice 4.0 I made the code examples indented with some scripts and a bit of manual work. I also tweaked help-to-wiki conversion script, so online WikiHelp of LibreOffice 4.0 will feature syntax highlighting of Basic code examples.
For the local help content, my idea was to re-use SyntaxHighlighter class from svtools in help compiler, so we could add the colors build-time, without modifying the source and create work for translators. Dávid Vastag, a university student, who worked with Novell Hungary as a trainee, helped me to implement this feature in help compiler. The following screenshots show how an example Basic code is rendered in different versions of LibreOffice help.
Size reduction of local help
When I studied help XML files, I noticed that many of the tags and attributes are not needed run-time. Some of them are even completely obsolete, and are not needed at all. However a mass clean-up in the source would not be desirable, it can cause extra work for translators for example. My idea was to apply a stylesheet to each file in the help compilation phase. I created compact.xsl, which removes comments, whitespace, and unnecessary tags and attributes. The size of en-US Windows MSI help pack decreased from 7.83 MB to 5.14 MB – 34% less!