The number of people who design typefaces has drastically increased in the last twenty years. However, not all typefaces work as they should, i.e., as a group of characters with shared attributes. We present a tool for helping type designers in their creative process, which explores the anatomic relations among characters of a typeface. Having computer-aided design as a goal, our tool helps in the early stages of designing a typeface by using semi-automatic letter-part sharing and allowing the users to compare their design with existing typefaces.
In the last century there was a massive proliferation of typefaces, being di cult
to know how many there are today [
A typeface has a key role in terms of communication as can even change the
intent of its message. However, its importance is often overlooked and the impact
of the communication is negatively a ected by choosing an unsuitable or even
poorly designed typeface. As changing users' habits is something not feasible,
we believe that we should instead focus on trying to improve the way users
design typefaces. By doing this, we aim at increasing the overall likelihood of
the production of better quality designs by both experienced type designers and
users without a design background. One of the criteria to evaluate a typeface's
quality is its consistency { the way typeforms match each other, i.e. how the
characters are designed into a set of diversi ed and yet uni ed forms [
Having computer-aided design as a goal, we focus on helping the designer
in the early stages of the design process by combining type design principles,
derived during the research stage, with an exploration of the Creativity-Support
Tools domain, using mixed-initiative approaches [
We present a prototype of a type design aiding-tool which is currently composed of two di erent components: the Part-sharing { based on the consistency criterion { and the Adviser { which uses Self-Organizing Maps to suggest similar designs to the user.
Copyright © 2016 for this paper by its authors. Copying permitted for private and academic purposes.
The development of type related digital applications is nothing new and the current approaches can be divided into di erent categories according to their authors/users or their end purposes. There are three main types of authors: designers, engineers and artists. This di erence on background knowledge has a huge e ect on the type of application: some are purely artistic; others are technical and often dependent on too rigid rules or structure, thus resulting sometimes in visually non-appealing outputs; and others are within the scope of software speci cally developed for type design { none of which explores the domain of computational creativity to its advantage in a signi cant way. Being more interested in type design, we will avoid addressing applications which have a visual artifact as output and focus on those that have a font as nal product.
CarveLCD [
Other applications allow the user to change the value of pre-de ned
parameters which control a given characteristic in order to generate fonts (e.g. Meta op
[
Schmitz [
There are also some systems that use Evolutionary Computation for
designing type. Some require user interaction (e.g. [
In spite of the existence of such applications and systems, not only none of them addresses all the issues we have previously identi ed but also their output is considered the nal product { we act on the initial stage of the design process. Concerning the followed approach, most of the aforementioned applications rely on prede ned typefaces or skeletons, whereas we aim to allow the user to input its own designs. Additionally, the majority of them presents as nal output something that { as a text font { has low quality both in terms of legibility and coherence among characters. 3
Our tool aims at helping type designers by combining co-creativity with type design principles. The developed prototype is currently composed of two di erent components: the Part-sharing and the Adviser. The Part-sharing component is strongly based on type design principles and uses them to both help designer reduce time-consuming tasks and stimulate creativity.
1. Looking for consistency { By focusing on the principle of consistency, the rst stage of the development of the Part-sharing component has three main goals: identify the characteristics that make a typeface work as a whole; understand the reason for the existence of relationships among letters; and identify the possible patterns in their construction.
Our research approach consisted not only in bibliographic research but also in the conduction of interviews with type designers. These interviews allowed us to understand their way of working and the details they pay attention to when drawing a typeface. In addition, we also analyzed the di erent letters, in order to identify patterns in their construction and infer possible rules followed in the design of a text typeface. The collected material and reached conclusions were then used as a support and applied in the development of the application.
As observed in some of the projects presented in Section 2, it is possible to make a metaphor between typefaces and biology: di erent typefaces can be seen as di erent species as they have a di erent structure. On the other hand, as living creatures within the same species share a given karyotype, within a typeface the di erent letters also share a set of characteristics.
According to Meseguer [
Both the repetition of modules and shape derivation have key roles in terms of giving coherence and maintaining the harmony among characters.
By drawing the rst letters, it is already possible to foresee how the others will be as making a decision for one letter often a ects the rest of the letters. The designer is then faced with the question of which elements of the drawn letters can be used in the new ones and which ones must be adjusted or modi ed.
In addition, it is possible to separate the characters into several groups based
on their morphological similarity (e.g. in upper case the round shapes group is
O, Q C, G and S ; in lower case is o, c and e). This categorization is of great
importance since similar structures can and should be designed as related forms
[
The process of designing in sequence was mentioned by all the interviewed designers when describing their way of working. They not only share the preference of drawing the lowercase rst { upper case is much more limited in terms of creativity and di erentiation { but they also have a set of favorite rst letters.
Most designers start with the key letters which de ne the proportions and personality of the type, good starting points are the lowercase letters a,e,g,n and o. The letter n is normally one of the rst, due to the fact that it is easy to obtain parts of the letters h, m, u and r from it. And with it, it is possible to de ne a lot of the rhythm and proportion of the typeface.
2. Our approach { Our initial ideia was to establish rules that would, in some way, allow to generate all the characters of a typeface based only on some given by the user. The user would input some previously drawn vectorial glyphs and then identify their parts. After identifying the letter-parts, it would be possible to generate the rest of the letters. This generation would be based on the prede ned rules and would use the details about the introduced glyph, given by the user. After the generation, the user would be able to change the generated shapes, in order to correct any imperfection, and afterwards export the results. The goal of this concept was to generate a font nearly ready to be used. The end version of the application works similar to what has already been described but its main goal is completely di erent.
As explained in Section 3 (Looking for consistency ), a system with too rigid
rules, would lead to something greatly repetitive and would probably result in
something with a modular appearance. Such a product would go against one
of our main goals: to have something serious in terms of typographic quality
and useful as a text typeface. According to Goudy [
Another important issue is related to the introduced characters. As mentioned in Section 3 (Looking for consistency ), there are some letters that allow to foresee how the rest of the font might look like (e.g. the n or o) { by partially de ning the proportions, contrast, etc.. However, there are others that do not and are much more di cult to extract useful information from (e.g. k, x or z ), consequently increasing the di culty of generating the rest of the characters. Moreover, just a few letters are not enough to generate the all of the remaining characters, which denotes a clear problem in our initial concept.
For already mentioned reasons, the goal of the application was changed: instead of being considered as an application able to generate a complete and ready to use font, it should be seen as an aid-tool to the type designer, giving support to the design task and stimulating creativity. It helps to reduce the time spent by the designers in the initial stage of the design process.
The way of working is highly similar to what has already been described. The user is able, at any time, to add new previously drawn glyphs and identify their parts. The shape-repetition is done automatically by the application. When the user is satis ed with the characters drawn using the tool, he can continue the design process with another software specially developed for type design, using the output of our application as a draft and an initial version of the typeface.
The current version is a prototype, not having all its functionalities fully implemented. In the part-sharing component, we have chosen to begin with the lowercase because it has a greater importance and usage { as already mentioned. Not only that but also all the interviewed type designers start the majority of their typefaces with the lowercase letters. The implemented rule system was based on the identi ed shape-sharing relationships among letters (see Fig. 1).
3. User input { The current version of the application was implemented using Processing and the library Geomerative. This library was used to read the introduced svg les and access the points and Bezier curves of the vectorial shapes. By introducing a vectorial le, the user is rst asked to identify the letter it corresponds to. The user is then able to identify the several parts of the introduced glyphs. These parts are prede ned in the application, i.e. the user has a list of possible parts to identify (based on the relationships, see left side of Fig. 1). This identi cation is done through point selection of all the points belonging to the part being identi ed. For example: having introduced a serifed glyph, the user can select all the outline points which are part of the serif and choose \serif" to save it as such. After identifying a letter-part, the application automatically checks which letters might use it in their construction and assigns it to them (see Fig. 2). The input is not limited: the user is able to input vectorial les for as many letters as he/she wishes and even replace a previously given one. This allows the user to work step-by-step in an incremental way.
4. Letter-part attribution and positioning { The attribution of the letter parts is done according to two criteria: need { does the letter need that part or does it already have one specially drawn for it? { and suitability degree { is there any other already de ned letter-part which is more suitable or should it be replaced? For example, the top part of the l stem can be used to make an i stem but the top part of the j might be more adequate.
One of the issues that had to be solved was related to the positioning of letter-parts { i.e. how should a copied shape be positioned? The solution was to use a letter skeleton with the several letter-parts identi ed (see right side of Fig. 1). Contrary to some of the applications mentioned in Section 2, the skeleton is only used for letter-part positioning purposes. This is not an optimal solution as it does not account for every style/proportion. Despite this, we do not consider it a problem, as the user is able to move the letter-parts.
The positioning according to the skeleton is also not trivial, as the positioning method is not the same in all letter components. An example of this can be seen in the letters n and l. The left stem of the letter n can be positioned by aligning it to the left with the corresponding skeleton part. Di erently, the stem of the l is centered in relation to its skeleton. This makes it necessary to previously de ne the positioning method for each letter-part. 5. Editing shapes { In spite of not having a nal typeface as a goal output nor aiming at developing an application to compete with software specialized in type design, we decided that the user should be able to edit the letter shapes. The importance of this functionality is even more evident when considering positioning. Therefore, the user is able to both move shapes, by selecting all their points, move single points or even their respective control points. This makes it possible to change the generated shapes in order to correct any imperfection and make slight adjustments (e.g. optical compensations). 4
The second component is used as a guide and its purpose is to present the user with possible letter designs, based on a user given glyph. The suggested designs are from already released typefaces that are similar in style to the one introduced by the user. This functionality is particularly helpful for non-experienced users and has two main possible uses: (i) it allows the user to see how the characters of similar-looking typefaces were designed, thus being useful to guide the user when designing a typeface of a speci c style; on the other hand, (ii) it helps the user in distancing the typeface being designed from others, thus avoiding an excess of similarity of the output.
To implement the Adviser, we use a Self-Organizing Map (SOM) [
A SOM is used to produce a map of di erent character styles for each letter,
organized in terms of similarity. This makes it possible to group similar
typefaces and nd the ones visually near to a given one. Moreover, it also allows a
gradual distancing from a particular style { without getting too far from what
is established by tradition for that speci c style of typeface. It is important to
bear in mind that breaking with tradition when designing a typeface is often
not a good choice as it might have a negative e ect on legibility and easiness of
reading [
1. Producing SOMs { Di erently from the component described in Section
3, in the current version of the Adviser component we only used uppercase letters.
This was mainly due to fact that, the upper case is much more limited in terms of
di erentiation and creative freedom when compared to the lowercase [
We produced a SOM for each letter with a dataset of 4034 typefaces. The currently used SOMs followed the following experimental parameters: number of iterations : 800; lattice size: 25 25; samples per character : 250.
Following the production of the SOMs, we calculated the correspondence between the dataset typefaces and the best match SOMs node for each character, i.e. each SOM (e.g. SOM of the character A, see left side of Fig. 3) has a list of best match node for each typeface (e.g. the node that is most similar-looking to the glyph A of a given typeface). This establishes proximity relationships among the typefaces from the dataset.
2. Finding look-alikes { The Adviser component uses the produced SOMs to suggest the most similar-looking typefaces, based on the glyph given by the user. This process consists in nding the node of the character's SOM that has the highest degree of similarity and then provide the user with a list of typefaces. The similarity comparison is done using the Euclidean distance { also used in the SOMs production { which compares the input glyph with each node. The list of best matched typefaces is then produced by gathering the typefaces which were attributed to the best matched node and the nodes that are close to it. This results in a list ordered by similarity degree.
3. Guiding the user { The interface is the same as the one developed for the rst component, as they are part of the same tool. When using the functionalities of the Adviser component, the user is able to click on every letter button, even though some of the letters do not have a de ned glyph yet. This is due to the components way of working: it does not need a glyph to show a suggestion of a possible design.
The suggestion is shown with a shadow-like e ect, being only a visual clue to the user (see right side of Fig. 3). There are two di erent modes of suggestion: single suggestion { only a glyph typeface is shown { and multiple suggestion { several are shown by overlaying them. Despite being totally functional, the interface still needs some improvements in order to make both components t well together in terms of usability and way of working.
We have presented and described the functionalities of a type design aidingtool which has as main purpose to make the design process easier by reducing time-consuming tasks and stimulating creativity. It follows a mixed-initiative approach and is currently composed of two di erent components: the Part-sharing { strongly based on type design principles { and the Adviser { which uses SelfOrganizing Maps to suggest similar designs to the user. The main goal is not to create completely nished and ready to use typeface but instead to allow the user to design a rst draft by using the tool as a support. It is to be used in the early stage of the design process as the user will be able to export the typeface draft and continue the process in an application specially developed for type design, thus allowing the user to afterwards improve details and correct drawing problems such as those related to optical compensations.
Concerning the Advisor component, there are also issues to be solved. We consider that the use of SOMs full ls its purpose as it allows similar typefaces to be found. Notwithstanding, the used dataset has some clear problems which need to be corrected: (1) Some of the typefaces used are too similar; (2) It contains di erent weights { this is pointless, as we are only designing the regular weight.
In addition, as every SOM is di erent and nds di erent similarities among the data, more attention should be given to both SOM production and SOM quality assessment as well as to the used experimental setup.
Regarding the process of nding similar typefaces using SOMs, we aim to further develop its way of working by focusing on multiple matching. The current version only nds similar typefaces based on a single glyph; with multiple matching it would be based on several glyphs, consequently aiming to nd typefaces that match the maximum number of glyphs.