Casey Kuhlman

This week I threw together a little site for the daughter of some friends. Lexie is my friends’ daughter and she is lovely. She had to do a Flat Stanley project but she named it Flat Lexie instead. So they sent me a Flat Lexie and we basically travelled the world together – flat lexie and I. We had a few adventures so I wanted to try to capture the pictures I took but also to capture the geography and background of the different places. Indeed, this is supposed to be the point of the Flat Stanley/Flat Lexie exercises for kids to know about the world. In any event, here is the result; here is the code.

It is a simple Sinatra app (first for me), running on Heroku (another first for me), which integrates the gMaps package I installed with Bower (first, first), and a bit of jQuery I added along the way to tie everything together (not a first).

Lessons Learned

What did I learn?

• I like Ruby.
• I’m not sure I like javascript.
• At a minimum, I’m pretty awful at javascript.
• In any event I’m more comfortable with Ruby.
• Sinatra is smooth.
• Heroku is smooth.
• I still have to figure out how to pass JSON data to javascript run views from Ruby controllers that doesn’t rely on data attributes – as that feels like such a patch.

How

The chunk that took me the biggest portion of time was building the javascript file that would tie gMaps, jQuery and the view together. I built the view so it would preload all of the images in boxes that I wanted to slideToggle the display of in sequence. This was straight-forward jQuery, nothing special there.

Then I wanted the map which comprises a 100%x100% background to move around zoom in and zoom out on certain events. Basically I wanted the map to start zoomed out, so that Lexie could see the context, and then after waiting a few seconds I wanted to zoom in to the pinpoint location. When moving to the next picture in the series I wanted the sequence to run like this: slideToggle the old picture/entry, I wanted the map to zoom out to a preestablished zoom level (which depended on how “big” the transition was), then I wanted to put a marker in the new location, then I wanted the map to slide its center over to the new location. It turned out to be not that difficult. gMaps is a great API wrapper for Google Maps API. Between gMaps and jQuery it wasn’t that difficult to craft.

Still I have some issues with javascript. My issues aren’t with javascript per se, as in they are the language’s problem, they are my problem in that I don’t really know how to use the language properly yet. I still don’t fully understand how to call functions and functions as extensable objects is still quite confusing to me and also variable scope is killing me. Both of these Ruby is much more straight-forward about (or else I’ve read more about and understand better). So if anyone wants to point out the innumerable flaws and less than optimal code in the javascript below I’m happy to learn.

In any event, my script that tied the whole thing together and made Flat Lexie works.

