I recently fell into this class variable trap described in the posts above. Here is some code simulating my problem.

irb(main):001:0> class Person
irb(main):002:1>   @@count = 0
irb(main):003:1>   def initialize(name)
irb(main):004:2>     @name = name
irb(main):005:2>     @@count += 1
irb(main):006:2>   end
irb(main):007:1> end
irb(main):008:0>
irb(main):009:0* class Customer < Person
irb(main):010:1>   @@count = 0
irb(main):011:1>   def self.count
irb(main):012:2>     puts @@count
irb(main):013:2>   end
irb(main):014:1> end
irb(main):015:0>
irb(main):016:0* a = Person.new("Jim Bob")
irb(main):017:0> b = Person.new("Jason Yates")
irb(main):018:0> c = Customer.new("Albert Einstein")
irb(main):019:0>
irb(main):020:0* puts  Customer.count

3

You would expect to get ’1′ back from the ‘Customer.count’ method. It is the more obvious behavior or the one with the least surprise. The issue is, as you may have already noticed, class variables are shared with its subclasses. This behavior, speaking from personal experience here,  can lead to very confusing and hard to diagnose bugs.

The problem above is easily solved by the use of class instance variables.

irb(main):001:0> class Person
irb(main):002:1>   class << self; attr_accessor :count; end
irb(main):003:1>   def initialize(name)
irb(main):004:2>     @name = name
irb(main):005:2>     self.class.count ||= 0
irb(main):006:2>     self.class.count += 1
irb(main):007:2>   end
irb(main):008:1> end
irb(main):009:0>
irb(main):010:0* class Customer < Person
irb(main):011:1> end
irb(main):012:0>
irb(main):013:0* a = Person.new("Jim Bob")

irb(main):014:0> b = Person.new("Jason Yates")
irb(main):015:0> c = Customer.new("Albert Einstein")
irb(main):016:0>
irb(main):017:0* puts Customer.count
1

As you can see this simulates the expected behavior.

This will all become mute fairly soon anyways. In Ruby 1.9, class variables are now read-only by its subclasses. With this even the first example should work correctly.

I was tired of manually opening Vim, starting the Rails server, tailing the development log, and opening the Rails console every time I opened a project. So I pimped my gnome-terminal.

#!/bin/bash

