Links for September 2011

Speech synthesis/TTS links, focusing on Russian:

OpenSource:

• FestLang, Festival voices for different languages, in particular, Russian.
• VoxForge, speech corpus collection site
• AOT, automated text processing (Russian)
• RHVoice, mailing list archive (Russian)

Comparison of OpenSource PDF readers for Android

Today we're going to review few open-source PDF readers for Android platform. The table below provides links and feature-by-feature comparison, with more detailed discussion of features below the table. It should be noted that all these readers are based on the same PDF rendering library - MuPDF, so offer roughly the same rendering quality, the differences may be only due different version of the library used, or different configuration options (for example, some readers compile MuPDF without JPEG2000/JBIG support, or without standard PDF fonts).

The review summarizes with expectable conclusion - there's no perfect reader so far, but selects clear winner, which is worth to be hacked on.

Feature	DroidReader 0.5	APV aka PDFViewer 0.2.9	VuDroid 1.4	MuPDF Android Client 0.8.165
Builtin open file	-	+	+	-
On-screen zoom	-	+	+	+
Continuous pages	-	+	+	-
Page smaller than screen	- (force close on attempt)	+	-	-
In-app rotate	+	+	-	-
Go to page	+	+	+	-
Table of contents	-	-	-	-
Find text	-	+	-	-
JPEG2000/JBIG	- (doesn't recognize pdf)	+	-	+
Other formats	-	-	DJVU	-

• Builtin open file - whether you can start application and select file to view, or must have a compatible file manager and open PDF in it using "open with".
• On-screen zoom - whether you can zoom by direct manipulation on screen (like, pinch zoom, zoom in/out widgets) or need to go to menu. Needless to say, without on-screen zoom a reader is hard to use for real reading.
• Continuous pages - whether you see single page at time and need to use explicit next/prev page actions, or can just scroll a page away and see next/previous page. (Arguably, continuous page reading is easier and more productive.)
  
• Page smaller than screen - whether you can zoom out page so it is smaller than screen. For continuous pages reader, that would mean showing more than 2 pages at the same time on the screen. While this seems like neat feature, it actually just complicates real reading, when you need to take extra care to zoom back carefully after occasional zoom-in. (That's of course why most apps don't bother to implement it.)
• In-app rotate - whether app has own support for rotating pages, or relies on OS to support rotation. Got a vendor-crippled device without OS support for rotation? You're lost without in-app rotate, so that's boon.
• Go to page - basic navigation feature. That's not much convenient for real reading, but without this, you can't do any real reading at all.
• Table of contents - real navigation. For an app to be really usable, it must support this. Nope of apps in review does though.
• Find text - other very useful navigational feature. You hardly can read technical/reference docs without this.
• JPEG2000/JBIG images support - Apps which doesn't support these images format don't really support PDF, just some crippled subset of it.
• Other formats support: You found your perfect PDF reader? Congrats, now repeat that for all other ebook formats you use. Don't wanna waste time like that? Choose readers which support all reasonably similar formats. For already typeset ebook, there're actually two formats: PDF & DJVU, so good reader should support both. For TXT, HTML, CHM you indeed would rather look for different reader with different featureset.
  

And the winner is...

Based on the table above, the clear winner is VuDroid: it supports both typeset-ebook formats, PDF & DJVU, and has reasonable usability features (like has limit for page zoom out, as well as adjusts zoom on rotation). One serious, but easy to fix thing lack of JPEG2000/JBIG support (fixable by extending MuPDF config). Other thing it lacks comparing to APV is text find. Well, all readers in review lack ToC support, which a perfect reader must have. Back to VuDroid, it's UI is rather bare - there's no even About dialog, so you can't know that you're running VuDroid at all, or its version!

OpenSource Package Manager for Android

Android is surely breaks records in many areas, like openness of platform, etc. But not only that, Android Market delivers spyware and junkware to your devices with unsustainable ease - I don't remember such wealth at Palm and PocketPC times. Maybe paid apps save the situation, but wise platform owners don't offer them in various places around the world. All in all, while it's generally great fun to dig for gems in such places, there got to be something else.

So, next move of thought is towards open-source package manager. But only to find out that:

• Trackdroid is fool's gold, with source never released (or taken down after release)
• Undroid is stopped because "ultimately it was made irrelevant by Google market place."
• apkget was started just this year, but already undergone repo created - something committed - repo removed cycle.

Googling for "android opensource package manager" doesn't give much - you know, it's all "Android OpenSource Project" and there's a PackageManager class. And - suddenly, thanks to Wikipedia, there's a winner:

f-droid.org

They offer maintained client, they offer repository of packages. Hurrah!

UPDATE: F-Droid is a fork of Aptoide, which also specialized in Android repository provision, but not specializes in FOSS. Consequently, Aptoide client lacks detailed information about licencing, etc. and the repository provided by Aptoide project contains more than just FOSS project. At the same time, Aptoide seems to be leaning towards meta-level (i.e. provide package provision solution for others to reuse), and thus has more documentation and momentum.

F-Droid on the other hand also includes build system for its packages, albeit simple/limited one (e.g., entire recipe is written in one line).

All in all, it's great that there're such solutions for Android, and pity that that they are relatively hard to find, they should be published more, that will contribute to overall software quality on Android platform.

How it all started: F-Droid Repository Vapourware

Xara Open Source - Sleeping Beauty

 You just can't imagine what fairytale may happen in the industry, while you just do common things like hacking, building, and debugging... Anyway, as any fairytale, it started long time ago. I first saw a demo of Xara Studio when CPUs were 100MHz and Windows just turned 95. Don't hold your breath - software was better those days, but not really magic, so you've got to recognize and remember when you see a miracle. Xara, a vector graphics editor, was exactly such miracle. CorelDRAW the Third was king of the hill those times, which ruled without inspiration, though did its job. Well, Xara brought real fresh spirit into the area of graphics design - not only it brought anti-aliasing support, it was also real-time. And there was streamlined and logical UI and set of advanced graphics tools, like blending shapes - also realtime.

So, Xara showed that you can do great software if you like, to stand out of the crowd and make a difference. I remember it since then. And today I found out that Xara was open-sourced! "They must be crazy to have done that" - was first thought which occured to me when I saw the site. But this is fairytale, remember, and evil sourcerers must have kept me in parallel world - it turned that happened long ago, the first wave of commercial companies opening up their projects, and it had been dead few years by now, and epithaph written. So, they weren't mad after all, they didn't open up their low-level graphics lib which on 100MHz behaved better than Adobe Flash does now on 4-core 2GHz CPU. And community guys were too lazy to port it to multitude of other graphics engines, so project's dead.

But what amazes me is that open-source site is up and nicely running, docs are there, etc. just timestamps are old. And mailing lists are quiet. And the temple is full of ancient scrolls suggesting checking if SVN works by telneting to a port. Hush, this is fairytale. It's all working, it's not dead, it's sleeping. Sleeping Beauty.

So, apparently, as the site is running smooth, the company apparently does well. I checked Wikipedia - they do, and keep amaze their users (content-based bitmap resizing is what I saw with a corner of my eye). I don't know how to treat this case. I can't say "better they wouldn't have opened it up". I can't say "they must have opened up their gfx lib". It's not the case that everything should be open, and such applied software as Xara clearly should bring its owners a direct value. So, I better be amazed by Xara and its creators for the second time, it's nice to know they have tried. Not only they tried - they did it. I installed  it on Ubuntu and it looks and works great, even though it's not maintained much any longer (well, there's Ununtu developers' merit to that too).

What amazed me is that, even though I tried, I found no attempts to resurrect it. Well, I found this, but it didn't get much beyond changing a preference dir name. It also used some ancient systems like SVN and imported some history-less archives. Well-well. I'm finishing git svn clone now, to push to gitorious, for git be more comfortable bed for the sleep...

https://gitorious.org/xaralx


UPDATE 2012-10: There's revived project to port Xara to Cairo: https://github.com/eradman/xara-cairo

Weekend project: porting a game to QVGA

Following a mediaplayer, games would be next thing people ask for Angstrom. So, I decided to look what would be good candidates to add to feed. There're bunch of different games' recipes in OE, but I was thinking about some catchy, dynamic arcade. Of course, SuperTux came to mind! ;-)

