Recently a client came to me with a small project: a single new page on her site, password protected to keep out casual browsers and search engines, but not requiring a high degree of security.

When I’m very busy, as I am now, I occasionally subcontract to other American-based freelancers with whom I’ve worked closely and whom I trust to produce excellent work. Because this project was in a language I rarely work in, I decided the most efficient use of the client’s money would be to subcontract to someone with more experience in that language. I reached out to some contacts and was put in touch with someone who received enthusiastic recommendations.

Not realizing that this individual (who will remain nameless) actually ran an outsourcing firm, I sent him some instructions; the page was presented to me the next morning.

To someone not closely familiar with web technology, it might have looked perfect. You input the password. If it was incorrect, you received a warning and nothing happened. If it was correct, you were redirected to the actual page.

However, there were two major flaws in the implementation that suggested that the requirements — or the reasoning behind them — had not been understood:

1. Use of Javascript

The password verification was implemented entirely in Javascript — I recognized this immediately from the alert box that appeared when an incorrect password was input. The problem with this is that it is entirely client-side: i.e. performed in the user’s browser. A user could simply “view source” for the page to retrieve both the password and the URL of the destination page.

2. The destination page was not password protected

That is, if you visited the URL of the destination page without first going through the password page, there was no validation performed — it could be accessed without a password. This defeated both of the purposes of the password protection: the URL could be shared among users, and if a user were to put a link from another website to the page, it could be picked up by search engines.

I sent the project back to the subcontractor, explaining my disappointment with the use of client-side authentication. He agreed to have the flaws corrected, and it was at this point that I learned that he was outsourcing overseas.

When the “corrected” page was returned to me the next morning, the password authentication had indeed been moved server-side (meaning that a casual user could not retrieve the password or destination URL); but the two-page structure that permitted unauthenticated access to the destination page had not been corrected (the correct behavior would have been to use a “cookie” to create a “session” identifying the user, and to refuse to present the destination page if the session did not indicate that the user had entered the password).

Finally, disappointed, I decided to implement the page myself, and will not charge the client for the time spent by the subcontractor. Lesson learned: be certain in advance whether the subcontractor I’m hiring outsources. I could have saved myself some time and money if I had known this — I might have hired someone else, or at the very least would have been much more specific in my instructions (overseas developers will typically implement whatever takes the least thought to meet the instructions given, so you must give them very explicit instructions.)

The same caveats apply to anyone hiring for web development. If you are considering hiring an outsourcing company rather than an American-based agency or freelancer, be certain that you have someone in house with the technical savvy to both a) communicate very detailed instructions to the outsourcer, and b) evaluate the resulting product for technical flaws and adherence to specifications.

In the end, please consider hiring your friendly neighborhood freelancer, who will make the effort to understand the problem you are trying to solve; will be able to offer suggestions as to alternate and possibly more efficient solutions; and will consider it a point of pride to solve it correctly.

The obvious solution was to code my own module, and here it is: usertrack. You can also check it out from Subversion at http://svn.triopter.com/drupal/usertrack/trunk/usertrack/ .

Usertrack includes simple Views integration for filtering, sorting, and annotating your User view with login status and last logout date. Please read the README for compatibility and installation notes.

But there are several different raster formats. What’s the difference between them?

BMP

Let’s start with BMP, which is the most straightforward format. BMP stands for “bitmap”, and it is literally a list of pixels, with a color specified for each. Although Microsoft Office seems to like them a lot, BMP’s are not especially desirable for designers. They have large file sizes and often low color depth (meaning they can store only a few distinct colors and not subtle gradations of color). They are usually appropriate only for clip art

TIFF

TIFF is a little like BMP with some improvements. A TIFF is also a list of pixels with a color specified for each, but it can handle a lot more colors, so it is appropriate for photos. TIFFs can also have multiple layers (like data for multiple images in a single file) or parts of an image that are transparent; however, not all software recognizes those features, and most TIFFs do not use them.

TIFFs are a preferred format for saving high quality photos, and they can be compressed (the file size reduced) to a certain degree without losing any quality.

