• cufón – fonts for the people A very impressive framework that embeds any font into a website, via javascript and the canvas element. Great cross-browser support.
• mikeash.com: Method Replacement for Fun and Profit Method replacement and method swizzling in Objective-C.
• Core Data Tutorial: How To Use NSFetchedResultsController | Ray Wenderlich
• TwitThis – Use Multiple Twitter Clients on your iPhone Application The class TwitterClientManager loads a list list of supported Twitter clients is loaded from a plist file, which can be extended to support more clients in the future;
  Each Twitter client is represented by an instance of the TwitterClient class;
  The user can choose his preferred Twitter client at any time, and launch the application by a simple touch; the TwitterClientManager class stores the selected value in the user settings.

• Ten logo design tips from the field | Logo Design Love
• 10 astonishing CSS hacks and techniques
• Adaptive CSS-Layouts: New Era In Fluid Layouts? effective techniques to create 100%-functional adaptive CSS-layouts
• WordPress Theme Development Frameworks If you build and develop WordPress themes often, you will probably be fed up of all the repetitive code writing, the constantly checking of your mark-up and all you really want to do is focus on the design and the project-specific features. The answer is a WordPress development framework
• How to Draw Pixel-Perfect iPhone Toolbar Icons Using OmniGraffle

• 49 Decent Virtual Assistant & Personal Outsourcing Resources
• PHP: Display Adobe PSD files on a web page "Any webdesigner know the PSD filetype, which is the Adobe Photoshop format. PSDs have a lot of great features, as such as layers, but they can’t being read by a browser. Unless you use this great PHP class!"
• Iconfinder – Icon Search Made Easy
• Typetester – Compare fonts for the screen
• KNAppGuide KNAppGuide is a Cocoa framework for embedding “guides” into your application, visually inspired by Apple Guide from the System 7 and 8 era

• XSD Schema XML Validator A XSD Schema validator in Java, provides lots of useful information; use it with a schema and an xml instance
• Three20 Three20 is a collection of iPhone UI classes, like a photo viewer, and general utilities, like an HTTP disk cache. Three20 is derived from the Facebook iPhone app, which is one of the most downloaded iPhone apps ever.
• CSS Decorative Gallery …How to decorate your images and photo galleries without editing the source images. The trick is very simple. All you need is an extra <span> tag and apply a background image to create the overlaying effect.
• Comet (programming) – Wikipedia, the free encyclopedia Comet is a neologism to describe a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it
• Cocoa Is My Girlfriend » Cocoa Tutorial: awakeFromNib vs applicationDidFinishLaunching A very good overview of the 'startup' procedure for objects stored in IB nib/xibs.

For example:

This is a PHP framework that uses the common GD library to manipulate images.

It’s main interface is a content filter – give it HTML, containing images, and it will return the same HTML modified so that the images are now the converted versions, according to their ‘class’ attributes, with appropriate width/height attributes, etc. This makes it super easy to work with.

It stands alone, but it is also going to be a WordPress plugin (as you can see on this site, it’s already operational), a Joomla plugin, and I’m considering establishing a web service too, so those who don’t have adequate software on their server can still use it.

It has a plugin-based architecture so anyone can add new ‘themes’ (props to my partner Katherine for that beautiful wooden frame, by the way). I’m going to also implement a simple XML-based plugin schema, and possibly an interface to it, so that it’s easy to do so. I’m planning a ‘community’ style directory site to host contributed styles.

The base frame rendering code is such that it is trivially easy to add a new ‘theme’. It extracts segments from a single frame image, and handles seamless tiling to make the frame the right dimensions, so you don’t even have to worry about overlapping regions.

I will release it soon, after adding a little more content – keep your eyes peeled.

For now, check out the Michaelangelo showcase, which gives an idea of the different styles, and contains an interactive sampler to play with styles (IE users should stop being IE users to view this).

Doing my bit to beautify the web.

