Technically correct versus practical application

Matt McDonagh

I’m nearing the final phase of development in the font shown below and am struggling with a practical dilemma.

The font is currently in two forks — one for Roman and the other for italics. Both make use of stylistic sets to activate the Gaelic characters. In certain cases there are multiple stylistic sets (to enable/disable the long ‘s’ and ‘r’, for example).

My dilemma is this: while this all works very well, it all relies on the awareness of end users that stylistic sets exist. Further to this is awareness of key commands to activate seimhiús (dot accent) on letters.

While Unicode supports all of the required glyphs, the bulk of my target users will most likely be working on Office in Windows, with UK English keyboard settings. My aim is to make using the font as easy as possible for the end user.

I’m debating separating the Latin and Gaelic versions into separate fonts and using something other than dot-accent to generate the seimhiú accents.

I’d be interested in hearing other type designers views on this. I realise is is a bit niche, I don’t think it has any parallels with other languages as the Gaelic forms were largely abandoned in the 1950’s in Ireland.

Thanks in advance for your thoughts.

Thomas Phinney

If most of your users are on Office and are not graphic designers, then do the build as two fonts. Could be Bunbeg Latin and Bunbeg Gaelic.

For your own production/maintenance purposes, keeping the source integrated as a single font and then doing the builds with a script or the like would probably be ideal. Or you could do it as a post-process with PyFtFeatFreeze. https://github.com/twardoch/fonttools-utils/tree/master/pyftfeatfreeze

ClintGoss

I wrestle (endlessly, it seems) with similar issues.

It would be great to have statistics on global usage of stylistic sets. However, that would require callback from authoring systems, so not likely to happen.

Although this is unusual, a few type designers such as David J. Perry (Cardo) and a Hebrew font that I recall, have written substantial user guides for their fonts. That might help.

I too am producing a user guide, but I am also erring on the side of "separate fonts" rather than stylistic sets, even for things like choosing among figure styles (e.g. tabular/proportional, lining/oldstyle/hybrid).

My target audience are academic authors. I believe that, even though they may be "smart", they may not be quite so fanatical about typesetting details as some of us. A one-time choice among fonts might serve them better than making sure the appropriate stylistic set has been chosen in all the situations where it is called for.

One downside may be that if parallel fonts are loaded, apps (Word, I'm thinking) may make a hash of the font selection list ... flooding the user with many top-level choices rather than cascading appropriately.

Matt McDonagh

Thomas Phinney said:

If most of your users are on Office and are not graphic designers, then do the build as two fonts. Could be Bunbeg Latin and Bunbeg Gaelic.

This is my intent as it stands. I may keep a combined version (as Bunbeg Pro) for graphic designers, however I am continually surprised with the number of working designers who are unaware of (or just don't use) stylistic sets.

On the subject of diacritics, should I stick with standards or hack an alternative? MS word in particular makes you jump through hoops to insert accents. Or should I write a comprehensive instructional readme file?

Helmut Wollmersdorfer

As I understand the "Gaelic characters" are mainly a different optical appearance. This compares to other historical styles of Latin scripts, e. g. Uncialis, Rotunda, Textura, Blackletter.

Use two different fonts for it. It's easier for users to choose a different font compared to read the documentation and activate a feature (if the authoring software supports features).

If a character has a code point in Unicode that's the way to go. E. g. for long_s or rotunda you should use the Unicode code point. A font should not behave unexpected. If it supports long_s it should render one for the code point of long_s.

I don't know the historical Gaelic alphabet. Is it this https://www.omniglot.com/writing/irish.htm:



It's the question, if the user should enter 1) b + COMBINING DOT ABOVE or you support 2) rendering b_dotcomb for the digraph <bh>. Option 2) should only be a feature turned off by default. For the two different forms of & (e_t ligature and "7") I would use the first as default and the second as a stylistic variant.

I am not a friend of writing text in the modern alphabet and the font renders old forms by complicated feature rules. I know this from German Fraktur fonts, implementing the orthographic rules for long_s versus normal s and all the ligatures, but not the official code point of long_s. This means to control the behaviour by inserting ZWNJ and ZWJ, if you want to transcribe a historical document exactly as it is, including spelling mistakes or historical orthography. This also means to know the feature rules which are specific to the font.

As a guideline for good practice think about authoring as a form of transcription of historical text with 3 levels:

1) modern alphabet. This has the disadvantage that information about the shape is lost. In most cases the text can't be converted back to the original form automatically. The advantage is, that any user can read it, and computer search works.

2) as near as possible to the historical shape using Unicode code points (assigned characters). This needs skilled or trained transcribers, maybe supported by special keyboard drivers or on-screen character-pickers. This means to transcribe b + COMBINING DOT ABOVE as such.

3) academic special level. In historic documents characters, variants or symbols (old currencies or measures) can appear, which are not defined in Unicode or the special shape is scientifically important. Then special fonts using the PUA or tailored feature rules are needed. 

A historical font should IMHO support option 2) at best. This allows a user to display the text in any font supporting the characters even if not rendered fine polished. E. g. it allows me to look at the results of historical OCR in the command line or a text editor, even if the fixed width font (Menlo in my case) renders U + COMBINING SMALL E not perfect.

Thomas Phinney