They also display graphics without loss in quality, although they are not as flexible as vector images in that the graphic cannot be separated from the background and the size can only be decreased, not increased, without losing quality. If you must send a graphic, such as a logo, in a raster format, a high-resolution TIFF can be a good choice.

However, file sizes are larger than for other formats (other than BMP), and not all browsers can display TIFF files, so while your designer may request a TIFF to work with, he or she likely will use another format for the final product.

JPEG

JPEG is the best-known image format out there today; but it is often abused. JPEGs are a “lossy” compressed format. That means that file sizes are made smaller by discarding some data; the software that displays the image then approximates the data that is missing.

JPEGs are good for photos, and a high quality JPEG can be many times smaller than a TIFF of the same photo at the same size. The trouble with JPEGs is overcompression, which results in what are called “compression artifacts”:

If you look closely at a JPEG on a good monitor, you can see little blips around the edges of things. Those are the compression artifacts. An overcompressed JPEG like the one above will have visible compression artifacts clearly visible even to the untrained eye.

Worse, even a high quality JPEG loses additional data each time you open and re-save it. So a good image that is edited several times may end up with ugly artifacts like in the image below, even if it’s saved at high quality each time (before, then after; compare her teeth):

For photos, a moderate amount of compression is barely visible, but because compression artifacts can make what should be even colors look uneven, JPEG is a very poor choice for graphics like logos (first image is a GIF, second is a JPG):

Nearly all web browsers can display JPEGs, and they have the smallest file sizes for photos, so JPEG is easily the best format for displaying photos on the web, but is not a good format for graphics, and is not quite as good as TIFF for storing photos that are going to be edited. And be careful of how much compression you use!

GIF

GIF is also a “lossy” format, but instead of discarding detail, GIFs discard color information. The fewer colors a GIF has to display, the smaller the file size can be without losing any information. But GIF also has a maximum of 256 colors.

That means that GIFs are great for displaying things like logos, but horrible at displaying photos:

GIF has another feature, transparency, which gives it an advantage over JPEG for certain uses:

GIF is also recognized by nearly every web browser, and is often used for graphics on the web. It is another format that is not usually good for sending images to your designer, but that your designer may produce for the finished product.

PNG

PNG comes in two varieties, 8-bit and 24-bit. The numbers refer to the amount of data stored for each color. An 8-bit PNG can store up to 256 colors and is functionally equivalent to a GIF.

24-bit PNGs are interesting. You can store a photo in a 24-bit PNG, although it will result in a very large file. However, because it does not suffer from compression artifacts, 24-bit PNG is a great format for displaying images that contain both graphics and photos, such as a screenshot of a website (click for full size):

What’s especially interesting about 24-bit PNGs is the potential for partial transparency:

Sadly, older versions of some browsers (particularly Internet Explorer) don’t support partial PNG transparency without messy workarounds that have other drawbacks. Soon, however, PNG may replace GIF as the dominant format for non-photo web graphics.

You’re probably already familiar with JPEG images, but today I’m going to tell you about some of the other formats web designers use (such as GIF, TIFF, PNG, EPS, PSD, AI, PDF, and SVG), and why we use them.

What Are Vector and Raster Images?

Here’s a piece of terminology that a lot of people find confusing. Often I’ll receive an image in a “raster” format and request it in a “vector” format instead.

A raster image is what you’re accustomed to seeing. It is made up of a finite number of colored pixels arranged in a grid. If you try to make a raster image larger, it ends up looking either pixellated or blurry. Here’s an example of a circle in a raster image format. 1) original size; 2) zoomed in so you can see the pixels; 3) quadrupled in size without smoothing; 4) quadrupled in size with smoothing:

(Click to see full size.)

A vector image is actually described by mathematical equations that trace out curves. A vector image can be enlarged to any size and still look good. Here’s an example of a circle in a vector image format. 1) original size; 2) the mathematical points and curves that are used to describe it; 3) quadrupled in size without smoothing; 4) quadrupled in size with smoothing.

(Click to see full size.)

JPEG, GIF, PNG, and TIFF are raster formats, while EPS, SVG, and AI are vector formats (although they can include raster images inside them). PSD is a raster format that sometimes includes vector images inside it. PDFs can contain raster or vector data, or a combination of the two.

