Download Summary - Leeds VLE

Summary
The designs of heraldic coats of arms are constructed according to a defined structure and rules. The
aim of the project was to develop a software system that will, given formal specifications of heraldic
designs, produce appropriate visual representations in accordance with such rules.
Research was undertaken into the rules and structures of heraldic designs, existing methods for the
specification of heraldic designs and existing software systems for the generation of visual
representations of heraldic designs.
A formal language for the specification of simple heraldic designs was developed and a software
system named CoatCompiler was designed and developed that produces image files as output when
given a specification written in the formal language as input. The system was implemented using the
Java platform programming language and environment, the finished system was evaluated and
suggestions are made about possible areas for future expansion of the system.
i
Acknowledgements
I would like to thank the following people for their contributions:
●
John Stell for his advice and support at every stage in the project.
●
Martyn Clark for his helpful suggestions at the progress meeting and in the mid project report.
●
My good friend Seb for putting up with me frequently spoiling a quiet pint by talking about
heraldry in the pub.
●
My friends Antti, Chris, John, Keijo, Mark, Mattias and Timo for distracting me with computer
games at every possible opportunity.
●
Yoko Kanno for producing outstanding and unique music which helped me through writing this
report.
ii
Contents
1
Project introduction 1
1.1
Problem definition ............................................................................................................. 1
1.2
Project aims ...................................................................................................................... . 1
1.3
Project objectives .............................................................................................................. 1
1.4
Requirements ..................................................................................................................... 2
1.4.1 Minimum requirements for the project ................................................................... 2
1.4.2 Possible extensions to the minimum requirements ................................................ 2
2
1.5
Project deliverables ........................................................................................................... 2
1.6
Project schedule ................................................................................................................ 3
Background research 4
2.1
An overview of heraldry ................................................................................................... 4
2.2
Previous approaches to adapting blazonry for computer processing ............................... 5
2.3
Existing systems for drawing coats of arms from blazons ............................................... 6
2.3.1 Blazon95 ................................................................................................................. 6
2.3.2 Blazons! 2000 ......................................................................................................... 7
2.3.3 JEmblazoner ............................................................................................................ 8
3
Formal language for coats of arms 9
3.1
Historical blazonry .......................................................................................................... .. 9
3.2
Work upon a formal language based upon blazonry ...................................................... 11
3.2.1 The initial attempt ................................................................................................. 11
3.2.2 The second attempt ............................................................................................... 11
3.3
Simplified formal language specification in detail ......................................................... 12
3.3.1 A note on the meaning of the colon ...................................................................... 15
4
Design and implementation of CoatCompiler 4.1
15
Java ........................................................................................................................... ....... 15
4.1.1 Choosing to use Java ............................................................................................. 15
4.1.2 Java platform ......................................................................................................... 16
4.1.3 Java API .......................................................................................................... ...... 16
4.1.4 Java2D API ........................................................................................................... 17
4.1.5 Batik SVG Toolkit ................................................................................................ 18
iii
4.2
The initial attempt ........................................................................................................... 19
4.3
The second attempt ......................................................................................................... 20
4.3.1 Design ................................................................................................................... 20
4.3.2 Implementation ..................................................................................................... 24
5
Project evaluation 5.1
26
Criteria for evaluation ..................................................................................................... 26
5.1.1 Does the system produce accurate output for the language supported? ............... 26
5.1.2 Does the system produce high quality output visual representations? ................. 27
5.1.3 Is the system superior to pre­existing solutions? .................................................. 28
5.1.4 Is the design of the system amenable to further development / expansion? ........ 28
6
Extension of the project 29
Bibliography 31
Appendix A: Personal reflection 34
Appendix B: Formalised blazonry specification 35
Appendix C: Simplified formal language specification 38
iv
1
Project introduction
1.1 Problem definition
There exist a number of software systems which can generate a visual representation of a coat of
arms when given some form of description of the coat of arms as input. However as will be
discussed in section 2 these existing systems are either flawed or are unavailable.
Therefore there is opportunity to improve upon these systems' shortcomings and produce a new
software system for the generation of heraldic designs.
1.2 Project aims
The aim of the project is to develop a software system that, given formal specifications of heraldic
designs, will produce appropriate visual representations in accordance with the rules governing
heraldic designs and their structure.
1.3 Project objectives
●
Research heraldic design rules
●
Research existing systems for the specification of heraldic designs
●
Research existing systems for the generation of heraldic design visual representations
●
Specify a formal language for describing simple heraldic designs
●
Design a software system to generate visual representations of heraldic designs
●
Implement the software system
●
Evaluate the produced language and software system
1
1.4 Requirements
1.4.1 Minimum requirements for the project
●
●
A formal language supporting heraldic designs composed of:
•
field divisions
•
ordinaries
•
charges
•
A simple (colour, metal) tincture specified for each design element
A command line application taking as input a file containing a description written in the
language and producing as output an image file
●
The application should support the design elements supported by the formal language
●
Output image should be of high quality and saved in a standard raster image file format
1.4.2 Possible extensions to the minimum requirements
●
Support for additional raster image file formats
●
Support for vector image file formats
●
Allow user to specify output image dimensions
●
Allow user to specify black and white image, using Petra Sancta system (Friar, 2004)
●
Support complex fur tincture patterns
●
Support for extending the system by adding support for extra charge types at runtime
●
Support for the loading of external image files at runtime which contain the data to draw
for charge types added at runtime
●
Support in language and application for specification of position and orientation of
charges
1.5 Project deliverables
●
Project report
●
Formal language specification, included in the project report
●
Completed software system
2
05
/0
5/
20
05
Final report
06
22
/0
4/
20
00
5
/0
4/
2
05
08
/0
3/
20
05
25
/0
3/
20
05
11
/0
2/
20
05
25
/0
2/
20
05
11
/0
1/
20
00
5
28
14
/0
1/
2
00
4
/1
2/
2
04
31
/1
2/
20
04
17
/1
2/
20
00
4
03
19
/1
1/
2
00
4
/1
1/
2
05
22
/1
0/
2
00
4
1.6 Project schedule
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Figure 1: Initial project schedule
The task numbers on figure 1 correspond to the project objectives from section 1.3, repeated below
with their numbers for convenience, with an additional task:
1. Research heraldic design rules
2. Research existing systems for the specification of heraldic designs
3. Research existing systems for the generation of heraldic design visual representations
4. Specify a formal language for describing simple heraldic designs
5. Design a software system to generate visual representations of heraldic designs
6. Implement the software system
7. Evaluate the produced language and software system
8. Production of the project report
3
Initially this schedule held and tasks 1, 2 and 3 were completed in accordance with it. However, as
discussed later in section 3.2.1 problems occurred during task 4 which resulted in considerable loss
of time and pushed back serious work on tasks 5 and 6. Consequently work in tasks 5 and 6 became
intermingled and not strictly delineated as was originally intended.
Overall the initial schedule chart was reasonably accurate, with the major change being that task 5
slid back approximately 2 weeks and task 6 become loaded towards the end rather than evenly
progressing throughout the duration of the task. Task 7 did not take as long as anticipated,
thankfully, which relieved the time pressure a little.
2
Background research
2.1 An overview of heraldry
On the field of battle it was necessary for a knight to be able to easily distinguish his allies from his
enemies. With the advent of fully enclosed armoured helmets which covered the wearer's entire face
there began the custom of marking a knight's shield and surcoat (Levin, 2005) with distinctive
brightly coloured designs to aid in identification. These designs became known as coats of arms.
Initially this occurred on an ad­hoc basis with a knight choosing a design for his coat of arms freely,
perhaps based on personal taste or an existing family motif. However as the practice became more
widespread it was realised that measures had to be taken to avoid clashes of design and hence
potential misidentification on the battlefield – and later socially as the role of heraldry grew beyond
the battlefield. Thus a system of written descriptions was adopted to allow coats of arms to be
accurately defined and recorded. A blazon is such a description; to draw a coat of arms from its
blazon is to emblazon it (Rosebush, 1995).
Blazons have a well defined vocabulary and grammar, structured such that a properly written blazon
constitutes enough information for the accurate reproduction of a coat of arms by an artist (Miller,
1998). It is important to note that a blazon is not an absolutely exact description (it does not define
the precise sizes of the various elements for example) – it is expected that the artist knows the rules
and conventions of heraldry, and a certain amount of artistic interpretation is acceptable as long as
the finished coat of arms is clearly identifiable (Wikipedia, 2005a).
4
2.2 Previous approaches to adapting blazonry for computer processing
Thiele describes one approach to making the language of blazonry more suitable for computer
processing, in creating what is described as “a generalised algorithm to describe trademarks, logos,
and other types of graphic designs” (in addition to coats of arms) (Thiele, 1990).
Thiele then goes on to discuss how his algorithm could be applied to assist the comparison of logo
and trademark designs to determine how alike they are and so, for example, given a suitably
comprehensive database of existing trademarked logos, avoid infringing on an existing mark.
This however seems to be the primary focus of Thiele's algorithm and although it successfully
applies the principles of blazonry to the description of logos, it doesn't provide for descriptions of
sufficient detail for one to faithfully reproduce them given a description created using the algorithm.
For example the Coca­Cola logo is given as an example, with the text described simply as script
“Coca­Cola” ­ which, whilst not an inaccurate description, does not exactly describe the very
stylised script the Coca­Cola logo uses.
As previously mentioned such slight ambiguities are not of great importance when it comes to coats
of arms, as firstly they are composed from well defined component elements, and secondly a certain
amount of artistic interpretation of the blazon was expected. But in the domain of trademarks and
logos such ambiguity would be extremely undesirable and as such Thiele's descriptive algorithm is
unsuited to the reproduction of such imagery. Additionally from the point of view of this project the algorithm is not sufficiently focused on
heraldry and coats of arms. As Thiele comments, in the examples given the algorithm seems
awkward compared to the equivalent blazon. Indeed a system using the algorithm for the input of
blazons would still need to recognise a wide range of heraldic vocabulary. However his point that it
is intended for “mechanical processing and the blazon is not” is valid, and certain elements such as
the structure in respect to coats of arms that include other coats of arms (many are composites of two
or more) may prove useful in the project.
Another alternative to blazon is to be found in a web based system by Stoyan (2005) which seems to
use descriptions composed of numbers as input. It appears to be a personal project and unfortunately
as such is not well documented (at least not in English – much of the the system interface is written
5
in German). Thus it was not possible to gain an understanding of the system used and hence gauge
its merit with respect to this project.
2.3 Existing systems for drawing coats of arms from blazons
2.3.1 Blazon95
Blazon95 is a freeware (free for educational and non­commercial use) program for the Windows 95
platform. The purpose of the program is to allow the user to create a coat of arms in a drag and drop
manner, dragging design elements from a pallete onto a representation of a shield. Once in place the
user can alter properties of the elements such as their colour or the shape of dividing lines.
The program can produce the blazon from the user's design but there is no capability for the user to
input a blazon. The blazons that it produces are not always accurate and positioning and sizing of the
elements is not consistent with authentic heraldry.
Figure 2: The arms of Steer from the Blazons! 2000 database, reproduced using Blazon95.
Blazon95 uses vector graphics (albeit of low quality in terms of the complexity of the shapes of the
elements) and so the output image scales without loss of quality. However no function to save the
image to a standard file format is provided other than to transfer data to another application via the
Windows clipboard. The application to be transferred to must support one of the data formats
Blazon95 uses in order for transfer to be possible.
At the time of writing Blazon95 is available from the author's website at:
http://petebarrett.members.beeb.net/blazon.htm
6
2.3.2 Blazons! 2000
Blazons! 2000 is a shareware program for the Windows 95/98 platform. Its primary function is to
generate an image of a coat of arms, given a blazon as input. In addition to this Blazons! 2000 also
provides access to a database of approximately 1400 blazons and their associated surnames. Other
notable features include a menu driven blazon designer function and a rudimentary image editor for
editing the image files used in the emblazoning process.
Blazons! 2000 succeeds in emblazoning many simple blazons correctly but the user encounters
problems when the blazon entered is more complex. For example a blazon telling the program to
draw 3 lions in a column down the vertical centreline of the shield results in a correctly drawn shield,
but if the user specifies 3 charges of different types (lions in different poses for example) then they
will be drawn in the centre of the field overlaying one another – unless the user explicitly specifies
their positions. Also, the emblazoned shield is not always drawn in the most aesthetically pleasing
manner possible, with charges partially overlain or extending off of the edges of the field. As
Blazons! 2000 builds the coat of arms from bitmap images aliasing artefacts are evident, particularly
when an element is scaled from the original image size.
For an example of an image created by Blazons! 2000 see Figure 3, but note that Figure 3 was
subjected to some post processing to improve its appearance (specifically the softening of aliasing
artefacts, the addition of a shadow and the addition of shading to the lion shapes) and as such is not
strictly representative of the quality of images produced Blazons! 2000.
According to the documentation Blazons! 2000 does provide a means for the user to adjust the sizing
and position of charges once emblazoned, but due to apparent compatibility issues between Blazons!
2000 and the version of the Windows operating system used (Windows XP Professional) it was not
possible to test this functionality during evaluation. These compatibility issues, in combination with
a requirement to run the software at a particular screen resolution and with particular Windows font
settings means that there were frequent issues with display errors rendering some aspects of the
software unusable, and in other cases greatly inconveniencing the user.
Overall it was possible to identify various areas where this project can improve on Blazons! 2000;
The quality of the rendered image of a coat of arms, a cross platform user interface free of unusual
system configuration requirements, and correct positioning of charges upon the field.
7
At the time of writing Blazons! 2000 is available from:
http://www.blazons.com/
2.3.3 JEmblazoner
JEmblazoner is a “Java­based user interface for Content­based Image Retrieval (CBIR) in databases
of coats of arms images” described by Breiteneder et al. (2002). The paper describes how
JEmblazoner allows the user to input the blazon of a coat of arms and then emblazons it to produce
an image, which may then further be used as an input into a database to search for similar coats of
arms. In comparison to Blazon95 and Blazons! 2000, JEmblazoner's user interface and capabilities
(as documented) are rather simpler, focusing on a specific task. The user is presented with a text box
for blazon entry, a small number of options affecting the output image (colour or black and white,
antialiasing on or off) and a button to press to emblazon the coat of arms. There is neither the facility
to design a new coat of arms, nor the ability to edit the image once it is created beyond editing the
blazon and emblazoning it again.
Another described advantage that JEmblazoner has over Blazons! 2000 is that when no explicit
position is given for charges they will be drawn in the established “default” positions as was the case
with real blazons and their artistic representations.
The paper describes high level details of the design of JEmblazoner, with a partial UML class
diagram and a UML sequence diagram in addition to a written overview. It is mentioned that
JEmblazoner uses the Java2D API and specifically the Graphic Layers Framework package in order
to manage layers of graphical elements.
At the time of writing the JEmblazoner software was not available. Accordingly it was not possible
to test it by inputting real blazons to determine its limitations and advantages compared to Blazon95
and Blazons! 2000.
8
3
Formal language for coats of arms
3.1 Historical blazonry
As was mentioned in section 2.1 the historical description of a coat of arms is known as its blazon.
The language in which blazons are written is known as blazonry. Blazonry is a standardised
language with a strict grammar and its own vocabulary (Breiteneder et al., 2002), with a blazon
structured as follows (the following bullet points and 2 paragraphs are paraphrased from Miller
(1988)):
●
The field (shield background) is described first, then
●
The primary charges (objects such as geometric shapes, or animals), if any, then
●
Secondary charges around the primary charge if any, then
●
Tertiary charges located upon the primary or secondary charges, if any, then
●
Peripheral secondary charges, if any, then
●
Tertiary charges located upon the peripheral secondary charges, if any, then
●
Marks of cadency and augmentations (additions to the coat to indicate ancestry or
honourable acts)
Each part of the blazon also follows a standard structure. The structure of the description of the field
consists of the tincture (colour or pattern) of the field, or in the case of a divided field the type of
division is described followed by the type of dividing line(s) if other than straight finishing with the
tinctures in (from the viewer's point of view) left to right, top to bottom order.
The structure of the description of a charge or group of charges is as follows. Firstly the number of
charges in the group, or “a” where there is only one. Secondly the type of the charges, all charges in
the group being of the same type (in the case of certain simple geometric charges a line type may be
specified). Thirdly any specific attributes of the charges are described, such as what pose lions are
in, or in what way are swords oriented (not all charges have such attributes, and different charges
have different optional attributes). Fourthly comes the tincture of the charges, which may be omitted
if it is the same as that of the most recently described group of charges. Lastly comes the location
and/or arrangement of the charges on the shield which may be omitted in many cases as there are
traditional “default” positions and arrangements for variously sized groups of charges. Miller (1988)
notes that the location and arrangement part may occur earlier in the description of the charges if it
9
aids the clarity of the blazon.
Marks of cadency and augmentations take the forms of additional charges that may follow additional
rules regarding their selection (for example the addition of a 5 pointed star to the top of a coat of
arms indicating a third son) but are blazoned in the same way as other charges described above
(Friar, 2004).
Figure 3: The arms of Steere, from the Blazons! 2000 database.
For example, the blazon for Figure 3 is:
“Per pale sable and gules three lions passant argent.”
The blazon is structured as follows:
“Per pale”
Divide the field into halves, vertically...
“sable and gules,”
the left half black, the right half red.
“three lions”
Draw upon the field three lions...
“passant”
walking with their front right leg raised...
“argent.”
coloured silver.
10
3.2 Work upon a formal language based upon blazonry
3.2.1 The initial attempt
Given that blazonry follows such well defined structures and has a specialised (and limited
vocabulary) the first approach taken in this project to the development of a formal language for
heraldic designs was to formalise blazonry and derive a context free grammar defining a language
with minimal differences from historical blazonry.
A draft of such a grammar was produced and revised until it seemed to support all of the main
features of blazonry (but not certain advanced features such as marshalling of arms, which is the
process of combining two or more coats of arms to form a new coat of arms and which was used to
represent marriages and other alliances). The grammar had become quite complicated (see Appendix
B) and even after many revisions errors, omissions and unsupported blazonry features were still
being found. As a consequence of this and fundamental changes in the software system design
(discussed in section 4.3.1) it was decided that this grammar was unsuitable for use in the project and
work began on a simpler grammar.
3.2.2 The second attempt
The first decision taken was that the simpler grammar would retain much of the vocabulary of
blazonry as the alternative would be to replace the blazonry terms for tinctures, field division types
and various charge types with alternative terms (or symbols perhaps) for the same things. Doing so
could (given suitable choices of words or symbols) make the resulting language marginally easier to
learn for those with no knowledge of blazonry but would most likely serve as a barrier to use for
people who are at all familiar with blazonry – the most likely users of a software system using the
language.
The second decision taken was to limit the language to the heraldic design features anticipated of the
software system and to expand the language later if required rather than the initial approach of
producing a language that supports everything and then choosing what to support in the software
system. It was therefore recognised that care should be taken to avoid creating a language that would
present difficulties if it was, in future, to be extended to include additional features.
11
The specific feature set chosen was:
●
Standard heraldic tinctures (colours, metals, furs)
●
Single tincture fields, simple (2 and 3 way) field divisions
●
A subset of heraldic charges including standard ordinaries (a specific class of charges of
geometric design) to be drawn on the field
A language supporting this such a feature set could support simple heraldic designs consisting of
charges over a plain or divided field. More complicated designs could potentially be accommodated
by the extension of the language to allow features such as the explicit positioning of charges.
3.3 Simplified formal language specification in detail
The following is an discussion of the grammar for a simplified blazonry like language supporting the
feature set discussed in section 3.2.2. For the grammar without explanatory text see Appendix C.
The grammar is presented in an extended Backus­Naur form (Wikipedia, 2005f) with the following
notational conventions:
Curly brackets – { and } – surrounding something indicate that the contents are optional; either all
are present or none are present. Parenthesis – ( and ) – surrounding something indicate grouping.
For example “a” ( “b” | “c” ) { “d” “e” } means “a” followed by either “b” or “c”
which is optionally followed by both “d” and “e”.
<Blazon> ::== <field> { “:” <charges> } ;
A blazon must consist of, at minimum, a field specification. Optionally it may include charges,
separated from the field by a colon.
<field> ::== <tincture> | <tincture> “,” <tincture> “,” <2 way
division> | <tincture> “,” <tincture> “,” <tincture> “,” <3 way
division> ;
A field is either a single tincture, 2 comma separated tinctures and a 2 way division type or 3 comma
separated tinctures and a 3 way division type. Note that the “2 way” and “3 way” refer to the
numbers of tinctures used and not necessarily to the shapes of the divisions.
12
<tincture> ::== <colour> | <metal> | <fur> ;
<colour> ::== “azure” | “gules” | “purpure” | “sable” | “vert” ;
<metal> ::== “or” | “argent” ;
<fur> ::== “ermine” | “ermines” | “erminois” | “pean” | “vair” |
“counter-vair” | “potent” | “counter-potent” ;
A tincture is either a colour, a metal or a fur. Rules exist in heraldry disallowing the use of colours
over colours and metals over metals, hence the distinction. Furs are distinct as they are not simple
colours but rather patterns. All standard heraldic tinctures are enumerated here.
<2 way division> ::== "per pale" | "per fess" | "per saltire" | "per
bend" | "per bend sinister" | "quarterly" | "per chevron" | "per
chevron inverted" | "gyronny" ;
<3 way division> ::== "per pall" | "per pall inverted" ;
The two way and three way divisions, using the historical blazonry vocabulary. All standard simple
heraldic field divisions are enumerated here.
<charges> ::== <tincture> “,” ( <ordinary> | <charge ) { “:”
<charges> };
Charges are specified by giving a tincture, a comma and then specifying either an ordinary type or a
charge type. If further charges are to follow they are separated from this one by a colon.
<ordinary> ::== "fess" | "bars" | "pale" | "pallets" | "bend" |
"bendlets" | "bend sinister" | "bendlets sinister" | "chevron" |
"chevronels" | "cross" | "saltire" | "pall" | "pile" | "chief" |
"orle" | "tressure" | "flaunches" | "inescutcheon" | "canton" |
"quarter" | "bordure" ;
A simple enumeration of the standard heraldic ordinaries, using the historical heraldic vocabulary.
<charge> ::== “mullet” | “lozenge” | ... ;
Additional simple charges (a star and a diamond shape in this case). The ... is used to indicate the
13
intention for this part of the language to be extendible by the software system, using a plugin system
to allow additional charges to be added to the application at runtime.
Some example blazons written in the language:
gules
A red shield.
gules: or, fess
A red shield with a yellow horizontal bar across it.
gules, sable, per pale: or, fess
A shield divided into a left red side and a black right side, with a yellow horizontal bar across it.
gules, sable, azure, per pall: or, fess
A shield divided three ways in a Y shape – with the top triangle red, the left area black and the right
area blue. A yellow horizontal bar runs across it.
Figure 4: 3 example coats, generated by CoatCompiler, corresponding to the second, third and fourth examples given above, respectively.
14
3.3.1 A note on the meaning of the colon
The use of the colon character to separate the field from the charges and the charges from each other
is, for this grammar, merely an aid to clarity in blazons (the same purpose server by the comma
separating the tinctures) and as such it could be removed from the grammar. The reason for its
inclusion is to assist a possible extension of the grammar which would add an alternative semicolon
separator. The idea is that the colon would then separate the specification of design elements from
those layered atop them in the coat of arms, whereas the semicolon would separate design elements
from those at the same level in the coat of arms – for example two charges side by side.
For example given this possible extension consider two blazons written in the language:
gules: argent, mullet: gules, mullet
This would specify a red field with a white star on it, and within (on top of, effectively) that star, a
red star.
gules: argent, mullet; argent, mullet
This would specify a red field with two white stars on it (according to heraldic convention they
would be arranged with one towards the top of the shield, the other towards the bottom).
As the planned basic feature set of the software system does not include support for positioning a
design element within another design element or arranging design elements so that they appear to be
at the same level (i.e. they do not overlap) the semicolon separator has not been included at this
point.
4
Design and implementation of CoatCompiler
4.1 Java
4.1.1 Choosing to use Java
It was decided to use Java in this project at a relatively early stage as it is the programming language
that the author is most comfortable and experienced with. In addition the use of the Java2D API (see
section 4.1.3) by the JEmblazoner system (see section 2.3.3) prompted further reading on its
capabilities and it became apparent that it offered suitable facilities for the graphical requirements of
15
the planned software system.
4.1.2 Java platform
The Java platform is an “object­oriented, platform­independent, multithreaded programming
environment” (Sun, 2005b) created by Sun Microsystems. The main components of the Java
platform are the Java programming language, the Java Virtual Machine (JVM) and the Java
Application Programming Interface (Java API) (Kramer, 1996). Sun Microsystems (and other
vendors) provide tools (as part of the Java Software Development Kit (Java SDK)) to compile Java
programs into Java bytecode which can be executed on a JVM. JVM implementations exist for many
different computer systems and so Java programs can be written and compiled once and executed on
any system that has a Java Virtual Machine specification (Sun, 1999, Wikipedia, 2005c) compliant
JVM (Wang, 2003). This constrasts with a typically compiled language such as C, where C source
code is compiled to processor specific machine code which uses operating system specific calls.
Hence in order to run a C program on a different platform to that for which it was written requires at
the least a recompilation. Often programs of a more than trivial nature require changes to the source
code which, if there are large differences between the source and target platforms, can be quite
extensive. The process of making such changes to a program is known as porting (Wikipedia,
2005b).
4.1.3 Java API
The Java platform includes an extensive class library, providing classes and methods useful to the
development of Java applications (Wikipedia, 2005e). These include utility classes equivalent to the
standard libraries that are available for many other programming languages, providing, for example,
common mathematical operations, string manipulation methods and data structures. Also provided is
“an abstract interface to tasks that would normally depend heavily on the hardware and operating
system” such as file manipulation, network functionality and graphical user interfaces (Wikipedia,
2005d).
Sun Microsystems provides the following descriptions of the four main packages in the Java API:
java.lang – “The java.lang package contains the collection of base types (language types)
that are always imported into any given compilation unit. This where you'll find the
16
declarations of Object (the root of the class hierarchy) and Class, plus threads, exceptions,
wrappers for the primitive data types, and a variety of other fundamental classes.”
java.io – “The java.io package contains the declarations of classes to deal with streams and
random­access files. This is where you find the rough equivalent of the Standard I/O Library
you're familiar with on most UNIX systems. A further library is called java.net, which
provides support for sockets, telnet interfaces, and URLs.”
java.util – “The java.util package contains various utility classes including collection classes
such as Dictionary and Vector. Here you'll find common storage classes such as HashTable
and Stack, as well as special use classes like Date and Time and classes to handle encoder
and decoder techniques.”
java.awt – “The java.awt package is an Abstract Windowing Toolkit that provides a layer
enabling you to port Java applications easily from one window system to another. This
library contains classes for basic interface components such as events, colors, fonts, and
controls such as buttons and scrollbars.”
(quotes from chapter 9 of (Sun, 1997))
4.1.4 Java2D API
The Java2D API extends upon the java.awt package (Sun, 2003a) to provide Java programs with “a
set of classes for advanced 2D graphics and imaging, encompassing line art, text, and images in a
single comprehensive model” (Sun, 2005a). An image is generated by creating a Graphics2D object
to provide a context into which to draw, creating shape objects to draw, setting any desired drawing
options and then passing the shape object(s) to the drawing methods of the Graphics2D object (Hall,
1998).
Shapes can be simple shapes such as rectangles, ellipses, arcs, points or lines. More complex shapes
are supported such as paths composed of lines and curves. It is also possible to create a shape that is
defined in terms of the intersections of two or more other shapes by means of boolean operations, as
illustrated in figure 5. (Sun, 2003b)
17
Figure 5: Shapes composed by boolean operations (Sun, 2003b)
Drawing options include options to influence rendering quality, such as whether to use antialiasing
and dithering when rendering the image. Attributes of any lines drawn such thickness, patterning (a
dashed line for example), line end styles and corner styles (the programmer can specify rounded line
ends and corners for example) can also be specified (Sun, 2003c).
The programmer can set the paint object used by a Graphics2D object to fill shapes it renders. In this
way shapes can be rendered as filled by flat colour, a gradient from one colour to another, or with a
pattern (Sun, 2003c). Transformations can be applied to the Graphics2D object, causing rendered
shapes to be translated, rotated, scaled, sheared or subjected to an arbitrary transformation as
specified by the programmer (Hall, 1998).
Figure 6: Shapes filled with a gradient and a pattern (Sun, 2003c)
4.1.5 Batik SVG Toolkit
“Batik is a Java(tm) technology based toolkit for applications or applets that want to use images in
the Scalable Vector Graphics (SVG) format for various purposes, such as viewing, generation or
manipulation” (Apache, 2005a)
The capabilities provided by the Batik toolkit are wide, proving support for creating SVG images,
converting to and from SVG file format, added scripting to SVG files and much more. For the
purposes of this project however it is the ability that Batik provides to create SVG images using the
Java2D API, and to save those images in either SVG format or a raster format such as JPEG that is of
interest (Apache, 2005b).
18
SVG is an XML based file format for the storage of 2D vector graphics data, as well as text and
raster images. It is an open format with published specification documents that are freely available
on the Internet. Consequently it has become relatively widely supported by graphics software and
web browsers (Wikipedia, 2005g). Being vector based SVG images can be scaled without loss of
quality making them better suited to high resolution printing than raster images and it was primarily
for this reason that SVG support was considered to be a desirable feature.
The feature sets of SVG and the Java2D API are similar (SVG supports all Java2D features that this
project is likely to use) and so once the author learned of the Batik toolkit (relatively late in
development unfortunately) the decision was made to utilise it for image file generation. See section
4.3.2 for discussion of the impact of this change.
4.2 The initial attempt
The approach initially taken to the design and development of the software system which early on
had been named CoatCompiler after its intended function (and more whimsical reasons for desiring a
name with the initials CC) called for the use of software designed to aid in the development of
compilers, specifically the lexical analyser generator JFlex and the parser generator CUP (Klein,
2004a). Given that CoatCompiler can be looked at as being a compiler for coats of arms (each takes
as input a string of text conforming to some grammar and produces an entirely different
representation as output) this seemed to be a natural approach to the problem. The use of JFlex in a
module on compiler design within the School Of Computing also influenced this decision.
A formalised version of blazonry (see section 3.2.1) was developed to be used as the basis from
which to create a lexical specification for JFlex (Klein, 2004b) and a grammar specification for CUP
(Hudson, 1999). Preliminary work on these specifications were undertaken and almost immediately
problems were encountered, specifically in using the grammar with CUP. Revisions were made to
the grammar with the aim of making it more suitable to use with CUP and also to correct omissions
and errors that were discovered but it still proved difficult to use and furthermore it was becoming
apparent that, although CoatCompiler was conceptually similar to a compiler for program code, in
fact it was rather different. The code generation oriented JFlex – CUP pairing was not as well suited
to the task as had been thought and the realisation was made that a different approach was needed.
19
Consideration was given to switching to using the SableCC compiler generation framework
(SableCC, 2005) which was also being used in the compiler design module. However that idea was
rejected on the basis that it was also an attempt to fit the project into a programming language
compiler model to which it was ill suited. Additionally at this point it was becoming apparent that
the initial ideas for the capabilities of CoatCompiler were too ambitious. Thus it was decided to
abandon the approach of using a complex language and program language compiler generation tools.
4.3 The second attempt
The decision was made to aim the creation of a software system with much more realistic
capabilities, specifically in terms of the complexity of heraldic designs CoatCompiler was to be able
to produce and therefore the complexity of the language used for input. As described previously in
section 3.2.2 a reduced feature set was drawn up for the language and hence for the heraldic designs
that CoatCompiler would be capable of reproducing. The capabilities required of CoatCompiler were
determined to be:
●
A command line application with arguments specifying an input file containing a blazon
written in the simpler formal language and an output file name
●
To be capable of reproduction of any design specified according to the simpler formal
language (specifically: heraldic designs consisting of charges over a plain or divided field)
●
Produce output of a high quality and in a standard file format (JPEG was chosen early due
to widespread support for the file format in a wide range of applications)
With the basic requirements established work began on designing CoatCompiler.
4.3.1 Design
Work on the design of CoatCompiler started using an informal object oriented design process since
the Java platform is an object oriented programming environment (Sun, 2005b). Object
decomposition was carried out on a description of the functions of the system and a preliminary
group of candidate objects were identified (Sommerville, 1996).
At this point similarities were noticed between the some of the candidate objects and those
20
mentioned in the brief section on the design of the JEmblazoner system described by Breiteneder et
al. (2002). This is hardly surprising given how similar CoatCompiler is to JEmblazoner in purpose,
albeit using the command line interface rather than a graphical user interface as JEmblazoner does.
Figure 7: JEmblazoner class diagram by Breiteneder et al. (2002).
There was one particular aspect of the design of JEmblazoner, as shown in the class diagram
reproduced in figure 7 above, that seemed very well suited to CoatCompiler – that of delegating
responsibility for parsing the various parts of the input text to the same classes that draw them.
This approach to the parsing of the input was determined to be a good idea for a number of reasons.
It removes the need to have an object (or objects) performing up front parsing which had seemed to
be too similar to the previous compiler based approach. Conceptually it fit well with the object
oriented paradigm of modularity, with each object having its own area of responsibility (Wang,
21
2003).
Perhaps most importantly, given the intention to allow CoatCompiler to be extended by the use of
plugin classes supporting new charge types, such a design would provide a simple means for such
plugin classes to extend the recognised input language – for example to support attributes such as the
posing of animal charges.
Thus the decision was taken to include a similar system into the design of CoatCompiler.
Consequently it could be said that the design of CoatCompiler was inspired by JEmblazoner although
given the similarities in the purpose of the two systems, the shared use of the Java platform and
specifically the Java2D API, it was likely that the two systems would share similarities in design.
Main
Tincture
ArmsParser
ShieldParser
ChargeParser
Charge
ChargeOne
Ordinary
ChargeTwo
...
Figure 8: CoatCompiler concept class diagram
22
The design calls for eight main classes:
Main – Program class. Handles command line arguments, sets up input and output files, and
the Java2D API classes to provide a context into which other classes can draw. Passes the
blazon input string to ArmsParser.
ArmsParser – Splits the blazon input string into the field part, and the charge parts, if any.
Passes the field part to ShieldParser and the charge parts to ChargeParser.
ShieldParser – Parses the field input string and draws the shield as instructed.
ChargeParser – Parses charge string data and checks if any ordinaries are to be drawn. If so
passes the input string to ChargeParser. Otherwise the input string is checked against the
Charge classes that are loaded at runtime and if a match is found the appropriate charge is
drawn.
Ordinary – Draws whichever type of ordinary is specified in the input string passed to it.
Charge – Abstract class defining a common base for charge classes, to be loaded at runtime
by ChargeParser. This is the basis of a plugin mechanism allowing the easy extension of the
range of charges supported by CoatCompiler.
Tincture – A class used by the classes which draw output, to handle the tinctures in input
strings.
The three additional classes shown in figure 8 as subclasses of the abstract class Charge are example
charges, included to indicate that Charge may have many subclasses, all used by ChargeParser via
Charge class references at runtime.
With a basic design worked out, including the responsibilities of each class, it was time for work to
progress onto defining the methods and attributes of each class. At this point, with the remaining
project time running low due to earlier false starts, the design and implementation stages of the
project ran together. The details of the classes inner workings were partially designed in advance (to
23
the extent specified above) and partially worked out as they were implemented.
4.3.2 Implementation
As previously discussed the CoatCompiler application was implemented in the Java programming
language using the Java2D API, later augmented with the use of version 1.6 of the Batik toolkit.
Primary development work was conducted using the Java 2 Platform Standard Edition Software
Development Kit (J2SE SDK) 1.5.0 from Sun Microsystems, on the Windows XP platform.
Secondary development tasks such as compatibility testing were undertaken using the J2SE SDK
1.4.2, also from Sun Microsystems, on the Linux platform. The NetBeans Integrated Development
Environment 4.0 was used throughout the course of development.
Implementation work began with the creation of the 8 main classes discussed previously (see section
4.3.1) and the necessary structure to allow the Main class to be compiled and executed, though of
course at this point it did nothing. Then began a process of incremental development with the adding
of new code to expand functionality towards the minimum requirements in small steps. Testing was
performed “in parallel” with development (as much as an individual can perform two interdependent
tasks in parallel anyway). This style of development continued until the discovery that the Batik
toolkit offered a relatively straightforward means of implementing a desired feature that the author
had thought was not achievable due to time constraints.
The decision to use the Batik toolkit to provide the ability to save images in the SVG format meant
the replacement of existing code for image file generation as the SVGGraphics2D object used did not
support the required method of the Graphics2D object it replaced. However this did not prove to be a
great problem because, firstly the design of CoatCompiler's classes and secondly SVGGraphics2D's
compatibility with the Java2D API drawing methods used meant that only code in the Main class
needed to be altered. Ultimately SVG support was added in a very short timespan, and had minimal
impact upon the existing code. Also, use of Batik opened the possibility of supporting additional
raster file formats too.
See figure 9 for a more detailed CoatCompiler class diagram.
The completed CoatCompiler application satisfies all of the minimum requirements and some of the
suggested extensions. Specifically, it supports an additional raster image file format (PNG). It
24
supports a vector image file format (SVG). It allows the user to specify output image dimensions.
Finally it supports extending the system by adding support for extra charge types at runtime.
The suggested extensions that CoatCompiler does not support for various reasons will be discussed
later, in section 6.
Main
+<<static>> m ain(args:String[]):void
-<<static>> handleArgs(args:String[]):boolean
ArmsParser
+Arm sParser(gIn:G raphics2D,sIn:String)
+valid():boolean
+draw Arm s():void
ChargeParser
ShieldParser
+ChargeParser(gIn:G raphics2D,sIn:String)
+valid():boolean
+draw Charges():void
-loadClassNam es():void
+ShieldParser(gIn:G raphics2D,sIn:String)
+valid():boolean
+draw Shield():void
Charge
Ordinary
+Charge()
+Charge(new X:float,new Y:float,new Scale:float)
+getX():float
+getY():float
+getScale():float
+setX(new X:float):void
+setY(setY:float):void
+setScale(new Scale:float):void
+<<abstract>> draw (g:G raphics2D):void
+<<abstract>> getM atchString():String
+O rdinary(gIn:G raphics2D,sIn:String)
+<<static>> valid(sIn:String):boolean
+valid():boolean
+draw O rdinary():void
Tincture
ChargeOne
ChargeTwo
+<<static>> valid(sIn:String):boolean
+<<static>> getPaint(sIn:String):Paint
...
Figure 9: Class diagram for CoatCompiler
25
5
Project evaluation
5.1 Criteria for evaluation
In determining evaluation criteria consideration must be given to the problem being solved, namely
that existing solutions for generating visual representations of heraldic designs tend to produce low
quality (and not always very accurate) results.
This can be broken down into separate issues. Firstly accuracy in resulting visual representations is
of great importance if any system such as this is to be of use for anything other than amusement. A
historian would not tolerate a system that incorrectly rendered a coat of arms entered into it!
Secondly the aesthetic quality of resulting visual representations is important as people will always
wish for results from a tool of any sort to be as good as possible. One would not tolerate a system for
audio recording that made recorded voices unpleasant to hear, and a camera that produces better
quality photographs is usually more sought after than one of inferior quality. So produced visual
representations should be of as high a quality as is reasonably possible.
Given that the reason for the development of the system is to address shortcomings in existing
systems it would be reasonable, as one of the criteria against which it is to be judged, to consider the
question of whether or not the completed system is superior to those existing systems.
In the development of virtually any computer program it is desirable to strive to make future
expansion and development as painless as possible (since you may be the one conducting such
expansion!). Therefore it seems reasonable to ask of the system, to what degree it is amenable to
such further development.
Each of these points has been turned into a question and answered below:
5.1.1 Does the system produce accurate output for the language supported?
The system does produce accurate visual representations of designs expressed in the simplified
formal language supported. This claim is based upon the fact elements of the design are drawn in the
order in which they are specified in the input file. Since a shape (A) drawn later than another shape
26
(B) is drawn over it, and the order of elements in the input file also represents the order in which they
are to be drawn, from the bottom layer (the field) up, it would not be possible for elements to be
drawn in an incorrect order.
In combination with the limited number or divisions and charges supported by the system this allows
the author to claim a high degree of confidence in the accuracy of the output from the system.
It is acknowledged however that the system for adding charges at runtime could (given an incorrectly
implemented charge class) cause unexpected results.
5.1.2 Does the system produce high quality output visual representations?
The system does produce high quality visual representations. Output images are antialiased, high
quality settings are chosen for image compression (where applicable) and output in a vector graphics
format is available allowing for scaling without loss of quality, high resolution printing from a small
file and editing without the need to rasterise the image.
However it could be argued that the charges supported by the system as it is are primitive and that
even given the primitive shapes rendering is not 100% perfect. It is acknowledged that some minor
artefacts can be seen in produced raster graphics files, caused by the antialiasing where shapes touch
the side of the shield and given certain colour combinations. It could be argued however that these
are only very minor issues and can be avoided by the use of the SVG format.
Furthermore on the matter of the charges being relatively primitive shapes, this is true. However it is
not a limitation of the system that caused this but rather time limits and lack of artistic ability on the
part of the developer. It would be entirely possible to implement a charge class that draws a higher
complexity shape such as a heraldic lion, for example, it would just be time consuming and
painstaking work. With the addition of the ability for a charge class to import an SVG image to use
this process would be a great deal easier – sadly time did not allow for such functionality but the
author believes that the Batik toolkit provides sufficient means to add such a feature to the system
with relative ease.
27
5.1.3 Is the system superior to pre­existing solutions?
The answer to this question must be a yes and no. It can be argued that, within the limited range of
charges supported the system produces superior quality output, especially as compared against
Blazon95. On the other hand in comparison to the pre­existing systems CoatCompiler has very
limited charge support, and lacks many of the features required to reproduce a great many relatively
uncomplicated coats of arms – in particular the lack of ability to specify the position, orientation and
size of charges (a minor point of interest here is that the Charge abstract class has been designed with
such future expansion in mind, and includes attributes and accessor methods to support positioning
and sizing at least).
On balance it is conceded that the system is currently inferior to pre­existing solutions but that it has
the potential to become superior (in at least some respects) given further development.
5.1.4 Is the design of the system amenable to further development / expansion?
The author believes that it is. Firstly the charge plugin system allows for easy expansion of the
charges supported (and as discussed above a little more development in a certain area would assist
this greatly). Secondly the formal language used has some features intended with future expansion in
mind (see section 3.3.1) as does the design of CoatCompiler (as discussed in response to the previous
question). Admittedly the system design does little to directly facilitate certain possible future
features such as attributes of charges, but at the same time it could hardly be argued that the design is
an impediment to such expansion either.
28
6
Extension of the project
The author has a number of suggestions for possible future extensions of the project.
One possibility is to add the ability to produce black and white images, using the historical Petra
Sancta hatching system as described by Friar (2004). This could be done by altering the Tincture
object to enable it to return hatching patterns rather than flat colours. Such an alteration is well
within the capabilities of the Java2D API. Similarly support could be provided for complex fur
tincture patterns, as was originally intended for this project (in CoatCompiler furs are rendered in
grey).
Another possible extension that it would have been very useful to have been able to include is the
ability for charges to load external image files at runtime which contain the data to draw for charge
types. This would allow for the creation of complex shapes using dedicated graphics software. The
Batik toolkit provides means to read SVG files from disk into data structures, and means to render
the data in those structures so it should be possible and probably not too difficult to achieve.
Adding support in the language and application for the specification of position, orientation and
sizing of charges would be very useful indeed as it would allow more complex “real world” blazons
to be reproduced, albeit manually rather than automatically (i.e. by the mapping between a blazon
and the equivalent expressed in the language would probably no longer be so straightforward).
Again, the Java2D API provides methods for scaling, translating and rotating shapes so such support
would be possible to add.
Adding support for automatically positioning charges according to heraldic tradition and ensuring
that charges to not intersect with one another. Of all the features suggested this one would probably
bring CoatCompiler closest to being able to reproduce a wide variety of historical blazons accurately
without lots of manually tweaking the input file. However it is also the most difficult of the
suggestions to implement by a considerable margin and the author has no suggestions as to how it
might be achieved.
Finally if the previous suggestions were implemented a further suggestion is support for marshalling
of arms – that is the production of composite coats of arms from two or more blazons. This should
be easier than the previous suggestion (though there would be little point in implementing it having
29
not implemented the previous suggestion) and would, in combination with the other suggestions,
allow faithful reproduction (charges allowing) of most historical blazons.
30
Bibliography
Breiteneder C., Eidenberger H. and Wasinger M. (2002) JEmblazoner: Construction of Coats of
Arms Images from Textual Descriptions,
http://www.ims.tuwien.ac.at/media/documents/publications/eva2002­jemblazoner.pdf
[25 April 2005].
Friar S. (2004) The Sutton companion to heraldry, Sutton.
Levin C. (2005) The Law of Arms in Mediaeval England,
http://www.sca.org/heraldry/laurel/lexarm.html [25 April 2005].
Miller B. (1988) A Grammar of Blazonry, http://www.sca.org/heraldry/laurel/bruce.html [25 April
2005].
Rosebush J. (1995) Blazon computer graphic notation. In: Understanding Images. Finding Meaning
in Digital Imagery, New York, 123­141.
Stoyan H. (2005) Design your own coat of arms!,
http://www8.informatik.uni­erlangen.de/html/arms.html [25 April 2005].
Sun Microsystems (2001) Programmer's Guide to the JavaTM 2D API,
http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d­bookTOC.html [25 April 2005].
Thiele H.E., Jr. (1990) Heraldry and blazon: a graphic­based information language. Library Trends,
38(4), 717­736.
Wikipedia contributors (2005a) Heraldry ­ Wikipedia: The Free Encyclopedia,
http://en.wikipedia.org/wiki/Heraldry [25 April 2005].
Hall, M. (1998) Java2D: An Introduction and Tutorial, http://www.apl.jhu.edu/~hall/java/Java2D­
Tutorial.html [25 April 2005].
31
Sun Microsystems (2005a) Java 2D API, http://java.sun.com/products/java­media/2D/index.jsp [25
April 2005]
Wang, P. (2003) Java with Object­Oriented Programming, Brooks / Cole.
Sun Microsystems (2005b) About Java Technology, http://www.sun.com/java/about/ [25 April 2005]
Kramer, D (1996) The JavaTM Platform A White Paper,
http://java.sun.com/docs/white/platform/javaplatformTOC.doc.html [25 April 2005]
Wikipedia contributors (2005b) Porting ­ Wikipedia: The Free Encyclopedia,
http://en.wikipedia.org/wiki/Porting [25 April 2005].
Sun Microsystems (1999) The JavaTM Virtual Machine Specification,
http://java.sun.com/docs/books/vmspec/2nd­edition/html/VMSpecTOC.doc.html [25 April 2005]
Wikipedia contributors (2005c) Java Virtual Machine ­ Wikipedia: The Free Encyclopedia,
http://en.wikipedia.org/wiki/Java_virtual_machine [25 April 2005].
Wikipedia contributors (2005d) Java Platform ­ Wikipedia: The Free Encyclopedia,
http://en.wikipedia.org/wiki/Java_platform [25 April 2005].
Wikipedia contributors (2005e) Java 2 Platform, Standard Edition ­ Wikipedia: The Free
Encyclopedia, http://en.wikipedia.org/wiki/Java_2_Platform%2C_Standard_Edition [25 April 2005].
Sun Microsystems (1997) Java Base System and Libraries,
http://java.sun.com/docs/white/langenv/Libraries.doc.html [25 April 2005]
Sun Microsystems (2003a) Java 2DTM API Overview,
http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d­intro.html [25 April 2005]
Sun Microsystems (2003b) Geometries, http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d­
geom.html [25 April 2005]
32
Sun Microsystems (2003c) Rendering with Graphics2D,
http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d­awt.html [25 April 2005]
Wikipedia contributors (2005f) Backus­Naur form ­ Wikipedia: The Free Encyclopedia,
http://en.wikipedia.org/wiki/Backus­Naur_form [25 April 2005].
The Apache Software Foundation (2005a) Batik SVG Toolkit, http://xml.apache.org/batik/index.html
[25 April 2005].
Klein, G (2004a) JFlex ­ The Fast Scanner Generator for Java, http://www.jflex.de/index.html [25
April 2005].
Klein, G (2004b) JFlex User's Manual, http://www.jflex.de/index.html [25 April 2005].
Hudson, S (1999) CUP User's Manual,
http://www.cs.princeton.edu/~appel/modern/java/CUP/manual.html [25 April 2005].
SableCC (2005), SableCC Java parser generator, http://sablecc.org/ [25 April 2005].
Sommerville, I. (1996) Software Engineering – fifth edition, Addison­Wesley
The Apache Software Foundation (2005b) SVG Generator: SVGGraphics2D,
http://xml.apache.org/batik/svggen.html [25 April 2005].
Wikipedia contributors (2005g) Scalable Vector Graphics ­ Wikipedia: The Free Encyclopedia,
http://en.wikipedia.org/wiki/Svg [25 April 2005].
33
Appendix A: Personal reflection
Throughout the course of this project probably the most important lesson I have learned is not to be
too ambitious in my aims. I am not advocating being overly conservative and cautious but rather
being realistic about your abilities and most importantly about the time available to you.
My overly ambitious initial approach to the design of my program eventually cost me more time than
I could really afford and caused me a great deal of unnecessary stress.
So, aim high, but be realistic about it. Try to ensure that you keep the time scales of your project in
mind at all times – don't allow ambition to cost you as it cost me. Over ambition can be just as
counter­productive as apathy.
One other (somewhat related) lesson I've learned is to set myself personal milestones along the way.
Official deadlines can seem to be a very long way away but when you consider other coursework
(particularly that given to you near to the end of your project) you really don't have as long as it
seems. It is easy to end up finding yourself in a panic with a deadline looming!
34
Appendix B: Formalised blazonry specification
The grammar is presented in an extended Backus­Naur form (Wikipedia, 2005f) with the following
notational conventions:
Curly brackets – { and } – surrounding something indicate that the contents are optional; either all
are present or none are present. Square brackets – [ and ] – surrounding something indicate that the
contents may be optionally included one or more times. Parenthesis – ( and ) – surrounding
something indicate grouping.
For example “a” ( “b” | “c” ) { “d” “e” } [ “f” ] means “a” followed by either
“b” or “c” which is optionally followed by both “d” and “e”, which is followed by zero, one or more
occurrences of “f”.
<Blazon> ::== <field> [ <charge group> ] ;
<field> ::== <tincture> | <division> ;
<tincture> ::== <metal> | <colour> | <fur> | “proper” |
“countercharged” ;
<metal> ::== “or” | “argent” ;
<colour> ::== “azure” | “gules” | “purpure” | “sable” | “vert” ;
<fur> ::== “ermine” | “ermines” | “erminois” | “pean” | “vair” |
“counter-vair” | “potent” | “counter-potent” ;
<division> ::== <division type> { <line type> } <tincture>
<tincture> | <3 part division type> { <line type> } <tincture>
<tincture> <tincture> ;
<division type> ::== “per fess” | “per pale” | “per bend” | “per
bend sinister” | “per saltire” | “per chevron” | “per chevron
35
inverted” | “gyronny” | “barry” | “bendy” | “bendy sinister” |
“paly” | “chevrony” | “chequy” | “lozengy” | “barry bendy” | “paly
bendy” | “pily” | “pily bendy” | “pily bendy sinister” ;
<3 part division type> ::== “per pall” | “per pall inverted” ;
<line type> ::== “invected” | “engrailed” | “indented” | “dancetty”
| “nebuly” | “wavy” | “embattled” | “raguly” | “dovetailed” |
“rayonne” | “urdy” | “potenty” | “embattled grady” | “arched” ;
<charge group> ::== { <arrangement> } <number> <charge> | “on”
{ <arrangement> } <number> <charge> “,” { <arrangement> } <number>
<charge> ;
<charge> ::== <charge type> { <orientation> } <tincture> ;
<charge type> ::== <ordinary> | <animal> { <attitude> } | <object> ;
<ordinary> ::== <ordinary type> ( ( { <linetype> } | { “voided” } |
{ “cotised” } ) <tincture> | <tincture> “fimbricated” <tincture> ) ;
<ordinary type> ::== “fess” | “bars” | “pale” | “pallets” | “bend” |
“bendlets” | “bend sinister” | “bendlets sinister” | “chevron” |
“chevronels” | “cross” | “saltire” | “pall” | “pile” | “chief” |
“orle” | “tressure” | “flaunces” | “inescutcheon” | “canton” |
“quarter” | “bordure” ;
<animal> ::== “lion” | “tyger” | “eagle” | ... ;
<attitude> ::== “rampant” | “salient” | “passant” | ... ;
<object> ::== “mullet” | “mullet of 6” | “lozenge” | ... ;
<arrangement> ::== “in fess” | “in pale” | “in bend” | “in bend
sinister” | “one and two” | “two and one” | (“in” | “to”)
36
{ ( “dexter” | “sinister” ) } “chief” | (“in” | “to”) { ( “dexter” |
“sinister” ) } “base” | (“in” | “to”) “dexter” | (“in” | “to”)
“sinister” ;
<orientation> ::== “palewise” { (“inverted” | “reversed”) } |
“bendwise” { “sinister” } { (“inverted” | “reversed”) } | “fesswise”
{ ( “inverted” | “reversed” ) } ;
<number> ::== “a” | <digit> [ <digit> ] ;
<digit> ::== “0” | “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” |
“9” ;
37
Appendix C: Simplified formal language specification
This grammar is presented in an extended Backus­Naur form (Wikipedia, 2005f) with the following
notational conventions:
Curly brackets – { and } – surrounding something indicate that the contents are optional; either all
are present or none are present. Parenthesis – ( and ) – surrounding something indicate grouping.
For example “a” ( “b” | “c” ) { “d” “e” } means “a” followed by either “b” or “c”
which is optionally followed by both “d” and “e”.
<Blazon> ::== <field> { “:” <charges> } ;
<field> ::== <tincture> | <tincture> “,” <tincture> “,” <2 way
division> | <tincture> “,” <tincture> “,” <tincture> “,” <3 way
division> ;
<tincture> ::== <colour> | <metal> | <fur> ;
<colour> ::== “azure” | “gules” | “purpure” | “sable” | “vert” ;
<metal> ::== “or” | “argent” ;
<fur>
::== “ermine” | “ermines” | “erminois” | “pean” | “vair”
| “counter-vair” | “potent” | “counter-potent” ;
<2 way division> ::== "per pale" | "per fess" | "per saltire" | "per
bend" | "per bend sinister" | "quarterly" | "per chevron" | "per
chevron inverted" | "gyronny" ;
<3 way division> ::== "per pall" | "per pall inverted" ;
<charges> ::== <tincture> “,” ( <ordinary> | <charge ) { “:”
<charges> };
38
<ordinary> ::== "fess" | "bars" | "pale" | "pallets" | "bend" |
"bendlets" | "bend sinister" | "bendlets sinister" | "chevron" |
"chevronels" | "cross" | "saltire" | "pall" | "pile" | "chief" |
"orle" | "tressure" | "flaunches" | "inescutcheon" | "canton" |
"quarter" | "bordure" ;
<charge> ::== “mullet” | “lozenge” | ... ;
39