The Document Foundation Planet


February 08, 2016

Gülşah Köse

Academic Informatic Conference 2016

Academic Informatic Conference's organized at Adnan Menderes University,  Aydın, Turkey. Academic Informatic Conference is 18 years old huge and very important organization for free softwares. Volunteer educators gave 39 courses about free softwares. There was 100+ educators and 1500+ attendees at the courses and 3500+ conference attendees.

We've done LibreOffice Development Workshop for four days. We wanted to build LibreOffice from attendees before the workshop. Because of poor internet connection for the first and second day, our workshop hitched. Nevertheless, 13 patch was merged during the workshop. And we brought in two new contributors. +Erdem Demirkapı  and +Nurhak Altın . We hope they will continue to contribute.

LibreOffice Development Workshop

After the courses conference started. We gave a talk about LibreOffice Development and Localization Works in Turkey with +Necdet Yücel . Our session was fulled. Presentation is here.

LibreOffice Development and Localization Works in Turkey
Necdet Yücel, Gülşah Köse
We look forward hackfest will organize in Turkey and hope to next year we will talk about more development and localization works.

by Gülşah Köse ( at February 08, 2016 11:12 AM

February 07, 2016

LibreOffice Design Blog

What do you expect from Libreoffice Draw in the future?

Libreoffice promotes its graphic tool with the words:

‘Draw lets you produce anything from a quick sketch to a complex plan, and gives you the means to communicate with graphics and diagrams. Draw is a an excellent package for producing

by The LibreOffice Design Team at February 07, 2016 06:16 PM

February 04, 2016

Jan Iversen

Camp in Turkey, produces patches to LibreOffice


One of our new contributors attended a programming camp in Turkey, this resulted in patches for Libreoffice.

A big “thank you” to Kader and her friends. We are currently studying possibilities for a LibreOffice hackfest in Turkey as we expect many applicants to GSoC.

If you want to join a triving community, having fun making changes to one of the largest opensource projects in the world, do not hesitate to contact us

Please remember LibreOffice and opensource are all about having fun, because we are volunteers and use our spare time. In todays world, being able to write “I helped LibreOffice” on your CV, opens many doors for developers.


by jan at February 04, 2016 10:37 AM

February 02, 2016

Jan Iversen

GSoC preparations.


With FOSDEM 2016 done, it is time to concentrate on GSoC.

We see a lot of student submitting patches in order to ease the GSoC qualifications. Submitting patches and showing interest for the community are clearly a good start for being accepted. However we see many patches that are mechanical changes (search/replace) in the source, such patches shows little (if any) understanding of what development is.

A succesful patch, is one that shows understanding for the code. If a student shows (with a patch) understanding for how C++ works, it is a plus in my mind, whereas mechanical changes are actually a minus in my mind.

We are available to help, through email or IRC, so feel free to ping us, but please try to make quality patches. Sending multiple patches with the same error is not a GSoC qualification, but a single well thought over and implemented is the first step to qualify.

We look very much forward to GSoC and to mentor students who want to help make LibreOffice an even better product.

Let us together make GSoC 2016 and LibreOffice a period to remember.

by jan at February 02, 2016 01:06 PM

February 01, 2016

Andras Timar

Exporting custom shapes to DrawingML – Part 3

On LibreOffice FOSDEM 2016 Hackfest I continued to work on DrawingML export of custom shapes. (See also Part 1 and Part 2 of this work.)

This time I worked on export of flipped and rotated custom shapes, and I made progress. Check out the screenshots below.

Colorful rotated arrows in an ODF document in LibreOffice Writer

Colorful rotated arrows in an ODF document in LibreOffice Writer

DOCX export of the file opened in Word 2010 before the patch

DOCX export of the file opened in Word 2010 before the patch

DOCX export of the file opened in Word 2010 after the patch

DOCX export of the file opened in Word 2010 after the patch

by timar at February 01, 2016 10:26 AM

January 31, 2016

Michael Meeks

2016-01-31 Sunday.

  • Up early; breakfast meeting near the ULB. Sat in a corner writing slides at great length - a terrible use of good time at FOSDEM - when I should have been chatting to people. Frustrating to see them passing and have no time; made some progress at least with Kendy's help.
  • Gave my talk; slides as hybrid-PDF below:
    Slides of Scaling and Securing LibreOffice on-line: hybrid PDF

January 31, 2016 07:05 PM

Miklos Vajna

Mail merge embedding in LibreOffice Writer FOSDEM talk

Yesterday I gave a Mail merge embedding in LibreOffice Writer talk at FOSDEM 2016, in the Open document editors developer room. The room was well-crowded — seems this year LibreOffice Online was a hot topic. ;-)

We also had a hackfest with about 20 hackers attending, (again) kindly hosted by Betacowork on Thursday and Friday, before FOSDEM.

There were a few topics I hacked on:

  • .uno:Paste AnchorType param for Writer

  • tdf#97371 DOCX import regression fix about TextBoxes

  • tdf#96175 RTF export feature about company doc property

  • refactoring around Writer’s new (in 5.1) hide-whitespace feature, as requested by Ashod

  • code coverage: RtfExport::WriteRevTab() was completely untested previously, now fixed

A full list of achievements is available, if you were at the hackfest and you did not contribute to that section, please write a line about what did you hack on. :-)

Quite some other slides are now available on Planet, don’t miss them.

January 31, 2016 10:45 AM

January 30, 2016

Michael Meeks

2016-01-30 Saturday.

  • Up; mail chew, breakfast with Kendy; to the venue ... caught up with lots of old friends; exciting times. Announced our exciting partnership with Kolab - really looking forward to working closely together.
  • Out for LibreOffice dinner, not improved by transient dancer - but improved by good company. Back to the hotel late - up until 4:30 am or so working on my talk.

January 30, 2016 09:00 PM

Official TDF Blog

