The Art of
Gilbert Munger

by Michael D. Schroeder Bio     Email

Title Page
Document Archive Guide
Document Archive
The Picture Catalog
 Locales Depicted ...
  California   Idaho
  Minnesota   Nevada
  New York   Oregon
  Utah   Virginias/DC
  Washington   Wyoming
  Unknown USA
  England   France
  Scotland   Venice
Picture ID# Index
Munger in Museums
Munger in Tweed Museum
2003/4 Exhibition
Wa(h)satch Views
Systematic Geology Prints
Autograph   Palette
Munger in IAP
Auctions sorted by ...
  Painting   Date+$   House
More Artists "Munger"
Site Updates   Site Notes
Color Target

Prev   Home   Next

Construction Notes for

Note: this page is still being written.


This website devoted to Gilbert Munger and his paintings went on-line in September of 1999. It was and still is hosted by the Tweed Museum of Art at the University of Minnesota, Duluth. The Tweed owns the largest collection of Munger pictures. Gilbert Munger's brother Roger was of one of the founders of Duluth and there has always been interest in his artist brother there.

At its inception the website contained 170 pictures. Now it contains over 300. In addition, the amount of reference material has grown considerably, now including an archive of period articles and books about Gilbert Munger totaling more than 60,000 words.

A primary consideration in the website's organization at the tools, code, and files level was ease of maintenance. I decided to use a database primarily to ease the burden of keeping the site up-to-date. My ideas was that just by adding the data associated with a new painting to the database, the necessary site updates could all be generated at the push of a button. This proved naive. In addition, I seriously underestimated the amount of work involved in entering the period research materials, which mostly end up being done by me typing them in from faded copies of old newspaper articles.

Sources of Information

The primary objective for the site is to collect as much information about Munger and his pictures as possible. The sources of information are:

Development Tools Used

Windows 10 w/ big display Development environment
Microsoft OneDrive Cloud storage for the website under development
FreeFileSync Application for mirroring the OneDive folders to a local backup file system
WinSCP Application for synchronizing the development site to the production web server.
Photoshop Application for image preparation
FileMaker Pro Database for recording the descriptions for the individual pictures in the catalog. Used to automatically generate the web page for each picture, the guide pages of thumbnail images for each locale, and the two indexes. Many of these will change when a new picture is added to the catalog.
EditPad Pro Text editor for hand coding all the other html pages in the site.

Writing HTML files from FileMaker Pro

The more than 300 ".html" files describing and indexing the individual pictures in the catalog are generated by FileMaker Pro (FMP) scripts. The database contains a record for each picture in the catalog. The fields of each record describe the picture. An FMP script constructs an ".html" page from the record by concatenating values from record fields and various canned text strings into a single text field using the "InsertText" or "InsertCalculatedResult" script steps. The script then writes this constructed field to a file using the "ExportFieldContents" script step.

All versions of FMP write out text files using UTF-16 character encoding and a carriage return (CR) character for end-of-line (EOL). The Munger website uses UTF-8 encoding and uses CR followed by line feed (CR+LF) for EOL. Before version 16 there was no way to make FMP use a different encoding and EOL convention. The conversion needed to be done on each exported ".html" file with a text editor, an annoying extra step. Starting with version 16 of FMP, a new "Text Encode" function was included. It can be used in a script to convert to a text string to UTF-8 and CR+LF. Here is the script segment that creates the ".html" file for a picture from the constructed text field. The parameter "3" in "TextEncode" means use CR+LF, even though the FMP Reference Manual incorrectly says "4" means CR+LF.

UTF-8 Write ID Page to HTML File

Set Variable [ $filename; Value:"ID"  &  Munger Database::Record ID  &  ".html" ]
Set Field [ Munger Database::PageContainer; TextEncode ( Munger Database::CSSWebPage ; "UTF-8" ; 3) ]
Export Field Contents [ Munger Database::PageContainer; “file:../MungerSite/Pages/$Filename”; Create folders:No ]

A URL Surprise

I started developing this website 20 years ago. It wasn't until early 2019 that I learned URLs on **NIX web servers are case sensitive. Unfortunately, I used a lot of upper case in the folder and file names for this site. That means that when a user types a Munger Site URL into the address bar of a browser, they have to get the case of each letter in the URL correct, or the page will appear to be missing. I suppose that I could fix this with a week of work. There are a lot of Address Tags to fix, plus various scripts that generate web pages in FileMaker. That course also has the disadvantage that all the search results in search engine databases will stop working. It will take a while for the search engines to find the site elements under the new names.

It surprises me that there were not more prominent warning about this issue in 1999, or even today. Fortunately, the website is structured in a way that users almost never need to type in URLs. The developer and the Web Master, however, do need to be careful.

Getting Rid of HTML Frames.