• Lifehacker readers: Most Popular Reliable and Affordable Web Hosts Top seven hosts as voted by readers (DreamHost, Blue Host, NearlyFreeSpeech.NET, 1&1, GoDaddy, HostGator and A Small Orange)
• Domainr, the domain name search engine Given a name, suggests a variety of different domain name possibilities, and reports on availability
• Even More Rounded Corners With CSS – Schillmania.com Single-image, PNG-based, fluid rounded corner dialogs with support for borders, alpha transparency throughout, gradients, patterns and whatever else you (or your designer) could want
• 50 Beautiful And User-Friendly Navigation Menus Navigation inspiration
• OCR Terminal OCR Terminal is a free online Optical Character Recognition service that allows you to convert scanned images and PDF's into editable and text searchable documents. It accurately preserves formatting and layout of documents.

Highlights from this interview include: From UIView to OpenGL: the seven different implementations it took to finalize its unique — and Best App Ever award-nominated — UI. From audio-queues to Remote IO: the four different architectural approaches he tried before finalizing audio subsystems. The travails of trying to implement echo cancelation. The business of making a living off of a $10 app

Listen to it here, or subscribe in iTunes (30 min.)

In part 1, I wrote about Loopy’s interface. Part 2 will be more technical, and will cover some challenges encountered during the evolution of Loopy from concept and mockup to working software. Or, more specifically, the stupid things I did along the way.

The Long Path to Audio

Loopy’s audio implementation went through many revisions, as I both gained insight into the workings of the iPhone’s audio subsystem, and chased down performance.

Take One

Audio implementation #1

The audio implementation that Loopy’s first prototype had was based on the common ‘Audio Queue’ services: Each track had an audio queue for playback, and an audio queue for recording. Each queue was just started and stopped as needed.

The problem here was the long delays: Whenever one started a recording queue, for example, there was a half-second-or-so delay before audio started coming in. Obviously, for a music app, this was crazy – you’d lose the first beat!

Take Two

Audio implementation #2

The second attempt involved a single recording audio queue that was always running – when we weren’t recording, we’d just throw away the sound. When a track started recording, the recorded sound from the queue would be pushed into the recording track.

This did away with any startup delays – but the new problem was the time taken to start and stop tracks playing. Again, there was a half-second delay when tracks were started.

Take Three

Audio implementation #3

The third attempt used a single playback queue, to avoid the play/stop delays. When no track was playing, silence would be output; when one or more tracks were playing, their audio would be manually mixed and given to the queue.

This nearly had it, but latency was just too long – if one tapped out a beat, the sound coming out of the speakers would be often half a beat behind, which really messed with one’s head.

Take Four

Audio implementation #4

The final implementation, which turned out fairly well, uses a system that is shrouded in mystery: Remote IO (or IO Remote, or The Great Audio Interface Of Doom depending on where you look)

The Remote IO system gives you near-direct access to the audio equipment, which means you can essentially pick the audio latency you want, at the cost of convenience and sanity.

Learning enough about this system to use it was a long process, and it ended up being a pastie.org snippet, random bits and pieces from a libSDL source code commit notification, and some obscure sample code from Apple that led me in the right direction. The lack of proper documentation here was quite absurd, and not at all helped by the stranglehold that Apple had placed on all development chatter at the time. Thankfully, things are moving in the right direction now. (I even got asked recently to write some documentation for Apple on the Remote IO framework, which was very cool, if mystifying)

Anyway, the new audio engine was fast and responsive, and I breathed a sigh of relief.

Echo Folly

The other aspect of Loopy’s audio worth mentioning was my foray into echo cancellation – the original intention for Loopy was as a ‘performance’ device, able to be used without any necessary bits and pieces – like headphones – plugged in. This, of course, was complicated by the fact that the iPhone’s mic is right next to the speaker.

Consequently I decided to have a go at removing the echo signal from incoming audio.

Echo removal is actually a fairly interesting technology – at least, it is if you’re a geek like me. The general idea is that you have some audio playing, which you remember, and you have some audio recording. The recorded audio, because the speaker is nearby, consists of both the desired signal (singing, etc), plus a version of the audio coming out of the speaker.

Because we remembered what we last put out the speaker, in theory we can then subtract the known audio from the recorded sound, to single out the original desired sound.

