History Of This Website

Where It Came From
Where It's Going
& Other Miscellaneous Trivia

Prehistoric Times

My first attempt at creating a website was in the late 1990’s. I was running an engineering consulting business, and being in the tech industry, setting up a website seemed to be the thing to do. The website building tools available at the time were crude, and that site ended up being only about three pages long. It was hosted as a free service on my local ISP. When the ISP stopped hosting these small sites, I didn’t bother to find another host for it, and it died. I lost no sleep over its demise, because in the specialized industry where I worked, I got all my work by word of mouth.

Electron Bunker is born

Then, sometime in 2008 it was suggested that I should set up a website to host a few technical articles I had written. By this time there were much better tools available. Being a Macintosh user, I discovered Apple’s iWeb web publishing software. It was remarkably easy to use. It had a WYSIWYG interface, and I could drag and drop images wherever I wanted them. Working with text was just as easy as working in a word processor. If it hadn’t been that easy to use, I wouldn’t have had the patience to set up this website.

The Rise and Fall of iWeb

iWeb has received some negative comments over the years, because it creates some truly horrendous HTML code that often rendered differently on different browsers. It was also especially unfriendly to search engines. Despite these issues, I have no regrets about using it; it made the site development work so easy. iWeb hasn’t been updated in over a decade, and won’t run on current operating systems. It became more and more of a struggle to use it to maintain the site. iWeb keeps the entire site source code in a single huge file. As time went on, I started to discover some corruption in the published site after making occasional minor edits. For this reason, I have added new pages only reluctantly, and have avoided making any more revisions than absolutely necessary.

iWeb’s Replacement

Over the past several years, I have looked for a replacement for iWeb. A number of products have looked promising, but I have hesitated switching to a new one. Almost all of them use their own proprietary source file format. I didn’t want to get locked in to another web publishing tool that might someday disappear, leaving me with all of my work in an unreadable file. The ideal solution would be an editing tool that works directly on the HTML files. There have been a few of these available over the years, but most of the ones I’d looked at had not been updated in a long time and appeared to have been abandoned.

During the Covid pandemic of 2020-2021, I had a lot of spare time on my hands, and I decided to find out how difficult it would be to recreate the site, writing my own HTML code using a plain text editor. There was definitely a learning curve to this, but once I’d figured out the basics of style sheets, I was able to set up a master style sheet for the entire site in a few days, so that the new theme looked nearly identical to that of the old site. Once I could see how good things looked, I felt confident that I could recreate the site without too much difficulty. With the style sheet complete, the individual pages were surprisingly easy to create. I could copy the content from my old site and paste it into the new pages. The simpler pages could be created in just a few minutes. The pages in the Radio Theory section took considerably longer though, because they contain a large number of mathematical formulae that had been created from LaTeX source code and rendered as bitmapped images. The resolution of these images was adequate at the time, but not good enough now for modern high resolution displays. So, these all had to be redone. It wasn’t difficult, but it was a time consuming process. One of technical theory pages could take a couple of days to complete. I decided to tackle these complex pages first, partly to get the tedious work out of the way before my enthusiasm ran out. It was also a good idea to do these ones first because they were the ones most likely to show up problems with the style sheet.

Details of the Conversion Process

This probably won't be of any interest to most people. However, anyone who finds themself in a situation like mine, trying to convert an old iWeb site may find some useful information here.

HTML Cleanup

I mentioned above that it was a simple matter to recreate my old pages simply by cutting and pasting text from the browser display of the old site or from iWeb's source pages. There was actually an extra step or two in the process.

