The Document Foundation Planet

 

March 22, 2017

Official TDF Blog

LibreOffice Conference 2018: Call for location

LibreOffice Conference 2016

We’re currently organising the LibreOffice Conference 2017, which will be held in Rome from September 27 – 29. But we like to plan even further ahead, so today we’re putting out a Call for Location for 2018’s conference.

Why are we doing this so early? Well, we want to give the 2018 conference organiser a chance to attend this year’s conference to see how it works. So if you’re a member of the LibreOffice community and are interested in organising 2018’s conference in your town or city, you can write up a proposal. All the details are on the wiki, including what you need to know in advance, and what your proposal should contain.

The deadline for proposals is June 30 2017. We’ve already had great conferences in Paris, Berlin, Milan, Bern, Aarhus and Brno – and we look forward to hearing your ideas!

The post LibreOffice Conference 2018: Call for location appeared first on The Document Foundation Blog.

by Mike Saunders at March 22, 2017 01:40 PM

March 21, 2017

Official TDF Blog

LibreOffice Contributor Interview: Lera Goncharuk

Our native language projects benefit enormously from volunteers around the world, who help make LibreOffice a success in many different locations. In our latest contributor interview, we talk to Lera Goncharuk who is active in the Russian community, helping out with translations and documentation.

LibreOffice contributor Stanislav HoráčekWhat is your IRC nickname, nationality and current location?

I am “tagezi” in the IRC channels on Freenode, as well as The Document Foundation (TDF) wiki, but my friends call me Lera – that is a short version of my full name, Valerii. I was born in the USSR and lived in the Russian Federation the biggest part of my life. Now I live in Finland.

Do you work for a LibreOffice-related company or just contribute in your spare time?

I have been using Linux as my primary operating system since 2004 on a daily basis. And I started to use LibreOffice since the early days of the project’s formation, which came to replace OpenOffice.org.

What areas of the project do you normally work on? Anything else you want to tackle?

My main goal is translating documentation, wiki articles and news for the Russian community. But in addition, I have made a few patches for the Help system, and I have been trying to improve the formatting and navigation of the wiki pages. I am also a TDF wiki administrator and moderator of Russian-speaking communities in Google+ and Facebook, and I sometimes write articles about LibreOffice on my blog.

What was your initial experience of contributing to LibreOffice like?

At that time, I was working in Calc, visualizing data using charts. And I saw that I couldn’t find good Russian articles about using charts in LibreOffice. There is a proverb: “If you want something done well, do it yourself.” So I did that, starting to write articles myself, and now there are several available – not only about charts in Calc, but also on general topics related to LibreOffice.

In 2014, one member of the Russian-speaking community asked me for help with finding mistakes in the Russian interface of LibreOffice Calc 4.3. I began to help, and in the process found out more about the needs of the community, its concerns, and its hopes. And my next step was to start translating the TDF wiki. So I came to global LibreOffice community.

Which is your preferred text editor? And why?

I can use any text editor. Even if I have never worked in it, I can master it quickly. But I prefer to work in either Vim or LibreOffice Writer. I use Vim when I need to write or edit low-level texts such as source code or documents in markup languages like XML and HTML. Perhaps this is just a habit. When I switched to Linux, Vim was the first editor I used, and at the beginning I experienced significant difficulties – but about a week later, I was able to deal with simple tasks, to make templates and write simple scripts.

A month later, my skills improved, and now I cannot imagine how I could get along without it. For higher-level texts, when the text needs to be edited and printed by other people, I use LibreOffice Writer. I really like its implementation of the style concept, which helps to quickly create and edit documents with a complex structure. I use other editors and IDEs when necessary – when a problem requires a specific editor. But that happens less and less.

How much time do you spend on the project? What do you do when you’re not working on LibreOffice?

I devote myself to the LibreOffice community at least a few hours a day, typically four to six hours per day. In addition, I also often use LibreOffice on a daily basis. I have a radio-amateur database, several calculators for fast computations, and I often use Calc for data processing. Based on it I take notes and gather thoughts, which then grow into ideas and articles for my blog. Therefore, I can say that LibreOffice is an essential part of my life. The rest of the time, when I am not engaged in LibreOffice-related activities, I devote myself to my family or to learning new stuff.

Do you have any hobbies or interests you want to mention?

I am a radio-amateur and I like history and hiking. Especially the latter, because it lets me get distance from everyday routine, to refresh my mind and to come back to the project being full of energy and with new ideas. The rest are just ways to relax, to switch activities, when there is no opportunity to go to mountains.

What would you advice to people considering joining the LibreOffice community?

First of all, welcome. Do not be shy, but try instead. Many people think: “I’m not a developer. I don’t know programming languages, so how can I be useful?” In fact, developers constitute the community core, but the community is much bigger. There are many people around them: teams of documentation, localization, QA and marketing. All these people play important roles in the community.

Who will write documentation and translations, or spread the word about LibreOffice, if not these other people? There are a variety of tasks and jobs that satisfy any taste. Even if your English isn’t perfect and you don’t know programming, you can contribute to your local LibreOffice community. So, there is work for everyone, waiting for to come and do it. In my experience, the LibreOffice community is like a big family. You always can get support and help if you have difficulties. So welcome – the doors are open for you.

Thanks Lera! And as he says, there are so many ways to get involved with LibreOffice – so join us today and help make the software better for millions of users around the world. We look forward to meeting you!

The post LibreOffice Contributor Interview: Lera Goncharuk appeared first on The Document Foundation Blog.

by Mike Saunders at March 21, 2017 02:42 PM

Michael Meeks

2017-03-21 Tuesday.

  • Up early, noticed the ice-crusher motor relay is the same as the compressor one (and presumably far far less used), de-soldered both relays, swapped them and bingo: a working compressor. Bench testing suggests the duff relay is only good at making nice clicking noises, rather than power switching; good.
  • Poked mail; pushed fixes.

March 21, 2017 09:34 AM

March 20, 2017

Michael Meeks

2017-03-20 Monday.

  • H. ill, fridge compressor appears to have packed-in; spent a while dis-assembling it variously; annoying. Consultancy call. Lunch, sync. with Andras & Tor, code review.
  • Poked at the Daewoo FRN-U20DA in the evening ; no error codes, nothing doing, compressor not running, but starter seems ok, and continuity good. Brian over to help; jumped the compressor all working well there in the plumbing section - good. Set to work on the electronics; found the RT (Room Temperature) sensor, seems to be fine; hmm. Ordered a new compressor relay: OMIH-SS-112LM.

March 20, 2017 09:00 PM

Miklos Vajna

LibreOffice now uses pdfium to render inserted PDF images

pdfium is the rendering library used in Chromium’s pdf viewer. It’s based on the foxit pdf renderer and its rendering quality is much better compared to the pre-existing "convert PDF to ODG, then to an image" code when it comes to just viewing a PDF file. First, thanks to PMG who made this work possible.

Let’s look at a few samples that compare the old pdfimport rendering result and the new pdfium-based one. One important feature is that embedded fonts are handled. This is how this inserted PDF looked like previously:

https://farm4.staticflickr.com/3727/33163219940_3a2a3278a0_o.png

Compare it with the new result:

https://farm3.staticflickr.com/2927/33547029855_92c1a5150d_o.png

Now let’s see the front page of a magazine, you can see 3 unexpected artifacts:

https://farm4.staticflickr.com/3952/33163219890_c4ae5cf153_z.jpg

New result:

https://farm3.staticflickr.com/2809/33547029645_de7cbcd800_z.jpg

Finally a problem with pdfium was that LibreOffice got bitmaps from it, so in case you re-exported to PDF, the quality of these PDF images were worse than in the original PDF file. The PDF specification has a reference XObject feature that helps in this case: it allows the PDF export to still write the bitmap to the exported PDF, but in case the reader supports this feature, the vector-based original file will be shown, not the bitmap.

Here is a simple hand-crafted star in a PDF file, as it looked initially:

https://farm3.staticflickr.com/2915/33163219680_30f63b4a82_z.jpg

This is how it looks after LibreOffice’s PDF export learned to emit reference XObjects:

https://farm4.staticflickr.com/3933/33547029485_4f487bb26c_z.jpg

All this is available in LibreOffice master, towards 5.4.