Note that my suggestion of offering two separate fonts does not mean one could not also offer a single font with features. Or in the first font, it has the features, and the second is available for those who prefer that approach.

ClintGoss said:

I too am producing a user guide, but I am also erring on the side of "separate fonts" rather than stylistic sets, even for things like choosing among figure styles (e.g. tabular/proportional, lining/oldstyle/hybrid).

Word actually supports these distinctions. So for me that seems way overkill. Especially seeing as you would need 6x as many fonts to support all those combinations!

Matt McDonagh

Thanks for your responses. Helmut, that was very comprehensive. At the moment I am using level 2 as you describe above. All of the characters are defined in Unicode, so option 3 doesn't come into play.

I think I'm best to stick with level 2 and build a manual showing users how to activate the dot accents in Word/ InDesign etc.

As a side note, 'et' wasn't commonly used, the '7' variant was the standard. I've used the 7 as the default with an et in a stylistic set.

Helmut Wollmersdorfer

Thomas Phinney said:

Note that my suggestion of offering two separate fonts does not mean one could not also offer a single font with features. Or in the first font, it has the features, and the second is available for those who prefer that approach. 

It's an option to offer precompiled variants of a font. There is an example, Unifraktur Maguntia, coming in 6 variants (16th - 20th century) and a full featured one:



It's questionable, if a font designed 1901 (Mainzer Fraktur) should support the styles of centuries before, or alternate forms easier to read. Look at the K, Ä and x in the last line. These are creations and not the original shapes. Otherwise it doesn't harm to support rotunda (it's a latin character) and even modern console fonts support it. Also it's not wrong to support extended Latin and the combining diacritics with special care for precomposed glyphs for languages historically written in Fraktur. The main 4 forms of the numerals are needed as they appear in old books, also the big mathematical symbols. Same for fractions. But this font is a little bit bloated with 800+ glyphs, supports 35 languages, cv00-cv28, 258 KB, and comes with 4 PDF documentations (EN/DE x Antiqua/Fraktur) each 58 pages. Maybe a showcase for font makers what's good practice and what isn't. See http://unifraktur.sourceforge.net/

Andreas Stötzner

Roman vs. Gaelic style: seperate fonts by all means.

> I've used the 7 as the default with an et in a stylistic set.

although the motivation for that approach is obvious, I’d rather recommend to use the proper encoding 204A for the tironian et sign (to be on the safe side).

In Andron Irisch I made OT styl. set 1 for switching to the traditional insular forms of s and r, and styl. set 2 for replacing bh, ch, gh, mh… by the lenited consonants.

Helmut Wollmersdorfer

Andreas Stötzner said:

Roman vs. Gaelic style: seperate fonts by all means.

> I've used the 7 as the default with an et in a stylistic set.

although the motivation for that approach is obvious, I’d rather recommend to use the proper encoding 204A for the tironian et sign (to be on the safe side).

In Andron Irisch I made OT styl. set 1 for switching to the traditional insular forms of s and r, and styl. set 2 for replacing bh, ch, gh, mh… by the lenited consonants.

This means your font supports encoding/transcription level 1), i. e. use of the modern alphabet and display it by OT-features in old style. This is OK, if the features are turned off by default. A user turning on the features knows what she is doing. In this case it's expected. The use case would be having a text written modern and switch to old appearance. In a controlled environment, e. g. proofreading of OCR in large projects, it can make sense, if the user can switch with one mouse click between Antiqua and historic font plus features. But in an office document it will be boring for me to enter Gh to see Ġ or diagnose a problem. Personally I don't like a digraph <Gh> to change the shape completely into Ġ. Also this needs to know, which font supports it to change or select a font.

Keyboards support input of both encodings. On Mac I can just change to Irish Extended and write in both forms:

Level 1)

Oideachas trí mheán an Ghaeilge i dTuaisceart Éireann

Level 2)

Oideaċas trí ṁeán an Ġaeilge i dTuaisceart Éireann

Level 2a) with long-s

Oideaċaſ trí ṁeán an Ġaeilge i dTuaiſceart Éireann

Existing fonts for Gaelic support all characters with Unicode encoding directly.

http://www.smo.uhi.ac.uk/~oduibhin/mearchlar/fonts.htm#The%20fonts

The author of this webpage does not recommend the use of

<div>'ſ'&nbsp; U+017F&nbsp; LATIN SMALL LETTER LONG S (Lowercase_Letter)
<span style="background-color: transparent; color: inherit; font-size: inherit; font-family: "lucida grande", "lucida sans unicode", tahoma, sans-serif;">'ɼ'&nbsp; U+027C&nbsp; LATIN SMALL LETTER R WITH LONG LEG (Lowercase_Letter)</span>
</div><div><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: "lucida grande", "lucida sans unicode", tahoma, sans-serif;">'ẛ'&nbsp; U+1E9B&nbsp; LATIN SMALL LETTER LONG S WITH DOT ABOVE (Lowercase_Letter)</span>
</div><div><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: "lucida grande", "lucida sans unicode", tahoma, sans-serif;">'⁊'&nbsp; U+204A&nbsp; TIRONIAN SIGN ET (Other_Punctuation)</span>
</div>

but most Gaelic fonts support them. Also the fonts with large Unicode coverage support them, of course with a different shape of the longs.

A fontmaker should support all variants and maybe special features (for people readings docs) to make as many as possible users happy.