OE already has recipe for SuperTux, and quick try in QEMU showed it works. In VGA mode. Attempt to run with QVGA screen resulted only in error that suitable video mode cannot be found. So, I decided to see if quick hack could solve this, and then document what it would take to do so.

Quick look at the source code showed that it is one of the critical cases of software engineering - 640x480 resolution is deadly hardcoded, with numeric coordinates spread around the code. Fortunately, short after I spent 10 mins figuring where to stuff divisions by 2, I googled for "supertux qvga". Hits followed! SuperTux was ported to GP2X and even to WinCE. I took GP2X version to look at.

GP2X port is nice produce of folks who have motivation to do something, but don't know what the diff is ;-). It was also done against SuperTux 0.1.3, while OE had 0.1.2. On the way, I bumped OE's version to 0.1.3 too, while finding that fixed-point patch for 0.1.2 no longer applies to 0.1.3 (will need to rediff). Finally, making diff out of GP2X version and cutting off changes related to autoconf-generated files, I got ~70K patch implementing --enable-320x240 and --enable-gp2x options (adding those was neat, unlike not producing a diff). Applying that patch on top of pristine 0.1.3 (with bitbake recipe of course!) and cleaning off some sloppy gp2x changes which were compiled in even though --enable-gp2x was not given, I finally got the package built. Quickly checking that it doesn't work in 240x320 mode, I had it run with xrandr applied, just to see garbaged fonts and graphics. Of course! Of course gp2x patch doesn't resize the original graphics on the fly, but expects it to be downscaled already, even though such gfx is not included in source archive. I pulled it from binary package though, and few minutes later saw the expected fun:


So, thank you scachi (Ingo Arndt) for doing all the fun work, and leaving dirty work of cleaning it all up to me! ;-D

On that route I proceeded, and next task was figuring out what to do with graphics. Having a binary drop of graphics was for sure no more acceptable than a complete source archive instead of diff. We talk port here, not something. I still don't target that at upstream, but not because it's not worth being there, but because it would be hard to explain what's it all about to people who write draw(537, 39) ;-(. Nonetheless, QVGA graphics must be produced from upstream version during build time. Just few days before I heard pH5 talking about imagemagick-native, so having checked it was not in OE (while target version was), I caught him on IRC to find out that it belongs to "would be nice to have" category. 15mins later it was there, fortunately "inherit native" was all needed for it.

My initial attempts at resizing original SuperTux graphics at 50% proved to give rather bad results, having size as big as original, or even bigger, and for sure much bigger than gp2x versions. But man'ing thru and recalling my old ImageMagick experience quickly gave its fruit by applying adequate color quantization after resize (I used --colors 64). Adding pngcrush-native and running magick's images thru it was final touch - in the end, I got image set ~30% smaller than gp2x's, while still looking better!

What's next? Too big a package. It would be nice to let people install this thing to flash, plus I target it for inclusion in LiveRamdisks, so 6.5Mb compressed package was not very bright. Glancing over data files shipped with SuperTux, it turned that music/ is nice candidate for slimming. First of all, there're few duplicate tunes, just one copy with "fast" suffix. Size was same, and diffing them, there were handful byte changed. Looking thru code, "fast" version is played when level's time limit is running out. I llluv that feature! But not at the expense of my flash ;-I. "fast" version went to /dev/null for the QVGA, and now, small-size version. Secondly, there was a credit.ogg file, which gp2x port replaced with some .xm. Trying .ogg still, I found that SDL can't scroll screen and play 160kbit ogg at the same time, on PXA 400MHz. So, bye, .ogg, good riddance! And thanks gp2x again for offering a replacement.

Now I finally decided to run game on full-fledged hardware - h4000, as earlier I ran it in QEMU and on h3900, which lacks audio. It immediately crashed on startup, complaining about not being bale to load a .mod music. A check of source, then libsdl-mixer recipe and - the latter has mikmod support disabled. Poor. With it on, I finally have a nice, commercial-grade arcade running on a Linux PDA! I even was able to quickly finish couple of levels, even though controlling PDA in a landscape position is not ideal.

Final touch I made was extracting bonus levels to separate packages. Level description are text files, taking more than a megabyte in raw size, but packages turned out to be ~50K. Well, let's save space for ext2 people nonetheless, and most importantly, have a complete experience of what it takes to produce a nice PDA port of a game.

So, that's how it was. I took time to write this long, if not detailed, description, in the hope that it will both motivate people to port games to OE/Angstrom, and will give hints how to do that. So, let's hope that people will care for their favorite OpenSource games, or choose to have such a weekend fun ;-). Otherwise, thinking about it, games are likely the best candidates for bounty-sponsored porting - after all, due to the manner many games are written, it's not too easy to port them to a lower resolution/smaller size/more CPU efficiency. So, if people want more fun, they should take the fun of doing a port (it's much more fun than playing a game itself, trust me ;-D ), or motivate other people who want to do that ;-).


Oh, and back to tux the super: the supertux-qvga recipe should land soon in OE. I hope to dump packages to unstable feed too. Then, there're following TODOs before it's perfect:

1. Forward-port fixed-point patch to 0.1.3 (I get ~25fps with sound, and that's not too much, and there's jerky scrolling sometimes).
2. There're few relatively big .mod's which are used relatively rarely. It would be nice to leave just a couple of smaller ones in a core package, to really slim it down, and put the rest in extra-music package.
3. Fully clean up gp2x patch, it's still too dirty.