Just a Thought...

Test Strips on Oriental VC FB Paper

I got it stuck in my head that I would print all the negatives that I inherited from my grandparents. These are a treasure trove of years gone by that capture a world we have forgotten about. Along with these negatives comes some inherent problems. The negatives are pretty near 60 years old already, and were made before the film base was standardized on something that doesn’t deteriorate so quickly. The film is either Kodak Plus-X or Kodak Tri-X (they had several rolls of each). None of it is safety-film which means it isn’t. The film format is 127 film. That means it is not quite as big as modern day medium format or as small as 35mm film. The negatives are about 4cm wide with some frames 6cm, some 4cm, and some 3cm. I can’t find proper sleeves, and the film has a nasty curl due to being stored rolled up in a plastic baggy.

Archivists will tell you to make sure you store the film in archivally safe sleeves that are acid-free, buffered, lignin-free, etc. Lignin is found in paper, cardboard, etc. Rubber-bands deteriorate and the byproducts also help break down the negatives. These negatives were stored in a plastic baggy with the original cardboard boxes when available (which is where I got the dates from), or wrapped with rubber bands that were disintegrating. I can’t say it’s archivally safe, but there is no more cardboard or rubber bands anymore. Due to the storage conditions, some of the negatives are damaged, but most are OK for now. I really need to find out how to copy the negatives on to standard film. I’d rather step up a size rather than down, because I don’t want to lose any more information than I have to.

All that said, several of the negatives are in good shape and almost all are printable. The picture at the top of this article is one of those pictures. As you might expect when the person taking the picture (my grandma) is not a professional photographer, many of the negatives present significant challenges. This negative is losing contrast to the shadow detail, so I have to bump it up on the paper. This picture requires a #4 contrast filter to bring out any definition. I may have to go up even more than that, but I think I’ll live with this. The quality going to limit how much I can enlarge the picture. The picture would have been even more striking if grandma thought to reflect a little light up underneath this gentleman. A large sheet of white paper would do the trick nicely. Based on the angle of the highlights and the shadow under this guy, it was probably taken around noon.

In my insanity to grow my darkroom skills, I decided to use fiber based (FB) papers. They are similar to resin coated (RC) paper in the sense that it is paper, and it uses a gelatin based emulsion. Other than that they are completely different. When RC paper gets wet, it doesn’t feel any different. The chemicals only penetrate the emulsion, and thanks to the resin or plastic coating on the paper it does not penetrate the paper. RC papers are therefore much more convenient in that the process is a whole lot quicker. FB papers feel different once they are in the solutions. The paper actually gets wet, and you can feel the fiber of the paper much better. Glossy also looks different. The gloss on a FB print is virtually unnoticeable until the print dries, where on RC paper it is ever before you. It seems that FB paper is more susceptible to dry-down effects. However, FB paper does take toning better than the RC paper cousins.

Bottom line, this will be a good learning process and I will be able to pass on my personal family history to another generation. Part of the process will be making digital copies as well as copies of the negatives.

What would happen if you could integrate a word processor and a compiler? That’s precisely what geoProgrammer from Commodore 64 fame did. The Graphical Environment Operating System (GEOS) team had several tools available out of the box. That included geoWrite and a few other cool apps. Because the GEOS team controlled the file formats for all the tools that were part of the system, they could integrate things a bit better than others. There was no plain text editor in the GEOS system, that wasn’t sexy. That wasn’t graphical. So why bother with it?

You wrote your applications in geoWrite and compiled them with geoAssembler which produced relocatable bytecode. Finally you linked it with geoLinker . The whole suite came with a comprehensive API manual which was quite nice considering that GEOS was all assembly language. The experience taught me that you can have very elegant code even when you are working at the assembly level. However, an interesting side effect of using geoWrite to write the code was that you had fonts and font sizes available. It was actually rewarding to write nice looking comments. In fact, the comments would be more noticeable than the code. It was an unexpected side-effect from using a word processor for writing code.

Another very nice side effect was that if you wanted to embed graphics for buttons and such, all you had to do was paste your graphic into the document with some marker so that you can reference the graphic in your code. Can you imagine if your code would make it that easy to reference a graphic instead of having a large byte field encoded in numbers or relying on the linker to get it right?

Something like this has never been done since, for a number of reasons. First, it used to be that graphical operating systems were simply too expensive. Next, it was that all word processors had their own proprietary formats. Finally, you have the geek chic of only using text editors because that’s what geeks do. You’d be surprised what a little style can do to make the code more readable. One example are the text editors and IDEs that color your code for you. Now that we have an Open Document that most word processors can be extended to use, why not leverage that standard?

It turns out that the answer is that it makes the compiler more complicated. Of course, it’s easy enough to write a bit of code that simply strips out all the style and feeds the compiler/interpreter the plain version of the code. Do I expect something like this in the future? I’m not sure. There has to be a cultural demand for it to happen, and right now we are still stuck in the mainframe and resource starved origins. I think that UTF support in the source code is going to be a sooner cultural demand than WYSIWYG prettifying of code. The future is still unwritten.