$(document).ready(function(){

  // Hide the boxes that are not the first box
  $('.box').slice(1).hide();
  $(".section a[href^='http://']").attr("target","_blank");

  // Title toggles the view of the content box
  $(".title > a").click(function(){
    $("content").slideToggle('fast');
  });

  // Initial variables
  var LAT = $('.box').first().data('lat'),
      LNG = $('.box').first().data('long'),
      ZM_OUT = 4,
      ZM_IN = 20;

  // Set the initial map
  map = new GMaps({
    div: '#map',
    zoom: ZM_OUT,
    mapTypeId: google.maps.MapTypeId.HYBRID,
    lat: LAT,
    lng: LNG
  });
  setTimeout(function() {map.addMarker({ lat: LAT, lng: LNG, });}, 1250);
  setTimeout(function() {map.setZoom(ZM_IN);}, 2500);

  // Previous_event clicks should be hidden on the first box, the rest should run the previous transition
  $(".previous_event").click(prevTransition);
  $('.box').first().children('.previous_event').hide();

  // Next event should run, and reloop if it is the last box
  $(".next_event").click(nextTransition);
  $('.box').last().children(".next_event").click(reloopTransition);

  function nextTransition() {
    $('.nav a').addClass('disabled');
    TRANS = $(this).parents('.box').data('transition');
    if(TRANS == "bigTrans")
      ZM_OUT = 4;
    if(TRANS == "medTrans")
      ZM_OUT = 8;
    if(TRANS == "smallTrans")
      ZM_OUT = 16;
    if(TRANS == "microTrans")
      ZM_OUT = 20;
    map.setZoom(ZM_OUT);
    $(this).parents(".box").slideToggle('slow', function(){
      $(this).next().slideToggle('slow', function(){
        var LAT = $(this).data('lat'),
            LNG = $(this).data('long');
        setTimeout(function() {map.addMarker({ lat: LAT, lng: LNG, });}, 750); 
        setTimeout(function() {map.setCenter(map.markers[map.markers.length-1].getPosition().lat(), map.markers[map.markers.length-1].getPosition().lng());}, 1200);
        setTimeout(function() {map.setZoom(ZM_IN);}, 3750);
        setTimeout(function() {$('.nav a').removeClass('disabled')}, 4000);
      });
    });
  };

  function prevTransition() {
    $('a').addClass('disabled');
    TRANS = $(this).parents('.box').prev().data('transition');
    if(TRANS == "bigTrans")
      ZM_OUT = 4;
    if(TRANS == "medTrans")
      ZM_OUT = 8;
    if(TRANS == "smallTrans")
      ZM_OUT = 16;
    if(TRANS == "microTrans")
      ZM_OUT = 20;
    map.setZoom(ZM_OUT);
    $(this).parents(".box").slideToggle('slow', function(){
      $(this).prev().slideToggle('slow', function(){
        var LAT = $(this).data('lat'),
            LNG = $(this).data('long');
        setTimeout(function() {map.addMarker({ lat: LAT, lng: LNG, });}, 750); 
        setTimeout(function() {map.setCenter(map.markers[map.markers.length-1].getPosition().lat(), map.markers[map.markers.length-1].getPosition().lng());}, 1200);
        setTimeout(function() { map.setZoom(ZM_IN); }, 3750);
        setTimeout(function() {$('a').removeClass('disabled')}, 4500);
      });
    });
  };

  function reloopTransition() {
    ZM_OUT = 4;
    map.setZoom(ZM_OUT);
    $(this).parents(".box").slideToggle('slow', function(){
      $(this).siblings(":first").slideToggle('slow', function(){
        var LAT = $(this).data('lat'),
            LNG = $(this).data('long');
        setTimeout(function() {map.addMarker({ lat: LAT, lng: LNG, });}, 750); 
        setTimeout(function() {map.setCenter(map.markers[map.markers.length-1].getPosition().lat(), map.markers[map.markers.length-1].getPosition().lng());}, 1200);
        setTimeout(function() { map.setZoom(ZM_IN); }, 3750);
        setTimeout(function() {$('a').removeClass('disabled')}, 4500);
      });
    });    
  };
});

For the record, Flat Lexie can easily be adopted to your needs if you have a Flat Stanley project to do. Just fork the repo, add your pictures, add the datapoints.json lat/longs, write any copy you may want and git push heroku. Voila.

Happy Hacking everyone!

~ # ~

Finally had a chance to update my legal markdown package for Sublime. The package is built to fill a couple of holes in the system that I use.

As background, I use Sublime as my main IDE both for coding and for my legal work. I use a word processor, but only to review client documents and to do a final review on documents that I build. All the documents that build, I do so in Sublime. I write regular memos in regular markdown and pandoc them to ODT, double check the formating and output to PDF (and docx if the client needs it) using Libre’s multiformat save extension. I draft laws, regulations, contracts, and corporate governance documents in lmd format, use legal_markdown package to push them (interstitially to normal markdown and then via pandoc) to ODT.

The system worked fine, but I did have to pull down my Terra terminal, cd to the proper directory and run the pandoc command – after converting the lmd file in Sublime to normal markdown. So I knew I wanted to combine some of the better aspects of the various pandoc - sublime integrations (there are at least three that I know of) with the legal_markdown preprocessing.