When cutting material from the browser, any links in the copied text were preserved, but most text formatting was lost. This is due to how iWeb does character level formatting. It doesn't use the standard HTML bold, italic, superscript and subscript tags. Instead it applies its own custom style tags which are next to impossible to decipher. However, when working in iWeb, if you select and copy the source text, the style information is preserved, and when pasted into a word processor the formatting is intact. Unfortunately, any embedded links were lost. So, neither method was perfect. Consequently, the choice of where the material came from depended on whether it had a lot of links, or a lot of character level styling. In many cases, one paragraph would be copied from the iWeb source and the next paragraph would be copied from the browser. In either case, the copied text was pasted into a LibreOffice Writer document. Any corrections that needed to be done to the text formatting was done in LibreOffice. Then it was copied from the LibreOffice document and pasted as HTML into a utility that I wrote in Xojo (a BASIC-like programming language). This utility then stripped out a lot of extraneous tags and did some other minor cleanup. From there, it was then copied/pasted into the HTML document in the plain text editor (Visual Studio Code). That sounds like a very confusing operation, but once I'd established the workflow, it was very quick to copy the original material over, and get it correctly formatted in the new .html file.

Equation Editing

As mentioned above, all of the mathematical formulae were generated from LaTeX source code. For the old site, I used a utility called LaTeXiT that came as part of the Macintosh TexLive distribution. At the time, LaTeXiT's only output formats compatible with iWeb were .png and .jpg bitmap files. Here is what one of them looks like:

Compare this with the following .svg (scalable vector graphics) version.

The difference is readily apparent on a hi-res monitor, and especially noticeable when zoomed greater than 100%. Unfortunately, both are just images, and cannot be edited after they've been generated.

HTML5 has provision for MathML (Math Markup Language) code, and the latest versions of the major browsers can display it, but the quality was originally terrible—almost as bad as MS Word's equation editor. For that reason, I rejected it, and went with .svg images, even though they are not editable after the fact. Here is the same equation as MathML code rendered by your browser:

M=r1r2(1+px2r12)(1+px2r22)02πNdθ1-θ1-θ1+2πNdϕcosϕ+px2r1r2R2+[y2-y1+pϕ]2

What you see displayed above is dependent entirely on which browser you're using and which version it is. It may look better than the .svg image above, or it may look worse. How it looks is out of my hands unfortunately. Several months ago it looked absolutely terrible, rendered in the current (at that time) version of Firefox. As I write this (2023-02-03), the latest Firefox version renders it slightly better than the above .svg image. Unfortunately, this has come too late, because most of my equation reformatting has been completed. For future work, I may reconsider MathML.

There is one further drawback to using MathML. The MathML code, while being plain text, is not human readable in any practical sense, except in the case of nearly trivial expressions such as:
  x = y + z