Tender for a Quality Assurance Engineer (#201601-01)

The Document Foundation (TDF), the charitable entity behind the world’s leading free office suite LibreOffice, seeks a

Quality Assurance Engineer

to start work as soon as possible.

The role, which is scheduled for 20 hours a week, includes amongst other items:

  • keep a continuous overview and reporting on the state and progress of LibreOffice QA as seen on its bug trackers, mailing lists, Gerrit, and other tools and communication channels (e.g. Jenkins, IRC)
  • foster communication between QA and other teams
  • help community outreach to encourage more people to join the QA team and help onboarding new QA contributors
  • provide and

by Italo Vignoli at January 30, 2016 05:17 PM

Jan Iversen


Attending FOSDEM2016, for the first time with my new LibreOffice hat on. It is nice to meet old and new friends/collegaues.

I gave a speech about lowering the bar for new contributors. You can see the slides attached:


by jan at January 30, 2016 01:42 PM

January 29, 2016


Choosing line alignment in LibreOffice


The Alignment tab of a LibreOffice paragraph style has four ways of positioning text on a line: Left, Right, Centered, and Justified. In practice, however, Right is used mostly for highly-formatted documents such as brochures, while Centered is mostly reserved for titles and sub-titles. For body text, the choices are usually Justified, in which the left and right sides of the text column align with both the left and right margins, and Left or “ragged right,” in which only the left side of the text column aligns consistently with a margin. Asked to choose between Justified and Left alignments, most users will choose Justified — but the choice is not as simple as you might think.


Left vs. Justified Alignment

The preference for a justified alignment dates to the early days of computers. On most typewriters in those days, the only choice was a left alignment. By contrast, a professionally printed page was almost always justified. When the first word processors appeared, suddenly anyone could print a justified page, and, wishing to look professional, that was what most people chose.

The trouble is, a Justified alignment often requires more work to make it look acceptable.

Too often, it results in irregular spacing between characters or words that looks far worse than Left alignment ever could. You almost always need to tinker to find the best distribution of characters and words on a line.


Generally, too, the shorter the line, the harder you have to work to make Justified work. As a rule, lines of less than 40 characters are too much effort to be worth justifying. A Left alignment can have the same problems, but they are often less severe, especially in columns or tables.

The easiest way to tell if a paragraph style can easily use Justified is to set it up with dummy text, and count the number of lines that end in a hyphen, and the blotches of irregular white space.

By contrast, a Left alignment requires less work. A ragged right alignment may not always look as finished as a justified one, but it requires less effort, and is usually good enough for most purposes. In fact, typographical fashion today rebels against justified alignment, and even professional publications sometimes deliberately chooses a left alignment — all of which explains why LibreOffice Writer defaults to a left alignment.

The Last Justified Line

If you do decide to use a justified alignment, one problem you will consistently have is that the last line of justified text is only a complete line by luck. Almost always, it is an incomplete line.

LibreOffice offers several choices of how to handle this problem. Frankly, though, you have to wonder why. The others all leave large gaps between words or letters that anyone who cares about the design of their documents should find unacceptable.


The only consistently aesthetic choice is to set the Last line field to Left. This selection is the only one that eliminates the impossible situation of trying to justify a line of text that is too short and has ugly gaps in it.

The other options, Justified, Centered, Expand single word, and Left, all look awkward. The only reason to use any of them is to provide a sample of why they are unacceptable.



You may be able to improve the look of Justified by selecting Snap to Text Grid (If Active) and adjusting the grid set in Tools > Options > LibreOffice Writer > Grid. However, getting an acceptable look is likely to take a lot of trial and error.

Choosing a left alignment is typically less work than insisting on a justified alignment, especially in columns or tables. However, be aware that any text can have problems, especially if lines are hyphenated or less than forty character lines.

Setting hyphenation

No matter which alignment you choose, its success can depend on whether you choose to hyphenate. Given a normal line length of 55-75 characters, hyphenation can sometimes improve the spacing between words and characters with a justified alignment. However, in a left alignment, whose lines end at different places on the right, allowing hyphens sometimes adds to the clutter. Moreover, no matter what the alignment, the shorter the line, the more hyphenation can be a problem unless you are willing to adjust the settings.

Hyphenation options are set on the Text Flow tab. You can try to improve hyphenation by adjusting the settings on the Text Flow tab. The number of letters at the end and start of the line should be 1–4. Sometimes, the Characters at line end and Characters at line begin fields can sometimes be manipulated to improve hyphenation by playing one off against the other. Working by itself, the Maximum number of consecutive hyphens field can also make a difference. The typographical convention is not to allow more than two lines in a row start with a hyphen, so whatever you can do to eliminate hyphens should be an improvement.



Mercifully, in many documents, only the Text Body paragraph style and perhaps another handful of related styles are used often enough to require adjusting hyphenation. Headings, which are rarely more than a few words long and almost never more than two lines, generally do not need to be hyphenated at all. If anything, headings are easier to scan if not hyphenated.

Tweaking alignment and hyphenation



You may be able to improve your alignment and hyphenation choices by adjusting:

You may want to change the hyphenation by adjusting:

  • The Hyphenation settings on the Text Flow tab.
  • The font weight or size.
  • The choice of fonts.
  • The settings for Tools > Options > Language Settings > Writing Aids > Options > Minimal number of characters for hyphenation. These settings are over-ridden by any formatting in the document itself.
  • The Scale width and Spacing fields on the Position tab to expand or condense character spacing. Frankly, these fields are a last desperate measure, since they are difficult to use.

In addition, if you do hyphenate, the line divisions can be improved by running Tools > Language > Hyphenation as a final touch on the document. This tool not only works interactively, giving you more control, but also generally does a better job than the on-the-fly hyphenation, if run when the document is complete.

For extra fine-tuning, go through a document when it is complete, and hand-hyphenate by positioning the cursor between syllables and pressing Ctrl+ -. This key combination creates a conditional hyphen that only comes into play when it is in the hyphenation zone near the right margin.

Alignment and hyphenation may seem like simple choices. However, making decisions about them is not as simple as merely imitating what you think professionals designers prefer. Instead, making the best choice is a matter of many other formatting choices. In the end, the right choices are the ones that together make your document easiest to read — and what works for one document may not work for another.

By Bruce Byfield

by wlmanager at January 29, 2016 09:22 PM

Michael Meeks

2016-01-29 Friday.

  • Up; off to the hack-fest; lots of hack-fest'y work. Spent some considerable time successfully hacking at per-user memory usage for tilebench - with some considerable success. Discussed some awesome testing work Markus is doing - encouraging.
  • Out for a fine meal with Georg, Aaron & the Kolab guys. Checked in to the hotel, wandered the Delirium crush, back for some more slide'y action.

January 29, 2016 09:00 PM

January 28, 2016

Michael Meeks

2016-01-28 Thursday.

  • Up; breakfast with Norbert, quested through the town un-successfully for night/tooth-guards - pharmacies don't sell them, nor the sports-shop I tried; interesting - its enough to make you grind your teeth.
  • Arrived; poked with Lionel at his nasty event ordering bug inconclusively; met lots of fun GNOME guys, lots of LibreOffice hackers. Meeting with Kendy & Miklos, worked through some mail. Out for a dinner nearby in the evening, and back - waffles.

January 28, 2016 09:00 PM

Jan Iversen

Hackfest in Brussel as a prelude to FOSDEM.


The hackfest in Brussel has started, at noon the first day we were around 20 people.

A hackfest is a good way to get to know people. If you are thinking of helping out with one of the biggest open source projects. At LibreOffice we welcome new people, come and see us.

FOSDEM this weekend is also a good posibility to talk with the developers.

have fun.

by jan at January 28, 2016 11:21 AM

January 27, 2016

Michael Meeks

2016-01-27 Wednesday.

  • Into Cambridge, heading eventually for the Eurostar this evening - construction workers dug up an un-exploded bomb there; got to the office; paperwork. Went over financials with Tracie.
  • Trains to Brussels variously; to the Astrid - synched with JanI, good to catch-up with Markus at length; others arrived later for beers, to my room; finished VCL slides very late; bed.

January 27, 2016 09:00 PM

Kohei Yoshida

LibreOffice mini-Conference 2016 in Osaka

<figure class="wp-caption alignnone" id="attachment_1879" style="width: 300px">Night view in Osaka, overlooking the Metropolitan Expressway.<figcaption class="wp-caption-text">Night view in Osaka, overlooking the Metropolitan Expressway.</figcaption></figure>


First off, let me just say that it was such an honor and pleasure to have had the opportunity to present a keynote at the LibreOffice mini-Conference in Osaka. It was a bit surreal to be given such an opportunity almost one year after my involvement with LibreOffice as a paid full-time engineer ended, but I’m grateful that I can still give some tales that some people find interesting. I must admit that I haven’t been that active since I left Collabora in terms of the number of git commits to the LibreOffice core repository, but that doesn’t mean that my passion for that project has faded. In reality it is far from it.

There were a lot of topics I could potentially have covered for my keynote, but I chose to talk about the 5-year history of the project, simply because I felt that we all deserved to give ourselves a lot of praises for numerous great things we’ve achieved in this five years time, which not many of us do simply because we are all very humble beings and always too eager to keep moving forward. I felt that, sometimes, we do need to stop for a moment, look back and reflect on what we’ve done, and enjoy the fruits of our labors.


Though I had visited Kyoto once before, this was actually my first time in Osaka. Access from the Kansai International Airport (KIX) into the city was pretty straightforward. The venue was located on the 23th floor of Grand Front Osaka North Building Tower B (right outside the north entrance of JR Osaka Station), on the premises of GMO DigiRock who kindly sponsored the space for the event.
<figure class="wp-caption alignnone" id="attachment_1872" style="width: 300px">Osaka Station north entrance.<figcaption class="wp-caption-text">Osaka Station north entrance.</figcaption></figure>


The conference took place on Saturday January 9th of 2016. The conference program consisted of my keynote, followed by four regular-length talks (30 minutes each), five lightning talks (5 minutes each), and round-table discussions at the end. Topics of the talks included: potential use of LibreOffice in high school IT textbooks, real-world experiences of large-scale migration from MS Office to LibreOffice, LibreOffice API how-tos, and to LibreOffice with NVDA the open source screen reader.

After the round-table discussions, we had some social event with beer and pizza before we concluded the event. Overall, 48 participants showed up for the conference.
<figure class="wp-caption alignnone" id="attachment_1907" style="width: 300px">Conference venue.<figcaption class="wp-caption-text">Conference venue.</figcaption></figure>

Videos of the conference talks are made available on YouTube thanks to the effort of the LibreOffice Japanese Language Team.

Slides for my keynote are available here.


We also organized a hackfest on the following day at JUSO Coworking. A total of 20 plus people showed up for the hackfest, to work on things like translating the UI strings to Japanese, authoring event-related articles, and of course hacking on LibreOffice. I myself worked on implementing simple event callbacks in the mdds library, which, by the way, was just completed and merged to the master branch today.

<figure class="wp-caption alignnone" id="attachment_1888" style="width: 300px">Many folks hard at work during hackfest.<figcaption class="wp-caption-text">Many folks hard at work during hackfest.</figcaption></figure>


It was great to see so many faces, new and old, many of whom traveled long distance to attend the conference. I was fortunate enough to be able to travel all the way from North Carolina across the Pacific, and it was well worth the hassle of a jet lag.

Last but not least, be sure to check out the article (in Japanese) Naruhiko Ogasawara has written up on the conference. The article goes in-depth with my keynote, and is very well written.

Other Pictures

I’ve taken quite a bit of pictures of the conference as well as of the city of Osaka in general. Jump over to this Facebook album I made of this event if you are interested.

by Kohei Yoshida at January 27, 2016 04:19 AM

January 24, 2016

Official TDF Blog

R.I.P. John McCreesh

533120_10151138749737628_577502702_nJohn McCreesh, a founding member of The Document Foundation and the author of the project “manifesto“, has suddenly passed away on Saturday, January 16, at the age of 61.

This is an extremely sad time for The Document Foundation, as John has been a friend of every project founder, and often a mentor for the younger members. Without his work as a volunteer, the free office suite environment would have not been what it is today.

In fact, John wrote the original OOo Strategic Marketing Plan, which was instrumental for the growth of the project from 2004 to …

by Italo Vignoli at January 24, 2016 07:47 PM

Chris Sherlock

Why I love hacking at LibreOffice

The LibreOffice codebase is, to be frank, messy. This isn't a criticism of previous developers - it's still an amazing product and an amazing feat of programming given the number of platforms it runs on. The StarView guys, and later development team, did a great job. For instance, I was reading up on the font mapping code and I often saw Herbert Duerr's name, and I've got nothing but respect for the work that he did and his dedication to the project.

Unfortunately, the messiness is the result of a codebase that was first created in 1988 and has been actively worked on and changed directions a number of times. So... what is it that I love about working on LibreOffice?

In a word: the people. I've never met any of my fellow hackers in person, only a few phone calls to Michael Meeks and listened in on some Collabora meetings when I did some work for them. Mostly I stick around the IRC channel and keep an eye on the mailing list.

On the IRC channel, however, I've noticed the good humour and tolerance of the developers towards those not as expert as themselves. For example, Stephan Bergman (sberg) is the go to guy in terms of anything C++ related - and the other day he helped me out with a tricky bit of code (well, I thought it was tricky) related to the equality operator. Tor Lillqvist, as another example, is a diamond in the rough IMO and has often pointed me in the right direction when I'm online. And I cannot forget to mention Norbert Thiebaud (shm_get on IRC) for his constant maintenance of Jenkins (a thankless task!) and gerrit. These are literally just some of the folks who I interact with all the time and just a small sample of the folks who work on the LibreOffice project.

Without the goodwill and encouragement of the folks who hack away daily on the LibreOffice project, I doubt I'd be able to work on the small part of the codebase that I have chosen to improve. In fact, there is an active outreach program currently being run lead by Jan Iverson (JanIV on IRC) and there are quite a few commits coming in from newbies of all stripes. This is leading to some real improvements in the code, for instance new developer Dipankar Niranjan did a whole series of commits to remove the "dog-tag" code from the VCL module (the "dog-tags" was a way of attempting to ensure that Windows weren't deleted at the wrong time, but was a total hack and has been solved by VclPtr) - this has recently allowed sberg to remove ImplSVEvent::maDelData. Seeing the code evolve is also highly enjoyable :-)

