In mathematical notation all single letters denominating an object (variable, constant, set, function, ...) are usually written italic. Some special like the number spaces, e.g. the set of natural number are written in blackboard style \mathbb{N}. A powerset is written calligraphic \mathcal{P}, the universal set with Greek capital omega. Named functions like tan or sin are written upright.
Italic does not mean does the f needs to have a hook, it's just a tradition Italian italic, which I also prefer in scientific texts.
If fonts are limited in some context like the engraving on a lens, in drawings or in bold text, then it's maybe not the typical italic or blackboard style. See sample below: bold f in the red box versus f in the legend, upright y in the drawing versus italic y in the legend, bold R in the drawing versus blackboard R in the legend.
Unicode provides the encoding distinction between regular f and hooked ƒ, but with two big caveats:
a) as discussed in this thread, the hooked ƒ is uniied with the florin sign, which may have stylistic and also spacing characteristics in many fonts that make it inappropriate for natural language orthographies;
b) if a typeface design has an italic with a traditional f form with descending hook, then the distinction between f and hooked ƒ is lost, and needs to be managed at the glyph processing level. This means relying on character variant, stylistic set, or langsys locl GSUB, or some combination of these, none of which are a robust mechanism for text interchange and the distinction thus made can easily be lost in a change of fonts.
I don’t see why I would include an italic florin in an upright font. The upright version also reads well in the currency and aperture contexts, and reads perfectly in natural language texts.
On the other side, an italic florin in an otherwise upright font disrupts the reading of natural language text, causes issues when uppercasing a string, and is only marginally better (if at all) in the currency and aperture contexts. Ƒ has no italic uses in upright fonts, and the flip from the italic form to the upright from due to case changes is jarring.
If the italic form is still desired for the currency and aperture contexts, OpenType features can be used, like cv##, ss##, or—if you must—calt, like Apple’s SF does it:
At one time, a script M was used as the symbol for the German Mark. So the idea that the florin symbol might be inherently italicized does not seem odd to me. But in that case, it must not be unified with the LOWERCASE F WITH HOOK that is a letter in the Ewe alphabet, which had better not be in italics unless it is in text with italics.
So my position is one of disagreement with Florian Pircher about the fundamental admissibility of an "italic florin", while I agree that the specific character should not be italicized - but only because it is used as a letter in some languages. If it was only used for the florin symbol - then it could have whatever attributes are the convention for that symbol; special symbols are sometimes intended to be a bit jarring.
To me, though, this seems to be a case where the unwary font designer ends up taking the blame for the mistakes of the Unicode Consortium.
Of course, since the Netherlands is using the Euro now, adding a non-unified florin symbol to Unicode may be... unlikely.
To me, though, this seems to be a case where the unwary font designer ends up taking the blame for the mistakes of the Unicode Consortium.
It is. At any rate, as you say, the Florin has a retroactive importance as an historical currency notation, so less essential. But since it is in many basic encodings, as I am designing a version of Times, I am wondering — given the unified codepoint question · if it’s then more correct to design the character as a f with hook and then provide an alternative.
@John Hudson, if you do not plan to support phonetics or the Ewe language (at least at the beginning), what would you provide? And how would you encode it? I mean, Times usually has a cursive f form, which I suppose at this point would be wrong if encoded as an f with hook as the codepoint implies.
EDIT: I already have the answer. I see how you treated it in your STIX Fonts, which are Times-like: as a straight up “f with hook” form. And that’s just fine, unless one wants a form more associated with the Florin or the f-stop, which can be provided as an alternative, in case.
Note that the STIX Two fonts support IPA, so there is a functional reason for the /fhook is straight up and coordinated with the other letters. These days, I lean towards that as a default approach anyway—it is a good way to future-proof fonts that might be extended to phonetic notation or Ewe orthography—, unless a client specifically requests a traditional florin sign.
Note that the STIX Two fonts support IPA, so there is a functional reason for the /fhook is straight up and coordinated with the other letters. These days, I lean towards that as a default approach anyway—it is a good way to future-proof fonts that might be extended to phonetic notation or Ewe orthography—, unless a client specifically requests a traditional florin sign.
That is very solid reasoning. I think just in case one can provide an alternative to be used as the Florin or fstop symbol.
Comments
Italic does not mean does the f needs to have a hook, it's just a tradition Italian italic, which I also prefer in scientific texts.
If fonts are limited in some context like the engraving on a lens, in drawings or in bold text, then it's maybe not the typical italic or blackboard style. See sample below: bold f in the red box versus f in the legend, upright y in the drawing versus italic y in the legend, bold R in the drawing versus blackboard R in the legend.
a) as discussed in this thread, the hooked ƒ is uniied with the florin sign, which may have stylistic and also spacing characteristics in many fonts that make it inappropriate for natural language orthographies;
b) if a typeface design has an italic with a traditional f form with descending hook, then the distinction between f and hooked ƒ is lost, and needs to be managed at the glyph processing level. This means relying on character variant, stylistic set, or langsys locl GSUB, or some combination of these, none of which are a robust mechanism for text interchange and the distinction thus made can easily be lost in a change of fonts.
On the other side, an italic florin in an otherwise upright font disrupts the reading of natural language text, causes issues when uppercasing a string, and is only marginally better (if at all) in the currency and aperture contexts. Ƒ has no italic uses in upright fonts, and the flip from the italic form to the upright from due to case changes is jarring.
If the italic form is still desired for the currency and aperture contexts, OpenType features can be used, like cv##, ss##, or—if you must—calt, like Apple’s SF does it:
@John Hudson, if you do not plan to support phonetics or the Ewe language (at least at the beginning), what would you provide? And how would you encode it?
I mean, Times usually has a cursive f form, which I suppose at this point would be wrong if encoded as an f with hook as the codepoint implies.
EDIT: I already have the answer. I see how you treated it in your STIX Fonts, which are Times-like: as a straight up “f with hook” form. And that’s just fine, unless one wants a form more associated with the Florin or the f-stop, which can be provided as an alternative, in case.