March 20, 2017 09:00 AM

March 19, 2017

Michael Meeks

2017-03-19 Sunday.

  • Off to NCC at The Stable; did the kids work with Klara downstairs - fun. Back for a pizza lunch, snoozed with J. for a while. Pottered around with babes. Out for a walk with Sue & Russell & back for tea. Put babes to bed.

March 19, 2017 09:00 PM

Naruhiko Ogasawara

LibreOffice Kaigi 2016.12 Videos

Time is passing too fast.  And I'm sorry not to mention here that LibreOffice Japanese community had published presentation videos at LibreOffice Kaigi 2016.12.

You can enjoy Mr. Franklin Weng's awesome keynote "LibreOffice/ODF Migration in Taiwan."

Any other videos in the Kaigi have been published at "LibreOffice Kaigi 2016.12" playlist at YouTube.  This list is provided by LibreOffice Japanese Team (LibreOffice Japanese NLP) official channel.  The channel also provides videos at another event "LibreOffice mini Conference 2016 Osaka/Japan."

Every talks except the keynote has been in Japanese (because Kaigi is a "Japanese-local" event), but I hope you all enjoy the videos.

by Naruhiko Ogasawara (noreply@blogger.com) at March 19, 2017 04:20 AM

March 18, 2017

Michael Meeks

2017-03-18 Saturday.

  • J. out to take H. and M. to "Shine"; got on with some plumbing bits with M. machined a new tap chain connector out of aluminium sheet together. J. back, out to buy some marine plywood with M. Lunch.
  • Knocked together some shelves for walking boots in the porch together in the afternoon. Out to Sandy's birthday party in the evening; nice to see Daniel, Adeline & family there too. H. to Charlotte's for birthday 'sleep'-over.

March 18, 2017 09:00 PM

March 17, 2017

Michael Meeks

2017-03-17 Friday.

  • Up; out to NCC for Men's Prayer Breakfast; mail chew. Partner call. Lunch.
  • Slightly scary with J. training in bereavement counselling to see a calendar appointment labelled: Sudden and Traumatic Death.
  • Hackery left & right, chat with Eloy.

March 17, 2017 09:00 PM

March 16, 2017

Official TDF Blog

The Document Foundation announces LibreOffice 5.3.1

Berlin, March 16, 2017 – The Document Foundation (TDF) announces the availability of LibreOffice 5.3.1, the first minor release of the LibreOffice 5.3 family released in early February, with 100 bugs or regressions fixed against the previous version.