There are so many more examples of this it's just not possible for me to list them in this post. It's interesting that LibreOffice has made so much traction in the last year in terms of code quality - whilst the UI hasn't changed hugely (though that is going to change I suspect in the next year!) the incremental improvements have been increasing at a rate of knots and folks are beginning to notice the positive effects. One user, who will remain nameless but is an active follower of the LibreOffice development process, told me that he noticed that the 5.x release was very much more responsive and stable that the 4.x series... and amusingly commented that "it's remarkable how interesting it is to watch the development of such an intrinsically boring type of software".

So there you have it, the reason I love hacking at LibreOffice is the people who work on it! May it ever be this way.

by Ta bu shi da yu ( at January 24, 2016 10:35 AM

January 23, 2016

>Pranav Kant

Update on Libreoffice and GNOME integration

It’s been a long time I have talked about the project that I started with GSoC 2015 some time back. We reached at pretty much exciting results by the end of the summer where we could see the integration working pretty well with LibreOffice. We finished and merged all the major work on the Libreoffice side alongwith just-made-it-work integration with gnome-documents. Things were still in the development stage for gnome-documents, and we needed good amount of effort to get it merged upstream.

Things moved pretty slow on the integration because from time to time during the integration I would realise that I had missed something in LO, and I need to fix it before I could move forward with the integration. I would then jump back to LO, fix it, and switch back to gnome-documents, and so on. But it was only till Dec 2015 that things were slow. I suspect this thing to be the turning point. Bastien, [Debarshi] (, and Cosimo held the string from gnome-documents side, and started working with my earlier WIP work/patches for gnome-documents. There were many issues that needed to be fixed for the proper ready-to-merge LO integration, and better user experience. But I was lucky now that I had the experts to take care of it.

As I expected, there were still some minor fixes to be done on LO side which they found out during the integration. Bastien would report LO related bugs; I would fix them in LO; David would help with the reviews, and build and ship the package for us. As I write this, I am glad and feeling proud that we are now there with most of the work already merged upstream in gnome-documents. With LO 5.1 release just few weeks away, gnome-documents seems to be all set to integrate LO with its next major release, 3.20.

Here is the screencast I made running gnome-documents master with LO 5.1.0 rc2 koji build on fedora. There are bug fixes that couldn’t make to LO 5.1, and some more that you will uncover as you use this. :) So, it might take little more time (one more release, maybe) while it settles down. Note that LibreOfficeKit API (to expose LO functionality) is still unstable, but the widget is quite usable in the view-only mode, and that is how we have integrated it in gnome-documents for now.

Screencast is here :

<iframe allowfullscreen="" frameborder="0" height="315" src="" width="560"></iframe>

Earlier, gnome-documents was converting these non-supported formats into PDFs using unreliable command unoconv, which sometimes would not give good results especially with spreadsheets where it would scramble things up during the conversion. With the use of this new widget, now, you would see the documents as they exactly are, unless you do not have LibreOffice installed on your box in which case it would pop up an error asking you to install LibreOffice.

If you want to try it out yourself, you need to build atleast LibreOffice 5.1.0 rc2 and gnome-documents master branch. If you are on fedora, you can use this koji build to install LO 5.1.0 rc2 on your box, and you can use jhbuild to build gnome-documents from master. Running gnome-documents now should automatically make it to use LibreOffice in the background.

I would like to thank all the people, aforementioned, Bastien, Debarshi, and Cosimo to finish the GNOME integration with LibreOffice. On the LibreOffice side, Miklos and Michael with whom I started this GSoC project, and David Tardon who has helped us ship the LO package with much needed fixes in time.

While I am at it, I also want to announce about my new job at Collabora Productivity where I would be hacking on LibreOffice full-time. It would be an exciting and wonderful learning experience for me. I am greatly looking forward to it.

January 23, 2016 12:00 AM

January 22, 2016

LibreOffice Design Blog

Way Down In The Libreoffice Menus


With the release of LibreOffice 4.4 last year, we began making incremental updates to the main menus, with the major overhaul happening in the upcoming 5.1 release. The work is guided by LibreOffice’s new Human Interface Guideline (HIG), …

by The LibreOffice Design Team at January 22, 2016 02:59 PM

January 20, 2016

Charles Schulz

In Memoriam of John McCreesh & FOSDEM 2016

I was about to write about the main topic of this post, namely FOSDEM 2016 when we learned of the death of someone who was a really nice and gentle human being, John McCreesh. For those who may not know John, it’s important to say that while he was not as famous as Ian Murdock, he was definitely one of the pillars of the community for long years. He served as a volunteer there in various capacities, but mostly as one of the marketing project lead. During his tenure, he had to deal with complicated situations and several challenges. John was, I already wrote it, a gentle human being. He managed to help build and strengthen the community and make it bloom even when times were dire. He was nice, always listening to others, soothing and comforting people around him. John knew the value of peace and moving forward. His origins (he was born in Northern Ireland if I’m not mistaken and his family origins are quite interesting in that regard) and upbringing made him respect anyone who was coming towards him and his welcoming stance gained him many friends and many open source volunteers. In some cases, his generous and kind attitude helped him make people stay in the project even as they had every obvious reasons to leave.

It is not known that John was one of the key people who helped push the LibreOffice project. He had no desire to appear as a leader, and no more time to contribute as his new involvement in the local government left him little time. We have lost a beautiful and precious being – I could sign this with my Document Foundation hat anytime.

Let’s now get back to the original topic: FOSDEM 2016. I will be there at the LibreOffice booth and I’m quite excited about it. I do not yet know if I will have time to attend all the sessions I have bookmarked but below are a few of them. Hopefully we will meet there?
OpenDocument Editors room: an obvious choice. But there are some really nice sessions there, especially if you want to hear about the Android and cloud versions development.
Desktops room: Converged experience with Ubuntu phone apps. This one is going to be popular I think. Have a seat in advance.
Open Source Design devroom: intriguing. I like that these kind of initiatives exist and such talks can take place at FOSDEM.
Security Devroom: there’s the first session about PCI-DSS testing that could be quite good… let’s see.
Guile track: functional package management with Guix could be quite fun. In fact, Guix is really fun and promising I think.
Distros track: the whole track is a must, I will really try to attend it.
– So is the Office track. Seriously, Michael Meeks will introduce you to LibreOffice Cloud version. Just be there!
Virtualization track: microdatacenter with Raspberry pi and Kubernetes. Waow. Much good. Must go. Nice. Super cool.

I hope to see many of you at FOSDEM!

by Charles at January 20, 2016 09:47 PM

Stephan Bergmann


Some notes on building LibreOffice master (towards LO 5.2) with recent GCC trunk (towards GCC 6.0):

  • I ran into two open bugs with GCC that for now need workaround patches to be applied to LO:
  • (There was also another test breaker that took a while to track down as “Make sure desktop under LOK does not see osl_setCommandArgs CommandLineArgs.” But that one was not caused by any sort of mis-compilation, but rather by the fact that LO, when mistakenly asked to open a dynamic library as a document, happens to auto-detect an ELF library built by GCC 6 as a MacPaint document, while it auto-detected such libraries built with older GCC versions as plain text Writer documents.)
  • All the other (minor) fixes and tweaks have gone into the LO code base by now, and make check succeeded for me for both an (implicitly) --disable-debug as well as an --enable-dbgutil build (on some random Fedora 22 Linux box).
  • (With the caveat of having to --disable-firebird-sdbc in the --disable-debug case due to some error during building of that notorious external module,
    make -f ../gen/Makefile.refDatabases empty_db
    make[4]: Entering directory 'lo/core/workdir/UnpackedTarball/firebird/gen'
    make -f ../gen/Makefile.static.createdb
    make[5]: Entering directory 'lo/core/workdir/UnpackedTarball/firebird/gen'
    make[5]: Nothing to be done for 'all'.
    make[5]: Leaving directory 'lo/core/workdir/UnpackedTarball/firebird/gen'
    rm -f empty.fdb
    ../gen/firebird/bin/create_db empty.fdb
    invalid request BLR at offset 24
    -Too many Contexts of Relation/Procedure/Views. Maximum allowed is 255
    ../gen/Makefile.refDatabases:66: recipe for target 'empty.fdb' failed
    make[4]: *** [empty.fdb] Error 254
    make[4]: Leaving directory 'lo/core/workdir/UnpackedTarball/firebird/gen'
    Makefile:275: recipe for target 'empty_db' failed
    make[3]: *** [empty_db] Error 2
    make[3]: Leaving directory 'lo/core/workdir/UnpackedTarball/firebird/gen'
    Makefile:6: recipe for target 'firebird_embedded' failed
    make[2]: *** [firebird_embedded] Error 2
    make[2]: Leaving directory 'lo/core/workdir/UnpackedTarball/firebird'
    lo/core/external/firebird/ recipe for target 'lo/core/workdir/ExternalProject/firebird/build' failed
    make[1]: *** [lo/core/workdir/ExternalProject/firebird/build] Error 1

    which I have not been able to track down yet.)

  • The most common new warning encountered was -Werror=misleading-indentation. We already have a Clang loplugin:bodynotinblock (“compiler plugin check for if/while/true bodies with possibly {} missing”), so this new GCC warning did not find any more errors, but it does warn about cases where an additional statement follows a complete if statement on the same line, like in “-Werror=misleading-indentation (GCC 6).”
  • The diagnostic information presented by the compiler when it finds an error in the code has improved still with GCC 6, but unfortunately the most dreaded
    lo/core/sw/source/core/text/txtfrm.cxx: In member function ‘virtual bool SwTextFrame::Prepare(PrepareHint, const void*, bool)’:
    lo/core/sw/source/core/text/txtfrm.cxx:689:0: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]
          if( nLen != COMPLETE_STRING && GetOfst() > nPos + nLen ) // the range preceded us

    emitted when building with optimizations enabled still leaves you completely clueless about what is going on, like in “Silence some odd -Werror=strict-overflow (GCC 6).”

  • (And PR66460 “ICE using __func__ in constexpr function” is still open, so we still have the somewhat unfortunate situation that we detect HAVE_CXX14_CONSTEXPR=1 in the --disable-debug case, but HAVE_CXX14_CONSTEXPR=0 in the --enable-debug case—or its --enable-dbgutil superset, or its --enable-assert-always-abort subset.)

