U+0192

John Hudson's picture

Over here Paul Hunt was asking about how to deal with the Unicode unification of the hooked f and florin as a single character. This strikes me as a build issue, so I'm posting comments here.

In the general case of two possible forms for a single Unicode character you usually need to decide two things:

1. Which form will be the default, i.e. which glyph will be mapped to the Unicode character directly in the cmap table.

2. What method will be used access the second form, i.e. in what layout feature is it appropriate to map the non-default glyph to the default glyph?

The fhook / florin case is a troubling one, though, because there isn't an obvious answer to the second question. Personally, I think it was a really bad unification in Unicode: the florin should have been encoded separately in the currency symbol block. But it is much too late to do anything about that.

I usually make a font-level distinction about this character. If a font has limited language support, e.g. it only supports the Latin 1 character set or one of its derivatives (Mac Roman, MS codepage 1252, etc.) I'll encode a florin symbol glyph a U+0192. If a font supports a wider range of languages, including languages that use the hooked f as a letter, then I'll encode a normal lowercase hooked f glyph at U+0192. The choice can be simplified like this: Does the font contain an uppercase hooked F (U+0191)? If so, then the U+0192 should be the letter not the currency symbol.

It would be possible, in the latter case, to include a special florin currency symbol glyph simply as a stylistic variant, but my inclination would be not to. The straight, lowercase hooked f is recognisable as a florin sign, and there is a risk of ending up with the wrong glyph in text where the hooked f letter is desired, which would be very bad.

A more troubling aspect of the hooked f is that a regular italic f very often has a hooked descender, and is confuseable with the hooked f: f ƒ. So in font families that support languages that use the hooked f as a letter, you need to make a decision about how to design the normal italic f? Do you draw it without a descender? Do you draw it with a straight descender? Do you draw it with a reduced lower terminal? Or do you draw it with the hooked terminal but provide one of the other forms as a stylistic variant for use by people who need to make a distinction with the hooked f?

paul d hunt's picture

sorry to throw you off with retracting my original post and then bumping a separate thread, &c, but thank you for giving your take, John.

Personally, I think it was a really bad unification in Unicode: the florin should have been encoded separately in the currency symbol block. But it is much too late to do anything about that.

I agree and this is an unfortunate situation. Your solution is very straightforward, I had decided to make the hooked-f the default in a project i'm working on and was mostly wondering how to handle the florin, but i think the florin consideration is not that important.

Thomas Phinney's picture

What about using the 'locl' (locale) OT feature to help the distinction between the two forms?

T

paul d hunt's picture

A more troubling aspect...

i'm finding that this is a general problem with many of the hooked letters for African languages, especially in italic fonts where the hook could be confused as just a chancery swash.

John Hudson's picture

What about using the ’locl’ (locale) OT feature to help the distinction between the two forms?

You mean for distinction to distinguish a variant italic f from the italic hooked f? Yes, this would be possible, although I'm not sure exactly for what languages it would be appropriate. I'll see if I can draw up at least a partial list and post it here.

One of the fonts for which I've been asked to include support for U+0192 as a letter uses it in a romanisation scheme for ancient semitic scripts. So one might end up with a 'latn' script tag and e.g. a 'HEB' language system tag, i.e. Hebrew written in the Latin script. This is certainly possible in the context of OpenType Layout architecture, but I wonder into what application support issues this might run?

paul d hunt's picture

Yes, this would be possible, although I’m not sure exactly for what languages it would be appropriate.

isn't that the main problem? Many of the languages that use/will be using the hooked f are still developing standard orthographies, or they have not been recorded yet. Is that correctly stated, John? I guess you could always use a stylistic set, but that's a bit inelegant isn't it?

John Hudson's picture

The relative instability and/or lack of record for developing orthographies may be an issue, but it isn't necessarily a major problem. It can become a problem if application developers assume a relationship between the misnamed OpenType 'language system' tags and natural language tags for e.g. spellchecking, hyphenation, etc. But if it is possible to access the OT Layout tags independently, then users have a mechanism to select the typographic conventions that they want, and the association to particular languages is simply a convenience.

I guess you could always use a stylistic set, but that’s a bit inelegant isn’t it?

Even if I were using the language system tags for this sort of thing, I would still also provide access via a stylistic set. I don't think this is 'inelegant': there is a variant form of the f in an italic font, and some users may wish to deploy it. There is an orthographic reason for the variant to exist, and some users may require it to make an orthographic distinction, but others may simply like that form.

typovar's picture

Apart from all possibillities in programs etc. You do know that this florin-sign is no longer of (real) value in Holland. I don't know of any other currency that use florin, but in Holland we ended up using €.

John Hudson's picture

But presumably there are a lot of existing documents from the pre-Euro period that still need to display the florin symbol, even if its use is now historical. History is real too. :)

typovar's picture

I realised that later too...
Because I had to use ƒ.
Silly!

Syndicate content Syndicate content