Following the writeup of An Idiosyncratic System for Publishing the Traceable Heraldic Art, I put together a few notes laying out some of the kinds of data managed by the current system with an eye towards a possible design for the schema of a future database implementation:

Items

The fundamental unit of the Traceable collection is something we could call an “item,” although that’s super vague and I’d be open to an alternate name.

There are currently around 5,000 items.

Item Types

Most items are charges, but some are field divisions, field treatments, or complex lines.

There are also a small number of items which fall into other categories, such as helms and mantling and compartments and motto scrolls, all of which are generally displayed outside of the escutcheon as part of an achievement or other heraldic display.

The current site also includes a few things that might be harder to squeeze into the same framework, such as escutcheon outlines which show different shield shapes found in period, doodle sheets for use in consultations, and a collection of diapering textures which can be used to apply a texture to a solid fill area to give it more visual interest.

These are only loosely related to the core content of the collection, and if the new system ends up not having a good place for them, that wouldn’t be a big deal and I could make a separate little page somewhere that can just hold these pages.

Throughout or Mobile

Items are either “throughout” or “mobile” or “complex lines”:

• Field divisions and field treatments are always throughout, as are ordinaries and a few other kinds of charges — this means their images are specific to a field shape (like for the device or badge forms, or in rare cases some alternate field shapes) and always appear in a fixed size and position relative to its boundaries.
• Most charge items are mobile — this means they can be made larger or smaller depending on whether they’re a primary or secondary charge, whether there’s just one or multiple, etc.
• Complex lines also can be made larger or smaller, but when they’re made smaller they get more repeats.

Name

Each item has a name. Currently the name takes two forms:

• The original format is written so that the “primary” part of the name comes first (typically this is the name of the charge) with commas to indicate how the name should be rewritten.
• The rewritten format has the words in the order you would expect to find them in a blazon.

When rewriting, anything after the first comma, or between the first and second comma, is moved to the front of the name. For example:

• The name “Hammer, Sledge” would get rewritten to “Sledge Hammer.”
• The name “Hammer, Smith’s” would get rewritten to “Smith’s Hammer.”
• The name “Lucy, Winged” would get rewritten to “Winged Lucy.”
• The name “Lucies, Three, Fretted” would get rewritten to “Three Lucies Fretted.”
• The name “Fleur de Lys, Demi-” would get rewritten to “Demi-Fleur de Lys” with no space after the hyphen.

This system allows items to be listed in alphabetical order by their original name and have all of the hammers grouped together, and all of the lucies grouped together.

Headings

In the current system, the name is used to calculate the headings that an item should be associated with. See “Headings” below for more information.

Descriptions

Items have short chunks of descriptive text attached to them.

In the current system, all of the items that share a primary heading generally start with the same text, which is effectively the description of that heading.

For example all of the items under the heading “Fleam” share this description:

A surgeon’s knife, associated with bloodletting.
Default alignment: blade to chief, curved handle to base. No proper coloration.

Sometimes there is descriptive text that applies only to specific item.

For example, the item “Hungerford Knot” includes a note that it is “​​Also called a Dacre knot.” and this description doesn’t apply to any of the other items on the “Knots” page.

In the current system, the description text also includes information about the source and artist. See “Sources and Artsits” below for more information.

Image Variations and Master SVG Files

Each item has one — or sometimes two, and rarely a few more — master SVG files associated with it.

While most individual items only have one master SVG image associated with them, there are a fair number of cases where there are several images that are heraldically “the same.”

• The primary case of this is for “throughout” items, like field divisions and ordinaries, such as the Bend, which include multiple versions that are adjusted to fit on different field shapes.
• I’ve also piggybacked on this capability for some of the oddball items; for example, the collection of escutcheon outlines usually has two SVG images for each item, one with the tick marks around the edges used to align ordinaries and field divisions, and one without them.

There are currently around 6,000 “master” SVG files averaging around 50 KB each, but the sizes are quite variable — there are a lot that are only 1 or 2 KB, and a few of them are particularly complex, up to nearly 1 MB at the high end.

The master SVG is expected to be in grayscale. (I suppose no harm would be done by allowing people to upload full-color SVGs and then automatically creating grayscale SVGs from them, but I’ve avoided introducing any color charges to date because I think it makes it easier for people to imagine things in whatever color they want if they start out neutral.)

Derivative Image File Formats

For each “master” SVG, we also make additional versions of each file in other formats.

