The Art of
Gilbert Munger

by Michael D. Schroeder Bio     Email


Home Page
User Guide
Introduction
Document Archive Guide
Document Archive
Sources
Acknowledgments
The Picture Catalog
 Locales Depicted ...
  California   Idaho
  Minnesota   Nevada
  New York   Oregon
  Utah   Virginias/DC
  Washington   Wyoming
  Unknown USA
  England   France
  Scotland   Venice
  Unknown
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 Construction Notes
Color Target
search engine by freefind

Prev   Home   Next

Construction Notes for gilbertmunger.org


Introduction

This website, devoted to Gilbert Munger and his paintings, went on-line in September of 1999. It was 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.

In November 2020 the site moved to its own URL: https://gilbertmunger.org. That URL has existed since 1999, but had been forwarded to the Tweed Museum hosted site. Now the forwarding is reversed.

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 totaling more than 60,000 words.

The Plan

A primary consideration in the website's organization at the tools, code, and files level was ease of maintenance and additions. In 1998 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.

Then the Book

Mike Holding Book In addition to ease of maintenance, another consideration is the long-term availability of the information collected by the website. As long as I am able to provide the maintenance the site will certainly continue. When I am no longer able to do that the website could easily fall in to disrepair or be shut down. To preserve the information contained there in such a case, in the Spring of 2020 I spent several months turning the content of the website into a hardcover, library quality book. The book, The Art of Gilbert Munger, is a snapshot of the website as of February 2020.

A website is not an archival medium. Computer systems change so that outdated programs can no longer be used. Digital media becomes unreadable. A website can survive online only if there is an organization keeping it going by copying it and restructuring it as the technology changes. Experts agree that archival paper copies are the medium of choice for long-term survival of information. Reference libraries are designed to retain archival paper indefinitely. Providing long-term retention is the role that the book version of the Gilbert Munger website is intended to play.

The book contains 527 pages. Twenty copies have been printed and are being distributed to major libraries. So far the following libraries have accepted copies: Tweed Museum of Art, University of Minnesota Duluth; Crocker Art Museum, Sacramento CA; Madison Historical Society, CT; Library of Congress; New York Public Library; Metropolitan Museum of Art, NY; British Library, London; Courtauld Institute of Art, London; National Gallery of Art, Washington DC; Amon Carter Museum of American Art, Fort Worth TX; Harvard Fine Arts Library, Cambridge MA; Chicago Institute of Art, IL. Adding the title to these institutions' catalogs is in progress but will take a while.

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:

Website 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 the other HTML pages in the site.
Visual Studio Code Developer workspace management tool, used for checking the validity of HTML code.

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.

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. So 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, as is explained at many places on the web.

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:


div.container{
  max-width:1010px;
  margin:0 auto;
  height:100%;
  border-right-width:20px;
  border-right-style:solid;
  border-right-color:#add8e6;
  }

div.sidenav{
  height:100%;
  width:160px;
  float:left;
  background-color:#add8e6;
  overflow-x:hidden;
  padding-left:10px;
  padding-right:10px;
  }
  
div.main{
  height:100%;
  max-width:850px;
  background-color:#faefaa;
  overflow-x:hidden;
  padding-left:50px;
  padding-right:50px;
  }
    

In these CSS style declarations "div.container" is the box of the entire site; "div.sidenav" is the menu box; "div.main" is the content box. The container box is centered in the browser window.

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 has 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:

CSS
  div.period{
    padding-left:30px;
  }
  p.item{
    text-indent:-30px;
  }
  span.date{
    font-weight:bold;
  }

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

Check out the result at the Document Archive page.

More to follow ...


Prev   Home   Next
© Michael D. Schroeder; First edition: 21 October 2018; Latest update: 20 December 2020.