I’ve now pushed the result. One of the differences in my implementation of pandoc integration (beyond the preprocessing by the legal_markdown gem obviously) is to utilize a document type definitional system. Basically, I wanted to be able to define different output document types and to pre-establish all of the pandoc options for these in my user settings file for the package. Then, when I wanted to export the lmd file I just wanted a quick panel to show up where I could choose the export document type and let the package and pandoc take care of adding the correct mix of settings.

I think it works fine. Basically in the user settings, you add “build-format” keys and for each key you add a document type name (what will show up in the quick panel) key. Then inside this key you add whatever pandoc options you want. There are four main options that the package will use: “from” (pandoc’s reader options), “to” (pandoc’s writer options), “file-output” (triggers pandoc’s -o flag), and “options” (which you can use for general options such as –normalize -S flags which are technically writer options but I think of them as general options). Each of the fields (except for the “file-output” field) should be an array. The “file-output” field should be either “true” or deleted. If it is deleted then the package will replace the currently active buffer with pandoc’s output. Usually, for this package’s purpose you will almost always want to have it asa true.

Lastly, I wanted the package to automatically open a file for me. In other words when I’m converting a lmd file to odt I want to switch over to libreoffice to review the file. So the package also adds an optional field to each document type called “open-file-after-build”. This field is a simple command that you will call to open the file. The package will fill in the file that is outputted by pandoc after the command. So you do not need to type “libreoffice $FILE” into the settings file, you simply need to type “libreoffice” into the settings file and the package will take care of the rest.

I have not tested the auto open in OSX or Windows so if anyone else has those boxes and can test it, that would be fantastic. I’m happy to work to make it cross platform compatible as much as I can.

Still have a bit more work to go on the package as you can see from the roadmap but it is now one step closer to where I’d like it to be.

Happy Hacking!

~ # ~

Wordpress is a great system. A really great system, actually. Especially for non-technical users. It also requires a huge amount of overhead for what most people use it for. Also, it is not nearly as fast and reliable as I would like it to be. So I decided that my blog needed to move from Wordpress to Jekyll. I had been using the same blog theme for about four years now so I also wanted to refactor that. Here’s what I did to migrate it.

Step 1: Install Ben Balter’s Migrate to Jekyll Plugin

First, I downloaded Ben’s migrate plugin for Wordpress. Then I unzipped that into my plugins directory in my Wordpress install (which I deploy from my workstation using git), enable the plugin and click Tools -> Export to Jekyll. Then the server will chew on it for a while and spit out a decent zip. The zip file has the templates (which I didn’t use as I was rebuilding them from scratch and didn’t care what the old ones looked like), the posts, and the pages you have on your blog.

There were a few annoyances with the output, though. These annoyances are not any problem with the Exporter which worked as I expected it would. They were mainly annoyances with a lot of rust that is within the code/database of my blog. That rust was one of the main reasons that I wanted to switch to Jekyll. Since Jekyll is simply plain text files it is much simpler to iterate over the files and make the changes.

Step 2: Build the Jekyll Deploy How I Wanted it to Look

Next, I worked on the layouts, includes, html files, config, rakefile and put everything how I wanted it to be. This was simple web design and there are lots of tutorials which were quite helpful in this endeavour. Once the Jekyll deployment looked and acted how I wanted it to, it was time to chew on the files.

Step 3: Build a Ruby Script to Reformulate the Posts How I Wanted

