Short answer

No, but you can port it to there.

Longer answer

Officially, the Ruby plugin is only available for the (for-sale) IntelliJ IDEA Ultimate Edition. Proofs:

 So the official alternatives are to buy IntelliJ IDEA Ultimate Edition and install the free Ruby plugin, or to buy RubyMine. The functionality is roughly the same; for the remaining differences and help for the decision, JetBrains has an article up.

However, the concerned Ruby plugin is free software, licenced with an Apache 2.0 licence. Which means that it's legally possible to make it work on IntelliJ IDEA Community Edition. Maybe with a little loss of functioality as some required API might be missing, but not much: custom language support plugins are completely possible for Community Edition. It's admittedly not the nicest thing to do, as the JetBrains folks have really good quality software and reasonabe prices. It would probably not hurt too much as many professional developers would still rather buy RubyMine from them to have a simpler tool that is specialized on Ruby only. Anyway, it's possible and legal, but I did not find any project on the web doing this. Maybe somebody has the missing link for me (or feels inspired to start this thing …).

It is quite straightforward with code like this:

<div style="background:#fff; padding:3px">
  <iframe style="border:1px solid gray; height:700px; width:617px"
    <strong>Hide the chat column to get proper space for editing.<br/>
    Or <a href="">edit 
    this pad fullscreen on</a>.</strong>
  If trolls delete your content, use the "Time Slider" button 
  and copy it back to the current version. 
  If the pad makes trouble, contact