by stbergmann at January 20, 2016 09:56 AM

January 17, 2016

Florian Effenberger

LibreOffice Hackfest zur FOSDEM

Wie jedes Jahr findet Ende Januar die FOSDEM in Brüssel statt, einer der Treffpunkte für freie Software überhaupt. Auch die LibreOffice-Community ist natürlich wieder vor Ort – sowohl mit einem eigenen Stand als auch mit zahlreichen Vorträgen im DevRoom.

In diesem Jahr veranstalten wir in Brüssel an den beiden Tagen vor der FOSDEM, d.h. am 28. und 29. Januar, zusätzlich ein LibreOffice Hackfest.

Wenn ihr in der Gegend seid, schaut vorbei – selbst für mich als Nicht-Entwickler sind die Hackfeste immer eine spannende und gewinnbringende Veranstaltung. 😉 In diesem Jahr sind zudem wieder einige Leute vom Infrastruktur-Team mit dabei und wir wollen unter anderem unser Mail-System optimieren und an den virtuellen Maschinen arbeiten.

by Florian Effenberger at January 17, 2016 05:10 PM

Official TDF Blog

First 2016 meeting of the LibreOffice Indian community

CYcrDHsUoAAeZpMToday, the LibreOffice Indian community meets in Delhi, the capital of India, at Social Cops, to discuss 2016 activities. The event is supported by the FUEL Project, one of the largest localization communities worlwide (India alone has a large number of native languages, and localization is one of the first issues to tackle for any free software community).

