Git-Scribe Syntax Highlighting

‹prev | My Chain | next›

Yesterday I was able to cherry pick a commit from the upstream git-scribe into my fork of git-scribe that prevented code blocks from splitting across pages in the generated PDF. An even more exciting development in upstream is syntax highlight in code blocks—something I was never able to get working on my own.

Ultimately, I should try to get back on upstream, but I had invested quite a bit of time in getting the epub and mobi formatting working nicely in my fork (I did submit pull requests) before upstream went a different direction. Also, when I had tried out upstream after those changes went it, I was no longer able to control the PDF page size (I am use 7"x9"). It is going to be hard to get that rebased onto upstream if I cannot get my local a little closer.

Anyhow, I am pretty sure that I could not get highlighting working when I cherry picked the commit previously, but let's try it out to be sure....

➜  git-scribe git:(master) git cherry-pick cddb437d27e01c4fda7ae5a51bb47cdd57595acb
error: could not apply cddb437... Add syntax highlighting for PDFs
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

Checking the conflicts, I see:

➜  git-scribe git:(master) ✗ gst
# On branch master
# Changes to be committed:
#
#       modified:   docbook-xsl/fo/highlight.xsl
#       modified:   test/gen_test.rb
#       new file:   vendor/saxon.jar
#       new file:   vendor/xslthl-2.0.2.jar
#
# Unmerged paths:
#   (use "git add/rm ..." as appropriate to mark resolution)
#
#       both modified:      .gitignore
#       both modified:      docbook-xsl/fo.xsl
#       both modified:      lib/git-scribe/generate.rb

Ah, wait a second. Now it's all coming back to me. Upstream is now using saxon (java) to convert so that it has access to the libxslthl library which is written in java. Ugh.

Before I go down that path, I would like to see if alternatives might work. To the best of my knowledge, this means pygmentize. Rather than fiddle with it directly, I give the python script in this article a try (copying the html.xslt code listing from that same article):

➜  output git:(master) docbook_build.py --html html.xslt book.xml
Note: namesp. add : added namespace before processing              Recipes with Backbone
Writing /home/cstrom/repos/backbone-recipes/output/pr01.html for preface(_history)
Writing /home/cstrom/repos/backbone-recipes/output/pr02s02.html for section(_contact_us)
Writing /home/cstrom/repos/backbone-recipes/output/pr02s03.html for section(_how_this_book_is_organized)
Writing /home/cstrom/repos/backbone-recipes/output/pr02.html for preface(_introduction)
Writing /home/cstrom/repos/backbone-recipes/output/ch01.html for chapter(chapter_non_backbone)
....
Writing /home/cstrom/repos/backbone-recipes/output/index.html for book

When I take a look at the output, I find:

Aw, dang, that's really no improvement over:

To be sure the pygmentize formatting is a little prettier, but the same things are getting highlighted: this, keywords (return, function), and strings. None of the class names are highlighted. None of the method names in either is highlighted. So there really is no benefit to sticking with the old xsltproc-based way.

So it looks as though I am going to have to follow upstream down the saxon path. I will get started with that tomorrow, but, instead of working with the syntax highlighting, I am going to see if I can solve the page size first. 8.5in x 11in just won't cut it for me.

Day #241