Why Vector?

Vector images are usually more flexible both in terms of resizing and in terms of being able to edit them to create new images.

Additionally, vectors can be handier to have because usually it is possible to convert a vector image into a raster image of whatever size is needed; however, it is much more difficult (often impossible) to convert a raster image into a vector image of good quality without losing detail.

This is because if you already know the curves you can easily estimate what shade each pixel should be, but (as you can see in the zoomed-in image above) the pixel data doesn’t do a very precise job of indicating what the curves are.

Vector formats are strongly preferred over raster images for logos, and often for print design: file sizes for rasters with enough pixels to print cleanly at more than a few inches per side are often unwieldy. The exception to this rule is for photos, which are almost never available in vector format.

When your designer requests a vector format, see if you can find a copy of your image in EPS, AI, SVG, or PDF format.

Why Raster?

You may have noticed that the formats you’re most familiar with (JPEG, GIF, TIFF, PDF) are all raster (or optionally-raster) formats.

If vectors are so much more flexible than rasters, why do we ever use rasters? Well, there are a number of reasons. For instance, it’s not really feasible to take a photograph in vector format, because the camera only understands what color light is hitting it where, not the curves that make up the objects in the photo.

In addition, highly detailed images such as photos and hand sketches can usually be stored more efficiently (i.e. with smaller file sizes) in raster format.

Without using plugins such as Flash or Acrobat Reader, web browsers only began supporting the display of some types of vector images (particularly SVG) in the past few years. Some versions of Internet Explorer that are still widely used do not have native support for any vector formats.

Finally, a vector may take more computing power to display than a raster of the same image, especially for complex images or at smaller sizes.

Next: What is the difference between the different raster formats?

NOTE 2: I’ve noticed a lot of traffic to this page for “local edit incoming delete on update” errors, which are not what this article is about (the solution below may or may not work for that — I have no idea). This article is about “local delete, incoming delete on update” errors. Always back up your work before you muck around with something like this, but that goes doubly if you’re going to try to use these instructions for the “local edit” error.

For reason I’m still trying to untangle, I encountered some really terrible conflicts this afternoon with an SVN checkin that didn’t complete properly, leaving me with a few locked directories that wouldn’t respond to “svn cleanup”.

Using these instructions, I was able to get the directories sorted out:

1. Move offending directories out of working copy and to a safe place (e.g. desktop)
2. Run svn cleanup
3. Run svn up

This actually restored the messed-up directories. Some files were reverted and some deleted files restored; once the entire working copy is cleaned up, you can use the backup copies of the directories to copy back in your changes.

But before I could do that, I was left with a half-dozen individual file conflicts with the following messages:

$ svn st
?   C some_file.php
    > local delete, incoming delete upon update
?   C some_other_file.php
    > local delete, incoming delete upon update
... etc.

Thankfully, these were files that I did want to delete, so even without instructions I wasn’t afraid to trial-and-error my way to the following fix:

$ touch some_file.php some_other_file.php
$ svn revert some_file.php some_other_file.php

Once you’ve created the files, SVN can revert them, which leaves them in unversioned status:

$ svn st
?    some_file.php
?    some_other_file.php

And then you can just delete them from the command line or whatever file manager you use.

*Phew*

Once that was done I redid some deletions that had been overwritten by the update that cleaned up the directories, and all was right in the world.

Usual disclaimers, YMMV, etc.

More info about the site.

If you aren’t familiar with the plugin, it duplicates the image management dialogue to permit you to attach images to a post as metadata using a simple graphical interface — instead of having to locate, copy, and paste the URL into a custom field.

The new version allows fields to be accessed properly outside the Wordpress Loop as well as on archive and category pages. It fixes several bugs including broken template tags and some data loss bugs that were related to post revisions, autosaves, and scheduled / future posts. It’s been tested with Wordpress 2.8.6 and will likely still work with earlier versions going back to 2.7.

I’d like to extend a big thank you to everyone who submitted bug reports and fixes for the plugin — I hope you’ll contact me so that I can give you credit (name and URL) in the documentation.