Florin vs Latin small letter F with Hook U+0192

[Deleted User]

The user and all related content has been deleted.

André G. Isaak

Most fonts don't contain the characters necessary to support African languages, and in such cases it is simply a currency symbol. If you want to support African languages I'd say you should supply separate glyphs using 'locl' since the glyph for the guilder isn't normally going to be appropriate to use as an alphabetic character.

John Hudson

I always design it as if it is the lowercase letter, even if only including it in a font for backwards compatibility with the codepage support for florin, i.e. I don't give it any special treatment as the currency mark, either in terms of slanted style or alignment with numerals, tabular spacing etc..

Although the gilder is no longer an active currency, the florin symbol may still occur in documents, but the f-hook form of U+0192 is acceptable for this use, whereas stylised florin forms are not useful as the letter.

Of course, to be useful as a letter, this character also needs its uppercase counterpart, and other diacritic letters used in the target languages. I take the view that any font I create might get extended to support any language, so even if I'm not supporting Ewe in a first release, I still design U+0192 as if it is the letter, since this will cause fewer problems later.

There's no really good way to support both forms in a font. Probably the least disruptive would be to make the letter form the default — since it is the more important to get right —, and have a florin version as a stylistic variant. I wouldn't try to handle either with a locl substitution.

[On the subject of language-specific substitutions, though, note that if your italic font has a descending, hooked form of f as default, as is often the case for European languages, you will need a variant with either no descender or with a straight descender for Ewe, since f and f-hook are both used and need to be distinguished.]

John Hudson

My Dutch client Brill publishes books that include the f-hook letter and also books that include the florin sign. I asked them how they wanted this to be handled, and they said they were okay with the letter form being used everywhere.

[Deleted User]

The user and all related content has been deleted.

Michael Rafailyk

The user and all related content has been deleted.

That's terrible that we can't read the original question. However, I may understand the privacy requirements. Anyway.

We have the discussion on Glyphs forum about fhook.sc, and I would be very grateful if someone could confirm or deny the suggestion that the small caps version of uppercase Fhook should be different from the small caps version of florin currency symbol.

Ray Larabie

I found it on archive.org. Here's a snapshot of the message:

Denis Moyogo Jacquerye

the small caps version of uppercase Fhook should be different from the small caps version of florin currency symbol

@Michael Rafailyk One is a small Ƒ, the small-cap of a letter, and the other is a small ƒ, the small-cap of a currency symbol.

Michael Rafailyk

So, to differentiate, thanks.
To be clear, I mean that the font will contain both and their design is different.

fhook.sc
florin.sc

And c2sc feature will look like that

sub Fhook by fhook.sc;
sub florin by florin.sc;

Denis Moyogo Jacquerye

This is mixing two approaches. Users who use Ƒ and ƒ as letters would get an incorrect florin.sc (designed like a small-cap currency symbol) when applying c2sc when they’d expect it not to change like other lowercase letters. What about smcp, does ƒ become fhook.sc or florin.sc?

Either Ƒ and ƒ are letters, or ƒ is a currency symbol.

Michael Rafailyk

So, there should be 3 different base glyphs – Fhook (uppercase letter), fhook or florin.loclEWE (lowercase letter), florin (currency) – where florin (uni0192) will be substituted by lowercase fhook (or florin.loclEWE) in locl feature for Ewe language.

script latn;
language EWE;
lookup locl_latn_ewe {
	sub florin by fhook;
} locl_latn_ewe;

And respectively, there should be 2 different small caps – fhook.sc (letter), florin.sc (currency).

smcp feature

sub fhook by fhook.sc

c2sc feature

sub Fhook by fhook.sc
sub florin by florin.sc

Is it correct?

Kent Lew

There are several African languages that use ƒ fhook, not just Ewe. It may not be realistic to try to catch all with {locl} substitutions (especially since texts may not be reliably language-tagged).

I would suggest that if a font is supporting African languages by including Ƒƒ letter pairs, it would be better to make the fhook the encoded default. The florin currency symbol is probably used much less than the fhook from the perspective of language speakers.

Probably the best way to support the currency in this circumstance would be with a stylistic set, I should think.

Denis Moyogo Jacquerye

That works.

I’d recommend making the letter the default for ƒ  instead of the currency symbol, and have a stylistic set for the currency symbol. Some fonts have a contextual substitution before or after digits.