As with many such things, it’s a lot more complicated: We have to find the speaker’s sound in the recorded audio before we can subtract it. Even more tricky, it won’t be exactly the same, because it’s distorted by the speaker – the audio will be a different volume, and in the case of the iPhone’s speaker, the bass parts of the audio will be gone, for example. It will also be sampled differently to the original signal.

Testing correlation

Anyway, I gave it a go. Enthusiastic for the challenge, I started an implementation myself, which included a cross-correlation procedure to find the speaker’s audio in the recorded sound, and a routine to perform a subtraction, with a mechanism to ‘tune’ the procedure by determining how much audio was removed, and tuning parameters accordingly.

And, you know, I got close…but not close enough – not enough sound was removed to make it usable. The main issue was the lack of sophistication of my actual signal removal routine. There are algorithms that do a better job out there, but I didn’t have the time to spend researching them all. Maybe another day!

I tried a pre-built solution, built into the great Speex engine, but the requirements of the Speex echo cancellation library were much too great for the poor iPhone, and sound lag was huge.

So, in liu of having echo removal, Loopy now drops the speaker volume whenever it is recording (The U.S. spent $11 million developing a pen that works in space…The Russians used a pencil).

Seven Different Interfaces

The second major challenge was Loopy’s interface – the six rotating platters. The problem was update rate: The display had to appear smooth with all six tracks playing, which means a framerate of at least 20 frames per second, for all six tracks – at least 120 renders per second.

It sounds easy enough, but Loopy’s interface was re-implemented no less than seven times before I got it right. Some notable stages along this journey:

• The first implementation used a sequence of images to draw the rotating ring. The drawing routine (drawInRect for each of the six UIViews) would simply draw each image in turn.

  This turned out to be too slow, and would completely block the interface with more than four tracks playing.

• Next, I tried putting the drawing routines into a thread, and then drawing to an off-screen buffer (actually, drawing into a UIImage). Then the UIView‘s drawing routine would only have to draw a single image, instead of compositing the background with the ring and other elements

  My plan failed, however – at the time, I couldn’t for the life of me figure out how to draw into an image in a thread (from what I remember after I found out, I think one has to use a CGImage, or something, as the entire UIKit framework isn’t thread-safe), and even drawing a single image appeared to be too much to keep the framerate up, anyway.

• I discarded the pre-rendered images, and decided to go with an approach which didn’t require sending images to the iPhone’s video card each frame. Instead, I draw a mask and used that to mask out the ring image, with the mask rotated for each frame.

  Surprisingly, even this technique was too slow, even after trying an implementation that consolidated the drawing for all six tracks into a single thread.

After some consultation with other developers, I realised that even Core Animation just wasn’t cut out to do this kind of rendering (I get the impression that Core Animation, too, creates and uploads image data to the video card for every frame), and threw it all out the window.

I re-implemented the whole thing in OpenGL, with the same ‘masking’ concept (but drawing rotating triangles with texture co-ordinates bound to screen co-ordinates), and got what I needed.

This new implementation was much simpler and easier to maintain – always a good sign that it’s the right one!

Start, Stop, Pad, Truncate

Timing of loop recording was quite tricky to get right – deceptively so.

Right from the start, Loopy’s timing mechanism has been based upon a ‘clock’, which defined a length of time representing a base loop length – in musical terms, a bar.

Tracks could then be multiples of the bar length, or a half, a quarter or an eighth of the bar. They could also be offset by a certain amount of time, meaning that recordings could start any time and would be kept in sync.

The original implementation forced the recording to extend to multiples of the ‘clock’ length:

This meant that if you tapped to stop recording, the track would continue recording anyway, until the next clock tick (or half-tick, etc.), plus offset, was reached. This was the “don’t trust the user” approach, assuming that users wouldn’t keep time properly and would need to be guided.

I tried several variations on this theme, testing different logic, such as if the recording length is more than X time than the clock length, keep recording until the next tick, otherwise stop and delete the last X of the track.

That whole concept was generally a bad idea, though, and resulted in people (including myself, once or twice) thinking the interface wasn’t working properly.

The final implementation stops as soon as directed, which feels much better. It will either pad the rest of the track, so that it is up to multiples of the clock length (or a full quarter/half/etc.):