The first problem that I had with the export was that the yaml frontmatter was loaded with a lot of crap that I neither needed nor wanted for the Jekyll. So I thought I would build a small ruby script that would clean the YAML Frontmatter. Here’s the part of the script that does that.

  def clean_the_yaml( yaml_block, first_para )
    new_yaml = {}
    new_yaml["layout"] = "post"
    if yaml_block["title"] != "" && yaml_block["title"]
      yaml_block["title"].gsub!("\"", "\'")
      if yaml_block["title"] =~ /\A"/
        new_yaml["title"] = yaml_block["title"]
      else
        new_yaml["title"] = "\"" + yaml_block["title"] + "\""
      end
    else
      new_yaml["title"] = ""
    end
    new_yaml["published"] = "true"
    new_yaml["comments"] = "true"
    new_yaml["meta"] = "true"
    if yaml_block["categories"]
      new_yaml["category"] = yaml_block["categories"].first.downcase 
    else
      new_yaml["category"] = yaml_block["category"] || "unclassified"
    end
    new_yaml["tags"] = yaml_block["tags"] if yaml_block["tags"]
    if yaml_block["excerpt"]
      new_yaml["excerpt"] = yaml_block["excerpt"].gsub("\n", "")
      new_yaml["excerpt"] = new_yaml["excerpt"][2..-1].strip if new_yaml["excerpt"][0] == ">"
    else
      new_yaml["excerpt"] = first_para.gsub("\"", "'")
    end
    if new_yaml["excerpt"][0] == "\""
      new_yaml["excerpt"][1..-2].gsub!("\"", "'")
    else
      new_yaml["excerpt"].gsub!("\"", "'")
    end
    new_yaml["excerpt"] = "\"" +  new_yaml["excerpt"].strip unless new_yaml["excerpt"][0] == "\""
    new_yaml["excerpt"] = new_yaml["excerpt"] + "\"" if new_yaml["excerpt"][-1] != "\"" || new_yaml["excerpt"].length == 1
    final_yaml = "---\n\n"
    new_yaml.each{ | head, val | final_yaml << head + ": " + val.to_s + "\n" }
    final_yaml << "\n---\n\n"
  end

That prt of the script mainly strips out the old rust from the YAML front matter and ensures that all my punctuation will not get in the way of Jekyll doing its job. For instance, I had lots of colons in my titles and these are a problem with YAML if you do not escape them or put the string in double quotes. Also I wanted all the posts to have some sort of a excerpt so if I did not have an excerpt in the Wordpress, I built the script to import the first paragraph and then escaped it and guarded against problems with punctuation in the paragraphh.

The second thing I had to overcome was the way the exporter handled images embedded in the text was not really how I wanted it. I am not sure if the exporter was made to export images or not, but I think because I run a multisite deployment – and because Wordpress handles multisite files much differently than single site files – that the images were a problem.

When I looked on my machine in the Blogs.dir for the Blog I was exporting I saw another problem which was that Wordpress saves a lot of different versions of the same file. This was going to be a problem when I tried to import the photos into the Jekyll asset pipeline I built.

I was used to the ruby system command but there was a problem when I tried to drop the return of the system command into a variable. And then I came upon my new favorite rubyism: backticks. These were great. They work just like backticks in bash/zsh scripting so they were quite intuitive. They run a system command and throw the result of that into a string variable – which you can split, strip, do whatever you need. This let me build a find command that I could use to get over the multiple files issue.

I also needed to reformulate how the images were called within the text. Wordpress puts a caption (which I almost always used) and the exporter used the reference link syntax that I don’t particularly prefer in markdown. So I wanted to reform that part of the source posts. Here’s the part of the script that did that.