This is the best solution I found to embed an Etherpad Lite provided by an external service. There's a newer version that allows more pretty embedding, but so far you can only use it when installing on an own server as the services providing it have a bug that leads to data loss when using in Firefox. Here is the background info for that:

  • There are two versions of Etherpad Lite: those with chat in a column on the right (like, and those with chat in a small box at the bottom, and many other design changes (example from The first kind of sites run Etherpad Lite too, not the original Etherpad it seems [source]. But probably an older version. Because the newer pads (with chat in a bottom box) in my tests all did not save anything when embedding in Firefox, probably because of this issue. It is said to be solved now, but until the public services update to that newest version you have to either set up your own Etherpad Lite server or embed the old version from or the like.
  • These "old version pads" do need a ?fullScreen=1 GET parameter to make them adapt as good as possible to a limited iframe size, avoiding scrollbars that result from an otherwise fixed pad width. When embedding the new version pads, you don't need the fullscreen parameter because they use fluid layout (indeed, that parameter is gone there).
  • Even in fullscreen mode, the "old version pads" have not much space for editing because of the right chat column. In this version, the alwaysShowChat GET parameter does not work. So I chose to put a hint at the bottom that the chat column can at least be minimized.
  • Also, all the other embed GET parameters do not work in these "old version pads". So we have not many ways to make the embedding prettier.

Another important requirement was to use low-cost resources for that.

Note: So far, this is my preparation for a solution that was not needed for the conference because we found a venue with wifi. So, expect this to not work out as intended the first time 😉 but it's a good source of inspiration to develop your own solution.

The "Wi-Fi on conferences" problem

Good presentations of the problem, and of solution alternatives:

Solution idea for a 100 people conference

The idea follows the same basic principles as all wifi setups for conference, with some simplifications because of the limited size:

  • DSL or cable line. A 15 MBit line should be sufficient for everybody's Internet use without restrictions, or anything from 6 MBit when having some rules and restrictions but being able to work without issues. So no special terrestrial radio broadband is needed, as done for large conference setups.
  • Router for Internet access. This is regularly already in place if the location has DSL or cable Internet. But to see if it is applicable: check its routing speed, NAT table capacity [source], and the DHCP server address capacity (if you don't use a normal computer as DHCP server). Example: I used a FritzBox 7050 as central router for a music festival office during 2 years, without capacity issues, with 40 concurrent users and ca. 300 devices in total. You can replace this router with one of those you use to provide wifi, if you need OpenWrt to provide more functionality in that router. Anyway, this central router should not provide any wifi if the signal can interfere with that in the conference room.
  • Five 100 Mbit switches. Provide five 16 port Ethernet LAN switches, to get at least the heavy users connected by wired LAN (expected here: 30 devices). By locating these next to each of the four wifi routers that provide the access points, it is simple to get electricity and a LAN cable to them – as the wifi routers need it too!
  • Five dual-band wifi routers. Provide enough of them for the others (expected here: 75 devices). Which means here, 5 dual-band routers. Normally one provides one access point per ca. 10 users for decent bandwidth in the 2.4 GHz band, or ca. 20-25 in the 5 GHz band (see below), so as the heavy users get cable connected and the wifi routers are dual-band ones here, we might easily get away with 15-20 per router. But that is untested yet – it also depends on how well the router itself can handle this. Here, I propose to use routers running OpenWrt, because I like free software and its flexibility, added options and long-term support. But it's not necessary in this scenario as the stock firmware will also provide all needed options. We will leave it simply to the users resp. their devices to connect to the 5 GHz band for a better wifi connection – only if the 2.4 GHz band is too crowded and the other too empty, we will have to tell users what to do to improve their connection. And if only by naming the 5 GHz network with an SSID that has a "-FAST" suffix.
  • Configure as access points. Make all devices Wireless Access Points, so all are using the DHCP server in the main DSL router. So, not configuring them as routers, and not using their own subnets, but all being in a same network (for example).
  • Overlap-free channels. There are four in the 2.4 GHz band which you will use here: 1, 5, 9, 13 [see Wikipedia on 802.11 channels]. The 5 GHz band has many more. So probably place one router in every quarter of the audience, with both bands enabled, and an additional central one with just the 5 GHz band enabled. The interference of overlapping, plus the reduced power settings to compensate, will probably do more harm than waiving the 2.4 GHz band for that one router. This way, the fifth router is also a kind of backup device to replace one of the four others, if it breaks.
  • Rules. If you have a limited outbound Internet connection (< ~15 Mbps), provide some or all of the following rules:
    • No file sharing. This should be obvious on conferences regardless of the bandwidth. But you should know how to block bittorrent etc. traffic.
    • No video and audio streaming during conference sessions. Excludes the most bandwidth-hungry applications without taking much from users.
    • Heavy users, use cable. This includes users with low-latency requirements (Etherpad Lite, Google Docs) and the exceptional official livestream webcam of the conference. Compare also my post on Etherpad Lite bandwidth needs.
    • Use native Twitter clients. I did not test this yet, but it seems intuitively clear that desktop Twitter clients and mobile apps for that use less bandwidth than the official web-based version.
  • Proxy. If you have limited outbound Internet connection, but traffic at the conference revolves around a special site (like your organization's own site), it can make sense to add a transparent proxy.
  • Manage router connections by power level. The best trick so far to prevent a router's wifi cell to have bad performance because of too many users connecting there is this: monitor connection numbers during the conference sessions, and lower power levels of routers with too many connections, forcing some user devices to roam away to another router. See below for details.
  • Move routers around for sessions in smaller rooms. The five routers are sufficient for 100 people, but if your conference has not just the plenum sessions but sessions in smaller rooms as well, you either have to supply additional routers there or (cheaper, so better here) to just unplug one of the routers from the main room, put it in the small room, and later back. The main room obviously does not need it while some of its people are in a smaller room!

Technical background and alternatives

This sections explains the rationale behind the above solution, and also lists alternative ideas and why I consider them less adequate in this scenario.

What bandwidth is needed? Data from similar events include:

  • RIPE 59 tech conference, 300 attendees: "We peak at around 250 wireless clients online, and total 44 Mbit/s traffic." [source]

So in this case, for 100 attendees one would expect about 85 client devices and 14 Mbit/s peak traffic.

Getting users to the 5.2 GHz band as much as possible. This is way better, see these explanations. The 5.2 GHz equipment seems quite frequently used already. A report from PyCon: "The first year I ran the network (2006?), we had around 25% usage. In 2008 we had over 60% in 5.2GHz." [source]. So hopefully, just offering the 802.11a/n connection should result in enough users getting on that to free the 802.11b/g/n connections for those who have no alternative. If not, one might have to tell users how to explicitly select the 802.11a/n connection if they can.

Not supporting 802.11b. Configure the routers to not support 802.11b connections, because routers usually have way lower throughput in mixed mode that includes 802.11b, including the model recommended below [source]. The probably more important reason is that the 802.11b channels are 22 MHz wide. Which would leave us with 3 non-overlapping channels only. 802.11g connections allow 4 of these (1, 5, 9, 13) because their OFDM modulated channels are only 20 MHz wide, even when using 802.11g at 11 Mbps and lower transmission rates. For that, compare Wikipedia on 802.11 channels and its list of WLAN channels.

There should not be many 802.11b-only devices. Even phones from 2008 have 802.11b/g (like the HTC Magic). If too many people complain, allow 802.11b connections: there should not be so many that interference hinders throughput much.

Getting the heavy users connected by cable. This seems the best tech tip for conference setups [example]. For a smaller, more homegrown conference, it is sufficient to say that heavy users should connect by cable, it's not necessary to offer a cable connection at every seat, just at some. Like 20-30 for a 100 people tech conference audience?

Consumer enterprise access points? Also, you can of course buy Cisco Aironet 1200 hardware used. You get a AIR-AP1231G-E-K9 for 120 EUR at the moment, capable of just 802.11b/g and nearing its end of service life. No third-party firmware like OpenWrt is available for it either. In total, the vendor lock-in makes such enterprise hardware way less attractive than they seem at first.

Using WDS. OpenWrt has support for WDS. It is meant to enable seamless handover between access points, which probably means, so that the user does not notice a loss of connection. However, how big of a problem is it for users when not using WDS? How often do handovers happen anyway in a rather static conference setting (most people sitting and listening)?

Why to use the same SSID everywhere. This is because of the way roaming is implemented in wifi: "the client radio periodically scans all access points and reassociates with the access point having the strongest signal (if the current access point signal amplitude is below a specific threshold)." [source] But clients can only roam between access points with the same SSID.

So that is how setting things to the same ESSID makes roaming possible.

How to keep wireless access points from overload. Name all of them with the same SSID. Then, "during the meeting, […] monitor the distribution of clients amongst APs, and adjust power levels where needed to avoid overloading a single AP" [source]. That is a pretty nice trick: you don't kick individual clients off the network just to see them reconnect a few moments later. Instead, the clients at the edge will lose the connection when you lower the APs radio power, and automatically connect to another access point with the same SSID.

Using a wireless management system. It is mentioned that, for making a really professional large wifi deployment, one would employ a "wireless management system" [source]. The main features is controlling the radio power levels and channels to: detect and fix interference, and to detect and fix holes and overlaps in the coverage [source].

The non-proprietary wireless management solution is CAPWAP. (There are other proprietary technologies, partially at end-of-life: WLSELWAPP) Its open source implementation is called OpenCapwap (website, project site). It is possible (and seemingly the cleanest) to run OpenCapwap for configuring a set of same of different routers that run OpenWrt.

For the current requirements (100 users), CAPWAP was not employed: with just a handful of wireless access points, a simple static configuration is sufficient: no interference at all because of proper channel selection, and being able to use highest power levels then without causing interference. Here,  CAPWAP would be overkill, just increasing the complexity. But for high number of access points, CAPWAP seems great. But so far (2012-11), it is no solution to run out of the box: there seems to be no OpenCapwap package for OpenWrt, OpenCapwap itself is considered alpha, and some coding seems needed to send proper configuration commands to ones selected routers.

Automating configuration tasks. There are two semi-finished but maybe usable ways how to centrally control the configurations of a multitude of access points (as discussed here): cfengine and AirKey. But personally, once reaching a number of access points too much for manual configuration, I would move to fully automatic configuration – see on CAPWAP above.

Selecting a proper 802.11n router. The 802.11n wifi standard applied both to the 2.4 GHz and 5 GHz band [source]. So if a router supports 802.11n, it does not imply it is capable to use the 5 GHz band, which is better for conference settings. Make explicitly sure it is a dual-band router. It is if it also supports 802.11a, which is only on the 5 GHz band. But even then, there can be cases where the router supports 802.11n only on the 5 GHz band [example], so exclude that if you want the fast 802.11n everywhere.

Hardware selection

Hardware selection criteria

  • No integrated DSL modem needed. All the devices listed below have no integrated DSL modem, so the WAN port is essentially a network port (on a different VLAN for protection through routing) that is to be connected to a DSL modem. Connecting to another router with integrated DSL modem will also work. It is unclear to me so far if the DSL modem has to be one that allows to enter the access data into it, or if the OpenWRT router has that feature to control the modem (probably yes).
  • OpenWrt support wanted. There are other third-party firmwares as well, but OpenWrt seems to be the most advanced / stable / biggest one based on the number of its derivatives [source].

Hardware selection list

By adequacy. After looking through more or less all brandname devices supported by OpenWrt as of 2012-11.

D-Link DIR-825. My favorite so far! Its B1 and B2 hardware revisions are supported by OpenWrt [source] and since the A1 revision is not sold new any more [source, in the customer review by Steve B] it should be simple to get the right version by buying new. However there is now also a C1 revision, and it is unclear to me so far if OpenWrt supports it since it only supplies the openwrt-ar71xx-generic-dir-825-b1-* firmware files. However, the DD-WRT project explicitly supports the C1 version now [source, firmwares here] so there is an alternative what could be installed on it.

Installing OpenWrt does not need a serial console, which is nice [source]. The device is available also new in larger quantities and short time from Amazon. Difference to the Netgear WNDR3700 / WNDR3800 might be subtle / subjective. I chose this one because of the better customer reviews on Amazon. And because some people with wifi-for-big-conferences experience consider some other inexpensive D-Link devices solid and adequate for that setting [source]. Which does not say much about this device of course. A very detailed test and review is found at and also at

Netgear WNDR3800. A detailed review is available here. Use with OpenWrt and specs are pretty much the same as with the Netgear 3700, see below.

Netgear WNDR3700 v1 / v2. These are true dual-band routers, providing 802.11a/n on 5 GHz and and 802.11b/g/n on 2.4 GHz. Well supported by OpenWRT. Available in sufficient quantities on eBay in Europe (about 75 EUR per piece on eBay as buy-now, from 77 EUR in normal shops). But one has to make sure to not get a WNDR3700 V3 model, as this is not supported at all by OpenWRT. Installation is possible without a serial console [source]. A detailed review is available here, including customer opinions which are quite mixed. The WNDR3700 v2 version has actually worse reach in the 5 GHz band due to antenna changes [source], but you might decide that this does not matter in a one-continuous-room conference setup.

Linksys E3200. Also a true 2.4 GHz and 5 GHz dual-band router. But itneeds the OpenWrt trunk (unreleased) version, and for installation also the serial console [source]. Also, much fewer devices are available on eBay (mostly oly auctions, then 40-50 EUR). Best source is 50 EUR new from here.

Linksys WAP4410N. Nice very modern one, OpenWRT supported, but quite expensive (150 EUR).

Linksys WRT160NL. More modern than the WRT54GL series routers, supporting 802.11n. However only on the 2.4GHz band, which makes them pretty useless for our purposes here of avoiding the 2.4 GHz band as much as possible. Available in sufficient numbers on European used item market, 50-75 EUR as buy-now on eBay.

Linksys WRT54GL. Well supported by OpenWrt, as they are the continuation of the original series that inspired OpwnWrt. Available in greater numbers for "buy now" on eBay. Available in sufficient numbers on European used item market. But only supporting up to 802.11g, and not the 5 GHz band at all (so pretty useless for our purposes).

This was a difficult question to answer, because the Internet was quiet about this. There is a discussion about load issues with EtherPad Lite, essentially saying that the server-side overhead of EtherPad Lite is so low that nobody yet had scaling issues on the server side, even with 100+ person pads. Also it says, there is no user limit encoded into EtherPad Lite. The most server-side CPU load is caused by the timeslider feature, which can be disabled then. (There are some reports from in that thread about experiencing a 60 user limit, but that seems due to their webserver setup or issues which have now been corrected.) It can however be important behind what web server one runs EtherPad Lite. An asynchronous one like nginx is recommended (again in the above thread).

But I only found one discussion about EtherPad Lite bandwidth usage, which boils down to: it’s not an isse server side, because other resources would saturate first. (Background: The text synchronization technique used in EtherPad Lite is called operational transformation.)

So I had to do some own tests to get some numbers. I used nethogs, available in Ubuntu’s community managed repositories, to show the bandwidth usage of a browser instance that I used just for typing with EtherPad Lite. The pad I tested was a new, public one from


  • one user, typing at full speed:
    • sending 3 – 3.5 kB/s
    • receiving 1.3 – 1.5 kB/s
  • two users, both doing nothing:
    • sending 0.0 – 0.12 kB/s
    • receiving 0.0 – 0.1 kB/s
  • two users, one typing at full speed, one only receiving, measured for the receiving one:
    • sending 1.9 kB/s
    • receiving 1.8 kB/s
  • two users, both typing at full speed:
    • sending 4.2 – 4.5 kB/s
    • receiving 2.9 kB/s

The given numbers are maximums, reached at a certain speed of typing, and not exceeded even when typing super fast. This is understandable by the way EtherPad Lite generates the change messages that cause the revisions: at most 2 per second for every user, so that one message will contain 7 characters or so when typing full speed. At least that is what I understood from the pad’s timeslider view, where there are max. 2 revisions per second and per user. However, one revision only contains changes from the same user – so the Etherpad server does not accumulate these server-side.

TODO: I don’t know about bandwidth requirements for more users. As a rough guess, I calculated with:

  • sending for each user: 3.5 kB/s for own typing at full speed, plus 1 kB/s of sending receipt confirmations for every stream of change messages from an additional user, so 3.5 kB/s + 1 kB/s * n, where n is the number of concurrent users. Multiply the result by the number of users to get the bandwidth requirement for all.
  • receiving for each user: 1.4 kB/s for each other user typing at full speed, so 1.4 kB/s * n, where n is the number of concurrent users. Multiply the result by the number of users to get the bandwidth requirement for all.
  • factor for real-life usage: nobody is typing at full speed in real life all the time, so on average one could assume a factor of 0.25 to lower the above bandwidth requirements. This is just a guess though.

No guarantees for that, it’s really just a rough guess from the above measurements. If you have better estimates, please tell.

In case you really run into bandwidth limits, like when working with lots of users at a conference with moderate bandwidth Internet, you could:

  • Maybe reduce the bandwidth usage by decreasing the rate at which user EtherPads will fire the change messages.
  • Install the EtherPad instance locally at your premises, as the LAN bandwidth (even if just 54 MBit/s WLAN) will very probably not limit the pads. You can even allow outsiders to contribute by also making the pad accessible via DDNS.

Update: Responsive width is now a feature in the new versions of CIMY Header Image Rotator. You do no longer need the hack described in this post. Instead see the comment by @rtpHarry on this page for how to set things up!

On this very website, I have rotating imagery in each pages header, and I use the quite sophisticated WordPress plugin Cimy Header Image Rotator 6.1.0 for that. The only thing I missed was having the header image width decrease with the rest of the page's width, when scaling down the window or when seeing the website on low resolution screens. By default, it wants a fixed width and height (in pixels) for the header image container div to be set in the plugin config form – and that will of course mean that the div with image in it will always have that size, if necessary even with a scrollbar, when scaling down the window or watching the page at 1024×768 px resolution.

Here is how I changed that for this website. I use no image fading effects, just wanting a random image for every page that gets loaded. So I do not know if this hack still works if you employ the plugin's effects and other options.

  1. In the WordPress admin area, go to where you inserted the Cimy Header Image Rotator code into your template – mostly it is about editing your template's header.php via "Appearance -> Editor". There, locate this CSS information:
    #cimy_div_id_0 { width: 1170px; }
    and instead make it to be:
    #cimy_div_id_0 { max-width: 100%; }
    The Cimy plugin already sets "overflow:hidden" for this header image container div, but that only has an effect for images larger than its width. We want this width now to depend on the available space, not to be constant.
  2. In the same place as in the last step, I also want to remove excess space over and below the header images by deleting this CSS information, but that's merely a cosmetic issue:
    #cimy_div_id_0 { margin: 1em auto; }
  3. In the WordPress admin area, go to "Plugins -> Editor" and edit the file cimy-header-image-rotator/js/jquery.cross-slide.js. You have to do these changes:
    1. Disable the following lines, as with them the plugin's JavaScript would not create the list of images any more because we eliminated the width: setting from the image container element:
      if (! self.width() || ! self.height())
        abort('container element does not have its own width and height');
    2. Find the section // find images to animate and set initial css attributes and change it so that the CSS contains position: 'relative' instead of absolute and also add 'max-width': 'none'. Note the use of quotation marks in CSS attributes with a dash! So, it will look like this:
      var imgs = self.find('img').css({
        position: 'relative',
        'max-width': 'none';
        visibility: 'hidden',
        top: 0,
        left: 0,
        'z-index': 1,
        border: 0
    3. Apply these changes also to jquery.cross-slide.min.js because only this minified version is in use. You cannot simply delete the minified version because it is referred to in the head section. Creating a new minified version with something like should be possible, but at least this particular tool introduced errors for me that prohibited the header image rotation from working. So the simplest working method is to copy the non-minified version over. Via SSH:
      cd wp-content/plugins/cimy-header-image-rotator/js;
      cp jquery.cross-slide.js jquery.cross-slide.min.js;
  4. Reload your page and try resizing its width. It should work now: when the header section width becomes narrower than the image width, portions of the image will be clipped from the right. The image will no longer stick out of the header section to the right. Job done 🙂

This hack solution was tested and found working in Firefox 16.0 and Chromium 20.0.

This howto follows along these original instructions (German). But it adds some fixes to get around incompatibilities introduced by changes in Ubuntu 12.04 and 12.10. Also, to get a cleaner installation it uses the Debian package builder functions of both the alc900-cups and the pipsplus-rpms packages.

These instructions were tested on Ubuntu 12.04 amd64, Ubuntu 12.10 i386, and Ubuntu 14.04 i386. Taken all together, here they are:

  1. Download and install libstdc++2.10-glibc2.2_2.95.4-24_i386.deb from here or here or here. Note how I used the i386 version because the Pipsplus software that comes with the driver only has i386 sources, but works also on 64 bit systems if they have the 32 bit compatibility libraries installed [source]. I don't know if using the 32 bit version is actually needed, or if you can also use the 64 bit version. To install, call: sudo dpkg -i libstdc++2.10-glibc2.2_2.95.4-24_i386.deb.
  2. Install gtk 1.2. This is old unmaintained software last available in Ubuntu Hardy, but is required by the alc-900 package building script later. The adamkoczur/gtk1.2 PPA mentioned in the original instructions is no longer available, so we install the packages (i386 versions) directly:
    1. Download libglib1.2ldbl (linked from here) and install it:
      sudo dpkg -i libglib1.2ldbl_1.2.10-19build1_i386.deb
    2. Download libgtk1.2-common (linked from here) and install it:
      sudo dpkg -i libgtk1.2-common_1.2.10-18.1build2_all.deb
    3. Download libgtk1.2 (linked from here) and install it:
      sudo dpkg -i libgtk1.2_1.2.10-18.1build2_i386.deb
  3. Install some packages with your package manager. They are needed for the package building scripts of the als900-cups and pipsplus softwares lateron (they will fail if these packages are missing). For Ubuntu 12.04 and 12.10:
    sudo apt-get install rpm lintian psutils a2ps zenity fakeroot gcc
    For Ubuntu 14.04: It comes with the alternative foomatic-db-compressed-ppds, which is however not correctly detected by the alc900 install script. So we replaced it above with the uncompressed variant, as follows:
    sudo apt-get install rpm lintian psutils a2ps zenity fakeroot gcc foomatic-db foomatic-filters
  4. Build the alc900 .deb packages.
    1. Unpack the alc900-cups-1.0.i386.tar.gz file:
      tar -xzf alc900-cups-1.0.i386.tar.gz
    2. Enter the new direcory and call:
      sudo ./ -b
    3. If it does not find your installed libstdc++2.10, add the -e option to exclude that dependency (I had to do so on Ubuntu 12.04, but not on 12.10). See ./ --help. We installed the library above, so it is there and will be found at runtime anyway.
    4. This step failed on Ubuntu 14.04 so far since the compilation could not find any Linux kernel headers even thoughthey were installed. I was able to install the packaged I had built on Ubuntu 12.10 though (needed removing package foomatic-filters again, and installing cups and cups-filters again though).
  5. Build the pipsplus .deb packages:
    1. Unpack the pipsplus-1.1-b-rpms.tar.gz file, enter the new directory.
    2. Edit the file and edit it. It seems that the dpkg -S output format changed since the script was made and includes now the package architecture in addition to the package name. To be able to process that input, we need to make a change (else the script will fails if a library is only provided by packages that output their architecture like that). Locate the line
      dpkg -S "*/${requireditem}" 2>/dev/null | grep ":[\t ].*/${requireditem}$" | grep -v ".* .*:" | sed "s/:/ /g" > "${tmplog}"
      and make it instead
      dpkg -S "*/${requireditem}" 2>/dev/null | grep ":[\t ].*/${requireditem}$" | grep -v ".* .*:" | sed "s/:i386//" | sed "s/:/ /g" > "${tmplog}"
    3. Call: ./
    4. As above, if it does not find your installed libstdc++2.10, add the -e option.
  6. The and scripts generated Debian packages (residing in /tmp/) which you can now install. The names may contain i386 instead if you're on that infrastructure. Install in this order to avoid dependency problems:
    1. sudo dpkg -i pipsplus_1.1-1_amd64.deb
    2. sudo dpkg -i pipsplus-epson-laser_1.1-1_amd64.deb
    3. sudo dpkg -i pipsplus-epson-alc900_1.1-1_amd64.deb
    4. sudo dpkg -i pipsplus-gtk_1.1-1_amd64.deb
    5. sudo dpkg -i alc900-cups_1.0-1_amd64.deb
    6. sudo dpkg -i alc900-cups-gtk_1.0-1_amd64.deb
  7. You can now add the printer in the standard Ubuntu printer dialog – the Epson AcuLaser C900 driver will now appear in the list.
    • If you use a window manager different than the Ubuntu standard one (Unity), the right printer dialog may not be available in the menu. In that case, you can bring it up by executing system-config-printer.
    • As per the file INSTALL from the alc900-cups software, be sure to use the alc900://... format for the CUPS URIs. However, contrary to that documentation, if your printer is behind a print server, you may have to use a format like socket:// We had to use something like that in our case, where the printer was not a network printer by itself but was behind a Fritz!Box 7141 router that functioned as a network print server here. This probably also means that the status and diagnostic functions of the printer are not available, as they would be with this driver when connecting the printer directly.
    • Before you can print a test page or first page successfully, make sure you set the default paper size in the driver settings correctly (like A4 instead of US Letter). Else, the printer will show the red error LED and will not print.

These instructions are for a Linux system. I used them to create a Fuengirola Printable Streetmap that you can also download via the Documents: Main section.


You want to create your own city (or map of any other area) using open data and free software. This is great because it does not cost any money except a few cents for monochrome printing on a laser printer, and once you have set up the basic system and know the process, it can also be faster than buyin a map.


Here is my procedure:

  1. Get TileMill running with OSM Bright. Follow the “OSM Bright Ubuntu quickstart” instructions. But note that the simplest way of installing TileMill is via its Ubuntu packages! This is a complex tutorial that finally should leave you with a functional TileMill installation including the OpenStreetMap data of the area you’re interested in, all local on your hard drive. You will also have the “OSM Bright” template in use for rendering, which already produces quite nice results.
  2. Edit OSM Bright to your needs. For editing, compare the CartoCSS reference. I edited the colors to have more contrast and, for zoom level 18, made the line width of streets and the font size of street and building labels ca. 2.4 times as large. Else, the font will appear way too small when printing out resp. the map would become twice as large when printing it so that the font gets readable. The map will be exported in zoom level 18 (highest) with these instructions, so we do not need to care for the other levels so far. Contact me if you want the adapted CartoCSS files – not posting them here because it’s a real messy hack to just adapt them for one zoom level.
  3. Set center and extent of maps to export. This can be adapted during every export, but by setting this once and for all you avoid the need to zoom in from a full world view to your map before you can export. To set these in your TileMill project, go to the project settings via the top-right button, zoom in and left click to mark the map center and Shift+drag to mark the extent. Your map’s center has to be within that extent. (And probably, by selecting the zoom level range here to include only one zoom level, you can define what zoom level (so, what styles) are used during the export, but I did not test this yet and rather tried until I got an export in the zoom level i wished for.)
  4. Test-export your map to PDF with TileMill. This is done in the TileMill top-right menu with “Export -> PDF”. You then zoom in until you can select the area to be covered by your map, select that area with Shift+Drag, and set the “Size” field. For exporting, this field determines the level of detail in your map; it is not influenced by the zoom level in the left-hand view, which is here only to select the boundary. You will have to experiment a bit to find the proper numbers, as the values to enter here have no apparent meaning (probably the field is just taken over from the PNG export, where it denotes the size in pixels, so has to be interpreted with some – unknown – dpi setting). So check the PDF results after a test and if necessary adapt the numbers. Too high numbers are not a good idea either, as this will make the labels appear smaller in relation to objects, thus becoming unreadable in normal printed map sizes. We rather want the labels to be quite large for map printing, and also provided for that with the adaptations to the OSM Bright map template. Example: for a 30 000 residents city, ca. 5000 x 5000 was the right setting for me.
  5. Export your map to SVG. This is done in analogy to the PDF export, and with the numbers for “size” that you determined by the previous tests with PDF exports. The SVG output will be pretty huge, but this is normal here (example: 20 MiB SVG, compared to a 3 MiB PDF for the same area and size settings).
  6. Convert the SVG to EPS. In my case, I simply opened the SVG file in Inkscape and saved it as EPS (using PostScript level 2 output, and keeping text as text). The size decreased slightly (20 MiB SVG to 16 MiB EPS). However note that for much larger files (like a full-featured map of a city of 500 000), this will probably not work as Inkscape would need way more main memory than you have … . For that case, a different way has to be found.
  7. Posterize the EPS to PS. This is done super-fast with the command-line program poster, available from the Ubuntu 12.04 repositories. In my case, to tile the input file with whatever page size on a grid of 4×4 A4 pages of output, I used this command:
    poster -v -m A4 -p 4x4A4 -c 15% infile.eps >
    Note that the output file will be very large (in this case 256 MiB PS file from a 15.6 MiB EPS input file, but this is not an error and will be fixed by converting it to PDF in the next step.
  8. Distill PS to PDF. This is done by simply calling this command, which decreased the file size from a 256 MiB PS file to a 6.5 MiB PDF file:
  9. Print and glue. The posterized PDF file is a nice vector map and ready to be printed in color or black & white. You may use it as a book-type atlas, or glue the sheets together. For glueing, the manpage of poster has good instructions.
  10. Create an overview page (optional). This is quite simple: export the same area as SVG but with a way lower size setting (maybe 400) to be applicable for a single page. Then open it in Inkscape and add a grid for the distribution to pages that you chose for the poster command. Maybe write grid element numbers into the elements, like the “(x, y)” style used on poster-generated output. Then create another A4 PDF page from this, and prepend it to the map’s PDF using the pdftk command-line tool.

Discussion of the Solution

  • Alternatives to OSM Bright? As of 2012-09, it seems that OSM Bright is clearly the best start to create a printable map with TileMill. There are just a few CartoCSS templates available at all for download: OSM Bright and Open Streets. Of these, OSM Bright is said to be better maintained, and also the Carto wiki only mentions OSM Bright as an example style [source].
  • Why go via SVG? The reason why the actual / real export is done in SVG is, there is no good way known to me to posterize a PDF file in Linux. There is the pdfposter program (available in the Ubuntu repositories), but it produced a 170 MiB output file from a 3 MiB PDF input file, and worse, the PDF output file was corrupt and could not be read. (I tried with Adobe Reader 9 and Okular.) Maybe you could try pdfposter version 0.5 to see if the bug is fixed there; I used version 0.4.4 from the Ubuntu 12.04 archives.
  • Do not use tilemill-reference-layer. You may install plugins offered in TileMill, but better do not install the tilemill-reference-layer plugin. It would create, for every new project you create after installing the plugin, a base layer with Mapbox street renderings that are loaded on demand as tiles from the Internet. This is essentially also OpenStreetMap data, but you do not have the option to adapt the rendering for better printing as done above with the OSM Bright template – because this layer is downloaded as pre-generated images and not rendered on your PC. However maybe, when indeed having the local map data and the OSM bright template additionally, the tilemill-reference-layer would be hidden anyway, and you still have the advantage that you can browse the rest of the world at street level without having to download and import it all. I did not check that in detail!
  • No overlaps possible with “poster”. It seems not to be possible to create more than the default 5 mm overlap between tiles with the poster command line tool. Because when using the -c option (e.g. -c 15%), it will increase the border, but leave it empty. However, such overlap would be great to have for using the maps in atlas book form rather than as a glued-together large sheet.
  • Still missing: street index. It makes of course no sense to create this manually, but to create the grid and the index, some custom software has to be used. So for now, you will often have to look up a destination on Google Maps, on a desktop computer or on your mobile phone, and then mark the location on your map. You then still have the map for walking through the city, which is way better for clarity and navigation than a tiny screen of some phone where you can never have details and the big scale at once.
  • Anybody wants to create a real print-optimized CartoCSS template? So more than the double-sizing mods from above. I would like to, but have no time right now. Anybody else? 😉 Here are some ideas:  Outlines for areas instead of fillings, and using textures instead of colors or gray shaded in areas. I once had 100 year old maps of my own area and marvelled at the ancient ingenuity of presenting everything in black and white print: they even did not have shades of gray or rasters to emulate such shades.
  • What zoom level will be used? When exporting, TileMill auto-selects the styles of one zoom level for the export. This depends on the extent of the map’s area, and the “size” setting. However note that size settings allow “intermediate” sizes, between the normal levels. The 18 or so levels in traditional OpenStreetMap and Google Maps zooming mean: the first level shows the full world in 256 x 256 pixels, and that pixel width and height is doubled for every new level. By using the size measure, you can give the size in pixels for the mapped area yourself, and use any value. However, the levels’ CartoCSS styles are not relative to these arbitrary scales, as they are given in pixels and not real-world equivalent meters. So with “size” values between the default sizes for the levels, you will get map elements like labels and street width that will appear smaller compared to a map in the level’s default size.
  • What are the default sizes for levels? This should be expressed as “pixels per degree”, so that when multiplying the longitude difference spanned by your map with this “pixels per degree” value, you get the width in pixels to enter into the “size” width field for a map in a desired zoom level that also has the map elements at the maximum possible size in this zoom level, just like they would appear with this map style on OpenStreetMap. (As TileMill always uses the Mercator projection, the pixels by degree value is the same for all longitudes, and also of course for all latitudes; no need to care about this.) The following table was generated from the premise, as used in TileMill / OSM, that zoom level 1 shows the full world in a 256×256 pixel image.
    • Level 1: 28 px / 360° = 0.7111 px/degree
    •  Level 2: 29 px / 360° =  1.422 px/degree
    •  Level 3: 210 px / 360° =  2.844 px/degree
    •  Level 4: 211 px / 360° =  5.689 px/degree
    •  Level 5: 212 px / 360° =  11.378 px/degree
    •  Level 6: 213 px / 360° =  22.756 px/degree
    •  Level 7: 214 px / 360° =  45.511 px/degree
    •  Level 8: 215 px / 360° =  91.022 px/degree
    •  Level 9: 216 px / 360° =  182.044 px/degree
    •  Level 10: 217 px / 360° =  364.089 px/degree
    •  Level 11: 218 px / 360° =  728.178 px/degree
    •  Level 12: 219 px / 360° =  1456.356 px/degree
    •  Level 13: 220 px / 360° =  2912.711 px/degree
    •  Level 14: 221 px / 360° =  5825.422 px/degree
    •  Level 15: 222 px / 360° =  11650.844 px/degree
    •  Level 16: 223 px / 360° =  23301.689 px/degree
    •  Level 17: 224 px / 360° =  46603.378 px/degree
    •  Level 18: 225 px / 360° =  93206.756 px/degree
    •  Level 19: 226 px / 360° =  186413.511 px/degree
    •  Level 20: 227 px / 360° =  372827.022 px/degree
    •  Level 21: 228 px / 360° =  745654.044 px/degree


There are a lot of other solutions, but in my case here they all had some other shortcomings so that I went with the TileMill solution above, even though it’s far from the optimum as well. All the following solutions are referenced in the OpenStreetMap OSM on Paper wiki page, but interestingly the solution proposed here using TileMill is missing there.

  • MapOSMatic. This is a completely awesome web service that produces maps exactly as intended here: as PDF, with overview page, detail pages, grid, street index. And (at least most of) the data is vector-oriented in the PDF, and the PDF has a small size. Only problem: They were down when I tried, having an outage for the last week … . But when they’re up and running again, definitely use them as it’s way simpler than the procedure below.
  • MapOSMatic pre-generated maps. Several thousand user generated maps are available, but there is no map index of these maps and usually no useful description as of 2012-09, you won’t find the map you are looking for.
  • OpenPaperMaps. A desktop application to create paper maps as PDFs, including grid and street index. Should be tried.
  • Field Papers. This is really a neat one, with a super nice interface for map selection and distribution to pages. However the output is rasterized (not vector graphics) and as of 2012-09 there was no way to get a full-detail map in the black and white rendering style for monochrome printing: even when using a zoom level and page distribution that produced all the street names and details in their OSM color map style, the black and white style had some missing.
  • osmbook. Nice approach and output (creating an atlas type book), but not yet too mature it seems …
  • Maperitive. A powerful tool, but seemingly configured with config files only, so not to create your city map in half an hour or so …
  • OSM Export Tab. The simplest solution, usable for simple situations as described in the linked wiki page.
  • OSM-Atlas.  It seems to be no longer in development since 2009. But probably one should try it out still, as it promises that it will create a PDF output file with overview map, detail map pages and street index automatically. But it’s unknown if the output is in vector or rasterized form.
  • bigmap. This does not work any longer – it seems to be out of maintenance for several years. The generated Perl scripts still download and mount a big image, but it will consist only of QR codes since the OSM interface to tiles seems to have changed.
  • StaticMap and staticMapLite. It seems that these can only create raster images of at most 1024 x 1024 pixels. Enough for embedding in a website, but not for a city’s street plan.