The currency symbol had multiple forms in practice, including letter-size upright f with hook.

Then the Ewe letter is also used in other languages like Avatime, Lelemi, Nyangbo, Tafi and Waci, some don’t have an OpenType language system tag and locl feature support is patchy at best. Additionally one may use words or names from those languages in other languages, for example an Ewe place name or person name in English text (like Turkish Erdoğan).

John Hudson

I’d recommend making the letter the default for ƒ  instead of the currency symbol, and have a stylistic set for the currency symbol.

That’s best, given the situation. Obviously Unicode should never have unified that encoding in the first place.

The currency symbol had multiple forms in practice, including letter-size upright f with hook.

The font that displays in the Typedrawers’ comment input/edit field has this descending-straight form on my system:

  

Thomas Phinney

I see the same thing in the input/edit field. I think we are both on Mac... this looks to be perhaps Lucida Grande, which in this respect differs from Lucida Sans Unicode (the latter using a form which is upright and has a hook on the descending tail).

(The numeral “1” is also a distinguishing clue for telling these two apart.)

Also interesting: though they have the same codepoint, Lucida Sans Unicode has the glyph name “fscript”!

Damn, it sure is a mess!

John Savard

It certainly is true that a currency symbol should not be involved in the unification of alphabetic characters in any way.

As for the African letter, given that Cyrillic and Latin aren't unified, nor Greek and Latin, when only one of the uppercase and lowercase forms of a letter matches the forms of a letter in another language, it would seem as if unification is inadvisable. However, Bulgarian and Serbian are unified with Cyrillic despite some funny goings-on at least among the italics.

Initially, I misread the discussion. I had thought that Unicode already had a florin symbol, and an f-hook to support some European language. Then, all that would be needed is to add a second f-hook to support Ewe, and other African languages with an f-hook would get unified either to the European linguistic f-hook or the Ewe f-hook, depending on which one their capital form most resembled (the remaining differences being handled as language localization stuff). This still wouldn't be ideal, but it would be in line with the current level of support Unicode gives to less popular languages.

But instead, upon more careful reading, I see that only African languages have the f-hook, and the only codepoint currently in Unicode is the florin symbol. Given that it apparently still is the case that some African languages with an f-hook have a capital form radically different from that of Ewe (and presumably more like what a European language with a lower-case f-hook would use if it existed) the daunting problem that is faced is to get the Unicode Consortium to add four codepoints for the capital and lowercase of each kind of f-hook, so that African languages could be reasonably accommodated. Which appears to be extremely unlikely to happen, forcing reliance of advanced localization features not well supported by inexpensive software.

I tend to apply the rule: if WordPad doesn't support it, it doesn't exist.

EDIT: I didn't quite get it right, even on my second reading. In addition to the florin currency symbol, U+0191 and U+0192 for the Ewe letter do already exist in Unicode.

EDIT: Still not right. The problem which was the topic of the thread is that there currently is no distinctive code for the florin currency symbol in Unicode, despite the florin currency symbol having been used in character codes for computers that predate Unicode, and thus the codepoint for the lowercase Ewe letter is being used for that purpose!

The fact noted in italics, of course, is supposed to imply the existence of a distinctive codepoint for said character in accordance with an ironclad fundamental rule of Unicode. The trouble is that to make that codepoint something other than U+0192 violates another basic rule, the one about not deleting, moving, or redefining existing characters. So one could just give the lowercase Ewe letter its own new codepoint, despite that being nonadjacent to the capital - on the basis that unlike the florin, the Unicode Consortium could pretend it wasn't breaking the rule on the basis that it never was really in Unicode to begin with. Of course, that's crazy, and instead the florin currency symbol should get a codepoint in the currency symbols block.

I just won't hold my breath.

However, the Unicode Consortium has had, ever since April 6, 2009, a proposal laid before it to add a distinctive codepoint for the florin, at U+20B9. Since new currency symbols have been added since then, it's possible that this codepoint is already in use, and the current first unused one would need to be used instead (and there's a new Sa'udi Riyal symbol incoming also).

EDIT: Indeed, at U+20B9 is the Indian Rupee symbol, and at U+20BD is the Russian Ruble. So the new Sa'udi Riyal presumably will get U+20BE, and U+20BF is where the florin symbol could be put, if the Unicode Consortium were finally to act on that proposal.