Brill font

ycherem's picture

So far I haven't seen much comment about John Hudson's Brill font. It was great news to me, but all I've found was the pdfs on Brill's webpage. It sounds strange it hasn't received much comment or reviews so far -- or am I missing something?

John Hudson's picture

Custom proprietary fonts, even if also made publicly available (for non-commercial use), tend not to attract as much comment as new retail font releases. Which is fine by me: I know the fonts are getting good use by Brill, and have had some nice emails from individuals using them for e.g. Phd dissertations.

If you're interested in commentary about how the fonts were built, rather than about the design, check out this video of the talk Text to Typeform, which I delivered at Brill's symposium on type and scholarship last November. [Apologies for the staggering number of times I say 'um' and 'ur' during the talk: I'm barely aware of it while I'm speaking, and always appalled when I hear recordings afterwards!]

Renko's picture

If you’d like to use the Brill font files you have to agree at the End user licence agreement page. (Scroll down)

After you have clicked the »I agree« button you can download the complete files.

John Hudson's picture

I have uploaded the slides of both my presentations at the Brill symposium and exhibition opening at the Boerhaave museum in Leiden last November:

Text to Typeform: building the Brill fonts
[These are the slides from the video linked above]

Scholarship -> Typography -> ... : designing the Brill types
[No video or accompanying texts for these, I'm afraid.]

ycherem's picture

Thanks a lot, that's what I was looking for! Hope to begin using it soon.

charles ellertson's picture

Just being a little careful here. A number of the threads you've started concern using type for what might be considered "commercial" work. "Not-for-Profit" isn't the same thing as "non-commercial" -- otherwise, most any university press could use these fonts. And that's not the case; they can't.

I'm not a lawyer & don't know, but if you publish journals & there is any fee at all for them, even if, in your eye, it is just to cover some of the distribution costs, Brill might consider that commercial & outside the license.

Best might be to write Brill & explain your intended uses, if for any kind of publishing.

alden52's picture

In my understanding on their given rules, anyone who want to use Brill font for commercial, you have to ask their permission. In addition, there is charge when it is commercial use.

ycherem's picture

@charles
---A number of the threads you've started concern using type for what might be considered "commercial" work.
No, absolutely NO threads I've started concern using type for commercial work.

charles ellertson's picture

Well, you've never said whether you're preparing manuscripts or final copy for printing, but I took

http://typophile.com/node/81296

as a possibility of something that, when published, had a purchase price.

Same with
http://typophile.com/node/86692

and maybe
http://typophile.com/node/91665

"Commercial" doesn't mean you're making money. One of the old, classic jokes is

"How do you make a small fortune in publishing?"
"Start with a large fortune..."

ycherem's picture

@Charles,

I see your point. At that time I just wished I had some leverage to suggest, as future editor/translator of the publication(s), the fonts/look for the actual designer. The experience with the actual design of academic journals I published in was rather unpleasant, so I thought, if I'm in charge of some publication or other, I won't let a book that cost so much in terms of time and money be published, and sold at a reasonable (that is, expensive) price, but still in Times New Roman. I always thought that, even if the publication is open access and also available online (the case with all my published articles), it does deserve some attention.

Otherwise, all I do is just typeset my all articles and handouts for students -- I wouldn't dare give them some "12pt double spaced Times ragged right" kind of syllabus.

But thanks anyway for your comment.

ilyaz's picture

Since I have a keyboard which allows exploration of such fonts [*] (and since I thought that it would help in showing the docs of the keyboard :-[) I did some (really trivial) experiments with the font. I investigated only diacritics on the ffl ligature (and the related topics). The results are: (a) very nice and impressive; (b) showing the limitations of the approach. (Instead of (b), they may be just bugs. ;-)

I focus on these: ƚ̧́ ļ́l̊́ ĺ̨. Note that on ƚ the cedilla is shown as ‘ₛ’, but on l it is shown as comma. One can put the stress (=acute) mark on l-ogonek, but not on l-cedilla. (This might be related to the exponential blowup of number of needed OT substitutions; or they may be just bugs…. On the other hand, I suspect that one do Unicode-like reordering of diacritics with linearly increasing number of rules — must think about it more…) (And maybe John just knows that ļ is never a vowel; I do not know — I do not speak languages where l is a vowel. ;-)

But this is just on the theoretical front; I did not try to invent a scenario where this would be a real-life problem. The major problem for end-user applications is that the font is “a specialized font”, so does not play games with the font environment. A lot of useful glyphs are missing (I did not try to time this, but my first impression is that the coverage for LCG is about the same as one of DejaVu, which is somewhere about end-of-90s/beg-of-00s). And when they are missing, they are not just let be subbed by .notdef: they completely disappear (in most of the cases: empty 0-width glyph) or are drawn as an explicit placeholder glyph (I did not see the latter in action, but this is what the character map shows; maybe this is circumvented by OT features).

Essentially, this means that systems which pick up a font automatically to show missing glyphs will be confused and will think that Brill supports all these “empty” characters. Which would mess up things enormously — the text which was shown fine before Brill was installed may now be not shown (and not shown in a very disasterous way — by just disappearing). (This is exactly the problem which forced me to start to tinker with GNU unifont.)

Ex: ₙₘₗ ⲁⲗⲫⲁ ⲃⲓⲇⲁ ⲅⲁⲙⲁ Ꚇꚁ꠷ нⷺт ꞡꞡ ļᶂḟƚ̧́

[*] http://k.ilyaz.org/iz

John Hudson's picture

Ilya, in what environment are you testing, and do you know whether OpenType GSUB and GPOS are properly supported (note that, for example, there is a bug in Adobe InDesign, up to and including CS6, that fails to handle {ccmp} decompositions for extended combining mark sequences lookups resulting in incorrect positioning of combining marks relative to precomposed diacritic characters that should be decomposed by the font).

It looks like there may be some issues with multiple mark positioning on l. Not sure why, but probably fixable. Thanks.

Note that on ƚ the cedilla is shown as ‘ₛ’, but on l it is shown as comma.

That seems to be because some software performs a character level substitution of l + combining cedilla to the Baltic ļ.

When you say 'a lot of useful glyphs are missing', I don't know whether you mean glyphs or characters. The character set coverage was defined to meet Brill's publishing needs. They had an extensive wishlist, based on current publication lists, review of existing publications, and new series. Now that the initial release of the fonts has been made, I anticipate review of possible additions, including some characters that have been added to Unicode since the glyph set was originally spec'd.

The font contains a clearly identifiable .notdef glyph, and if this is not being displayed in place of unsupported characters, then that is a software problem, not a font issue. Specifically, I think what you are seeing is the result of software not recognising fairly recent Unicode additions as characters, and failing to fall back to the .notdef glyph. I pasted your example string into Wordad on Windows Vista, and depending on what font I select I get various different permutations of invisible and .notdef glyphs. In NotePad, however, I get consistent .notdef glyph display for all unsupported characters. This tells me that the problem is likely something to do with RichEdit font fallback mechanisms.

ilyaz's picture

> Ilya, in what environment are you testing, and do you know whether OpenType GSUB and GPOS are properly supported

Right now I'm on Windows, and I test in Notepad, FF, Chrome, IE9 and LibreOffice. Sorry, I still did not manage to understand all the details of their support of OT…; all I know is that Notepad/Chrome is GDI, and FF/IE9 are DirectSomething.

> When you say 'a lot of useful glyphs are missing', I don't know whether you mean glyphs or characters.

Shame on me — I meant characters! My immediate needs are math notes in plain Unicode text (which implies UPA ;-), and displaying of docs for my keyboard layouts. (Since a significant part of the layouts is autogenerated based on heuristics based on Unicode tables, they contain a lot of flak; still, I'd rather this flak was displayable…)

> Specifically, I think what you are seeing is the result of software not recognising fairly recent Unicode additions as characters, and failing to fall back to the .notdef glyph.

I never saw anything like what you describe.

E.g., I look at the font in the Character Map. It displays a lot of empty glyphs (say, about U+04da) and a lot of narrow-rectangle glyphs (e.g., about U+0770 — but this may be what you hint to above…). Need to investigate it more….

John Hudson's picture

The Windows Character Map is notoriously unreliable as an indicator of what a font actually contains, because it makes use of the same system fallback mechanisms that also affect -- or afflict -- Wordpad and Word. So, for instance, it will display Arabic and Indic characters from a fallback font for pretty much any font, even though the font does not support them. For instance, it shows this for Brill, even though Brill supports no Indic scripts:

As you note, at other times Character Map shows the .notdef glyph for unsupported characters, and sometimes just a blank cell. I long ago concluded that the purpose of the Character Map tool is character selection, and there's no point to it providing a selection of fonts at all, especially since it's copy-to-clipboard function doesn't include font selection formatting.

With regard to the fallback issues I referred to in Wordpad, this is what I see when I copy your example string from FireFox into WordPad and set it in a variety font fonts:

What you are seeing here is a variety of different failures. Some fonts display .notdef for some unsupported characters, none of the fonts display anything at all for the U+A6xx range characters, all of the fonts display something recognisable for н and т even though most of them do not actually support those characters (i.e. font fallback is being used).

Syndicate content Syndicate content