…or it will truncate if it’s within some threshold of a beat:

Something I realised as I was using it was that it was impossible to record things like anacruses (AKA upbeats), where a riff starts just before a beat. With some experimentation, I decided to replace the straight truncation with a mix-then-truncate approach:

This is how Loopy operates now, and I think it works fairly well.

A Sense of Rhythm

The other timing issue was related to synchronisation and recorder latency – that is, if you record one track, then record another one, you want both recordings to be in time with each other. This was, and still is, tricky.

One has to track the latency for both the ‘play’ path – the time taken for audio in the memory buffer to get pushed out the speaker and heard – and the ‘record’ path – the time taken for sound to be digitised and stored in a buffer.

In Loopy’s current implementation, this latency estimation is a hard-coded number worked out during testing: This number is used to offset the time associated with a recording, so that it stays in sync. And on my iPhone, it works great. However, I hear reports that the timing is off for other users, and so this is still an outstanding issue.

Does this mean that latency varies between devices – manufacturing variations? Or, is it software-based – perhaps if the device is busy doing some other things, like checking email, latency will increase?

Time will tell, I suppose.

The Way Forward

Good software is a constantly-evolving thing, which grows and is guided by its users, and this is certainly the plan for Loopy. I recently wrote a status update on Loopy, which outlines a little of the planned path.

While the original idea for Loopy was very constrained, many users are already seeing a much greater potential, which is exciting and gratifying, and I’m looking forward to taking it in new directions.

At some stage, I would like to write a third article for this series, covering promotion. This will be a while in coming, though, as this is a learning curve I have yet to climb! I will say this: My next experiment will be the creation of a free, “Lite” version of Loopy, which advertises the full version. This seems to have worked ridiculously well for some, so it’s well worth a shot!
For those who made it this far, thanks for reading – I’d love to hear your comments on these articles, and on Loopy itself.

• Lost and Taken Free stock textures for your graphic design and photography projects
• NSCollection Extensions Weird and wonderful extensions to key/value coding ([myRecordCollection valueForKeyPath: @"[collect].{artist like 'Tom Waits'}.<NSUnarchiveFromDataTransformerName>.albumCoverImageData"])
• Free Fonts Generator Make Your Own Handwriting Font
• Grayson’s pluginmanager A series of classes that provides support for a vast number of scripting languages as well as standard Cocoa bundles
• Deezer Listen to full songs online: Good for getting a preview of albums, much better than iTunes' silly 30 second snippets

It’s development was a whirlwind of obsessive coding, near-vertical learning curves, impatience, excitement and occasional burnout and writers block.

I thought I’d share some facts and lessons learned from the process, in a several-part article. For part 1, read on.

Beginnings

After using Freewheeling while I was a Linux user, I missed it quite badly. I made several attempts to get it going under Mac OS X, but failed each time. I could never find anything quite like it, and so I made do without it.

Then, after deciding to jump on the iPhone app development bandwagon, I thought that pursuing this passion would be a good place to start.

This, of course, was entirely wrong – as Daniel Jalkut and Manton Reece said a while ago on their podcast Core Intuition, it’s a very good idea to start small for your first project, and work out the kinks before trying something more adventurous. Loopy was huge and ambitious, and thus risky – the emotional investment alone was significant, and if it was a flop, it would’ve been heartbreaking, aside from a waste of quite a lot of time.

While that’s lesson number one right there, I’m still not entirely sure I could’ve done it differently – I’m the type to get very swept up in an idea.

So, there that is.

Sketching Interfaces

Loopy’s first incarnation

The first version of the interface mockup emerged fairly quickly. The primary goal was a physical-feeling interface, and so naturally it was made up of LEDs and push buttons, inspired by studio equipment. As is the case with all such things, it had to be fairly simple to understand at a glance. What better path to simplicity by following in Apple’s footsteps: One button to do absolutely everything. Thus, loops consisted of just a button – press to start, press to stop.

The interface needed to quickly get across the concept of the loop, which is where the circle of LEDs came from (my laziness made it a circle that filled up, instead of a ‘chase’ sequence. I got over that fairly quickly). We all like audio meters, so they went in, too – mostly as a mechanism to identify which track was making which sounds.