LibreOffice 5.3.1 is targeted at technology enthusiasts, early adopters and power users, as it is focused on bleeding edge features. For all other users and enterprise deployments, TDF suggests the just released LibreOffice 5.2.6, with the backing of professional support by certified professionals (a list is available at http://www.libreoffice.org/get-help/professional-support/).

People interested in technical details about the release can access the change log here: https://wiki.documentfoundation.org/Releases/5.3.1/RC1 (fixed in RC1) and https://wiki.documentfoundation.org/Releases/5.3.1/RC2 (fixed in RC2).

Download LibreOffice

LibreOffice 5.3.1 is immediately available for download from the following link: https://www.libreoffice.org/download/download/.

LibreOffice users, free software advocates and community members can support The Document Foundation with a donation at http://donate.libreoffice.org.

Several companies sitting in TDF Advisory Board (http://www.documentfoundation.org/governance/advisory-board/) are providing either value added Long Term Supported versions of LibreOffice or consultancy services for migrations and trainings, based on best practices distilled by The Document Foundation.

The post The Document Foundation announces LibreOffice 5.3.1 appeared first on The Document Foundation Blog.

by Italo Vignoli at March 16, 2017 12:02 PM

March 15, 2017

Tomaž Vajngerl

Pivot charts in LibreOffice: Part 1

About

Pivot tables are a powerful tool to reorganise, manipulate and summarise the data set in spreadsheets to get the valuable information from it. To get a quick visual representation of the information, pivot charts can be used. A pivot chart can be created from the output of the pivot tables, and if the pivot table gets changed, so does the pivot chart.

Support for pivot tables in LibreOffice is available for a long time, but there was no support for pivot charts until now. For the past week I was working on pivot charts in a feature branch (feature/pivotcharts) and I got to a first milestone. Pivot charts will be released in LibreOffice 5.4.

Pivot chart data provider

From development point of view, pivot charts are just like normal charts but with a different data provider (source of data), so this was the task with which I started. Normal charts use a data provider which is based around reading from cell ranges, but for pivot charts I created a new data provider, which reads the output data from the pivot table and prepares it for the chart. The data columns are mapped to data series and the data rows become the number of data series in chart (See Figure 1).

Figure1: Pivot table to pivot chart data mapping
Now what is left is naming of each axis and data series in chart. The y-axis categories are mapped to row field names in the pivot table and the data series names, which are shown in the chart are combined names of all column field names of the pivot table.

Each data point and row or column field name also has an associated number format, which needs to be assign to chart data, otherwise the the number format would not the values correctly as in pivot table (this is especially important with date and time).

Updating a pivot chart

Once I managed to do the mapping correctly, the pivot chart showed up as expected, but the pivot chart wasn't updated when I update the pivot table. So to solve this, I had to implement a listener of pivot table updates in the pivot chart data provider, and for every update send the signal to chart to update the data again (which it gets from the pivot chart data provider). The whole update procedure sounds like a ping-pong play between components, but it works quite well.

Demo

In the following video you can see the current status of development:



Credits

One of the real privileges here is working on LibreOffice for a Collabora Productivity customer who funds significant feature work. Many thanks to Nantes Métropole and Ville de Nantes for their investment here, and making this feature available to all LibreOffice users. You can read more about Nantes deployment here.

To be continued...

by Tomaž Vajngerl (noreply@blogger.com) at March 15, 2017 11:19 AM

Official TDF Blog

Meet the Brazilian LibreOffice 5.3 team

We can assure readers of this blog that LibreOffice 5.3 in Brazilian Portuguese did not simply sprout from the last tropical rainfall. It is the product of a team of volunteers working to make the best free office suite in Portuguese a reality.

Following the experience gained by translating the Getting Started with LibreOffice 5.0 guide, the team began to translate the Help Contents of LibreOffice 5.3 in December 2016. This task involved translating 18,000 words on our Pootle server in two months, due to all the improvements, updates and corrections that went in the software since version 5.2. The work was split into smaller tasks under the supervision of Olivier Hallot, translator leader since 2007 (during the OpenOffice.org days). The LibreOffice 5.3 user interface translation was handled by Olivier in that period.

So, the Brazilian community and the Brazilian users say thanks to Chrystina Pelizer, Túlio Macedo, Raul Pacheco da Silva and Douglas Vigliazi for the new LibreOffice 5.3 and Help system in Brazilian Portuguese.

Chrystina Pelizer “It was like a challenge for me: to actively take part in a collaborative, international software project. Learning and using the tools and techniques that volunteers use to translate the software made me feel more important and met my expectations, because they greatly reduce the effort and we get results very quickly. Also, I am very happy to be part of a project team.” Chrystina Pelizer (Florianópolis – SC)
Raul Pacheco da Silva “I always liked to be part of the LibreOffice community when my professional activities let me do so. Specifically, I like to be part of the translation projects of the software and the documentation. I use all the resources I can to fulfil my duties within the team and I don’t like to miss our weekly team call.” – Raul Pacheco da Silva (Suzano – SP)
Douglas Vigliazi “I took advantage of the fact that my professional duties are related to LibreOffice, and for me, taking part in the LibreOffice project is an opportunity to develop my professional skills, including at an international level. The translation project is one of the opportunities to contribute to the community.” – Douglas Vigliazi (Santos – SP)
Túlio Macedo “I already had translation experience with the Fedora project in Brazilian Portuguese, and that helped me a lot with using the LibreOffice toolset. The translation helped me to get to know LibreOffice in depth, in order to understand the context of the translation I was doing. I also liked very much being part of a team.” – Túlio Macedo (Brasília – DF)
Olivier Hallot “After years of personal commitment to keeping the Brazilian LibreOffice fully translated and with quality, it was a great satisfaction to assemble a team that will be able to keep the project alive by themselves, ensuring part of the translation effort of this wonderful software.” – Olivier Hallot (Rio de Janeiro – RJ)

A big hooray for the team! Click here to discover Native Language Projects in your area

The post Meet the Brazilian LibreOffice 5.3 team appeared first on The Document Foundation Blog.

by Olivier Hallot at March 15, 2017 10:37 AM

March 14, 2017

Official TDF Blog

LibreOffice and Google Summer of Code 2017 – get involved!

Google Summer of Code (GSoC) is a yearly programme in which Google funds university students to work on free and open source software projects. LibreOffice has benefited from this – last year 11 students were accepted into GSoC to do various programming jobs, helping to improve the software.

GSoC students are assisted by experienced “mentors” in the LibreOffice community, as 2016 student Jaskaran Veer Singh explains:

For 2017, LibreOffice is once again an organisation in the GSoC programme, so if you’re a university student and want to get experience working on a well-known free software project, while also being paid for your efforts, get involved! But don’t delay: the application period runs from March 20 to April 3, so it’s not far off.

To get started, check out some ideas for projects you can work on. Each project describes what’s involved, the skills required, and the mentor you can contact to get help. If you see something you’d like to work on, contact the mentor as soon as possible! Then you can discuss how to proceed.

After that, read the general GSoC 2017 page on our wiki, which provides more information on the GSoC programme and tells you how to apply. You will have to complete an Easy Hack (simple programming challenge) to be accepted, which demonstrates that you’re comfortable modifying the LibreOffice source code, building it, and submitting a patch.

So, check out the ideas, talk to the mentors, and good luck with your projects!

The post LibreOffice and Google Summer of Code 2017 – get involved! appeared first on The Document Foundation Blog.

by Mike Saunders at March 14, 2017 05:39 PM

March 13, 2017

Miklos Vajna

ECDSA support in xmlsec-nss, bundled by LibreOffice

Last month a LibreOffice bugreport was filed, as the ODF signature created with Hungarian citizen eID cards is not something LibreOffice can verify. After a bit of research it seemed that LibreOffice and NSS (what we use for crypto work on Linux/macOS) is not a problem, but xmlsec’s NSS backend does not recognize ECDSA keys (RSA or DSA keys work fine).

The xmlsec improvements happened in these pull requests:

After this the xmlsec code looked good enough. I had to request an update of the bugdoc in the TDF bug twice, as the signature itself looked also incorrect initially:

  • an attribute type in the signature that had no official abbreviation was described as "UNDEF" instead of the dotted decimal form

  • RFC3279 specifies that an ECDSA signature value in general should be ASN1-encoded in general, but RFC4050 is specific to XML digital signatures and that one says it should not be ASN1-encoded. The bugdoc was initially ASN1-encoded.

Finally a warning still remains: while trying to parse the text of the <X509IssuerName> element, the dotted decimal form is still not parsed (see this NSS bugreport). The bug is confirmed on the mailing list, but no other progress have been made so far.

Oh, and of course: Windows is still untouched, there a bigger problem remains: we use CryptoAPI (not CNG) there, and that does not support ECDSA at all. Hooray for open-source libs where you can add such support yourself. ;-)

March 13, 2017 08:57 AM

March 12, 2017

LibreOffice Design Blog

Please participate in a survey about the standard color palette

With the latest update of color palettes published in New Color Palettes in LibreOffice we also introduced a new standard palette that has room for improvement. We asked for input on the design mailing list and received three new variants. Now it’s up to you to decided which one you like most.

The survey is run on our new Limesurvey platform at

https://survey.documentfoundation.org/index.php?r=survey/index&sid=597249

(Survey closed at Mar/19th; result report is in preparation)

The results from this survey will be reported here as soon it has been analyzed.

The post Please participate in a survey about the standard color palette appeared first on LibreOffice Design Team.

by The LibreOffice Design Team at March 12, 2017 10:10 AM

March 06, 2017

Tamas Zolnai

New chart test suit

It's good to see that LibreOffice project has more and more tests improving the functional quality of the software. In this post, I also write about a new test suit added to the project. At Collabora, we are working on a project about a new chart functionality and as a preparation we decided to add a test suit which covers the chart layouting code better than the tests LO already had. With this we can map the actual state of the chart code to test cases and so make sure it's functionality remains intact.

Different kind of automatic tests in LO

There are different forms of automatic tests in the project. The question was which one is the most effective for testing a bigger part of the code (chart layout) not only a small functionality. One form of testing is when we use CppUnit assertions to compare some properties of the actual test case with the expected values. These tests used to test a very specific test case. For example it can check whether one test document has 2 pages when it is imported into LibreOffice. This kind of tests can lead to code duplication when we test the same thing (e.g. page number) on different test documents. That's why this kind of CppUnit test is not effective when we need to test one bigger part of the software sistematically, which may need to test the same thing (e.g. page number) on different test documents, which documents might be important use cases.

Other tests use an XML dump functionality to dump the test document's layout to an XML file and use this file as a reference with which the test document can be compared later. Adding new test cases to this kind of test suits is easier, needs lesser code change compared to first form of tests. However this kind of tests checks the whole layout of the document in general. So when one of these tests fails, you need to check the XML file, understand it's structure and find out why the pointed difference is there. It's clear that this kind of test failures might be more difficult to understand compared to the first form of tests where the test failures point to a very specific document property not to a reference XML file.

New chart test suit

An important difference between these two forms are the generality level of what it tests. First form tests some specific properties of one specific test case, while second form test the whole layout of the test document. To avoid the issues of these two forms I chose to write a test suit designed to test the software functionality on a middle level of generality.

I added a test suit which contains similar tests as the first form, comparing some specific document properties to extected values using CppUnit assertions, but the expected values are not hard coded, but they are written into and read from a simple structured reference file. It's implemented on a way which makes easy to add a new test document for an existing test case and generate the reference file without extending the test code. On the other hand we get a helpful error message when one test failes, since the test case is more specific than an XML dump test.

Testing chart functionality

After I had the form I spent some time on adding the most common use cases to the test suit. I added test cases for different components of charts (axis, chartwall, legend, grid, data series, etc.) and also for common chart types (columnchart, barchart, piechart, etc.). All test cases contains more subcases, testing functionally distinctable use cases. The sistematic testing of the chart functionality also pointed out some issues of the software:

Future possibilities

Now with the new chart test suit bigger part of the chart functionality is covered with tests, but there are still use cases which are not tested. For example some exotic chart types have no tests yet, like bublechart, netchart or 3D charts. Tested document formats are also limited to LibreOffice native formats (ODS, ODP), but these tests are easy to extend to Microsoft Office file formats too, for compatibility testing. You can find new test suit at chart2/qa/extras/chart2dump/ in case you need to add new test cases.

by Zolnai Tamás (noreply@blogger.com) at March 06, 2017 11:28 AM

Improve pivot table import performance (tdf#102694)

After a short break I got back to Collabora and I continue working on LibreOffice. This time I handled a performance issue in pivot table's import code, as part of our work for SUSE. In some cases importing an XLSX document containing more pivot tables took such a long time, that user could interpret it as a freeze.

After some testing we found that pivot table grouping is one of the points which makes import slow. We means me and Kohei Yoshida, who is an expert in this area of the code and helped me with understanding it. So grouping was in our focus this time.

Pivot table groups

In case of pivot tables we can make groups for columns of the source data. This groups can be name groups (general groups), number groups (e.g. number ranges) and date groups (e.g. grouped by year, month, day, etc.). Since this groups are related to the source, they rather part of the source than the pivot table layout. This is true both for MS Excel and LO Calc implementation. Effectively this means that when we have more pivot tables using the same source they will have the same groups too. In case of LO Calc this groups are stored in the pivot cache linked with the corresponding source range.

Performance

The performance issue here was that however these kind of pivot tables (having the same source) were linked to each other by the pivot cache, XLSX import ignored that and worked expecting pivot tables are fully independent. Which means that same groups were imported so many times as many tables referenced them. What makes it even slower, this kind of tables are linked to each other on a way that when one table's grouping is changed other tables are also affected.

This difference between internal handling of pivot tables an the XLSX import code came from that XLSX import code was written before groups became part of the pivot cache. So I actually needed to update the import code to follow the changes of pivot table internal implementation. With that, pivot table groups' import time became quite good. For example the test document I uploaded to bugzilla (tdf#102694) took more than 20 minutes before and now it takes less than a half of a minute. This document contains a small data table and 20 simple pivot tables. So it's not something which should take so much time to load and now it doesn't.

by Zolnai Tamás (noreply@blogger.com) at March 06, 2017 09:02 AM

March 05, 2017

Andreas Mantke

First Steps With LibreOffice Online – Running It For The First Time

I finally compiled LibreOffice online and reached my first milestone. Once this was done I had to create a new subdirectory on my machine:

sudo mkdir -p /usr/local/var/cache/loolwsd

Because I had to run the LibreOffice online with the rights of the user I had to change the ownership of that directory:

sudo chown `whoami` /usr/local/var/cache/loolwsd

Then I could start the online office with:

make run

Once the server of the online office is up I get the information in my shell about the URL of the office with the direct link to the usual hello world document and of the admin Console. The latter one is https://admin:admin@localhost:9980/loleaflet/dist/admin/admin.html
The first one depends on the special configuration and file structure of your machine. It starts with:
https://localhost:9980/loleaflet/64dd841/loleaflet.html?file_path=file://(…)

I pointed my browser to this URL and get to the hello world document. But first I had to deal with the security configuration of my browser (Firefox), which complains about an unknown certificate.

LibreOffice Online Hello World Document
LibreOffice Online – The Hello World Document

And I could also get to the admin console with the URL that was displayed to me in the shell.

LibreOffice online admin console
The LibreOffice online admin console

by andreasma at March 05, 2017 08:00 PM

First Steps With LibreOffice Online – Compilation

I compiled LibreOffice from source code several times and want to give also LibreOffice online a try. Thus I checked out the source code from the git repository first with:
git clone git://anongit.freedesktop.org/libreoffice/online

I looked into the README file inside the new local git repository and got the information that I should look into the readme files inside the ‚wsd‘ and the ‚loleaflet‘ subdirectories. I started with the readme inside the wsd subdirectory.

This gave me the next step. Because I currently use the Linux distribution openSuSE Leap 42.2 I had to add another repository with zypper to the list with:

zypper ar http://download.opensuse.org/repositories/devel:/libraries:/c_c++/openSUSE_Leap_42.2/devel:libraries:c_c++.repo

Next I installed some dependencies with:
zypper in poco-devel libcap-progs

Then I run inside the main directory the following commands (in this order):
– libtoolize
– aclocal
– automake –add-missing
– autoreconf
– autoheader

And then follows the run of configure. In my case I used:
./configure –enable-silent-rules –with-lokit-path=~/libreoffice/gerritgit/libreofficeonline/online/bundled/include –with-lo-path=~/libreoffice/gerritgit/libo/instdir –enable-debug

But that doesn’t work, because the path to the directories of the LibreOfficeKit header files and the LibreOffice installation are to long. I gave it another try, copied the headers and the installation to another directory with a shorter path and it works.

I could then compile LibreOffice online with make and the process runs as described in the README inside the subdirectory ‚wsd‘.

by andreasma at March 05, 2017 10:43 AM

March 03, 2017

Andreas Mantke

New Release For The LibreOffice Templates Site AddOn

I released an update of a further Plone addon today, that I worked on  together with our service provider within some weeks. The addon drives the templates part of the LibreOffice extensions and templates website. The update creates some improvements for the website and updates the the localisation template and the German localisation with the last string changes. I edited and updated the German localisation file with poedit, a great open source tool.

You could get the new releae of the Plone addon from the ‚cheeseshop‘ (https://pypi.python.org/pypi) with the direct link:
https://pypi.python.org/pypi/tdf.templateuploadcenter/0.11

by andreasma at March 03, 2017 07:12 PM

March 02, 2017

Andreas Mantke

New Release For The LibreOffice Extension Site Plone AddOn

I worked together with our service provider on improvements of the Plone addon for some weeks, that drives the extensions part of the LibreOffice extensions and templates website. I added the last changes and an update for the localisation template and the German localisation today. I used for the latter one the open source editor poedit.

Once I finished the update of the German localisation I created a new release of the Plone addon and uploaded it to the ‚cheeseshop‘ (https://pypi.python.org/pypi). The release 0.14 of the addon is publicly available now at:
https://pypi.python.org/pypi/tdf.extensionuploadcenter/0.14

by andreasma at March 02, 2017 09:07 PM

February 27, 2017

Florian Effenberger

Interview über meine Arbeit in der Stiftung

Italo Vignoli hat mich über meine Arbeit bei der Document Foundation befragt. Das englischsprachige Interview findet ihr im Blog der Stiftung.

by Florian Effenberger at February 27, 2017 09:30 AM

David Ostrovsky

Gerrit User Summit 2016, Mountain View, CA

As you may know i was participating in this year Gerrit User Summit, 12th-13th November 2016, followed by Developer Hackathon in Mountain View, CA.

There were plenty of great talks, including EMail ingestion, Atomicity with change-sets, Gerrit analytics, Update on new and shiny UI, called PolyGerrit, based on Google’s own Polymer project, Zero-downtime Gerrit upgrades and what’s new and in Gerrit 2.12, 2.13 and coming next 2.14 releases.

I gave a talk about the status of my work on implementation of Bazel build for Gerrit.

After the user conference we had couple of days of Gerrit developer hackathon, where I continued to work on Bazel build implementation for Gerrit, approaching the feature parity with Buck build implementation. During the hackathon I uploaded a CL for removing Buck build, so that the new Gerrit version is going to be built and released with Bazel only.

I would like to thank Firma Frobese GmbH for sponsoring travel cost for my participation.

by davido at February 27, 2017 07:32 AM

February 17, 2017

Andreas Mantke

Another Round Of Content Language Setting For ODFAuthors

I worked again on the language setting of ODFAuthors content for some hours. I was able to change the language setting of a lot of content items and there are only a smaller list of remaining items. Seemed I could see the light at the end of the tunnel.

by andreasma at February 17, 2017 10:44 PM

Stephan Bergmann

Too Subtle?

Spot the difference between the two C++ programs

struct S { int a = b, b; };
int main() { return (new S())->a; }

and

struct S { int a = b, b; };
int main() { return (new S)->a; }

Right, the first one terminates cleanly with exit code zero, while the second one does whatever it deems necessary to counter undefined behavior.

Why is that? The expression new S() means direct-initialization, which for () means value-initialization. Class S has a default constructor that is not user-provided, not deleted, and non-trivial (because non-static data member a has a default member initializer). So the instance of S is first zero-initialized, then default-initialized. Zero-initialization means that a and b are initialized to zero. Default-initialization for S means that the default constructor is called, which means that a is initialized from its default member initializer, by copying zero from b (and then b is default-initialized, leaving it alone).

On the other hand, just new S (without the parentheses) means just default-initialization (without previous zero-initialization). So, again, default-initialization for S means that the default constructor is called, which means that a is initialized from its default member initializer, copying the uninitialized b (and then b is default-initialized, leaving it uninitialized)…

Too subtle? Probably.


by stbergmann at February 17, 2017 10:33 AM

February 16, 2017

LibreOffice Design Blog

Guidelines for keyboard navigation in the sidebar

LibreOffice takes accessibility seriously, and we want to make our program as enjoyable for users with disabilities as it is for everyone else. That means we care about motor impairments and, for instance, we always provide different ways for interacting with the software. And, of course, accessibility covers a wide range of visual handicaps related with color blindness, which are taken into account to ensure that information is not only coded by color, and also to account for cases of complete blindness, where a screen reader is necessary.

Not every modification in the past went well, and we are facing some issues with the latest version. For instance, Jean-Philippe Mengual mentioned at the LibreOffice conference in Brno that it is not possible to access styles in the sidebar. While we have human interface guidelines (HIG) for the sidebar UI, it lacks on advices regarding accessibility. Therefore, the UX and the accessibility teams analyzed the current state regarding keyboard navigation and summarized the outcome into a draft that should be added to the sidebar HIG.

A lot of good ideas were discussed, though mostly discarded. For example, the access to relevant content could be simplified when some less important features are excluded from the the navigation sequence and thereby ‘hidden’ from the screen reader. The striking argument is that disabled people work together with normal users and potentially face a situation where an unexpected state occurs. So one axiom is to make all functions accessible. Another rationale is to make simplicity paramount before consistency or clearness. Having different shortcuts for parts of the UI that technically do not belong together might sound reasonable but complicates the interaction. And finally, we do not want to change the learned interactions and keep things as much simple as possible.

Guidelines

Activation

  1. Activate the accessibility mode with F6.
  2. Navigate using F6 starts at the main menu, followed by the open toolbars, and finally the sidebar.
  3. On the sidebar, land first on the open deck‘s title bar, or the sidebar‘s tab bar when the deck is closed.
  4. Leave the accessibility mode with Ctrl+F6 and go back to the document position where the navigation has started.
  5. Use Escape to go back one step in the navigation, meaning from the content to the content panel title and then to the document.

Tab bar

  1. On the tab bar, land on the tab of the active deck or the tab of the first deck when the sidebar is closed.
  2. Jump to next/previous tabs with arrow keys including the configuration button.
  3. Jump to the title of the first content panel using Enter. In case of no content panel go to the first control with Enter.
  4. Expand or collapse the deck with space but stay at the tabbar.

Deck

  1. Cycle through the content panels (e.g. Styles, Character, Paragraph etc.) per arrow up/down.
  2. Make all parts of the deck accessible including the deck title.

Content panel title

  1. Traverse the content panels of a deck using the arrow keys when the focus is on the content panel title or through Ctrl+Tab/Shift+Ctr+Tab on any position in the content panel.
  2. Make all parts of the content panel accessible including the content panel title and the options menu.
  3. When jumping to the next content panel land on the title.
  4. Jump to the first control of the content panel using enter.
  5. Expand the content panels automatically on enter when collapsed.
  6. Expand or collapse the content panel with space but stay at the title.

Content panel

  1. Within the content panel navigate between controls using tab/shift+tab.
  2. Use arrow keys to access controls that are part of a collection such as toggle buttons, lists, dropdowns (e.g. bold, italic, underline etc.).

Visualization

The figure illustrates what is defined in the guidelines. Markups with numbers should help to find the respective advice.

Keyboard navigation in the sidebar

Figure 1: Keyboard navigation in the sidebar (Source).

Discussion

First of all we would like to thank Alex Arnaud from the Hypra team for contributing with his expertise. But as usual there may be aspects that we haven’t addressed or that might be solved better. So please speak up now and share your experiences with us.

The post Guidelines for keyboard navigation in the sidebar appeared first on LibreOffice Design Team.

by The LibreOffice Design Team at February 16, 2017 08:18 PM

Miklos Vajna

LibreOffice PDF export now supports videos

https://farm4.staticflickr.com/3924/32549564340_4d0990cfa4_o.png

PDF supports screen annotations, which means it’s possible to play embedded and linked videos on top of a static image. Given that LibreOffice also supports videos, it made sense to add support for this in our PDF export filter. First, thanks to PMG who made this work possible. This is currently added for Writer and Impress.

Linked videos

Linked videos are the situation when the video is not part of the document itself, but it’s located somewhere else, e.g. a http:// location. This is helpful if you want to email around a PDF file, and want to avoid sending large files when it has video content.

tdf#104841 is about this situation, first I added support for linked videos in Impress, then also in Writer.

The result can be played using Adobe Acrobat Reader — for some reason okular on Linux is a bit confused about http:// URLs, wants to convert them to relative ones, and then fails as of today.

Embedded videos

https://farm3.staticflickr.com/2666/32115175413_ec6f64243a_z.jpg

tdf#105093 is the embedded video case, this is handy in case you want to create an entirely self-contained PDF, where even the video content is inside the PDF file as an embedded file.

After Impress support (and a trick around Draw vs Impress shapes) the Writer part wasn’t too complicated.

Regarding the situation around various video containers and codecs, the above code is quite agnostic. :-) On the LibreOffice side all we require is to be able to extract a key frame from the video to provide a preview image, so e.g. on Linux the support depends on what gstreamer plugins you have installed. The video content is written to the PDF file as-is, so again if it will work in the PDF reader is up to the reader’s codec support. On Linux e.g. okular uses vlc for video playback, so the range of supported formats is quite wide. The same is true on Windows, what I personally tested is LibreOffice’s VLC backend and the embedded QuickTime player in Acrobat Reader.

All of this is available on LibreOffice master towards 5.4.

February 16, 2017 08:38 AM

February 14, 2017

February 11, 2017

Eike Rathke

42

Today is the 42nd day of the year.
Today is Boomtime, the 42nd day of Chaos in the YOLD 3183

by erAck (23@127.0.0.1) at February 11, 2017 11:42 AM

February 10, 2017

Jan Holešovský

Integrating LibreOffice OnLine into your web app

I've returned from FOSDEM 2017, where I talked about LibreOffice Online that we develop here at Collabora and how to integrate it with your own web service. If you did not have the opportunity to see the presentation there, here are the slides:

Click the slide to see the presentation

by Jan Holesovsky (noreply@blogger.com) at February 10, 2017 05:34 PM

January 31, 2017

Miklos Vajna

Impress bugfixes, in time for FOSDEM 2017

https://farm1.staticflickr.com/334/32605456735_ac88121be8_o.png

FOSDEM 2017 is here this weekend, and as Michael Stahl pointed out, this (together with the LibreOffice annual conference) are two time periods each year when lots of Impress bugfixes are made, as people start dogfooding. ;-) So below you can read about a pair of Impress bugs I fixed recently.

Changing font size now takes table selection into account

tdf#105502 is a situation where you have an Impress table shape, and you select part of the cells, then you click on the sidebar to change the font size. Previously this affected all cells of the table shape, now only the selected cells are updated.

Background fill for shapes

https://farm1.staticflickr.com/277/31761747774_4b1e6b8d38_o.png

tdf#105150 is a PPT(X) filter bug where a shape was previously imported as transparent, but it actually has to have the same fill type as the slide background. In case of PPTX this was already handled in general, but not in case the slide had no explicit background. The result was that in case the shape was used to cover other shapes, they were visible, leading to e.g. this unexpected red rectangle on the screenshot.

The same bug was present in the PPT import, though there existing support was even more limited: just the "background colored objects" were collected, but nothing was done to them. Now the above use-case should be as good for PPT as it is for PPTX.

January 31, 2017 08:17 AM

January 23, 2017

David Ostrovsky

Gerrit Hackathon at SAP, Walldorf

In September 2016, I attended 5 days Gerrit developer hackathon, in Walldorf, SAP.
As always it was a big pleasure to meet SAP Git/Gerrit hackers in person:
Sasa, Matthias, Michael and Chris.

I finalized my work on extending labels in secondary index to be change owner votes aware. Now it’s possible to use these gerrit queries:

Skip WIP changes, rejected by change owner:

is:open NOT label:Code-Review-2,owner

Skip non reviewable changes, approval by change owner:

is:open NOT label:Code-Review+2,owner

Detect changes, that violates “non-self approval policy”:

label:Code-Review+2,owner

Suggest changes for auto merge: approval by change owner + verify by the bot (assuming default label set: CRVW + VRFY):

project:foo
branch:master
is:open
is:mergeable
label:Code-Review+2,owner
label:Verified+1,buildbot
NOT label:Code-Review-2
NOT label:Verified-1

Dave finalized the work I started on cookie based PolyGerrit/GWT UI switch. With this change it is possible to switch between new and old UI. Given that the pure JavaScript (Polymer based) UI is not ready yet, it is not really a viable option to switch Gerrit site per configuration to the new UI. Switching in the live server, back and forth, makes a lot of sense. In Gerrit footer there is a toggle link “new UI”/”old UI” now. It can be seen on gerrit-review, that is running master. The new feature is going to be available in upcoming 2.14 release.

GWT upgrade from 2.7 to 2.8 was an interesting journey. Gerrit upgraded Jetty to 9 years ago, as the consequence, we have seen classpath collisions caused by GWT using older Jetty version Jetty 8. As an intermediate step, we strip Jetty 8 bits from the gwt-dev.jar artifact and fork some parts of GWT library in Gerrit tree and adapt it to use Jetty 9. It turned out, it wasn’t trivial at all to bump Jetty version to 9 in GWT, because HtmlUnit was still depending on Jetty 8, (more precisely WebSocket part of it). Given that WebSocket module was substantially refactored in Jetty 9 compared to Jetty 8, HtmlUnit must be adapted to this WebSocket refactoring.

So, in the end I’ve implemented this upgrade series in 3 different projects: HTMLUnit, GWT, Gerrit:

The rest of the week I continued to work on Bazel build implementation. In the end of the week, all core plugins can be built with Bazel.

Here is the summary from Sasa on all activities during the Hackathon.

Big thank to The Document Foundation for funding the travel costs for my participation.

by davido at January 23, 2017 04:06 PM

January 18, 2017

>Marius Popa Adrian

Firebird bug CORE-5452 is fixed : Segfault when engine's dynamic library is unloaded right after closing worker threads

Firebird bug CORE-5452 is fixed http://tracker.firebirdsql.org/browse/CORE-5452 The issue was reported multiple times in Firebird devel list, I will mention here Damyan Ivanov (Debian) and Stephan Bergmann. (RedHat) And related commit in Firebird 3.0 branch https://github.com/FirebirdSQL/firebird/commit/40f782ae3e918c4f3842571ff8064be1c4f54961 Stephan Bergmann contributed the patch to

by Adrian Marius Popa (noreply@blogger.com) at January 18, 2017 10:12 AM

January 17, 2017

Miklos Vajna

Hack-(rest-of-the)-week at Collabora

https://farm1.staticflickr.com/726/32306648426_b4ee93f6a1_o.png

As mentioned in the blog post of Mike already, last month we were allowed to hack on anything we want in LibreOffice for a few days. I used this time to progress with 3 different topics.

Stepping through TextBoxes using the keyboard

Given that a Writer shape with a TextBox is internally two shapes, this needed explicit support. After my TextBox bugfix it’s possible to have two such shapes in a document, and once you select one of them, tab properly jumps between the two shapes; previously nothing happened.

What did happen is we tried to activate the TextBox of the selected shape, which selected the shape itself, so at the end nothing happened.

RTF improvements

For some time it was already possible to import and export custom string document properties from/to RTF, but just in case the value type of the property was string. Now I extended support for these custom properties, so also the remaining types are handled: numbers, bools, doubles and dates.

xmlsec patch upstreaming

Last, I’ve started working on upstreaming external/libxmlsec/xmlsec1-noverify.patch.1. xmlsec has no ability to disable the verification of certificates (think of curl -k or wget -k), so in LibreOffice currently we just patch out that code as we don’t need it. So I wanted to add a new verification flag to avoid patching, but it turns out that in the NSS case xmlsec didn’t do the verification, so as a first step I fixed that instead in this xmlsec GitHub pull request. Now that it’s merged, the next step will be to add such a flag, and then LibreOffice can get rid of the patch after the next xmlsec release.

January 17, 2017 08:50 AM

January 16, 2017

LibreOffice Design Blog

DIY UI: How to create your own Notebookbar

Introduced recently with the MUFFIN concept, the Notebookbar is a blank canvas where controls can be placed and arranged freely. It offers all freedom to users who are not afraid to fiddle around with an integrated development environment (IDE). Here we explain how to start from scratch.

Setting up the environment

Notebookbars are ui files, which are just XML-formatted text files. Changing the files in any text editor is possible but quite tedious. The supposed way to modify ui files is to use Glade. (This may change in the future.)

After installing Glade, you have to add the LibreOffice catalog in order to use specific controls. Go to Edit > Preferences, click Add and search for the path <libreoffice>/share/glade. If all goes smoothly the LibreOffice controls will be listed in the left sidebar after restarting Glade.

Creating a new Notebookbar

Now you are able to modify existing toolbars. For Writer it is notebookbar_groups.ui or notebookbar_simple.ui at <libreoffice>/share/config/soffice.cfg/modules/swriter/ui/. Calc’s ui files are located at <libreoffice>/share/config/soffice.cfg/modules/scalc/ui/, Impress at …simpress/ui etc. Just load the ui file into Glade, modify as you like, save and switch the used toolbar in LibreOffice (no full restart needed).

But if you are afraid of messing around with the shipped files it is also possible to start from scratch. First you need to add a reference to your new ui file in <libreoffice>/share/registry/main.xcd. Unfortunately, this XML file is created during the build process without any line breaks, which hinders editing. Luckily there is the small tool called tidy that helps with formatting XML files. Rename the file main.xcd first to main.bak and run:

cat main.bak | tidy -utf8 -xml -w 255 -i -c -q -asxml > main.xcd

Now you can open the file in your preferred text editor. Search for the line with notebookbar_groups and copy/paste the complete section to duplicate it:

<node oor:name="Groups" oor:op="replace">
  <prop oor:name="Label">
    <value xml:lang="en-US">Contextual groups</value>
  </prop>
  <prop oor:name="File">
    <value>notebookbar_groups.ui</value>
  </prop>
  <prop oor:name="HasMenubar">
    <value>true</value>
  </prop>
</node>

There is more than one occurrence of notebookbar_groups.ui, one for every application. Make sure you change the section below:

<oor:component-data xmlns:install="http://openoffice.org/2004/installation" oor:name="Notebookbar" oor:package="org.openoffice.Office.UI">
//...
  <node oor:name="Applications">
    <node oor:name="Writer" oor:op="replace">

Now you change the node name from “Groups” to “MyMuffin”, the label from “Contextual groups” to “My Muffin”, and the file reference from notebookbar_groups.ui to notebookbar_mymuffin.ui.

Create the actual file notebookbar_mymuffin.ui at <libreoffice>/share/config/soffice.cfg/modules/swriter/ui/ and enter the basic stuff:

<?xml version="1.0" encoding="UTF-8"?>
  <interface>
    <requires lib="gtk+" version="3.12"/>
    <requires lib="LibreOffice" version="1.0"/>
  </interface>

You can also use Glade to create a new file or duplicate one of the other Notebookbar files and delete the content. Start Writer to see a beautiful blank canvas waiting for your creativity.

Editing the Notebookbar

To start with a very simple implementation we construct a “classic” toolbar. Run Glade and open the ui file. Click the Box symbol (first item in the section Containers) and drag it onto the blank canvas. In the pop-up dialog change the number of items to 1 (you can modify all properties later). Now add a Notebookbar toolbox (in the section LibreOffice one of the last items; the common toolbar under Containers will not work) and drop it into the GtkBox. You can resize all controls as you like, but the final alignment is done by LibreOffice.

Right click the sfxlo-NotebookbarToolbox and click Edit… In the dialog go to the tab Hierarchy and click Add. In the right hand area with properties look for Action name and enter .uno:Open there. For easy identification you can use Open at ID and delete the predefined text under Label. That would be enough to show the open icon with all the functionality in Writer.

“My Muffin” with the first button.

Figure 1: “My Muffin” with the first button.

Toolbar items are defined by default as buttons and in contrast to the normal Open function you will not have menu with the additional features. You can easily change this property under Hierarchy: Tool item > Type from Button to Menu.

You may want to add more functions, so the question arise how all the functions are called and where to get help from.

.uno:What?

The .uno: commands contain all information of an entity such as name and tooltips including translation, the icon depending on the selected theme, enabled/disabled status, the actual function, etc. into a generic model. For example, .uno:Bold means the button toggles the text property bold/not bold. If you know the function by name you can find the right .uno: command in the main menu specification (menubar.xml) at <libreoffice>/share/config/soffice.cfg/modules/swriter/menubar/ (respectively for other modules in scalc/menubar, simpress/menubar etc).

And of course it makes sense to have a look at the other Notebookbars. It shows how to deal with context depending sections, how to use tabs, and how to use big buttons instead of the very simple toolbar.

Summary

You can modify existing Notebookbars at <libreoffice>/share/config/soffice.cfg/modules/<module>/ui using Glade, or add your own after editing the file <libreoffice>/share/registry/main.xcd. The Notebookbar is a blank canvas where controls can be added.

Be aware that this modifications are quite hacky and will be overridden with the next update. We are aware that this procedure is not user-friendly. The current implementation is experimental and in a very early stage. But it gives an idea what is possible.

More important is that you can also fix or improve the existing Notebookbar variants that are shipped with LibreOffice. So when you see something that can be done better, we welcome improvements as patches!

Please reach out to us on IRC in case of questions – and start hacking LibreOffice today– it’s fun!

The post DIY UI: How to create your own Notebookbar appeared first on LibreOffice Design Team.

by The LibreOffice Design Team at January 16, 2017 03:24 PM

January 12, 2017

Mike Kaganski

LibreOffice MUFFIN

Recently, TDF has published its new MUFFIN concept. This publication has provoked a mixed response, with many negative reactions.

When we deal with UI, any possible change brings controversy, and it’s always very aggressive when someone finds that a function they are used to use some way had changed its position. OTOH, there is always a substantial part of community that aggressively promotes “modernization” of current UI.

We all remember how different projects made their UI changes. We remember cases when programs with huge user base made radical changes without an option to keep old UI for those who prefer it. And it forces many of us to resist any sign of possible UI changes in software we use.

Many believe that “design” and “marketing” are swearwords that are used when a company tries to make “purchasers” believe they need something they actually don’t. So, any use of these words in a press release makes yet another chunk of user base to get angry.

There are people that don’t care of UI changes, but have strong opinions that there are much higher-priority tasks to do, like improving stability, compatibility and so on. And when they hear of an effort in an area they regard as unimportant, they get upset. Some of them even have donated to TDF with hopes that donations would go to those goals, and now “see” that TDF wastes their money to pay some designers/marketologists instead of doing Right Things (TM).

Many see the news about UI and immediately realize that there’s indeed something new in UI that is announced. They don’t care to read (let alone comprehend), and so skip any text for screenshots/mockups, and get their views on the matter based on their perception of the graphics. And many of them are angry because they see something that disappoints their expectations of e.g. “ribbon-like” interface. Or they suppose that TDF fools them trying to make believe that there’s something new in the UI options (besides NotebookBar) when actually all that is presented is already possible for long time. “Ah, they try to show to you something old, and pretend that it recently have made a great work to create something new! Smart move!”

Some think that new UI elements are not ready for use and need to be polished in a different branch before inclusion into a LO release.

Many believe that UI changes must begin with UI implementation being rebased to some other library like QT, and that any effort that doesn’t do this is waste of time.

People seem to misunderstand what MUFFIN is.

Thankfully, there are some people in LO community who feel interested in design issues. They form our Design team. Those people are not necessarily developers, and if they are, they have their own interests and priorities, independent of TDF’s or some specific user’s. That’s a great feature of open source community, where each one is able to find an area of interests to apply their effort. And it doesn’t matter if you want LO to get a bug-fix/compatibility feature, and it doesn’t matter if I do some work on those fixes/features: those other people don’t need and aren’t forced to wait for me or help me; they volunteer to do their own contribution in their area in their spare time, and announce their results when they feel appropriate. So anyone who argues that some other things should have been done instead of this work, is misguided. If we would prevent the Design team from doing this, we wouldn’t get more man-power dedicated to your preferred tasks; rather, we would just had lost the man-power (and more important, we would loose those contributors, because there wouldn’t be any reason for them to stay with the project).

The Design team clearly sees the challenges that LO faces with regards to UI changes. On one hand, many want some “refresh”; on the other, many deny the very possibility of it and are afraid of it. There are issues in UI not following different OSes/DMs conventions (making LO to feel not native to these OSes/DMs). And with MUFFIN, the team had IMO made a very smart move.

MUFFIN isn’t a new interface itself. It is even not an interface concept in a usual sense of the term! What it actually is is a public statement, a promise made by LO to its users; and this statement and promise is that: LibreOffice believes that it should be pleasant and easy to use by anyone; and it will never take steps (like other softwares sometimes do) that will sacrifice one group of users’ preferences just to please another – instead, it promises to make its UI as much configurable and modular as it required to allow you, me and anyone to build their own UI of choice. The message is that LO will e.g. continue to provide toolbars: this is not a “first step after which some evil designer will inevitably drop support for good old UI”! And in the same time, LO will not ignore those numerous current and potential users that want another interface: their interests aren’t of lower importance.

If someone still believes in a conspiracy theory that will eventually deprive you from your dear toolbars, remember that LO is being developed by those developers who prefer toolbars themselves, and there’s no ultimate authority to make decision to drop it regardless of those developers’ PoV.

So, MUFFIN is not a NotebookBar or a Single Toolbar. It is a message to users, and a guideline to developers who make UI-related changes. MUFFIN is not the four presented UI options; rather, they are just demonstration of commitment to make it easy to any group to customize.

The four presented UI options are not meant to be necessarily something new. Of course, you can use standard toolbars, or customize them to let only one custom toolbar visible, or use sidebar with any combination of toolbars: the UI components and their combinations aren’t new. The UI components aren’t perfect, and the concept doesn’t claim they are. The concept is orthogonal to any framework used to implement UI components. So, those who are not pleased because the UI isn’t new or isn’t perfect aren’t right when they blame MUFFIN for that. MUFFIN is a promise – so it’s not something to be kept in a separate development branch; and it’s not something that needs screenshots. I’d say that providing screenshots in the press release actually distracted and misguided many readers from the real message.

TDF didn’t spend money to make this happen. It used a research that is publicly available. It doesn’t spend your money to pay some greedy designers: it uses its community’s great power. So no need to get angry that your money are wasted. (As a side note, I’d suggest people to get familiar with TDF role and understand that it doesn’t develop LO itself; instead, it provides home and shelter to community, and promotes the software. Understanding this can help you avoid disappointment when you find out that your donations go to other needs that you imagined.)

I believe that MUFFIN is a great message if you make an effort to hear it. Please do. And if you believe that there’s something to improve, please contribute and become part of community!


by mikekaganski at January 12, 2017 12:57 PM

January 10, 2017

Lera Goncharuk

Numbering of pages in LibreOffice Writer

If you have an experience of text document editing, you may skip the introductory remarks. I just wanted to say a few words to people who have just started to work in LibreOffice in order to they can understand about what the talk.

Read more »

by Lera Goncharuk (noreply@blogger.com) at January 10, 2017 07:30 PM

January 02, 2017

Lera Goncharuk

Creating a Tornado charts in LibreOffice Calc

Tornado charts help us to display opposite sides of one and the same process. This is not just a nice view, but the intuitive display of the process. In this article I will try to show a quick and easy way to build this type of charts in LibreOffice Calc. For example, such as this:

Read more »

by Lera Goncharuk (noreply@blogger.com) at January 02, 2017 01:56 PM

December 30, 2016

LibreOffice Design Blog

New Color Palettes in LibreOffice

A color palette is an arrangement of a limited set of colors resembling a painter’s palette. Some collections are officially standardized, others are individually assembled to serve, for instance, a branding purpose or to convey a certain mood.

Among many other things, good design means to have a limited number of colors that work well together. For example, a pale blue can harmonize with a muted red and it makes sense to combine night blue with a fluorescent yellow. Colors influence emotions and perceptions and carry a specific meaning according color psychology.

While our prototypical user Benjamin might be satisfied with a small palette that consists of well harmonizing colors it’s not sufficient for expert users such as Eve. Professional desktop publishing requires more elaborated palettes since certain colors need to be reproduced independently from the output target such as web, CMYK print, digital print etc. Different color models exist requiring a conversion between them, which may not always be perfect, depending on the respective gamut.

Another important aspect of palettes is the naming of colors. Large color collections require that each color can be identified with a unique and descriptive color name. That’s also true for color palettes with only tiny variations between two similar shades of gray, for instance, or when color blindness comes into play and the user cannot easily discriminate between red and green.

Status before release 5.3

LibreOffice shipped releases prior to 5.3 with the color palettes:

  • cmyk: 216 colors with small variations arranged in six steps using RGB values for the color names
  • gallery: 61 variations of basic colors arranged in ten steps named by RGB values
  • html: 131 colors following the web standard using the X11 color names plus hex and decimal value like “ghostwhite F8F8FF 248.248.255”
  • libreoffice: 32 colors of the LibreOffice branding including black and white
  • palette: 77 rather arbitrary colors; RGB values separated by % are used as labels
  • scribus: 545 colors with names following the X11 standard plus numbers, e.g. Chocolate4
  • standard: Hand-crafted palette based on Symphony, well arranged with basic names plus numbers, e.g. Green1
  • tango: 27 named colors from the Tango project
  • web: 232 arbitrary colors using RGB values for the color name

Additionally there are document colors, where the colors used in the current document are listed (unfortunately it is buggy), and recently used colors, which is actually a swatch listing what has been selected before (unfortunately it is also buggy).

It was possible to individually change the standard color palettes per Tools > Options > Colors.

Changes with release 5.3

Changes to the workflow

With the Google Summer of Code project Area Fill Style (planning was introduced here), the palette handling underwent a revision. Firstly, the recent colors are fully functional now, so the most important use case of having the same color on repeated actions is covered well with this feature.

Recent colors are working perfectly now.

Figure1: Recent colors are working perfectly now.

Newly introduced was the custom palette, which allows to add colors directly in the area style dialog. The custom palette serves the purpose of user customized collections.

Fifty shades of LibreOffice.

Figure 2: Fifty shades of LibreOffice.

This custom palette makes the manipulation of factory settings via Tools > Options > Colors obsolete ‒ and hence we deleted this option. Expert users who want to modify a predefined palette need to edit the file directly. The palettes are files with the extension *.SOC located at <libreoffice>/share/palette. The content is an XML formatted list of hexadecimal color values like

<draw:color draw:name="Azure" draw:color="#f0ffff"/>

Deleted and modified palettes

Furthermore, we reduced the set of palettes. The palettes gallery, web, cmyk, and scribus were removed because of the non-standard and rather arbitrary collections with inappropriate names. Tango and html received minor updates for labels and arrangement of colors.

The standard palette was also refreshed. The first row starts now with 12 shades of gray followed by 12 basic colors from the HSV color wheel. The next rows are variations of these basic colors in respect to saturation and luminance by 66%, 50%, and 25%. The final 12×8 arrangement fits perfectly into our color picker grid.

New standard palette.

Figure 3: New standard palette.

Added palettes

The palette breeze has been added to the default set. It comprises all values known from the KDE human interface guidelines as an alternative to tango.

Completely new is the tonal palette. It aims to provide a set of colors with the same luminance respective color contrast. It starts with 10% saturation (named accordingly such as ‘Violett 10%’ or ‘Chartreuse Green 10%’) and continues in 10% steps. Above ‘medium saturation’ the steps are 58, 65, 73, 82%, if possible. Colors that cannot have a higher hue saturation are added as whitespace and named ‘Out of Gamut’. We greatly appreciate the initial work by Wade D. Peterson.

Newly introduced palettes Breeze and Tonal.

Figure 4: Newly introduced palettes Breeze and Tonal.

In order to integrate LibreOffice into professional graphics and layout workflows the palette freecolour-hlc based on the CIELAB color model has been added. Its purpose is to provide a cross-media safe set of colors targeting expert publishers. The palette contains a range of muted RGB colors that can be replicated in CMYK and is perfectly suited for those who need a maximum of color correctness across media and platforms. The palette has been created by the non-profit association freieFarbe e.V. (freeColour).

The CIE-HLC palette ‘freecolour-hlc’ from freieFarbe e.V.

Figure 5: The CIE-HLC palette ‘freecolour-hlc’ from freieFarbe e.V.

Extensions

As discussed in a former blog post about LibreOffice Additions we should make customization easier by using extensions, and with version 5.3 you can install color palettes via extensions. For those who want to share their collections it shouldn’t be too difficult to become familiar with the format.

Extensions are basically ZIP files renamed to OXT. Within the archive the file config.xcu defines the path where the palette has to be placed (no need to change this) and the file description.xml with all information about the extension.

<?xml version="1.0" encoding="UTF-8"?>
    <description
        xmlns="http://openoffice.org/extensions/description/2006"
        xmlns:d="http://openoffice.org/extensions/description/2006"
        xmlns:lo="http://libreoffice.org/extensions/description/2011"
        xmlns:xlink="http://www.w3.org/1999/xlink">
        <!-- any unique identifier, e.g. my.fancy.palette  -->
        <!-- extension not hosted in the LibO repos shouldn't have an identifier starting with org.libreoffice -->
        <identifier value="org.libreoffice.breeze"/>
        <!-- version numbers are usually in major.minor.patch scheme -->
        <version value="1.0.0"/>
        <!-- extensions with palettes need minimal 5.3 -->
        <dependencies>
            <lo:LibreOffice-minimal-version d:name="LibreOffice 5.3" value="5.3"/>
        </dependencies>
        <!-- reference to the publisher here     -->
        <publisher>
            <name xlink:href="https://wiki.documentfoundation.org/Design" lang="en">LibO Design Team</name>
        </publisher>
        <!-- how the extension will be called in the extension manager   -->
        <display-name>
            <name lang="en">Breeze palette</name>
        </display-name>
        <!-- optionally an unique icon for the extension manager   -->
        <icon>
            <default xlink:href="images/logo.png"/>
        </icon>
</description>

 

 

The post New Color Palettes in LibreOffice appeared first on LibreOffice Design Team.

by The LibreOffice Design Team at December 30, 2016 11:11 AM

December 27, 2016

Tim Janik

DevLog: Meson and Beast threading (33c3)

33c3

The last update has been a while, so with the new year around the corner and sitting in c-base @ 33c3, I’ll do my best to sum up what’s been going on in Rapicorn and Beast development since the last releases.

Now both projects make use of extended instruction sets (SIMD) that have been present in CPUs for the last 8 – 10 years, such as MMX, SSE, SSE2, SSE3 and CMPXCHG16B. Also both projects now support easy test builds in Docker images, which makes automated testing for different Linux distributions from travis-ci much simpler and more reproducible. Along the way, both got finally fixed up to fully support clang++ builds, although clang++ still throws a number of warnings. This means we can use clang++ based development and debugging tools now! A lot of old code that became obsolete or always remained experimental could be removed (and still is being removed).

Beast got support for using multiple CPU cores in its synthesis engine, we are currently testing performance improvements and stability of this addition. Rapicorn gained some extra logic to allow main loop integration with a GMainContext, which allows Beast to execute a Gtk+ and a Rapicorn event loop in the same thread.

Rapicorn widgets now always store coordinates relative to their parents, and always buffer drawings in per-widget surfaces. This allowed major optimizations to the size negotiation process so renegotiations can now operate much more fine grained. The widget states also got an overhaul and XML nodes now use declare=”…” attributes when new widgets are composed. Due to some rendering changes, librsvg modifications could be obsoleted, so librapicorn now links against a preinstalled librsvg. RadioButton, ToggleButton, SelectableItem and new painter widgets got added, as well as a few convenience properties.

After setting up an experimental Rapicorn build with Meson, we got some new ideas to speed up and improve the autotools based builds. I.e. I managed to do a full Rapicorn build with meson and compare that to autotools + GNU Make. It turns out Meson had two significant speed advantages:

  1. Meson builds files from multiple directories in parallel;
  2. Meson configuration happens a lot faster than what the autoconf scripts do.

Meson also has/had a lot of quirks (examples #785, #786, #753) and wasn’t really easier to use than our GNU Make setup. At least for me – given that I know GNU Make very well. The number one advantage of Meson was overcome with migrating Rapicorn to use a non-recursive Makefile (I find dependencies can still be expressed much better in Make than Meson), since parallel GNU Make can be just as fast as Ninja for small to medium sized projects.

The number two issue is harder to beat though. Looking at our configure.ac file, there where a lot of shell and compiler invocations I could remove, simply by taking the same shortcuts that Meson does, e.g. detect clang or gcc and then devise a batch of compiler flags instead of testing compiler support for each flag individually. Executing ./configure takes ca 3 seconds now, which isn’t too bad for infrequent invocations. The real culprit is autoreconf though, which takes over 12 seconds to regenerate everything after a configure.ac or related change (briefly looking into that, it seems aclocal takes longer than all of autoconf, automake, autoheader and libtoolize together).

 

PS: I’m attending 33C3 in Hamburg atm, so drop me a line (email or twitter) if you’re around and like to chat over coffee.

Flattr this!

by Tim Janik at December 27, 2016 02:59 PM