The development of the LibreOffice Indian community is a very important objective for the entire project, as the Republic of India is the second largest country in the world by population, with over 1.2 billion inhabitants. In addition to Hindi, …

by Italo Vignoli at January 17, 2016 08:41 AM

January 14, 2016

Charles Schulz

Status report on Emacs

It has been some time I have not shared some news about my increasing use of Emacs. This post will be just about that. Let me quickly summarize what I do with Emacs on a daily basis:

  • email (mu4e)
  • note taking (org-mode)
  • blogging (org-mode, markdown, html)
  • project management (org-mode)
  • IRC (ERC)
  • code editing (html css, php, js modes + web-mode)
  • file management (dired & deft)
  • document viewing (docview)
  • document authoring (org-mode, olivetti)
  • learning (e)lisp

I don’t get to do all these at once every day, but still the majority of these tasks are performed on Emacs on a daily basis. I’m obviously getting more and more familiar with each tools and the general use of Emacs the more I use them. I would like to highlight a few thoughts about them:

Org-mode is this invention that has gone unnoticed by the IT press and the general public as well. But I think it’s life-changing. Probably as life-changing as using online social networks, but probably for better reasons. As a new or at least recent Dad, I can actually say that Org-mode has saved me time and energy in planning family activities, household chores and baby health tracking. I’m not even getting started on the more traditional project management and note taking uses of Org-mode, because then I’d gladly say that it changes one’s jobs and does reduce sweat and stress. I don’t consider myself a power user of Org-mode or anything like that. I do lists, tables, use tags, states, timestamps, deadlines and schedules mostly. The rest I have not really investigated at the moment. And yet, it already is a powerful tool.

