Free download:

Software Wars, the Movie

Soundtrack for the book:

If you enjoyed the free download, a donation of the cost of a newspaper would be appreciated.

The best book explaining free market economics:

The best explanation of how we can build a space elevator in 10 years:

Book explaining a political solution to our economic problems:

LibreOffice HiDPI Patches

I bought a HiDPI laptop in October 2013 to replace my 5-year old Thinkpad. Between the 5.7 million pixels, and the bright LED backlight replacing my dying and dim fluorescent bulb, it makes the daily computing experience much easier on the eyes. I’d put up with a lot for this screen. It turns out I have to compared to my old Thinkpad, as there is an incompatible and inferior keyboard layout, the Synaptics mouse drivers are flakey, it is difficult to replace the battery or hard drive, etc.

I run Arch with Gnome 3.10 in Classic Mode. Gnome is the only DE that recognizes the high-res screen out of the box and picks a good font size. It has specific bugs I described in my review of the laptop, but it generally looks fine albeit bland and crippled. Firefox needs the No-Squint plugin, but then the web looks acceptable. The next most noticeable problem for me was LibreOffice. The text and dialogs looked beautiful:

The text looked like a magazine, but the bitmaps were far too small, and there were other problems. LibreOffice offers 16×16 or 24×24 toolbar icons today, but the small ones looked like dead bugs on the screen, and even the large ones required concentration to recognize. One day, rich 48×48 toolbar bitmaps can be created, but in the meanwhile, you can double them to look reasonable and be easy to click on. Given that LibreOffice has hundreds of bitmaps, this temporary solution could be useful for a while.

In addition to the toolbars, the status bar controls, the navigator, the sidebar, and various dialog boxes had tiny bitmaps. One of the most annoying problems was that the spelling underline was so thin you didn’t notice it while casually looking at the screen. And so you had to stare carefully to see the lines, which imprinted them causing remnants when you shut your eyes. It was maddening!

And so I thought: perhaps some volunteer developer in LibreOffice could be given new hardware by The Document Foundation to work on this problem. The Gnome 3.10 HiDPI work happened because of a computer donation and perhaps it could happen here. And so I wrote an email to their discuss alias asking if there was interest but I received no public response.

Apparently, everyone is so busy delivering a new product, fostering a young community, paying down technical debt, making it run on Android, improving import and export, rewriting the Calc engine, removing Java, etc., that no one has time to make it look good on these beautiful screens. There is a lot happening without any rich benefactor anymore, and a split community.

If you think LibreOffice is amazing, just imagine what it would be if IBM gave them $10M / year, and the trademark, and didn’t seduce away naïve volunteers and donations. I believe if IBM were to ask Watson whether it should end the fork, the AI would recommend it. Watson is only being applied to customer problems instead of their own. One could spend a lot of time correcting the inaccurate FUD written on the AOO dev alias. Imagine we lived in a society that celebrated divorce instead of marriage.

I considered setting up a bounty on a website, but I decided to next see if I could find someone in the community with expertise who could be persuaded to work on this issue. It seemed that fixing the toolbars would be a great first step and I felt I’d be happy with that one improvement.

So I next emailed Michael Meeks and asked if he knew anyone who might have a few extra hours. I was put in contact with Andrzej Hunt, who eventually wrote a patch to double the toolbar bitmaps. It helped, but I felt that the spelling underline was the next highest priority issue. I decided to go through the codebase, and see if I could find the place that should be fixed. If I thought I could do it, I’d buy an external SSD to build and do some experiments.

My first stop was It is a simple and fast way to search through the codebase. This is one of best tools LibreOffice has setup since they started. Even when you have the code on your local machine, it can be better to use their smarter system. The Opengrok source is color-coded and everything is clickable to take you to the definition and references of classes and functions.

I don’t remember exactly how many searches it took, but eventually I found the code to draw “wave lines”. If I had known that term in advance it would have been faster, but I always thought of them as squiggly underlines and that term brought up nothing. Eventually I found interesting routines such as DrawText, ImplDrawTextLine, ImplDrawWaveLine, DrawWavePixel, DrawWaveLine, etc. One usually reads code for understanding, but at first, I was just trying to figure out if the code I was looking at was relevant.

I learned that LibreOffice draws wavy underlines as a font property, as part of spelling / grammar errors, and for other reasons, so I had to read through the code, understand who called who, etc. Eventually, I discovered that DrawWaveLine was the function I wanted. It was called from the end of the main routine DrawText, which called lcl_DrawLineForWrongListData, which went through the grammar and spelling error list and called DrawWaveLine for every problem area. And in that routine, I found a strong clue:

5302 if ( nStyle == WAVE_NORMAL )
5303 {
5304     nWaveHeight = 3;

I knew the spelling underline was 3 pixels tall, so at that point I knew my search had ended. I decided to spend money on an external SSD so I could download the code, build it, and make changes.

The wiki is superb and the build process is ridiculously easy. Here are the commands I ran after installing the build dependencies:

$ git clone git:// libreoffice
$ cd libreoffice
$ ./ --enable-dbgutil --without-java --without-help --without-myspell-dicts
$ make (wait two hours)
$ instdir/program/soffice --writer

With those few steps, I could then run LibreOffice and try things. After a few builds, I found what looked best. Here is the first diff I sent to the dev alias:

diff --git a/vcl/source/gdi/outdev3.cxx b/vcl/source/gdi/outdev3.cxx
index f3f5a77..6e142fd 100644
--- a/vcl/source/gdi/outdev3.cxx
+++ b/vcl/source/gdi/outdev3.cxx
@@ -5301,9 +5301,12 @@ void OutputDevice::DrawWaveLine( const Point&
rStartPos, const Point& rEndPos,
long nWaveHeight;
if ( nStyle == WAVE_NORMAL )
nWaveHeight = 3;
nWaveHeight = 5;
+? nStartY++; //Shift down additional pixel for hidpi screens
+? //TODO: Probably should be done above, before rotation happens
else if( nStyle == WAVE_SMALL )
@@ -5320,7 +5323,7 @@ void OutputDevice::DrawWaveLine( const Point& rStartPos, const Point& rEndPos, nWaveHeight = pFontEntry->maMetric.mnWUnderlineSize;

ImplDrawWaveLine( nStartX, nStartY, 0, 0,
-? nEndX-nStartX, nWaveHeight, 1,
+? nEndX-nStartX, nWaveHeight, 2,
nOrientation, GetLineColor() );

Note this code couldn’t possibly get checked into LibreOffice as-is because it changes the behavior for all screens, but it allowed me to test. Eventually what is needed is a way to know when to use the different values but there was no easy way to get that information. And so Michael Meeks introduced me to Kendy (Jan Holesovsky) who added a member to the low-level OutDev class containing the DPIScaleFactor. In principle, that information is based on the DPI of the screen / window, but sometimes the OS just returns 96 for compatibility reasons and therefore may need additional logic based on the system font size.

With the toolbar and spelling underlines looking good, it made the remaining problems more noticeable, and motivated me to keep going. I decided to next look at the status bar. The first control was zoom, the one I use the most. Eventually, I found the class: SvxZoomSliderControl. In this case, I was able to just read through the 400 lines until I saw the problem areas. For starters, it had hard-coded the bitmap size via #defines, so even if you plugged in a bigger bitmap, it would have mis-behaved. And so I first fixed the control to work based on the bitmap size, and made it draw bigger if necessary. The change was quite simple. From there, I went to the other status bar controls, the navigator, and various other places, and have so far submitted a first and second round of fixes.

The process was straightforward. First I’d find a problem visual area I wanted to work on, and then I’d trace through the code in opengrok till I found the right place, make a change, and see how it looked. I saw plenty of code I didn’t understand, but my changes were mostly simple and safe. A couple of times I had to first put in printf diagnostics to understand what was going on at runtime because there is no supported IDE with debugging, auto-complete, etc.

Sometimes hours of searches turned up nothing! I felt like Indiana Jones digging in the desert. After lots of sweating and effort, you find things, but it can take time to figure out if an artifact is valuable, how it fits with other pieces, etc.

The hardest piece of code to find was the black triangle in the toolbar font color dropdown, and many other places. I eventually resorted to commenting out drawing logic that looked like it might be handling it. At one point, random controls all over the product weren’t visible anymore, but the dropdown indicators were still there. It was the Terminator of Triangles. The LibreOffice codebase is overall very reasonable compared to Microsoft Office, but it does have a lot of widget logic because it tries to draw native visuals in a cross-platform way.

I emailed the dev alias and heard nothing. That wasn’t a surprise because the people who wrote the toolbar code are long gone. This happens more often in the proprietary world. Eventually I gave up and decided to work on the toolbar double-arrows which show up when some of the buttons don’t fit. That routine I found quickly by reading the code that laid out toolbars, figured out how it represented the situation of controls not having enough room, and then found the drawing routine which looked at that data.

And so I changed the arrow code, and started a build. While waiting, I decided have a look around, and found that triangle drawing code was the next function in the file. I couldn’t believe the odds. I had spent about 4 hours looking for it. The code change itself took 5 minutes.

Reading through the code to find the right place to make the change took an unknown amount of time. Once the proper place was found, the diff was mechanical, but usually there was something interesting about each case. Once you find the right function, the rest is usually easy, assuming what you want is possible via existing primitives. So far I’ve spent about 40 hours, working a few hours per session, and have fixed the most noticeable places in the product including the Sidebar.

Complexity and community

HiDPI is quite far from finished, in spite of the many changes I’ve made. Most of the code I’ve worked on will eventually be replaced! We shouldn’t be doubling bitmaps, we should have better ones. The toolbar dropdown triangle logic should eventually be replaced with code which calls into the toolkit / OS so it also looks more native. That is a better fix, but also bigger and riskier, and could have implications for toolbar layout. And I have no idea how to do that. I’m much better at telling LibreOffice to double integers and bitmaps.

There are more issues, but also more and more people who will want LibreOffice (and other apps) to work well on their new screen. I’ve been updating a wiki page as I go along and it also lists some of the remaining places. One isolated fix is the tab-drawing (and hit-testing) code in the ruler. The drawing logic starts on line 874.

On the Mac, someone needs to turn off the compatibility mode and see what happens. In my old life, I would have expensed a Macbook Retina to test it myself, but for now LibreOffice needs to find someone else to carry the work further.

This feature did not make it into LibreOffice 4.2.0, so it won’t get any of the automatic publicity that would come with that process, but I believe it can get into 4.2.1 and be announced then. LibreOffice make a minor release every month, and Arch automatically grabs them within a day or 2, so it means I’ve only got to wait an extra 32 days. That I could write some code in late December and get it on my machine in early March is quick turnaround compared to the proprietary world.

If I were an undergraduate in college, I’d take a bug somewhere in free software and work on it. LibreOffice is one of the most needed and relatively easy to get into. You have to look pretty hard to find ways to improve the Linux kernel, but with LibreOffice, that is not the case. A number of the things I worked on in school were writing toy programs. It made it easier to grade the assignments, but the code wasn’t realistic or useful to anyone. There also wasn’t as much great free software out there to learn from or contribute to. I joined Microsoft to learn more about programming because I knew there was a lot more to it than the toys I was making. LibreOffice is a very rich program to fully understand, but you don’t need to know very much to be productive. Most diffs are 5 to 50 lines.

One of the ongoing challenges for LibreOffice is to remove as much extra complexity as possible. It has already paid down a large amount of technical debt in the makefiles and other places, but this process will continue for a long time. I think that parts of Base should be re-written in Python, and the VCL replaced with WxWidgets or Qt, but these are very large tasks no one is working on, and therefore just pipe dreams. The good news is that they can be done incrementally. Porting the status bar to another toolkit could be done in a summer by a college student. The toolbar would be a bigger challenge that could take two summers. There is little work happening in VCL or the Writer layout engine. One of the downsides of the Symphony / Apache Sidebar is that it gave LibreOffice a new UI, but not a simpler and better way of building pretty UIs.

I received excellent “customer service” from Kendy along the way. The LibreOffice community is great and patches from first-timers get accepted all the time. So while we wait for IBM to change course, LibreOffice can keep doing the best that it can. LibreOffice has 100 dev contributors per month. Even if people show up to fix one real bug, it collectively adds up.

I plan on doing more, but first I want to help in the process of releasing the code already checked in. I wrote about some of the remaining issues in the wiki, but people might find others. For example, the first batch I submitted changes the width of the SvxPosSizeControl for normal and high-res screens. It is broken on current builds as the text doesn’t fit, and the bitmaps drew on top:

The status bar is one of the few places in LibreOffice that does layout based on pixels, and the resource XML files are not a place you can currently change at runtime.

A competitive office suite is critical to the success of a free desktop. There are billions of Office files out there and people who haven’t even heard of the best free alternative. LibreOffice is an extremely rich codebase, but it is more underfunded for its needs than the kernel, Firefox, systemd, etc. If someone can understand my diffs, they can contribute some code to LibreOffice. I note that the author of the article saying that LibreOffice is “ridiculously easy to build” never actually submitted a patch! People can contribute out of duty or selfishness like me, but it is best to find an isolated area or an issue they care about. There are plenty of Easy Hacks and bugs to read through, and various ongoing projects such as dialog format conversion.

I wrote this before LibreOffice released the patches. Part 2, of how it went during the ship process, is here.

Response from Synaptics regarding Linux drivers

Here is the mail I received this afternoon from Synaptics regarding the petition:

The open source Linux kernel currently has a PS2 touchpad driver from the third party open source community which was not developed, reviewed, or tested by Synaptics.  Based on industry and customer pull, we do not support PS2 interfaces for Linux as it is not a strategic fit for our roadmap or support model. In general, the trend in the PC industry is HID/I2C, for which we do offer driver support.  Our intent is to submit our HID/I2C driver to as time, resource allocation and customer project prioritization allow.

Best Regards,



Here is what I sent in response:

It would be great if you were to get working on submitting a driver to the kernel. People will help you find bugs in the code as part of this process, and improve it in ways you hadn’t considered. It occurred to me over Thanksgiving after your last email that writing a Linux driver but not freely releasing is like cooking that big meal and not eating it. Proprietary software was one of the big mistakes of the baby boomer generation.

I will pass this information along to the petitioners with some questions / comments. When you make something public, I hope you make a public announcement as well because it will be read more than your average one. People care about companies that share their values. Here is a video of Steam’s recent announcements regarding Linux that I thought you might appreciate:

Unfortunately, I’m not knowledgeable about the benefit of supporting the PS2 interface vs HID/I2C. However, I can say that not every trend in the industry is a good one. IPv6 is a trend that still hasn’t arrived. I think UEFI as implemented is of dubious benefit. Can you please explain in more detail why HID/I2C is better? I may do some more research on this topic and ask other people, but I can say that the existing venerable standard has gotten us a long way including multi-touch and gestures. So I wouldn’t recommend supporting only the new trends which are sometimes fads. The Linux kernel supports 60 file systems. Can you consider to support the extremely popular as well as the latest?

When you think about getting code into the kernel, I want to emphasize making good default configuration values. You didn’t mention that aspect so I raise it again in hopes of a response. I’m sure your driver will have interesting knobs people will want to tweak, but you are the best people to know what they should be by default for your devices. So can you please commit to providing a great out of the box experience by including tested and tuned configuration data along with code?

2. Getting 10,000 lines of code into the kernel could take a year. For example, it took quite some time for Google’s wakelocks code to make it upstream. In that case, there were big disagreements about the design which may or may not apply to your code, but unforeseen things like that do happen. Also, your lawyers end up taking time and I’m sure your kernel developers are already busy and possibly understaffed. As this is your first big contribution it will take even longer.

So in addition to the question of whether supporting only one standard is good enough, there is a question of timeframe. That is why I created the #2 item. I realize you didn’t write or review any of the existing code. However, because you hadn’t released any code publicly in the past other people have written it for your customers. The kernel is filled with code written by other people but this module has your name on it and is depended on by millions of people.

Here is the key point. By fixing that code, you will help many customers today. A 10 line fix to a driver would quickly be accepted and deployed to millions within a few weeks and the entire community within 6 months. It would possibly be backported to older releases as as your hardware is so popular and important.

I read a line that a good way to judge an airline is by what happens *after* they lose your luggage. If they were to tell you that yes, they’ve lost your luggage, but they are implementing a new baggage tracking system that will give it to you in a year, you might not be so happy with that answer.

I believe if you were to ask your Linux customers whether they would want you to fix 20-30 bugs in the existing already-upstreamed code or work on some big chunk of new code whose date for delivery is very uncertain, they would want you to fix the existing code first. So this strategy is faster for us and cheaper for you and could even be a useful learning process on the way to the HID/I2C utopia. Once all your customers are no longer frustrated you can run the process for your new driver at your leisure. So can you re-consider your priorities in light of the situation that currently exists?

3. Also, you didn’t mention the #3 issue about providing a UI to configure your devices. Can you please think holistically about the end-user experience and realize that as your hardware gets more sophisticated, a UI to configure the device becomes more necesssary? You could provide a good value for palm detection by default, but a UI allows me to test and change it if the default did not work for my situation. It is quite difficult to tweak a knob without a UI.

In this code as well, people will help you here, by for example suggesting gestures to be added or turned off by default. By not working on freely-available configuration code, you are missing feedback loops everyone will benefit from. It is overall easier to write UI code on Linux versus Windows. There are more Environments / toolkits, but only 3 are used by 90% of users, and the code will be debugged for you, compiled, deployed and translated for you, etc. You don’t need to start from scratch as these environments have code, but it just needs to be improved. Can you please reconsider this end-to-end aspect as well?  It is also easier to find people qualified to write UI code versus drivers and I think most people would judge this to be more important than a HID/I2C driver.

Thanks again for your mail. I hope you will consider these issues and respond soon. It is great to hear of a new path, but I can recommend you verify it is what your customers actually want as opposed to what some people say they ought to want. I will post a request for feedback on your ideas, but these are my initial thoughts.


Please post your thoughts about this, preferably on the petition page.

Arch Linux HiDPI wallpapers

Here are a couple 3200×1800 wallpapers I rendered in Blender using the new Cycles engine based on a file I found.


Change to glass material: