Archive for the ‘PHP’ Category.

Google was here

I’ve just discovered that Google has found all the old auto-converted news. Pretty cool!

I still haven’t moved the news from the old PhpWiki system, but I will do so one day. So far I’ve investigate the necessary SQL:

SELECT pagename, version, mtime, content
FROM phpwiki_version JOIN phpwiki_page USING (id)
WHERE pagename LIKE 'HomePage/200_-__-__'
AND pagename >= 'HomePage/2002-08-24'
ORDER BY id, version

That gives me the data I need: the name of the page in the Wiki together with the versions and the modification times and content of those versions. I then “only” have to create a new post in WordPress dated based on the first version, containing the content from the last version. Quite simple actually. There are some corner-cases where I’ve written about some event and back-dated the pagename, but that can be detected by comparing the pagename with the modification time given by the first version.

So that’s the outline — I wont have time to implement it before I go to Switzerland, so you guys will have to wait a couple of weeks before being able to enjoy five consequetive years of blogging!

Parse errors…

While trying to put my PHP tutorial back online I have just spend at least half an hour fighting the markup language! The problem is the lack of tables in [Markdown][].

I wanted a table listing the operators in one column and their meaning in another column — a quite simple talk one would think, and something which I was able to do in PhpWiki with only a minor problem: I could not use || when describing the or operator, since the latter is used in the definition of the table itself.

With Markdown I had to write the table myself. No problem, I’ve written lots of tables by hand! But no, everytime I saved the page the closing table tag somehow disappeared. This messed the page up quite severely.

Next idea: make the table in plain ASCII. It wont be as nice, but it ought to work. But no, even within a code block, where the lines are interpreted literally, I got into trouble. The line with the < ate the following spaces.

These things are what I hate the most with all those PHP content-management systems: they are all so fragile! The parsing done in [Markdown][] is based on regular expressions, and so is the parsing in all other systems I’ve seen. This just doesn’t work reliably — my experience is that you either get strange results like I did, or that you get silly limitations, or you end up with both.

The limitations I’m talking about is when you in PhpWiki cannot apply formatting markup to a link. A quick test to show that it works with Markdown.

I believe that using stronger tools for the parsing would help with these problems — in particular defining a proper grammar and writing a lexer and parser would make things more robust. When people submit a comment with parse errors it would be up to the compiler to flag them as such. It wont be easy to make a compiler with good error-recovery for such a system.

But if it were done, then we would in effect have a system of writing valid [XHTML][] without all the tags — that is a worthy goal! And given such a precise understanding of the structure of the text, one could easily convert it into all sorts of interesting formats such as [LaTeX][] (for later conversion into good-looking PDFs) and ASCII (for inclusion in README files and such).

Looking at the source code for the [GNU][] Flex and Bison tools one sees that they are not exactly trivial to reimplement in PHP — far from it. But I still hope that they will some day either support PHP natively, or that we get another lexer/parser framework for PHP.

Let’s try WordPress

My site has been lying dormant for the last couple of months, ever since NETsite decided to upgrade their server to the latest and greatest version of PHP: version 5.

That unfortunately broke my installation of PhpWiki. I believe that the CVS version of PhpWiki can run on PHP 5, but I haven’t tried. So now I’m giving WordPress a spin. It was mostly after I discovered Markdown which allows me to write in a Wiki-like syntax that I was convinced to try.

Get the Latest and Greatest PEL now!

Everybodys favorite (well… at least it’s my favorite) EXIF editing library — PEL, the PHP EXIF Library — just got better! Version 0.7 has been released. –Martin Geisler


Running PEL under PHP version 5.0.2 would produce incorrect EXIF data, this was fixed so that PEL works correctly on all versions of PHP 5. PEL now runs on installations without support for Gettext, but does so with English texts only. A new example script was added, showing how one can mass-rename images based on their timestamps using PEL. The Danish translation was updated slightly. The collection of test images has been split out as a separate download, cutting down on the size of a PEL download.


  • The image tests are now split into their own, separate download.

  • Added a test image from a Canon PowerShot S60.

  • Fixed a bug caused by a change in the way PHP 5.0.2 handles integers larger than 231-1. This change means that one can no longer use PelConvert::longToBytes() to convert both signed and unsigned bytes, one must now use sLongToBytes() for signed longs and longToBytes() for unsigned bytes.

  • Added a work-around, so the PEL will run (with English texts only) on installations without support for Gettext.

  • Added test/rename.php which shows how one can easily rename images based on their EXIF timestamps.

  • Updated the Danish translation.

  • Removed trailing newlines at the end of Pel.php and ~PelConvert.php.

Download PEL (279 KiB) (453 KiB) (608 KiB)

Download Image Tests (optional) (986 KiB) (991 KiB) (998 KiB)

View the full ChangeLog online

Go grab PEL version 0.6

The PHP EXIF Library (PEL) is written in pure PHP and makes it easy to read and write EXIF headers found in JPEG and TIFF images.

Before going to Switzerland I just found time to prepare a new release. Go grab it, and also remember to upgrade to PHP 5, which is now, finally, out as a stable version. Use as your source of PHP 5 debs for Debian. –Martin Geisler


The interface for PelJpeg and PelTiff was changed so that one now can add new content from scratch to JPEG and TIFF images. Bugs in the loading of signed bytes and shorts were fixed, aswell as a bug where timestamps were saved in UTC time, but loaded in local time. The code that turned PelJpeg objects into bytes was fixed, and new test cases were written to test the writing and reading of PelJpeg objects to and from files. New images from Nikon models E950, E5000, and Coolscan IV have been added to the test suite, bringing the total number of tests up to more than 1000.


  • The timestamps were saved as UTC time in PelEntryTime, but loaded as local time in PelEntry. This lead to differences when one tried to load a previously saved timestamp.

  • Changed the constructors in PelJpeg, PelExif, PelTiff, and PelIfd so that one can now make new objects without filling them with data immediatly. This makes it possible to add, say, a new APP1 section with EXIF to a JPEG image lacking such information.

  • Fixed loading of signed bytes and shorts in PelConvert.

  • Renamed the isValidMarker() method into just isValid() in PelJpegMarker, so that it matches the other isValid() methods found in PelJpeg and PelTiff.

  • Added test images from Nikon models E950, E5000 and the film scanner Coolscan IV ED, and added tests that would read their contents.

  • The shell scripts could only be run from the test directory because of the use of relative paths in the require_once() statements. The scripts can now be run from any directory.

  • A stupid bug that prevented PelJpeg objects from being turned into bytes was fixed.

  • Fixed the output of PelEntryRationals::getText().

Download PEL

PEL is hosted on SourceForge: (1118 KiB) (1273 KiB) (1438 KiB)