I would not actually say the same of drafting content in Markdown. True, this isn’t a critic of the Emacs Markdown-mode, because it does work just fine. But the markdown format itself turns to be somewhat of a disappointment for me; it looks like I’m not the only one to think so. It will stay at best as a transient format found on the web and in readme or config files.

Email is where things progressed the most. I’m now using mu4e everyday, for pretty much all my mails except for the encrypted ones as well as the ones in relation to calendar and scheduling. For these I use Evolution. I have not had the time to look into the proper use of gpg in Emacs beyond file en- and de-cryption. For calendaring I must say that unless you use standalone, ics calendars or GCal, the available tools (org-caldav) are limited at best, and often downright broken for people relying on the caldav protocols. I hear conflicting reports; for my online calendars at least, it still won’t work. This makes me use mu4e somewhere around 80% of the time now. I guess I’ve beaten my own expectations in that regard. Much to my surprise, reading html messages is a breeze with mu4e, and I am getting used to a text-only environment for emails slowly but surely. On top of that, I’ve decided to contribute just a little of my time to the mu project and it’s fun! People are nice, helpful, and the community small and healthy. It feels like a small town, at least when you’re coming from a large project, even a very friendly one such as LibreOffice.

The rest of the tools I’ve mentioned are used in conjunction or in relation to the primary tools and modes I’ve been discussing, except perhaps for the web site editing which was after all my first reason to use Emacs. To this day, I continue to do so but I don’t do web site on a professional basis anymore.

Where do I go from here? I intend to expand my knowledge of this wonderful editor, especially org-mode and other areas. At the beginning of 2015 I had started to read about elisp and I’m gradually learning about it. It is my first real programming language. A few people I’ve talked to find lisp a weird choice to start with, but I think that anyone who studied literature and humanities as his major fields will intuitively “get” these long lists of brackets. These are not maths -not seemingly at least- these are lists, content inside brackets, functions, new words, variables and arguments. It surely does get complicated at some point, but it can’t possibly be more complicated than a James Joyce’s opus!

by Charles at January 14, 2016 10:39 PM

Jan Iversen

2016 new year, new challenges

We are receiving requests from 2-5 new developers, who wants to help out making LibreOffice even better.

Many new developers join and do not realize how big and complex LibreOffice is, if you “attack” without guidance.

We are 10+ developers (some stable, some joining frequently) on IRC/ML every day, making 10-15 code changes every day. Managing this without management is a challenge, so we have some base “rules” of how to cooperate (like using git and gerrit).

New developers need to understand the purpose of having defined ways to work together, and setting that up (git/gerrit/bugzilla/mailing list) takes a bit of time. In order to help new developers we have published a step by step guide:

Step by step guide

We will add pages with different starting guides.

Have a good 2016.

jan i

by jan at January 14, 2016 12:20 PM

January 12, 2016

Miklos Vajna

RTF page background export in LibreOffice Writer

While I added support for page background colors in the RTF import back in 2013, the export part was missing up to now.

If you set a solid color fill for a page style, and you export it to RTF, here is how the reference rendering output looks like:

However, in Libreoffice only the background of the paragraph reflected the color set by the user:

After implementing this feature in the RTF export filter, it now looks much closer to the reference:

At the moment only solid fill is implemented, so other advanced fill types like graphics or gradients are still missing.

January 12, 2016 09:11 AM

January 11, 2016

Official TDF Blog

LibreOffice mini Conference 2016 Osaka

banner_2000x667The Japanese community has just organized their LibreOffice mini Conference 2016 in Osaka. We have asked Takeshi Abe, a leading member of the Japanese community, a few questions about the event.

Can you tell us more about the context of the Japan LibreOffice Mini-Conference?

In 2012, the idea of a mini Conference in Japan has emerged from discussions in LibreOffice Japanese Team, in charge of the organization of the series of events. Our team consists of the most active contributors in the Japanese community, serving as a NLP (native language project) now.

To explain the situation, let’s summarize the history …

by Italo Vignoli at January 11, 2016 02:29 PM

January 08, 2016

Samuel Mehrbrodt

LibreOffice and Eclipse: LOEclipse 2.0 released

<figure class="wp-caption alignright" data-shortcode="caption" id="attachment_28" style="width: 310px">Remote debugging an extension with LOEclipse<figcaption class="wp-caption-text">Remote debugging an extension with LOEclipse</figcaption></figure>

The LOEclipse-Plugin helps with developing and debugging extensions and UNO components from the Eclipse IDE.

Due to some changes in both LibreOffice and Eclipse, the Plugin didn’t work anymore with recent versions. It has now been updated and fixed to work with LibreOffice > 5.0 and Eclipse Mars (4.5). Note that it is no longer compatible with LibreOffice 3.x and 4.x. LibreOffice 4.4 is already at its End of Life and 5.1 will be released in February, so this shouldn’t hurt too much¹.

Also the Eclipse Update Site is now hosted by The Document Foundation. You can install the new version of the Plugin by adding this Update Site to Eclipse:


  • Support for LibreOffice 5.0 added. Older releases are no longer supported.
  • Support for Eclipse Mars (4.5) added.
  • Fixed Deployment & Debugging
  • Deployment: Install extensions without asking when in debug mode or using a separate user profile
  • Runtime configuration now reads package contents from instead of having an own tab for this
  • Renamed the extension and internal paths (OpenOffice -> LibreOffice)
  • Hosting now by The Document Foundation
  • Java 7 is the new baseline for the code (instead of Java 5)
  • Various internal cleanups
  • Fix #5: Invalid oxt files created on Windows

More information can be found on the plugin’s Github page.

Thanks to the Austrian Federal Computing Center and the Austrian Federal Ministry of Justice for sponsoring the work on this!

¹ If it does hurt, get in touch with us. We surely can help you with our LTS Services.

by Samuel Mehrbrodt at January 08, 2016 04:49 PM

Chris Sherlock

You can(not) have a void namespace in C++...