Unfortunately it looked fairly amateurish and busy, so I needed an alternative. I’d recently bought a Logitech diNovo Mini keyboard for our Mac Mini-based entertainment system, and one day it caught my eye.

diNovo Mini Touchpad

The diNovo Mini has a round touch pad, which functions as both a mouse, and a five-way control (arrows and enter). Depending on the mode, it would either light up around the outside in orange, or five symbols on the pad would light up green. It was very stylish, so as all ‘great’ artists do (not that I’m anything resembling an artist), I shamelessly nicked it. Don’t tell anyone.

The ring around the outside became a rotating platter, which conveniently carried many useful connotations for the audio – rotating LPs, in particular. The audio meter was replaced by varying the brightness of the ring, which kept the interface clean – although admittedly at the cost of some of its utility.

And thus, Loopy had its interface:

Control Freak

The tricky thing about this app was all the functionality it needed to offer, while still appearing simple. It wasn’t enough to just offer tracks that one could record, then start and stop, and that’s it. After pouring over Imogen Heap’s performance mentioned at the start of this article, I realised that there was quite a lot going on.

Firstly, she was mixing the looped sound with new audio, as she went. She would sing one part, then immediately sing a harmony, then sing another harmony, adding complexity to the looped sound as she went. That would be just too cumbersome to perform with only a basic recording functionality, so Mix Recording was born.

Towards the end of the performance, something else was happening – she would perform one loop, then immediately sing a harmony to it, before going back to the original tune. At the same time, only the last loop was playing – thus, she was alternating the main phrase with a harmony. Voila, Loop Recording.

The final track function, Merge, came much later. It emerged as a way to free up tracks, while not losing any audio, and was an alternative to adding more track buttons.

Combined with the need to reset a track, suddenly there were four functions a track had to perform: Record, Clear, Mix Record and Loop Record. Combine that with adjustments to the track (mainly volume), and suddenly the necessary control scheme had some serious complexity.

Track Functions

The original prototype implementation involved ‘swipe’ gestures to access the three features other than ‘Record’ (Clear, Mix Record, Loop Record) – one would swipe either left, up, or right to access each feature. This was cumbersome and unreliable: Half the time, one would end up accessing the wrong feature.

A variety of options were thrown around, during a discussion with a close friend and sometime partner in crime, Tim. Most possibilities were based on a radial menu, where one opened the menu, probably by holding down the button, then selected an item that popped up. This appeared to be far more sensible than haphazard swipe gestures.

Rather than radial menus, which involved breaking the physical metaphor of the buttons, and involved some complexity with fitting onscreen, radial ‘selectors’ were chosen instead – lights around the periphery of each button that one selected after holding the button for a moment. This kept the interface uncluttered.

Deciding to stay with the single-button interface was a slightly risky proposition, as it had the potential to alienate users who desired more easily accessible features. In the end, though, this was what I went with. The alternative was to break up tracks into multiple-button interfaces, which immediately cluttered the application, and either reduced the number of tracks that could be simultaneously manipulated, or reduced the size of the controls, making it harder to hit the right button. As I was after something that could be used while performing, for example, this just wasn’t going to work – it would’ve been too cumbersome.

Track Manipulation

The next issue was how to manipulate track volume. This came up after the initial interface plan was devised, once it become obvious that users would want control over track volume, at the least.

One of the options on the table was a landscape-view screen, that included slider controls for each track. One would hold the button down, rotate the device, and the track’s sliders would appear. This option was passed over for now, but is very likely to be revisited to support future track features.

Another option was to hold down the button while rotating the device like a giant volume knob, using the device’s accelerometer to detect the position of the ‘dial’. The sheer awkwardness of this approach made it a bit impractical, although it would’ve been cool.

It was a return to thinking about the original physical metaphor that yielded the final idea – kinda like a DJ pushes a record to speed or slow playback, a ‘swirl’ gesture seemed a reasonable and intuitive way to adjust track parameters like volume.

Tick, Tock

The final interface element, the clock, was almost an afterthought, and remains more-or-less at a prototype stage in the current version of Loopy. The tap-timing feature was one that spontaneously occurred to me during development, and got added in: Being able to pre-define a tempo seemed a useful feature, but not one that was expected to be widely used. As is often the case without performing large-scale user testing, it turns out to be a fairly popular feature. Consequently, future versions of Loopy are going to have a much more sophisticated clock, metronome and tempo management facility.

Interface Lessons

The main lessons which arose from Loopy’s interface design were actually testing and user interaction lessons. Impatience to get the product on the market stopped me from spending a great deal of time on talking to potential users about workflow and interface, but this would have been very useful. This is something I should still do: Find a bunch of musicians, and ask them what they would like to see, and how they work.

One limitation that I encountered along the way was finding an adequately diverse testing community.

Here’s where the iPhone App Store’s limitations were a pain. An increasingly popular trend amongst Mac software developers is to make available a free but time-limited public beta during the final stages of development. Cultured Code did this recently with their app, Things, for example.

Doing this has several big advantages: Firstly, you get free testing and feedback from many users, many more than one could typically get the app in front of during a private beta. Users are engaged with the software, because they are (a) being directly involved in the process, and (b) typically going to end up using the software, so it’s in their best interests to play an active role. Any user interface or workflow choices that users don’t like, you find out about almost immediately, without having to wait and then deal with once customers are paying and have higher expectations (and are leaving ratings!). Secondly, you are immediately building an image, a brand and a community, something that just won’t happen while you’re invisibly developing.

If the iPhone App Store had a facility to provide beta software for free, but with a time limit, and possibly with ratings disabled, this would be a fantastic tool for developers to collaborate with the community to make great software.

Something I needed to do more was to more actively engage beta testers – not everyone can be expected to come up with and communicate insights about software: It’s the developer’s job to start this communication. Short questionnaires and polls would have provided some useful information about the strengths and weaknesses of the interface, and this is the kind of thing I’ll be focusing on more for next time.

Coming up

Seven re-implementations of the user interface, two or three re-implementations of the audio infrastructure, a ridiculous lack of documentation, and timing, timing, timing…

Read on, in Part 2: Implementation.

• Creating libraries for the iPhone Discussion on creating static libraries for the iPhone
• Photoshop Tutorials – Layered HDR Tone Mapping Learn how to tone map with Photoshop CS3 to create beautiful high dynamic range (HDR) photos. The final result is exceedingly better than Photoshop's local adaptation and similar to Photomatix's tone mapping.
• Ajaxload – Ajax loading gif generator Generate loading animation images, given type, background and foreground.
• Free Texture Tuesday | BittBox "Jay over at Bittbox has just announced that he will be giving away five high resolution textures (3,000 x 2,000 pixels) every Tuesday of the year, absolutely free!"
• GeoNames Free service (including webservice) to search for place names, yielding co-ordinates and a feature class.

You’ve just designed the most beautiful template ever – pleasing composition, clean lines, smooth colours and gradients and an awesome typeface. You apply it as the theme for your blog, or release it to the community, and there is much rejoicing.

Then you or someone else inconsiderately puts a photograph into a post – disaster! That nasty square of graphic just destroyed your composition, and the page is unbalanced and suddenly looks terrible.

Images are particularly tricky to make work with a theme, mostly because they’re so unpredictable. With text, it’s easy to control the way it looks. With images, they can be any colour or shape, many of which will break the composition of a theme, especially if the design elements of the theme contains irregular lines.

A big impediment to making images work is the limitations introduced by the current versions of CSS: All you can really do is provide a square border, possibly with some padding. That’s it, unless you’re willing to manually add tons of markup around images every time – and willing to make your users do it, if you’ve released a theme.

Some people will carefully Photoshop-up their images to make them fit – Webdemar (who made the theme I first used on my blog) does this, for example, and it looks great. That’s a lot of work, though, especially if you make frequent posts with images!

If you’re a theme designer, there’s an easier way to make images work.

CSS Borders

There are a thousand and one different ways to create styled borders in CSS. The basic principle is that one adds a certain amount of HTML markup around the content to be framed, and CSS rules apply background images in a variety of ways. The best of these techniques are very flexible, and allow designers to apply any kind of frame they can imagine.

The Joomla documentation describes one of these techniques quite well, and it’s worth a read.

So, providing a frame around images allows designers to break up those straight lines, among other things. Thus, this:

Becomes this:

This is, of course, just one example, but there are many possibilities.

So, the question becomes: How do we provide the necessary HTML markup in the content, without doing it ourselves or making our users do it? Enter regular expressions…

Regex magic

The concept is very simple – whenever we encounter an image in the content, we surround it by the markup necessary to render a frame around it. There are, however, a few extra things that’d be nice:

• Provide the ability to frame any content, not just images, by supplying a class
• Provide the ability to avoid framing some images, to provide some control, by supplying a class
• Manage image sizing, in case a too-large image is provided
• Avoid showing frames if the surrounded image is too small (and would thus look wrong)
• Some styles/classes applied to the inner content should be also applied to the frame (such as float settings)

This PHP script gives an example of how it can be done as part of a WordPress theme: framing-sample.php.zip

The script provides a filter function, used by WordPress during the render pipeline to modify content. The function looks for blocks with a class of ‘frame’, or images. It avoids any block with a class of ‘noframe’ (and also ‘wp-smiley’, which is the class used for those small emoticons in WordPress). It then uses a ‘callback’ helper function to perform the actual replacement, capturing styles/classes for the inner object, and managing image sizes in the process.

A caveat here: The regular expression that supports wrapping any kind of content block (as opposed to just images) uses a relatively modern feature of regular expressions called recursive sub-patterns, which will not work with PHP installations with an older PCRE regular expression library. Hence, the ‘@’ sign preceding the preg_replace_callback, which will cause it to fail silently, without throwing error messages everywhere.

So, this code wraps the content in four ‘span’ objects, which can then be styled using CSS. For small images, it also applies the ‘small’ class, which can be used to provide a smaller frame to avoid visual glitching.

CSS time

So, we now have markup in place, and it’s time to provide some styles. Here’s some sample CSS:

/* Frame */

.frame-outer {
background: url(images/frame-top-left.jpg) no-repeat left top;
padding: 0;
margin: 0;
display: inline-block;
}

.frame-outer span {
background: url(images/frame-bottom-left.jpg) no-repeat left bottom;
margin: 0;
padding: 0;
display: block;
}

.frame-outer span span {
background: url(images/frame-top-right.jpg) no-repeat right top;
display: block;
}

.frame-outer span span span {
background: url(images/frame-bottom-right.jpg) no-repeat right bottom;
padding: 32px;
min-width: 150px;
min-height: 150px;
text-align: center;
overflow: hidden;
display: block;
}

.frame-outer span span span * {
max-width: 425px;
}

.frame-outer.small {
background: url(images/frame-top-left-small.jpg) no-repeat left top;
}

.frame-outer.small span {
background: url(images/frame-bottom-left-small.jpg) no-repeat left bottom;
}

.frame-outer.small span span {
background: url(images/frame-top-right-small.jpg) no-repeat right top;
}

.frame-outer.small span span span {
background: url(images/frame-bottom-right-small.jpg) no-repeat right bottom;
padding: 10px;
min-height: 38px;
min-width: 38px;
}

.frame-outer span span span span {
background: none;
}

Here’s a sample of the images that are used here:

Further possibilities

Providing frames around image is all very well, but what if that’s not enough? Perhaps you have a particular style set up that requires, say, rounded corners, or Aqua-style bubbles, or sepia tones? Maybe something more complicated, as with Webdemar’s page: Rounded corners, a dark border with a light inner-border, a gradient background, then the image itself rotated a bit then cropped.

It just so happens, there’s a whole lot one can do with the PHP ‘GD’ image processing library, if you’re willing to get your hands dirty. Imagemagick’s ‘convert’ utility is fairly capable too. This is outside the scope of this article, but I may return to the topic another time.

So, one possibility is to add an additional function that is called, which extracts the URL of any image, opens and processes the image, saves it to a local cache, and replaces the URL with a URL to the newly created, cached image. This function could do all kinds of nifty operations on the image, with zero work required on the part of the user.