On the beach

The earthworks to the right go down to the water table, the quicksands and possibly the pre-cambrian.

A quiet Sunday afternoon.

I hear the sounds of a secret club, the sea, and endearingly cute lessons in solving word puzzles.
Surely sally is not a sudden violent excursion.
I played the Mickey Mouse game.
We had a nice walk down the beach - gentle wind and plenty sun.

Fast Bowls

Went crown green bowling today with Rebekah, Tim and some guys from church.
Rebekah won her game 10-4.
Toward the end we did fast-bowls. All the players stand in a line and bowl on a ready-steady-go. Do that twice and all the bowls are bowled.
It makes for a quick and exciting game (as if it wasn't quick or exciting enough already).

Exporting to facebook

Most of my not-chat blog style posts will be made to my blog instead of facebook, but I use facebooks RSS-blog tracking to import these posts into facebook notes.

As I already copied many of my facebook posts into my blog I don't want them importing back into facebook, so I consulted http://www.consumingexperience.com/2008/07/blogger-unofficial-feed-faq.html so that I could prevent facebook from importing blog posts from before yesterday.

I'll still be using facebook for chatting (maybe until I get get plus'd)

My Song in the Night

Slightly cheesy video in some parts, but I'll let them off.

Improved PNG and ZIP merging

Following on from my post on displaying a zip as a png, I wanted to do a more robust job, to have the zip file properly enclosed as a non-critical png ancillary stream and to maybe even to have the png included as non-compressed member of the zip archive. ouch!

My main reason for doing this is compatibility reasons as I hear that windows zip-explorer cannot easily open zip files appended to a png.

PNG

Reading the PNG file standard I find that I should probably use the chunk type: ziPS making it a ancillary, private and unsafe to copy if the PNG is changed.

As the zip file must be at the end of the PNG it must be the last data stream in the PNG, however ancillary chunks are not allowed to have ordering restrictions, and IEND should be the last chunk.

Making the chunk unsafe to copy reduces the chances that a png editor could place the chunk in another position, however 14.2 c states A PNG editor is always allowed to copy all unrecognized ancillary chunks if it has only added, deleted, modified, or reordered ancillary chunks. This implies that it is not permissible for ancillary chunks to depend on other ancillary chunks.

Of course we are not attempting to preserve the zip in any major way if the png is edited, only to stop any zip stream being preserved in a way that prevents it being used.

ZIP

The resource for the zip format was wikipedia ZIP_(file_format) where I learn the the final part of the zip central directory is a 2 byte comment length and then a comment.

This tells me that the IEND image trailer could be the last 4 bytes of the comment... but it would mean that the ziPS chunk of the png would not include the entire zip file, as the last 4 bytes of the comment would be external to the zip file.

It means that a zip file which was formally extracted from the png would be incomplete and not recognisable.

I can accept this as the ziPS chunk is not intended to be formally extracted by png-aware software, we only enclose it as a png chunk so that it may be preserved in... er... circumstances where anything after IEND might be removed.

Compatibility

I hear that some zip programs fail to work against zip archives that have been appended to a png. This is an error on the part of such zip programs, which seem to presume that the first item of the zip file is a zip File Entry.

Wikipedia ZIP_(file_format) states:

Often the first thing in a ZIP file is a ZIP entry, which can be identified easily by its signature. But it is not necessarily the case that a ZIP file begins with a ZIP entry, and is not required by the ZIP specification.

We cannot accommodate such demanding ZIP programs, as the ZIP entry signature is:

ZIP local file header

Offset	Bytes	Description[5]
0	4	Local file header signature = 0x04034b50 (read as a little-endian number)
4	2	Version needed to extract (minimum)
6	2	General purpose bit flag

...

and the first eight bytes of a PNG datastream always contain the following (decimal) values:  137 80 78 71 13 10 26 10

Method

The method then seems to be:

1. Modify the zip file, by adding 13 bytes to the zip comment
1. a NULL to sort-of terminate any existing comment to try and hide IEND which we add
2. 12 bytes of IEND
2. Parse the PNG to find IEND
   (Probably the last 12 bytes of the file)
3. replace with the crafted zip file

As this won't solve the compatibility problem, I don't feel inclined to write the necessary code unless it becomes important to stop streams after IEND from being removed by png uploaders, if you know what I mean. (An ancillary stream or critical stream in a png is part of the png. A stream after the IEND is not part of the png).

Fluid google template

I'm using the Picture Window template but wanted a fluid (stretchy) design so that folk with wide screens don't need to see my lines of computer program wrapped in a terribly hard to read fashion.

I was able to find notes on adapting this template with custom CSS.

body {
padding-left: 50px;
padding-right: 50px;
}

html body .content-outer {
max-width: 1600px;
}

which does the trick nicely