By contrast, LaTeX expressions are infix code much like those you encounter in programming languages. The LaTeX code used to generate the above .png and .svg equations is:
M=\frac{r_1r_2} {\sqrt{\left(1+\frac{{p_x}^2}{{r_1}^2}\right)\left(1+\frac{{p_x}^2} {{r_2}^2}\right)}}{\displaystyle\int}_{0}^{2\pi N}{d\theta_1} {\displaystyle \int}_{-\theta_1}^{-\theta_1+2\pi N} d\phi \frac{\cos\phi+\frac{ {p_x}^2}{r_1r_2}}{\sqrt{ R^2+[y_2-y_1+p\phi]^2}}
While somewhat opaque, it's not all that bad comsidering the complexity of the equation, and you can get a rough idea what's going on after you've had some exposure to LaTeX code. Most importantly, I was able to generate it manually. Compare this with the MathML code shown below for the same expression:
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>M</mi> <mo>=</mo><mfrac><mrow><msub><mi>r</mi><mn>1</mn></msub><msub><mi>r</mi> <mn>2</mn></msub></mrow><msqrt><mrow><mrow> <mo stretchy="true" form="prefix">(</mo><mrow><mn>1</mn><mo>+</mo> <mfrac><msup><msub><mi>p</mi><mi>x</mi></msub><mn>2</mn></msup> <msup><msub><mi>r</mi><mn>1</mn></msub><mn>2</mn></msup></mfrac></mrow> <mo stretchy="true" form="postfix">)</mo></mrow> <mrow><mo stretchy="true" form="prefix">(</mo><mrow><mn>1</mn> <mo>+</mo><mfrac><msup><msub><mi>p</mi><mi>x</mi></msub><mn>2</mn></msup> <msup><msub><mi>r</mi><mn>2</mn></msub><mn>2</mn></msup></mfrac></mrow> <mo stretchy="true" form="postfix">)</mo></mrow></mrow> </msqrt></mfrac><msubsup><mo>∫</mo><mn>0</mn><mrow><mn>2</mn><mi>π</mi> <mi>N</mi></mrow></msubsup><mrow><mi>d</mi><msub><mi>θ</mi> <mn>1</mn></msub></mrow><msubsup><mo>∫</mo><mrow><mo>-</mo><msub><mi>θ</mi> <mn>1</mn></msub></mrow><mrow><mo>-</mo><msub><mi>θ</mi><mn>1</mn></msub> <mo>+</mo><mn>2</mn><mi>π</mi><mi>N</mi></mrow></msubsup> <mi>d</mi><mi>ϕ</mi><mfrac><mrow><mi>cos</mi><mi>ϕ</mi> <mo>+</mo><mfrac><msub><mi>p</mi><msup><mi>x</mi><mn>2</mn></msup> </msub><mrow><msub><mi>r</mi><mn>1</mn></msub><msub><mi>r</mi><mn>2</mn> </msub></mrow></mfrac></mrow><msqrt><mrow><msup><mi>R</mi><mn>2</mn></msup> <mo>+</mo><mo>[</mo><msub><mi>y</mi><mn>2</mn></msub><mo>-</mo> <msub><mi>y</mi><mn>1</mn></msub><mo>+</mo><mi>p</mi><mi>ϕ</mi> <msup><mo>]</mo><mn>2</mn></msup></mrow></msqrt></mfrac></math>
It's completely indecipherable, and impossible to generate manually. I had to create it by using an online LaTeX to MathML converter with my original LaTeX code as input. Therefore, there are at least two possible points of failure in the use of MathML. First is the quality of the LaTeX to MathML conversion, and second is the quality of the browser's rendering. MathML certainly shows promise, and I may switch to it in the future. However we still need to ask the question of why MathML was ever necessary in the first place? Why didn't the HTML standards committee simply adopt LaTeX which renders beautiful equations, has a well established code base, and has been in use and well tested for decades?

Calculator Pages

I left the calculator pages until much later in the conversion project, expecting a lot of problems with them, since they included a lot of Javascript, forms and iframes. Since this custom code had been well beyond the capabilities of iWeb, it had originally been coded as completely separate pages in raw HTML, and then inserted into the iWeb site using its external "Widget" facility. The problem with this was that the external code was inserted as an iframe, and iWeb was never able to correctly calculate the proper size of the iframe. This meant that some of the material in the iframe would get cut off on some browsers. This caused a tremendous amount of grief, and I was never able to find a fix.

It turned out that these were some of the easiest pages to convert, and I was able to get rid of the iframes that had caused so many problems on the old site. I was also able to condense a lot of repetitive Javascript code into a single file, making the code much easier to maintain.

Summary

As I write this (March 29, 2022), the conversion of the site is approximately 75% complete. It would have been completed by now, except for the fact that I have other interests, and only work on the conversion in sporadic bouts of manic energy, followed by long periods of utter sloth. I took several months away from this project to enjoy summer activities. While most of the web pages have been updated, they have not all been uploaded to the web server. They tend to get uploaded in batches due to some interdependencies between pages. Please refer to the Updates page which always lists any new page uploads. In the future, as the site conversion work gets closer to completion, I may add more comments here.

November 25, 2023 Update:

As mentioned in the previous paragraph, the conversion was about 75% complete in March 2022. It was complete by fall 2022, but due to other priorites, the new site sat on my hard drive for nearly a year before I could get it uploaded on November 24, 2023.

Now that everything is up and running in its new form, I can finally get back to creating and posting some new content without having to worry about whether it will break the site.




Back to:
Home
This page last updated: November 25, 2023
Copyright 2010, 2023 Robert Weaver