if [[ $# == 0 ]]; then
  PROJECT_DIR=$PWD
elif [[ $# == 1 && -d "$1" ]]; then
  PROJECT_DIR="$@"
else
  print "usage: pimp-term.sh [rails project directory]"
  return 1
fi

cd $PROJECT_DIR

gvim 

gnome-terminal
  --tab -t "app"
  --tab -t "server" -e "sh -x -c './script/server'"
  --tab -t "console" -e "sh -x -c './script/console'"
  --tab -t "log" -e "sh -x -c 'tail -f log/development.log'"

$ pimp-term.sh project/myblog

You’ve officially been pimped.

The Problem

The majority of PDF generators out there are exactly that generators. They simply create new PDF’s based on programming code. They don’t edit existing PDF files, let alone have the ability to fill in data. So I looked into a couple other solutions. First I checked out image based solutions like using ImageMagick. I could of course edit existing image files and add data. But, the problem is the added image data would have to be positioned. If the template image changed, so would my positions in code. So that was out.

I tried using PostScript files saved from Adobe Illustrator. I created a template and placed text like <% replace_me %>. That should work right? Wrong. For whatever reason Adobe Illustrator likes to create HUGE files. Yes 100,000 lines long in some cases. It also splits up text arbitrarily. So “<% replace_me %>” became “<% r” 20 lines of positioning and font information, “eplac” 20 lines of positioning and font information, etc. Making a search and replace impossible.

iText to the Rescue

iText is an excellent Java PDF library. In fact, I believe other then it’s C# counterpart. Is the only PDF library which could do what I wanted. iText can take existing PDF’s and manipulate them. It also can take blank PDF forms and fill out the data, similar to taking HTML form and setting each form field tags value attribute. This is exactly what I wanted. Although it is an ad-hoc round about solution it does work.

Creating PDF forms is pretty easy also. Downside is only one product can create them Adobe LiveCycle Designer, which comes with Adobe Acrobat Professional.

Solution

So first I needed to create a wrapper around iText using the excellent Ruby Java Bridge(Rjb).

require 'rjb'
Rjb::load('lib/itext-1.4.8.jar')

class PDFStamper
  attr_accessor :writer

  def initialize( template = "proposal_template.pdf" )
    filestream   = Rjb::import('java.io.FileOutputStream')
    acrofields   = Rjb::import('com.lowagie.text.pdf.AcroFields')
    pdfreader    = Rjb::import('com.lowagie.text.pdf.PdfReader')
    pdfstamper   = Rjb::import('com.lowagie.text.pdf.PdfStamper')

    reader = pdfreader.new( template )
    @stamp = pdfstamper.new( reader, filestream.new( tmpfile() ) )
    @form = @stamp.getAcroFields()
  end

  def set( key, value )
    @form.setField( key, value.to_s )
  end

  def fill
    @stamp.setFormFlattening(true)
    @stamp.close
  end

  def tmpfile
    return @tmpfile unless @tmpfile.nil?
    @tmpfile = File.join( Dir::tmpdir, make_tmpname )
  end

  private

  def make_tmpname
    return 'proposal-' + rand(10000).to_s + '.pdf'
  end
end

Then using Adobe LiveCycle Designer, I simply created a PDF form and added textfield’s which would be filled out by iText. The textfield’s can be styled, so don’t think you have to keep that normal “textfield” look. Make sure you give each textfield a name that you will use “set( textfield_name, value)” to set the value . In my PDF I simply named each textfield after the database fields. Then in my controller code, I had the following.

def output
  order = Order.find(params[:id])
  pdf = PDFStamper.new

  for column in Order.content_columns
    pdf.set( column.name, order.send(column.name) )
  end

  pdf.fill

  send_data( File.open( pdf.tmpfile ).read,
    :filename => "order.pdf",
    :type => "application/pdf",
    :disposition => "inline"
  )
end

Caveats

First of, you need Java environment variables set correctly before this will work.

export LD_LIBRARY_PATH=/usr/java/jdk1.6.0/jre/lib/i386/:/usr/java/jdk1.6.0/jre/lib/i386/client/:./
export JAVA_HOME=/usr/java/jdk1.6.0/

You can set these variables in the command line and start mongrel manually “mongrel_rails start”. Which will work fine. Except in production this isn’t really a good solution.

I ended up using the mongrel_cluster init.d script that comes with mongrel. Documentation is available here. I simply placed the export commands on the top of the script.

Another issue I hit was when Java starts. Java will check for total available system memory and then precedes to steal a good portion of it. Now this isn’t a problem with a dedicated server. A virtual server, on the other hand, is allocated a portion of the available system memory. So if the server you are on has 4gbs of memory. Java thinks it has 4gbs to play with, not the 256mb allocated to your virtual server.

This caused this weird issue where one mongrel process in my cluster would work and one wouldn’t. Because each mongrel instance starts its own Java process. The first one would steal all the available memory. Then the second couldn’t even start because no memory was available.

Making matters worse Rails or Mongrel, not sure which, would hide this memory error. I didn’t figure it out until I created a test script that forked, each fork loading the iText jar. The test showed the error coming from Java.

To fix this, I set the _JAVA_OPTIONS environment variable. The options get sent to Java as it loads, it limits the amount of ram each Java instance can eat up. Just place this next to your other Java environment variables inside your init.d mongrel script.

export _JAVA_OPTIONS='-Xms16m -Xmx32m'

You may have to fudge these numbers a little for your particular environment. Or, if you are using a dedicated server don’t worry about it.

Limitations

Now for my particular needs, I only needed text placeholders for the template. However, I believe using LiveCycle designer you can place image placeholders and table based data. Then use iText to fill them in. Don’t take my word for it though.

• HTML 4.01 ABBR tag
• Improved (though not yet perfect) <object> fallback
• CSS 2.1 Selector support (child, adjacent, attribute, first-child etc.)
• CSS 2.1 Fixed positioning
• Alpha channel in PNG images
• Fix :hover on all elements
• Background-attachment: fixed on all elements not just body

Most of these added features still have issues, or caveats related to them. Slack, of course, should be given with IE7 still being in beta. Overall though even with these additions, standards compliance hasn’t changed much in IE7. Web Devout analysis of both IE6 and IE7 confirms this. First let me say a semi-legitimate argument could be made saying Web Devout’s numbers are biased towards IE. However I still think is fairly effective especially when comparing IE with itself.

As you can see, there really isn’t much difference between IE6 and IE7 with regards to standards compliance. Most importantly, in my opinion, IE7 is still lacking:

• DOM Level 2 Events(Netscape Communicator had this in 2000!)
• DOM attributes are still broken
• No Javascript 1.6 support
• CSS :focus
• SVG support

However my list is quite short. There are many more lists out better than mine.

I wouldn’t go so far to say as IE7 is “just a bug release”. It is fairly close however. IE7 is still years behind most modern web browsers, and it hasn’t even been released.