How to Install FCKeditor on Drupal

After some trouble lately getting everything working, I finally have the FCKeditor WYSIWYG editor installed and working on Drupal. The official documentation leaves a little to be desired, so it seems prudent to document and share what I had to do to make it work.

I’m using Drupal 6.2, the FCKeditor module 6.x-1.2-1, and FCKeditor 2.6. Continue reading “How to Install FCKeditor on Drupal”

Save My <pre> WordPress Plugin, or, WTF-8 My Whitespace

If you’ve tried to use code samples in WordPress, you might have noticed unexpected behavior from the WYSIWYG editor. It will edit the whitespace inside of <pre> tags, leaving you with some poorly formatted, hard-to-read code. Today, I set out to stop that.

What causes this?

Whenever the WYSIWYG editor opens, it sends the content of the post through a few filters. You can find most of these in wp-includes/formatting.php. The culprit here is the function wpautop. This function runs a long list of regular expressions to make your content a little prettier and better formatted. But we don’t want that to happen to our <pre> tags; they’re pre-formatted. We want those left alone. To do that, I had to find a way to keep the content of the <pre> element from going through that filter.

WordPress’s plugin system allows you to change its behavior without altering the core code, so you don’t have to re-alter it every time you upgrade. As easy as it would have been, in the short-term, to just edit wpautop to make it behave properly, I wanted a longer-term solution that would be easier to share with other WordPress users. Therefore, a plugin. Continue reading “Save My <pre> WordPress Plugin, or, WTF-8 My Whitespace”

Fun with Acrobat

In my last post, I noted the need to convert some PDFs from a format suitable for a printer to a format suitable for online reading. The PDFs of the Muncie Times that I receive are laid out as spreads for each printed sheet of paper. So, for example, the first spread of the PDF includes pages 48 and 1, the next spread includes pages 2 and 47, etc. Many of the pages also have various printer’s marks along the edge.

In my last post, I noted the need to convert some PDFs from a format suitable for a printer to a format suitable for online reading. The PDFs of the Muncie Times that I receive are laid out as spreads for each printed sheet of paper. So, for example, the first spread of the PDF includes pages 48 and 1, the next spread includes pages 2 and 47, etc. Many of the pages also have various printer’s marks along the edge.

First, I established a general algorithm for tidying this up.

  1. Make a copy of the document in reverse order and append it to the end of the document.
  2. Crop off the unneeded half of each spread (left for the odd-numbered spreads, right for the even-numbered spreads).
  3. Delete the printer’s marks from the margins.
  4. Add top and bottom margins.

If you’ve tried to do much automation with Adobe CS applications, you’ve probably encountered the well-documented JavaScript APIs that make the job much easier. Acrobat is special. Its API is very different, much more limited, and boasts horrible, often inaccurate documentation. Even getting Acrobat to recognize and run a script can be such a chore that I’ve taken to copying code into its JavaScript console and running it from there.

That rant aside, it wasn’t too difficult to accomplish the first couple of steps. Step 1 (assuming you’ve already opened the document):

var nPages = this.numPages;
for (i = 0; i < nPages; i++) {
	this.insertPages({
		nPage: nPages-1,
		cPath: this.path,
		nStart: i
	});
}

Step 2:

for (i = 0; i < this.numPages; i++) {
	if (i % 2 == 0) {
		this.setPageBoxes({
			cBox: "Crop",
			nStart: i,
			rBox: [11.25*72, 0*72, 22.5*72, 13*72]
		});
	} else {
		this.setPageBoxes({
			cBox: "Crop",
			nStart: i,
			rBox: [0*72, 0*72, 11.25*72, 13*72]
		});
	}
}

Note that all measurements must be in picas. Since 1 inch = 72 picas, I just multiply all of my values by 72. I probably could have made this more universal by letting the script calculate the width of the page and then divide that in half.