def clean_the_content( entry_block )
  pictures_pattern = /\A(\[\!\[(.*?)\])(.*?\z)/
  file_pattern = /\A\s*\[\]:(.*?\/(.*?))\z/
  delete_lines = []
  for para in entry_block do
    if para[pictures_pattern]
      pict_line = $1
      caption = $2
      rest_of_it = $3
      picture_to_copy = false
      next if rest_of_it[/\A\(\{\{/]
      p_index = entry_block.index para
      delete_lines << entry_block[p_index + 1] if entry_block[p_index + 1][/\A#{caption}/]
      if entry_block[(p_index + 5)] =~ file_pattern
        full_pict_ref = $1.strip
        picture_to_copy = $2.split("/").last
        delete_lines << entry_block[p_index + 5]
        picture_to_copy = copy_over_pictures( picture_to_copy )
      end
      if picture_to_copy
        entry_block[p_index] = "#{pict_line}(http://coda.caseykuhlman.com/assets/images/2013-04-18 00:00:00 -0400/#{picture_to_copy})][#{full_pict_ref}]"
      end
    end
  end
  delete_lines.each{ | line | entry_block.delete( line ) }
  return entry_block
end

def copy_over_pictures( picture_name )
  location = `find #{@pictures_pull_dir} -name '#{picture_name}*' -type f | sort -nr`
  if location != ""
    location = location.split("\n").first.strip  
    picture_name = location.split("/").last
    if `ls #{@pictures_push_dir}/#{@publish_year}` == ""; `mkdir #{@pictures_push_dir}/#{@publish_year}`; end
    `cp #{location} #{@pictures_push_dir}/#{@publish_year}/#{picture_name}`
    return picture_name
  else
    `echo "Error importing to #{@publish_year} the file: #{location}/#{picture_name}" >> cleaner-errors.log`  
    return false
  end
end

That was it. Just a few regexs and a few deletes and a few system commands.

Step 4. Put it all Together && See What We Have

After I built the script and tested it on a few of the more recent posts I needed to run it on the entire directory of posts. I kept the posts in a separate directory out of the repo so if anything got screwed up with the script I could just re run it. I ended up having to do that a couple of times as I had to tweak my original version of the script a bit to arrive at what is presented above.

rm -rf _posts && cp ~/Downloads/jekyll-export/_posts . -R && git add _posts && ./cleaner.rb

One of the first things I realized was that I needed to add the _posts dir to the the repo again as when you run jekyll it will git ls-files. So I ran the above command until I was happy with the results and then I finally ran this command.

rm -rf _posts && cp ~/Downloads/jekyll-export/_posts . -R && git add _posts && ./cleaner.rb && rake site:publish

That was it! The full cleaner script can be found in this gist. If you want to use it, download it into the root of Jekyll, chmod +x cleaner.rb and you will be all set.

Lessons Learned.

• Testing of scripts is huge. I still don’t really know how to do this but I tested it with sample data and was prepared for things to go wrong.
• Backticks. FTW.

~ # ~

One of the most obvious appeals of Linux to me is the insane levels of customization you can achieve. I mainly use Gnome Shell as my desktop environment, but since I use Ubuntu I keep Unity on my machine. I’m not a hater of Unity or Gnome as many Linux users (who can be quite vitriolic in their statements as to desktop environments). I mostly use Gnome, but since Ubuntu has some interesting things going on with Unity sometimes I like to drop into Unity to see what I’m missing.

There is a problem at least in Ubuntu 12.10 running both desktops. To use Gnome Shell one should install the gdm package in order to get the full Gnome desktop experience - including the Gnome lock screen which is beautiful. GDM stands for Gnome Desktop Manager. It is an alternative to lightdm which Ubuntu installs by default and which Unity uses. When you switch to gdm I found out that just after installing it you should logout of Unity before restarting your machine. But I didn’t do that.

The result of installing gdm and then restarting your machine is that the X server (which runs most of the linux desktops and lies in the stack underneath both gdm and lightdm) doesn’t start correctly for “both” Unity and Shell. It is something to do with the way that dm loads the XSessions and it is beyond my understanding. In any event the problem for me was that while gdm made Shell work as it should out of the box, Unity would not load when I logged into Unity desktop.

So I built a small autostart script that for Unity that will load Unity after logging into the Ubuntu desktop. This was straight-forward. But the problem I had is that I didn’t want the script to try to load Unity when I logged into Gnome. But, as usual with linux, with a bit of Googling I came across the key. In X session desktop scripts (which are the main way to start/run programs) you can define which desktop environment they should show up in. This means that when you put the script into the autostart folder (~/.config/autostart) you can mark the script to … OnlyShowIn=GNOME; or OnlyShowIn=UNITY; or NotShowIn=GNOME; or NotShowIn=UNITY;. You can add multiple environments for the desktop script to be shown or hidden in after the semicolons.

This is helpful for showing or hiding certain programs/scripts in your menus in different desktop environments but also when you put it in the scripts in your autostart folder you can tell linux to only load the programs when you log into certain desktop environments. I tested the script and it didn’t work at first. The problem was because gdm wasn’t loading Unity, the autoload scripts I marked to only load in Unity weren’t triggering. Even though gdm sent me to Unity, the desktop environment wasn’t loading correctly. So I had to change the script from OnlyShowIn=UNITY; to NotShowIn=GNOME;. This meant that when the desktop environment saw that it was not in Shell it triggered the script for Unity. It isn’t ideal as the autoload scripts that are linked to Unity don’t run after the Unity reload script runs, but it is a decent enough work around for the amount that I use Unity (minimal).

This is very powerful as you usually want Gnome Shell and Unity to load the different sugar packages such as applets, indicators, etc., that help you define the environment you are working in. This is reason 7 million why Linux is awesome. In any event, here’s the script I use to reload the Unity desktop after I log into Unity.

[Desktop Entry]
Type=Application
Exec=unity
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Unity-Reset
NotShowIn=GNOME;

I saved that in ~/.config/autostart and voila all (mostly) working as it should.

Happy Hacking!

~ # ~

While it varies, I generally will have two meetings with a client before I will build the initial draft of the contract.

In the first meeting, I will try to ferret out what the client is trying to achieve. This is generally an overview meeting. Mostly, Somalis do not like doing too much in any one meeting – especially if they do not know you well. So I try to keep the goals of what I need to achieve in these meetings realistic and limited. During this meeting, I try to give them an idea of in which direction we are likely to take the transaction in terms of what types of contract(s) are going to be involved to facilitate and integrate the transaction. I also usually try to give the client a few of the key, and usually poignant, decisions that they will have to make so that they can mull it over between the first and second meetings.

In the second meeting, I will ask a lot more specific questions. This meeting is all about the details. Prior to the meeting I will have planned out the transaction documents and forked the appropriate templates of whatever documents will be required for the transaction. I use the specific forks of the primary templates as the basis of my checklist for the transaction. This is easy when building templates in legal_markdown form and sublime. I have been building (but haven’t open sourced it yet) a small script that automates this process for me. In my contract templates I just type ...?ASK?... or ...?CONFIRM?... and then the script finds these and builds them into a checklist specific to the transaction.

I know a lot of transactional attorneys like to build checklists based on the type of transaction. I have a few of those, but I find that usually I spend more time deleting irrelevant items and overall they are inefficient for me. I prefer to build questions into my document templates and then to build my checklist for the transaction based on the document templates that I’m going to use.

For example, this week I’ve been working on two different joint venture agreements. They are very different from one another and are based on two different templates (one of which is a fork of the main JV template that I have built). For me, it is more efficient to pull my checklists from each of the templates than it would be to fork a main joint venture checklist and then adapt that for each type of transaction.

In other words, the key is to integrate your checklist building with your template building. This has many distinct advantages, not the least of which are precision and efficiency.

The script that builds the checklists for me in sublime produces a list of questions. These provide me with the base the agenda of the second, more detail oriented, meeting with the client. Usually I print the checklist as I find that Somalis usually find a screen in the room either disrespectful or disorienting. So I usually just write my answers on the printed checklist.

After that second meeting, I build the first drafts of the documents necessary for the transaction. As I said earlier, I build my templates into a main repo and then fork the necessary templates from the main repo into the repo for the client. When I build templates I fill them with mixins, optional clauses, and questions. All I have to do after the second meeting is to fill in the answers to the questions that I have by replacing all the ...?QUESTIONS?... with the answers. Usually this just means filling in the YAML front matter of the template.

Once I have finished answering the questions, entering the mixins and selecting or deselecting the optional clauses (all of which I do in the YAML front matter), I simply save the legal_markdown file && pandoc it based on my contract template .odt. Then I open the .odt in libreoffice where I do a final read through of the contract, tweak the styles if necessary, and save as .pdf / .doc / .odt or whatever the client needs to review the document. All of these steps (minus the final review in libreoffice) I perform from sublime. I build the templates there, I massage the YAML front matter there, I pandoc from there, and I open the .odt file from there. It is basically a full scale contracts IDE for me.

After the client has reviewed the documents I will sometimes edit in Sublime, but if the changes are marginal then I find it more efficient to make the changes in Libreoffice and voila. Done.

Lately, I have been writing a lot in markdown. It is a freeing way to write documents because you focus more on the words than the tools around you in the wordprocessing interface. You pick your favorite environment to write – for me it is Sublime Text – and then you write. But, clients and courts do not read Github Flavored Markdown.

This is where Pandoc comes into play. Pandoc is one of the many markdown renderers / translators available. You can think of it like a swiss army knife for changing document types. The thing that makes Pandoc quite interesting, for my purposes as a lawyer, is that it when you translate your markdown into an .odt file (or .docx for those who like completely bloated, prorietary things) you can establish exactly how the end document will look.

What you do is first output some markdown text into an .odt file. Then you go into LibreOffice and modify the styles so that they are appropriate. I have templates setup for most of the documents I create and I simply linked the main styles that I use in my markdown to the ones in the template .ott files. I created multiple Pandoc .odt templates (which Pandoc calls reference files) to more or less mirror my .ott files.

In Sublime, I forked the excellent Pandoc plugin to modify it so that I could build custom templates and added a few other goodies so that Pandoc would play nicer with .odt files (which were not included in the original version). Using the forked Pandoc plugin I can simply output my markdown files to the appropriate reference file. I use the SideBarEnhancements plugin to right click on the newly created .odt and open in Libre to finalize everything. Mainly this entails dropping in my citations from Zotero and making sure that the styling is fine and everything is looking as it should. Save the new .odt file in GDrive. Output the .pdf to GDrive. Close the task on Teambox. Email the client. Done.

One of the most annoying things about using a wordprocesser and doing research is the new lines that pdf copy places on your clipboard. Since Python is a relatively straightforward language and not that different from Ruby for simple text manipulation, and since Sublime offers a very easy to understand API, it was quite easy – even for a beginner such as I – to build a plugin that will allow me to ctrl+alt+v and thus strip the newlines so that the text block pastes as a single text block.

Because Pandoc has inline footnoting, when I’m writing I simply drop in a marker quickly where I need to reference things. When Pandoc translates the markdown into an .odt file it builds the footnotes with the markers I need (usually pinpoints). Then I can simply inserting the citations from Zotero. When I was doing some research the other day I realized that FastCase does not have a translator for Zotero so I started working on one. It will be coming soon. And more about integrating Zotero and LibreOffice for legal research will accompany that.

For legal documents, particularly client focused documents, you don’t really need that much formatting. Indeed the less the better. Really you need only a handfull of styles within the document. Using a system such as this to force the proper styling techniques you can easily roll branding rules for your small firm and also let lawyers focus on the text rather than another Format Paste.

Admitedly, collaboration is still imperfect. A huge percentage of lawyers still are on Word and so the .doc and .docx formats and awful Calibri are not going away anytime soon. There is no simple way, when you need to track changes and integrate comments into a document, to utilize some of the tools that make writing so much more enjoyable on a text processor. Luckily, however, using these techniques allows me to limit my time in a word processor – even a quite nice one like LibreOffice.

~ # ~