The first edition of this website opened in 1999, several versions of HTML ago. The layout of the website is very simple: the constant menu box appears in column 1; the variable content box appears in column 2. The menu box is fixed into the upper left-hand corner of the browser window and stays put as the content box is scrolled, or the content box loads different pages. For this simple layout, which I still use, HTML Frames were the obvious method to use in 1999. But, HTML Frames turned out to have a lot of difficulties associated with them. presents a good discussion of the issues.

With the introduction of HTML5/CSS, HTML Frames were deprecated, which means that support for them may disappear from web browsers in the future. So, as part of updating the Munger Site to modern HTML5/CSS, I decided to ditch the HTML Frames and use the new features of HTML5/CSS instead. Thus began my saga of many months.

HTML5/CSS has a lot of new functionally, in the form of "styles" and their attributes, that address layout and appearance. HTML Frames are replaced with "div"s (rectangular areas that enclose content) or related structures, and associated "style" code that describes how the "div"s function and relate. When used properly these new features eliminate most (all?) of the problems associated with HTML Frames.

The top level description of this website as presenting a narrow, static menu box on the left and a wider, variable content box to the right of it, sounds simple, but the devil is in the details. Here are some of the second level requirements:

  1. The menu and content boxes are the full height of the browser window and collapse and expand vertically with the browser window.
  2. The the two boxes scroll independently if the browser window is too short.There is never a scroll bar at the edge of the full browser window.
  3. The menu box has a fixed width and the content box has a maximum width (to preserve readability).
  4. The content box can be compressed a certain amount in width by making the browser window narrower.
  5. The content box retains its width when a new page is loaded into it, even if the new page renders naturally in less width.
  6. The boxes have top and bottom padding so there is a margin above and below the displayed material.

The web is full of advice on how to achieve these effects, but most of them leave out one of the required properties or require the use of Java Script, which I didn't want. In many cases the suggested solution just didn't work as advertised. The essential problem is that the various CSS attributes controlling appearance and function of the two box interact in unexpected (and hard to learn about) ways. Here is the CSS style that is finally came up with to achieve these properties:


  border-right:15px solid lightblue;

In this snippet of CSS style declarations "div.sidenav" is the menu box; "div.main" is the content box. Both boxes are given a fixed position ("position:fixed") in the browser window at the upper left corner ("top:0; left:0"). But the menu box ("z-index:1") sits on top of the content box ("z-index:0"). The latter leaves space for the former with a large left padding ("padding-left:230"). For reasons that I do not understand, fixed width material in the two boxes must be prevented from overflowing in the width direction ("overflow-x:hidden") for the vertical scroll bars to appear on the boxes independently and not appear on the browser window edge.

That leaves unsolved issues number 5 and 6 from the list above. I could not find style attributes that addressed these that did not break the solutions to issues 1 through 4.

The solution to 5 that I came up with is to make sure every page to be displayed in the content box contains an in-line element, e.g. a paragraph, that uses the full maximum width (or more) to display. This element can and will wrap if it is too long for the current content box width. It also prevents the content box from narrowing, as it will do, if no contained in-line element needs the box's current width. Fortunately maximum-width in-line elements do not force the content box to widen if it is too narrow.

You would think that top and bottom padding would solve issue number 6. But I could never get bottom padding to work when a long page was scrolled up until the page end appeared. And top padding didn't seem to do anything when the page was scrolled down until the beginning appeared. Ditto for specifying top and bottom margins. My solution was to start and finish each page that appears in the content box with an empty paragraph using "<p></p>" The content box thus displays a little top and bottom pseudo margin when the end or the beginning of the page is in view.

I hope some person who knows more about HTML5/CSS will email me a better solution to these issues. But this one seems to be working! You can see/try all these features on the page you are looking at now.

Getting rid of HTML Tables

The pages of the original version of this website were largely laid out using HTML Tables. With HTML5/CSS, use of Tables for general formatting is advised against. Tables should be used only for naturally tabular presentations (think spreadsheets). It has taken a while, but the HTML Tables are pretty much now gone from this website. Using <div>, <p>, <span> float, text-align, clear, etc, one can obtain the same or better results. A good example is the More Artists "Munger" page. Use 'View Source' in the browser to inspect the HTML.

The hardest conversion was the Document Archive page, which was laid out as a giant Table with dates in the left column and the entry texts in the right column. This wasted horizontal space and required a lot of superfluous HTML tags. I switched to using a "hanging indent" paragraph layout, in which line one that starts with the date for an entry is un-indented. This can be accomplished using negative indention as shown here:


  <div class="period">
    <p class="item">
      <span class="date">1866 Aug 20 -- </span<b>Munger</b> resigns his army commission and
      moves to New York City. ...
    <p class="item">

Check out the result at Document Archive.

More to follow ...

Home   Next
14686     © Michael D. Schroeder;   First edition: 21 October 2018   Latest update: 16 August 2020;