Update: So this was discussed on IRC, and it turns out I've got this all entirely wrong. It's actually much simpler - it turns out you don't need a space before the scope operator thus you can legally have:

void::TheClass::TheFunction(int n1, int n2) {}

This is the same as:

void ::TheClass::TheFunction(int n1, int n2) {}


void     ::TheClass      ::TheFunction(int n1, int n2) {}


I ran doxygen over the vcl module in LibreOffice and I got a lot of warnings and errors. I am now making a concerted effort to fix these warnings because I actually find doxygen generates good info on the classes, and I rather like the collaboration and inheritance diagrams it produces.

However, a strange error that it produced was:

/home/chris/repos/libreoffice/vcl/source/control/combobox.cxx:1322 warning: no uniquely matching class member found for void::ComboBox::Impl::ImplUserDrawHandler(UserDrawEvent *pEvent)

"A void namespace in the LibreOffice codebase?" I thought. How could this be? How is this even possible?

Sure enough, the definition was void::ComboBox::Impl:ImplUserDrawHandler(UserDrawEvent*)!

In an effort to work out if this was what was intended (which I was very doubtful of) I tracked down the commit, which converted the old style IMPL_LINK macro to a boost signal. It was definitely not intended!

I then tracked down where the C++ standard is held and reviewed the C++14 draft (I can't afford to spend US$216 on the official ISO standard). Section 7.3 deals with namespaces:

Amazingly (to my mind) there is no restriction on the namespace identifier, thus it is entirely possible to accidentally create a void, int, float or any other reserved C++ keyword as a namespace!

I wonder if it might be worthwhile for compilers to spit out a warning if they see this? Perhaps we need to write a clang plugin to detect this sort of thing in LibreOffice. The only reason this hasn't had an impact is that it doesn't appear that anything is currently using user-defined draw signals on comboboxes.

I pushed commit 86338fbb94324ed to fix this.

by Ta bu shi da yu ( at January 08, 2016 10:41 AM

Restricting Doxygen indexing to particular LibreOffice modules

I have committed a code change to the LibreOffice tree to allow developers to specify what modules they want Doxygen to index. I have done this because indexing every module is quite time consuming, and you may only want to review a subset of modules (in my case I am interested primarily in the vcl module).

To index specific modules only, you now export the $INPUT_PROJECTS environment variable and run make docs. For example, if you want to index only the vcl and svtools modules, you would do the following:

chris@libreoffice-ia64:~/repos/libreoffice$ export INPUT_PROJECTS="vcl svtools"
chris@libreoffice-ia64:~/repos/libreoffice$ make docs
chris@libreoffice-ia64:~/repos/libreoffice$ unset INPUT_PROJECTS

by Ta bu shi da yu ( at January 08, 2016 04:58 AM

January 05, 2016

Chris Sherlock

Possible 15 year old regression

A few days ago, I filed bug 96826 ("Typewriter attribute not given enough weight when finding font based on attributes") against LibreOffice. Basically, I've been refactoring VCL font code and I was very interested to see what my predecessors had been doing before me. This meant that I actually read pretty much all of the commits I could find all the way back to the year 2000 for that file, which held much of the font code for VCL. 

One of the functions was originally in a class called ImplFontCache, which had a get() function that worked as a font mapper. It basically does a running total of a number of weighted values depending on the "strength" or "quality" of the font matching attribute. One of those attributes was to check if the font is a fixed-width font, then check to see if the font is a typewriter style font, giving a deliberately higher weighting to typewriter style fonts. 

Anyway, on the 29th June 2001 someone with the initials th (no idea who this was, nor is it really important) did some tweaks to the function in an attempt to improve font mapping in commit 925806de6. To ensure that the typewriter style was given a weighted value, they have multiplied the value by 2. However, they appear to have accidentally removed a zero from the weighting, thus reducing the weighting of the typewriter style fonts, not increased it!

As I was reading the code, I thought "whoops, that was unfortunate" and assumed I'd see the error picked up somewhere down the track and fixed. Now either the weighting has little effect on these fonts, or not many people have problems with typewriter fonts not being cleanly mapped by the underlying platform, but this has never been fixed

The code has since migrated its way into PhysicalFontCollection::FindFontFamilyByAttributes(), and it's still there!

    610         // test MONOSPACE+TYPEWRITER attributes
    611  if( nSearchType & ImplFontAttrs::Fixed )
    612  {
    613  if( nMatchType & ImplFontAttrs::Fixed )
    614  nTestMatch += 1000000*2;
    615  // a typewriter attribute is even better
    616  if( ImplFontAttrs::None == ((nSearchType ^ nMatchType) & ImplFontAttrs::Typewriter) )
    617  nTestMatch += 10000*2;
    618  }

As with any codebase with a 30 year pedigree, I've not committed a fix because I just don't know if this is something I want to touch. Hence I've logged the bug to see if anyone can shed any light on it. I'll probably follow up on the mailing list in a few weeks time to ping any more experienced developers, but until then this potential bug, which is in the middle of going through puberty, will remain. 

by Ta bu shi da yu ( at January 05, 2016 09:55 AM

January 03, 2016

Charles Schulz

The way you write

As the first post of 2016 on this blog I was wondering what I would be writing about. Not that I am lacking ideas but I was tinkering with a post about those never-happening new year resolutions. I ended up dropping this idea in favor of a question that is somewhat disturbing to me. Here it is:

I do promote and contribute to the LibreOffice project, the FOSS office suite. And yet it’s been two years I’m also talking about my use of Emacs in various ways. I quickly came to the realization that I was doing more and more things with Emacs that I could have done with LibreOffice. And yet I have not lost interest in the latter, quite the contrary. Is LibreOffice, or any office suite, not as effective as Emacs or other text editors?

The following is the personal point of view of someone who is not a developer even though I do edit CSS, html, php or javascript files from time to time.

The fundamental difference between a word processor and a text editor is not a matter of complexity or generation. Word processors simply do things differently than text editors, and both have existed side by side happily since the mid eighties. Whether they do things better is a completely different question, and perhaps a moot one, as a the different approaches serve different purposes. So let’s take the case where I need to write a fully detailed report about a given matter. The report will be roughly ten pages long, well formatted and with a rather strict constraint to use a predefined template. That template is usually not made with LaTeX but with a word processor. How would I go about creating this document, assuming I don’t know LaTex but use both a text editor and a word processor?

Let’s reason in a more simple way first. If I only use a word processor (which is the case of about 99% people out there) I do not really need to worry: I will go about using the same tool I’ve always been using and I may only hope that the word processor will handle the template well and that it won’t put too much formal constraint on what I can do in terms of formatting myself. If I only use a text editor, I need to see how I can work with the document template and see how I can add the text itself to that template so that at the end and actual document will be created.

These two different approaches do not necessarily highlight the superiority of the word processor; after all one could imagine an html template instead of one in OpenDocument Format or proprietary one. What it shows, however, is that a word processor deals with documents in a visual way. A text editor sticks pretty much to the text itself. The rest can be dealt with in other ways, either externally or in a programmatic method (with LaTex for instance). My point here is to stress that the two kind of tools rely on broadly different approaches.

Coming back to my previous example, here’s how I would go about writing the document using both tools. I would first organize my thoughts via the text editor, Emacs in my case, using mostly org-mode; perhaps if I needed to work on it in a more collaborative fashion (with friends or colleagues) I would need to bring portions of it on a wiki or a pad; I could use something like markdown-mode, or even good old html or text. Then I would insert the text into a new document, with LibreOffice for instance, and then I would finish editing both the text and the document. In my scenario, LibreOffice Writer is in charge of creating the actual document both in terms of design and content, while the genesis and perhaps the very rough content is handled by the text editor.

The big difference is the final output of both tools. It is a bit hard, unless one uses complex LaTeX macros (and I’m not even sure it’s possible) to create a document sticking to word processors’ templates. Sure, you can design beautiful documents in text editors using LaTeX but you need to learn how to programmatically design the document and you are still not integrating document templates from the outside. What’s more, mastering LaTeX to that level require quite some training and time to learn. While people can type anything in bold, italic or underlined with a word processor, the mastering of complex styles in it will require a rather small fraction of that time and energy.

There’s a beauty in using a word processor, especially if one knows how to use it well. There is a beauty in using a text editor, albeit of a quite different kind. The two philosophies may conflict at times but are from being mutually exclusive.

I hope I’ve shed some light on this question, at least for people who wonder why there are people still using text editors out there. What about you? How do you write?

Happy New Year everyone!

by Charles at January 03, 2016 05:14 PM

December 30, 2015

Dennis Roczek

Cleanup tasks ongoing

At the end of the year I started to cleanup many stuff in the wiki.

First I re-installed again the extension UserMerge to merge wiki users on request and did merge a user. For the case you want to merge some users, simply ping me in IRC, write me a mail or request it directly on my wiki page. ;-)

A seldom spam post was quickly deleted again.

Moreover I started to fix dead links. Most links were simply moved (Sun, Oracle, Apache did make really a mess with their links) or even in our own infrastructure… Moreover my bot ran through many links to switch the http links to the securer https variants.

Moreover I try to finish a few patch sets for our Bugilla-Mediawiki-integration extension to push them upstream.

by dennisroczek at December 30, 2015 02:21 PM

Florian Reisinger

2015 im Rückblick

Die haben einen Jahresbericht 2015 für dieses Blog erstellt.

Hier ist ein Auszug:

Ein New York City U-Bahnzug fasst 1.200 Menschen. Dieses Blog wurde in 2015 etwa 5.400 mal besucht. Um die gleiche Anzahl von Personen mit einem New York City U-Bahnzug zu befördern wären etwa 5 Fahrten nötig.

Klicke hier um den vollständigen Bericht zu sehen.

by Florian Reisinger at December 30, 2015 06:42 AM

December 28, 2015

Eike Rathke

Nitrokey Storage: USB Security Key for Encryption

I rarely advertise any products, and even though this is not physically available yet: get your USB Nitrokey Storage at Indiegogo until tomorrow. Realized with Open Hardware and Free Software it will enable secure logins, encryption, backups, ... Further information is available at the Nitrokey web site.

by erAck (23@ at December 28, 2015 12:16 PM

December 25, 2015

Naruhiko Ogasawara

Update: LibreOffice mini Conference 2016 Osaka/Japan

I'm working to prepare LibreOffice mini Conference 2016 Osaka/Japan as <gs class="GINGER_SOFTWARE_mark" ginger_software_uiphraseguid="0a9e1639-3941-465f-a0e6-5120710e8a36" id="46549932-c2e5-47e4-b3c8-f416dbd6ec7f">a</gs><gs class="GINGER_SOFTWARE_mark" ginger_software_uiphraseguid="0a9e1639-3941-465f-a0e6-5120710e8a36" id="b46f1da4-9071-421c-b3b4-69368346151a"> organization team members.</gs>  There are some updates.

  • Keynote: we've invited Mr. Kohei Yoshida, well-known Calc hacker.  His talk, titled "5 years of LibreOffice," will be an interesting talk from his experience, both as a full-timed developer and as a volunteer developer.
  • Talk: it was a very hard task to <gs class="GINGER_SOFTWARE_mark" ginger_software_uiphraseguid="004e3841-15b8-4a68-b11a-a04dd23b93d7" id="c0c9ac4b-d021-4b4a-b8ca-6eff1270256e">choice</gs> only 4 talks from many submitted talks. Finally, we will have talks about migration how-to, LibO with education, controlling <gs class="GINGER_SOFTWARE_mark" ginger_software_uiphraseguid="1ff711c3-727b-4e20-8edf-b52cd0945285" id="81eddaf2-bf57-42c5-8fdd-c393653a7224">LibO</gs> via API, and LibO Accessibility.
  • Event site: we now published the site.  Although the site is written in Japanese, and all talks will be in Japanese also, any non-Japanese speakers are welcome.  If you want to attend, please let me know.
  • We are having an event banner (thanks, Mr. Jun Nogata, who is a winner of <gs class="GINGER_SOFTWARE_mark" ginger_software_uiphraseguid="06eeb675-fe2b-4fb9-b121-01b9d6b30c67" id="9b1e6cdf-56f9-4a61-aff3-88cfcca8e61d">LibO</gs> 4.4 template contest).  You can see the LibO Official event page in Japan.
  • We are really appropriate to our sponsors:
So, yes, we will have a HackFest also.  Join us and hack LibreOffice together!

by Naruhiko Ogasawara ( at December 25, 2015 09:44 AM

December 22, 2015

LibreOffice Design Blog

Area fill options made consistent


As in many other dialogs, Libreoffice provides a lot of functionality for tweaking the hell out of areas taken up by shapes, charts, frames, etc. You can have a solid background color, with or without transparency/opacity, you may fill …

by The LibreOffice Design Team at December 22, 2015 01:32 PM

December 21, 2015

Dennis Roczek


… do not only happen in LibreOffice. ;-)


Although the Wikimedia Foundation has a really big CI (even for extensions which do only have a repository at WMF), they introduced a regression and released yet another bug fix…


MW1.24.6 was quickly updated. Luckily such a fix – in this special case – is really fast installed.

by dennisroczek at December 21, 2015 11:24 PM