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
Munger 2003/4 Exhibition
Munger Wasatch Views
Munger Autograph
Munger Palette
Munger in IAP
Auctions by ...
  Painting   Date   House
More Artists "Munger"
Site Updates
Site Construction Notes
Color Target

Prev   Home   Next

Construction Notes for

Note: this page is still being written.


The Gilbert Muger Catalog Raisonne web site 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 site 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 totalling more than 60,000 words.

A primary consideration in the site's organization at the tools, code, and files level was ease of maintenance. I decided to use a database primaily 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 amout 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.

Development Tools Used

Windows 10 w/ big display Develpment environment
Microsoft OneDrive Cloud storage for the web site 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
FilemakerPlus Database to record the data for the individual works of art. Used to automatically generate the web page for each work, the guide pages of thumbnail images for each section, and the two indexes. Many of these will change when a new work is added to the catalog.
EditPad Pro Text editor for hand coding all the other html pages in the site.

Writing HTML files from FilemakerPlus

I generate many of the HTML files in the site from the database by writing record fields to files with FilemakerPlus. The method is to write FileMaker scripts that construct text strings in record fields or global fields using the "InsertText" or "InsertCalculatedResult" opertions, then write the fields to a file using the "ExportFieldContents" operation.

FilemakerPlus versions earlier than 16, like I use, can only export to files this way using UTF-16 character encoding and using the carriage return character (CR) for end-of-line (EOL). The Munger web site uses UTF-8 encoding and (CR LF) for EOL. I needed a fast way to convert these files everytime they are recreated.

With EditPad Pro (as well as many other text editors) one can record a macro that does both convesions. I record the following commands in the macro:

To bulk convert files, open them all at once in EditPad Pro. Then use Marcos / Organize Macros to repeat the macro as many times as there are files. All will be converted, saved and closed.

A URL Surprise

I started developing this web site 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 web site 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 on 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.

More to follow ...

Prev   Home   Next
18064     © Michael D. Schroeder;   First edition: 21 October 2018   Latest update: 29 March 2019;