At this point I discovered an oddity of Acrobat. In other Adobe programs (and any image-editing program I’ve ever used), when you crop something, you define and area and remove everything outside of that area. Acrobat never removes any part of a page, it merely hides it. So while you have this document that looks like it has 48 pages, each 11.25 in. x 13 in., you really have a document that has 48 pages, each 22.5 in. x 13 in., which is to say a document twice the size that it needs to be.

In my search for a fix to this, I eventually came across this handy tip from the Acrobat 7 PDF Bible (p. 388):

If you want to eliminate the excess data retained from the Crop tool, you can open the PDF in either Adobe Photoshop or Adobe Illustrator. Both programs honor the cropped regions of PDF files cropped in Acrobat. When you open a cropped page in either program, resave it as a PDF.

Very helpful information, that, if the cure weren’t worse than the disease.

  1. Neither program can open more than one page of a document at a time. But I could write another script to do this part if that were the only problem.
  2. Photoshop rasterizes all of the text. Needless to say, that’s unacceptable.
  3. Illustrator can’t use embedded fonts if you don’t have them on your system and will replace them with whatever fonts are available. Since they have a Mac and I have a PC, this won’t work.

After mulling this over a bit more, I had an epiphany: print it! “Gasp,” you say, “wasn’t the whole point of this to avoid having to go through a print version?” Yes, but printing doesn’t have to go to a physical medium. In this case, I used the Adobe PDF printer that comes with Acrobat to print my PDF to a PDF. Incredibly, this worked. By setting a paper size to 11.25 in. x 13 in., I could print the document to a new, appropriately-sized document while discarding the excess data (and doing some optimization for online viewing while I was at it). Step 2 complete.

After discovering how to accomplish step 2, I realized that steps 3 and 4 could be accomplished in a similar manner. Crop the margins off and print to a new PDF with the margins I want, clear of any printer’s marks. As a matter of fact, these steps could be rolled into step 2. Simply take off an extra 0.45 in. from each side of the page, then print to a 11.25 in. x 13.75 in. page. So the new combined code for steps 2 and 3:

for (i = 0; i < this.numPages; i++) {
	if (i % 2 == 0) {
		this.setPageBoxes({
			cBox: "Crop",
			nStart: i,
			rBox: [11.70*72, 0*72, 22.05*72, 13*72]
		});
	} else {
		this.setPageBoxes({
			cBox: "Crop",
			nStart: i,
			rBox: [0.45*72, 0*72, 10.80*72, 13*72]
		});
	}
}

After that’s run, you create your custom paper size and print to PDF, centering the content on the slightly-larger page.

Off-Line Web Applications With Google Gears

One of the most frequent criticisms of the modern crop of web- and AJAX-based applications is the need for an Internet connection for them to work. After all, what good are Google Docs or webmail to you if you are on an airplane or facing a temporary connection interruption. Google has brought us one step closer to fixing that this week with its new Google Gears browser extension.

One of the most frequent criticisms of the modern crop of web- and AJAX-based applications is the need for an Internet connection for them to work. After all, what good are Google Docs or webmail to you if you are on an airplane or facing a temporary connection interruption. Google has brought us one step closer to fixing that this week with its new Google Gears browser extension.

As others have pointed out, Google is not the first to develop something like this. But putting their weight behind it should help increase the development and adoption of off-line web applications.

I can imagine several potential uses for Gears within the library. Someone could conceivably save a set of records within an OPAC web interface, and still have access to those records while taking their laptop through the stacks of the library (presuming the library doesn’t have adequate Wi-Fi, of course). Or a student could save several items from a digital collection and still have access to those pages when presenting them to a class later. These things can already be done, of course, but Gears should make them easier and more user-friendly.

Like many Google products, Gears is still in Beta (much like Google Reader, which has implemented Gears), which means there are still some bugs to work out. There is some suspicion that it was rushed out the door to meet the deadline of Google Developer Day. But hopefully Gears will soon be a stable, robust, functional API for delivering off-line web applications.