Braille and Unicode are more similar than I ever knew.

As you probably know, braille is a writing system that is widely used by visually impaired people. A couple of years ago, I visited China with my parents, where we went to take a look at the terracotta army. Suddenly, I noticed that they also had information in braille. Curious about how Chinese braille would feel, I walked over to the metal plate on the wall on which the information was written. None of the characters made sense to me, but what I did notice, is that they used the same 6-point braille system, that we use in Europe. To explain this, I'll first have to teach you a little bit about how braille works.

Each braille symbol consists of a matrix of 3 high and 2 wide. Each of the cells in the matrix may contain a dot. The cells in the matrix all get a number. The numbers are laid out like this:

1	4
2	5
3	6

As an example, take a look at this image, it's the letter f. This is written by typing points 1, 2 and 4.

Now, going back to the Chinese braille, a couple of weeks ago, I had the brilliant idea to just google "chinese braille", and the first link I came across was a wikipedia article. What a surprise. but in this wikipedia article, I found a great explanation of how different aspects of these chinese characters are shown in consecutive braille symbols. Standing in awe of this ingenious system, that could encode a language as complex as Chinese, into a system where there are only 2^6 possible symbols, I suddenly realized that western braille uses some of that magic too. We had to, with only 64 possible symbols. If you would encode all small and capital letters differently, that would already add up to 52 characters. Add to that our 10 digits, and we've already used up 62 characters, and we're still far from encoding everything. We haven't encoded any punctuation marks yet, the period, colon, semicolon, comma, question mark, exclamation mark and many more also want to be written down, and what about mathematical symbols for addition, division, multiplication and subtraction,...

Here are a couple of tricks that braille uses to circumvent these issues. First of all, we reuse our small leters as capitals, but than with a capital sign in front of them. So to write anyone's name, you'd first write a capital sign, indicating that the letter after this sign is a capital. This sign consists of point 4 and 6. Some abbreviaions and acronyms are written in all caps, and for that, we've got the permanent capital sign, which turns the entire next word into all caps. This significantly reduces the number of characters needed, but there's even more. We also reuse our letters as numbers. The a is the 1, the b is the 2 and so on until j, which is 0. You first write a number mark, and then, any characters that follow before a space, or another non-numerical character are now numbers. for example, let's say for a moment that the dollar sign is our number mark, then 123450 becomes $abcdej.

coming from my thoughts about how diferent languages may use braille in different ways, I suddenly thought about how Unicode does exactly the same thing. For the people who don't know what unicode is, it's a way to store text as numbers. A computer can only store numbers, so there needs to be a mapping from these numbers, to the characters made visible to me as I type out this blog post.

Many years ago, the most used standard was called ascii, which only used 1 byte to store each character, 1 octet to be completely precise, but I'm just going to call it a byte to keep things simple. A byte consists of 8 bits. A bit is a part of memory which can either be 1 or 0, so with 8 bits, you can form 2^8 symbols, But as technology grew more popular, internationalization was needed, and there was no way that all those arabic, chinese, russian, and all the other "weird" almphaets, would ever fit into 256 possible symbols. Unicode's sollution, was the same that braille used, multiple consecutive characters would form new ones. The similarity is not a great discovery, but still, it teases my mind to think about different ways to encode characters. Thinking about it even further, you may even consider our writing to be a character encoding, where each symbol we write is mapped to the idea of a certain character.

Is an API copyrightable

I'm a programming geek, and being in the kind of programmer culture that we have on the internet today, I love everything open source, or open in any other way, at least if it's not just a word in the marketing material. With the conflict between google and Oracle, around the IP theft of java API's, I started to think about the consequences it could have when API's get copyrighted.

What's an API?

You're probably using a twitter client on your mobile devices. Those twitter clients need some way to pull in the data from your twitter stream, and to post a new tweet, when you're drinking the best coffee in the world at your local starbucks, and feel the need to let the whole world know about it. To allow for this to happen, twitter built an interface, that programmers can use to hook their application into twitter. Such an interface is called an Application Programming Interface. But an API can also exist within one application. Take for example your word processor. Let's imagine that there is a component that keeps track of the current style settings such as color, font and font size. Such a component is not responsible for drawing the buttons on the screen that control these properties. So, when you use the mouse to click to select a color in the user interface, the component that reacts to that click, needs to have a way to communicate with the style component, and that's where that component's API comes in. The component exposes certain functions that can be executed in order to get or change style settings.

What we call the API is just the set of functions exposed, without considering the implementation, so we don't care how the style properties from our example are stored or retrieved.

The problem

Oracle is now claiming that google has infringed their copyright, by copying the structure of their API. I find this rather logical, many components used in many software applications have only one, or very few ways to structure them logically. Take for example our style component. it would logically have some of the following functions defined in it:

• get_font
• set_font
• get_font_size
• set_font_size
• get_color
• set_color
• ...

There is no other logical way to define this API. Now, imagine that the set_color function could take a color as a parameter, which would be a component in the program too, with functions like:

• set_rgb
• set_hsl
• set_cmyk
• ...

These functions are just creating colors based on commonly used color schemes. It would not make sense to create a new scheme, as not to infringe anyone's copyright.

The implementation

I do think that copyright should stay applicable to the implementation of a system, although the system has to be large and elaborate enough. There aren't that many ways to get the greatest common denominator of a set of numbers, so copyrighting that obviously would be a bad idea, but there can really be a lot of difference between different implementations for a spreadsheet application, so it's a good idea to copyrigt Excel or Numbers.app.