articles

geek: adkiller dib2bmp
other: reusable paper

geek

adkiller

You should use some popup window remover as such a method is more general. I personally use the adblock firefox plugin and some css in my userContent.css file.

If you own the website but your host automatically installs ads in your site, you can use an adaptation of one of the following.

For crosswinds.net just insert the following script into the of each html file on your site:

<script language="JavaScript" type="text/javascript">
<!--
w = PrivoxyWindowOpen('', 'jW4Los9wh');
w.close();
// -->
</script>

For sites that popup ads from http://www.popuptraffic.com this will probably also work if you replace 'jW4Los9wh' with 'cool'.

For geocities use the following.

<script type="text/javascript">
// prevents geocities from having access to the document to write ads
window.document = new Object();
// avoids errors
window.onerror = null;
</script>

dib2bmp

How to convert a CF_DIB clipboard to a .bmp file?

Simple - paste into MS Paint & do File -> Save. Read on for the harder way.

Note: all WORDs & DWORDs are little-endian According to the MSDN CF_DIB consists of a BITMAPINFO structure followed by the bits According to the MSDN .bmp files consist of a BITMAPFILEHEADER structure, a BITMAPINFOHEADER structure, a RGBQUAD structure array and a Color-index array The BITMAPINFO structure consists of a BITMAPINFOHEADER structure plus a RGBQUAD structure array so they are almost equivalent .'. We only need to add a BITMAPFILEHEADER structure from the MSDN:

struct BITMAPFILEHEADER{
    WORD bfType; //Specifies the file type. It must be BM.
    DWORD bfSize; //Specifies the size, in bytes, of the bitmap file.
    WORD bfReserved1; //Reserved; must be zero.
    WORD bfReserved2; //Reserved; must be zero.
    DWORD bfOffBits; //Specifies the offset, in bytes, from the BITMAPFILEHEADER structure to the bitmap bits.
}

bfType = 'BM' = 0x4d42 bfSize = sizeof(BITMAPFILEHEADER)+sizeof(CF_DIB)= 14+sizeof(CF_DIB) bfReserved1 = 0x0000 bfReserved2 = 0x0000 bfOffBits = sizeof(BITMAPFILEHEADER)+sizeof(BITMAPINFOHEADER)+sizeof(RGBQUAD array)

this is a bit harder sizeof(BITMAPFILEHEADER) is 14 always for the current structure but sizeof(BITMAPINFOHEADER) can differ depending on the version since BITMAPINFOHEADER can be replaced with newer versions, which are longer, but the size is always specified in the 1st DWORD:

struct BITMAPINFOHEADER{
    DWORD biSize; //Specifies the number of bytes required by the structure.
    ...
struct BITMAPV4HEADER{
    DWORD bV4Size; //Specifies the number of bytes required by the structure. Applications should use this member to determine which bitmap information header structure is being used.
    ...
struct BITMAPV5HEADER{
    DWORD bV5Size; //Specifies the number of bytes required by the structure. Applications should use this member to determine which bitmap information header structure is being used.
    ...

So this means we need to read the first DWORD after the BITMAPFILEHEADER or the dword at offset 14 () and sizeof(RGBQUAD array) differs depending on how many colours are present the BITMAPHEADER:

struct BITMAPINFOHEADER{
    DWORD biSize;
    LONG biWidth;
    LONG biHeight;
    WORD biPlanes;
    WORD biBitCount;
    ...

An extract from the BITMAPINFOHEADER documentation:

biBitCount specifies the number of bits per pixel. The biBitCount member of the BITMAPINFOHEADER structure determines the number of bits that define each pixel and the maximum number of colors in the bitmap. This member must be one of the following values.

1 The bitmap is monochrome, and the bmiColors member contains two entries.
4 The bitmap has a maximum of 16 colors, and the bmiColors member contains up to 16 entries.
8 The bitmap has a maximum of 256 colors, and the bmiColors member contains up to 256 entries.
16 The bitmap has a maximum of 2^16 colors.
24 The bitmap has a maximum of 2^24 colors.
32 The bitmap has a maximum of 2^32 colors.

so the number of RGBQUADs in the array = 2^biBitCount = 2^DWORD:28 and each RGBQUAD is 4 bytes so sizeof(RGBQUAD array) = 4*2^DWORD:28 .'. bfOffBits = 14 + DWORD:14 + 4*2^DWORD:28

To recap:

BITMAPFILEHEADER:insert 14 NIL bytes at the start of the data
bfType:enter "BM" as the first two bytes
bfSize:enter Size as a DWORD at offset 0x2
bfOffBits:enter <14 + DWORD:14 + 4*2^DWORD:28> as a DWORD at offset 0xA
- DWORD:14 is 40 for WinNT3 & Win?.? bitmaps
- DWORD:14 is 108 for WinNT4 & Win95 bitmaps
- DWORD:14 is 124 for WinNT5 (Win2000) & Win98 bitmaps
- DWORD:28 is bits per pixel

If you have MS Paint you can probably get away with entering anything instead of calculating the correct bfOffBits and then using File->Save As to calculate the correct bfOffBits, but that would be pointless since you could have just pasted into MS Paint.

other

reusable paper

It's time to introduce a new paradigm to the world, especially of computing, business and education.

We have fully dynamic energy requiring displays (current monitors).
- We have fully static energy reflecting displays (paper etc.).

Lets mix the two to make semi-dynamic (like some old monitors that only refresh when the image changes) energy reflecting (like paper) displays and produce a reusable equivalent to paper.

Applications for this new product will include for example anywhere that A3/4/5 paper is printed or written on, used for a limited amount of time and then discarded, temporary notes, perhaps newspapers and magazines and others. Official documents (cheques, contracts and others), art and documents on custom sized paper would not be appropriate for this new medium; these would have to remain on paper. This new product would not, therefore, replace paper, but rather reduce its production & consumption considerably. The new material would have to be flexible to allow its reuse multiple times. Eventually I envisage that "books" with pages made of this material could simply be plugged into a computer or other storage device and a whole publication be downloaded into the "book". Of the engineering & production of this product I, being a student of the life sciences, know naught. As such I tend to look to biology for inspiration and the process by which many chameleon and some fish camouflage themselves seems to me to be applicable to this product. Their skins contain small cells, containing pigments, which are spread across the cell during colouration and concentrated in the centre when the cell is not pigmented. How this design could be translated into the inorganic domain eludes me, however. I have been thinking that the devices for transferring the image to the media might use magnetism, electrostatic forces, and or lasers and could be integrated into printers and photocopiers. Also the product could be transparent so as to allow the use of the product in presentations using some form of projector, such as that used in delivering lecture notes to university students. The issue of its recyclability must also be addressed - I feel that its basic precursors should be recoverable from the waste and reused in the manufacture of more of it. Also a method for rejuvenating/repairing old and or damaged samples of the product would be useful and welcomed by consumers. The issue of the changeover from paper printers & photocopiers must also be addressed and it would be desirable that older models could be traded in for new models or a discount on new models and this would also be useful and welcomed by consumers.

I have been thinking about this some more & perhaps if it were possible to produce magnets that could be un/magnetised by electricity and magnetic fields then the "paper" could consist of cells containing magnetic particles that could be attracted to a magnet when the cell is to be un-coloured & released when the cell is to be black. Of course this does not lend itself well to colour "printing".

NB I was originally going to send this to paper, printer & photocopier manufacturers, but chickened out.