• Grayscale SVG: this is the master file.
• B&W SVG: We make a copy of the SVG converted by black and white by opening the SVG, looking for any hex color codes (#000000 – #FFFFFF), and converting them to either black or white (basically anything brighter than black becomes white).
• Grayscale PNG: The current system generates master PNGs from the source CMS application at the same time as it generates master SVGs, but the next generation of the system could instead use third-party tools to render the SVGs as PNG.
• B&W PNG: This is currently generated from the grayscale PNG using ImageMagick to run a “threshold 50%” operation.
• Outline PNG: This is like the B&W PNG, except all white pixels are converted to transparent.
• Grayscale PDF: The current system generates PDF images from the source CMS application, but I’m not sure how widely used these are — most modern applications that will import a PDF will also import an SVG. If we wanted to include them in a successor system, we could use ImageMagick or a similar third-party tool to generate them from the SVG files.

Tracing Page Files

Although most digital-first folks use the SVG and PNG files discussed above, there’s also a separate set of files that are important to a small but vital set of users — the “traceable” pages.

These are a set of printable PDF pages, one per item, which are used by hand-tracing artists. Each page includes several renditions of a single item:

• For “throughout” items, a full-size illustration of the device and badge shapes. (Example)
• For mobile charges, multiple repetitions (typically 3-12): one at the largest recommended size for a sole primary charge on a device form, and then a chain of smaller copies reduced by around 85% per step. (Example)
• For complex lines, multiple repetitions (typically around 8-10), again with one large one and a chain of progressively smaller copies. (Example)

The largest users of these pages are the “art tent” associated with the Heralds Point at Pennsic and a few other wars and in-person events. By stocking the art tent with a shelf full of three ring binders containing printouts of these pages, the collection’s clip art can be used at a site with limited or no internet access.

The users who rely on this capability aren’t necessarily visible in our online digital-centric discussion groups, and these events have all been cancelled for the last 18 months, but they were the original impetus behind building this collection, and in a normal year account for a significant percentage of the overall armory submissions, so we need to not abandon them when we build the next version of the system.

In the old system, these pages were generated directly from the master page-layout CMS, which allowed me to use some aesthetic judgement about what sizes to show images at and how to fit them onto the page.

However, it should be possible to programmatically generate them from the SVG files and item metadata. I haven’t yet implemented such a system, but I’ve given it a bunch of thought, and I believe that in addition to the SVG itself, we’ll probably also need some additional metadata along the following lines:

• Is this image “throughout” or is it a mobile charge? If it’s throughout, there’s a fairly standard layout used, with the device and badge images side by side. But if it’s a mobile charge, we also need the following pieces of data:
• What’s the largest size it makes sense to show this charge if it is the sole primary charge on a standard device form? Maybe there’s a clever way to automate figuring this out, but I don’t have a clear vision for it yet… possibly as a brute-force, we could render it at a large size, see what is the smallest possible escutcheon we can fit around it without touching any non-empty pixels, and then scale it down to 85% of that space on the standard escutcheon form.
• What’s the aspect ratio (height vs width) of the image? We should be able to extract this from the SVG, assuming that it doesn’t have a lot of superfluous whitespace around the margins.
• What’s the smallest size that it makes sense to show this charge at? We could live without this, but it would be neat if there was some way to record the fact that some charges (like a mullet) are still clear if they’re only a quarter inch tall, while others (like a hand-drawn dragon) are helplessly muddled when they’re drawn that small and there’s no point including them on the printable templates.

Issue Flags

There are a few markers that get applied to some items to indicate potential problems:

• This charge/posture is known to no longer be registrable.
• This charge is valid, but this particular image of it is badly drawn / difficult to identify / a possible cause for return.
• This charge/posture is considered a Step from Core Practice / SFCP / SFPP.
• Potentially problematic / may be subject to additional scrutiny, which is used for charges which are (or might be) considered offensive, or which are popular with problematic political movements and thus might be unregistrable in particular color schemes or combinations — for example if people look up the Fylfot we should show them what that means, but also explain that because it’s related to the swastika it’s not registrable.

In the current system, these show up as pages linked to on the home page alongside the heading “Cautionary Notes,” that list all of the items that currently have those flags set.

Items with these flags should remain in the collection but are visibly marked to caution people about them; currently they include red text in the description and get a red marker superimposed on top of the thumbnail image.

Headings

Headings are things like “Chevron” or “Embattled” or “Lion” or “Rampant.”

Each individual item is assigned to one or several headings — usually just one or two.

In the current system, the categorization is usually done automatically, based on the name of the charge, and a list of various kinds of keywords and patterns in the make.conf file that’s included in the build script download.

• For example, one part of the make.conf is the “Complex Lines” section, which includes entries for “Embattled”, “Dovetailed”, etc. Based on that, the script decides that a charge named “Chevron Embattled” belongs to two headings — “Chevron” and “Embattled”.
• Similarly there’s a “Postures” section in the make.conf file which contains words like “Rampant” and “Statant” that allows the script to decide that a charge named “Lion Rampant” belongs to the headings “Lion” and “Rampant”.
• That approach works for a lot of cases, but there are still a couple hundred cases where I needed to manually specify which headings a particular charge should be attached to.

Rather than the rube-goldberg system that’s currently in place, it might be easier for the new implementation to just collect that information when a new charge is being uploaded (or when a site administrator is coming along to make edits to an existing charge) although it would still be good if the “upload a new image” interface could notice that you’re naming the image “Lion Passant” and suggest that since there are already headings named “Lion” and “Passant” those are probably the two that apply to this new image.

Heading Categories

The headings themselves have an additional bit of data attached to them in that they’re grouped together into categories, which allows us to build the master list on the home page which has all of the complex lines headings grouped together, all of the ordinary headings in another group, the beast headings together, etc.

The categories each have a name, and they’re displayed in a “logical” order — starting with lines and fields, moving through divisions and ordinaries to various kinds of natural charges like plants and beasts, followed by artifacts like tools and buildings.

Volumes

You’ll notice several places in the current system that reference the concept of “volumes.” These are mostly equivalent to “heading categories” — eg, there are volumes for “lines” and “fields” and “divisions” and “ordinaries” and “plants” and “beasts” and “tools” and “buildings.”

Some aspects of the “volume” system are historical artifacts of the current implementation that don’t need to be preserved in the next generation, but I think we will still need some mechanism that assigns each item to one “primary” heading for the purpose of generating the master printable PDFs. For example, the Pennsic Art Tent wants to end up having a giant binder with all “beasts”, that has pages for every lion-related item printed out in one alphabetical section grouped under “L” for “Lion.”

However, they do not want a book of “Postures” with all of the Rampant beasts grouped together under “R.”

Sources and Artists

I started out just writing this information in as plain text for charges that I didn’t draw myself, but then realized it was useful to be able to make pages that show all of the images contributed by a particular artist, or taken from a particular source.

Again, my rube-goldberg approach to this involves writing the sources and artists out as text and then later having the build script parse them out, but it would be much more sensible to accept them as separate pieces of data during the upload/import process.

Most images have a single source and a single artist. And often sources and artists are tightly linked — for example, everything in the sixteenth century “Wappenbuch der Arlberg-Bruderschaft” was drawn by Vigil Raber.

In cases where the item is a new original work contributed to the collection and never published anywhere else, I consider the Traceable Heraldic Art collection to be the “source” (although you could also represent that as there being no source at all). In cases where there’s no artist listed, it’s something I drew — currently this is about 20% of the total — but in the next generation of the system that should probably be explicit rather than just a silent default.

… however, there are a bunch of cases in which things have more than one artist, and a few cases in which things can be associated with more than one source.

For example, the entry for “Hercules Maintaining a Club and a Lion” is credited as follows: “Source: Wappenbuch der Arlberg-Bruderschaft. Artist: Vigil Raber. (Page 24v.) Adapted by Owen Tegg.” That’s a case where Vigil Raber painted something five hundred years ago, and then six months ago a Scadian named Owen created an SVG version of it. I handle that by considering both Vigil Raber and Owen Tegg to be artists for that piece.

Giving people credit for that kind of work is both good form, and encourages people to contribute more, because it gives them a snazzy “work created by this artist” page that shows all of the images they’ve created: http://heraldicart.org/owen-tegg/#items (Nearly all of the items on that page are drawn from various historical sources, but they’re not just scanned in — they’re carefully traced, or vectorized and cleaned up by hand, a process that can take more than an hour per image, so it makes sense to acknowledge that work.)

And there are a few cases where there are more than two artists listed — for example, someone recently download one artist’s drawing of a lion’s head and attached it to a modified version of another artist’s panther and then cleaned up the image so it looked consistent, and I wanted the resulting image to properly credit all three artists who had worked on it.

When images are drawn from historical sources, they might have notes like “(Page 24v.)” or “(From the arms of the Scavino family.)” that let other people find the original drawing without having to flip through a 500-page period armorial.

Source Metadata

The sources also have additional data associated with them, namely some descriptive text, one or more links to view the originals, a time period, and a geographic region. I don’t have all of these values filled in for every source, but I’ve been trying to fill them in where I can as it allows people to understand the setting in which the image was created, and to go find the original graphics.

The description and links show up on the top of the pages generated for each source:
http://heraldicart.org/scheibler-armorial/

And the geographical and chronological data are used to build pages that group related sources so people who want to make arms that are distinctively Polish, or Spanish, or whatever can go look at sources from that context.
http://heraldicart.org/sources-geography.html