Template talk:f/

Discussion

“... using an italic serif font for the letter f (as is conventional in photography).”

I don't quite agree. When all is said and done, f is a quantity symbol in the context of both f/# and f-number, so it's naturally set in oblique type. When the running text is set in a serif font, as usually is the case, the upright font is “roman” and the oblique font is “italic” (cursive as well as oblique). And that's the context in which the f-number is normally seen. But there's nothing special about the symbol f—it's simply the italic font of the typeface for the running text, not a specially selected typeface.

The situation is different when the running text is in a sans-serif typeface, as is the default for Wikipedia. Common practice then is to use the oblique font of the regular typeface; good examples are the ISO standards for photography, which use sans-serif type and set quantity symbols in the oblique font of that face.

NIST Special Publication 330 and Special Publication 811 ostensibly support the claim that quantity symbols are always set in italic type, regardless of the surrounding text. But they also equate “roman” and “upright”, and “italic” and “sloping”, apparently assuming that running text is always set in a serif typeface. But they don't specifically mention using a serif typeface. In SP 330, in the appendixes describing the decisions of the CGPM and CIPM, the running text is in sans-serif type, and the quantity symbols are in the oblique font of that typeface. The same is true for the diagram at the end of SP 811. The BIPM follow the same practice in their SI brochure.

In sum, normal practice is to put quantity symbols in the oblique (or italic) font of the face used for the running text. I am no fan of using sans-serif type for running text; I think it's much harder to read, and that mathematics set in sans-serif type are generally ugly. The majority of books are set in serif type for good reason. But not everyone agrees, and Wikipedia have chosen sans-serif type for the default appearance.

There is, of course, a general issue of consistency for any Wikipedia article that includes mathematics. The TeX preprocessor sets everything in a serif typeface, and it's a different face than the serif font used when simple mathematics are rendered using HTML. So what does one do? Use TeX for all symbols in the running text? Additionally force TeX rather than HTML rendering? Usage that I've seen shows little consistency, and I readily admit that I'm as guilty as anyone else.

Using forced TeX rendering for all quantity symbols would arguably be the least confusing, if not the best typesetting practice, but in many cases it would also entail much unnecessary graphical rendering. Because of this, I generally use the running typeface for quantity symbols in the text, including the f/ symbol unless an article already makes extensive use of the template.

I readily admit that the result using the template is more attractive than using the running-text font, at least with the default font. But it's not quite right; a better approach would be for the template to simply set the italic (or oblique) font of the running typeface. JeffConrad (talk) 00:55, 1 August 2008 (UTC)

I've made separate replies under different parts of your response. JeffConrad (talk) 06:54, 1 August 2008 (UTC)

I agree with much of what you have written, in particular I'm very familiar with the fact that quantity symbols are conventionally rendered in the oblique or italic version of the font used in the surrounding text. The symbol for f-number is not an ordinary quantity symbol, however. It has a different syntax: One writes f/2, rather than $f=2$, for example. (The ordinary quantity symbol $N$ is sometimes used instead, so $N=2$ for an f/2 lens.) I made this template because someone or some source asserted that in photography the f/ symbol is always written in a serif italic font. I don't remember what the source of that claim was now, but it doesn't surprise me that the f/ symbol in photography might obey a different typographical standard than quantity symbols in scientific and mathematical usage. I'll have a look later to see if I can figure out what the source of the claim about the typography of f/ was.

I think your original argument was right; it looks as if you gave in a bit too quickly. I have great respect for Dick Lyon, and overall, we generally agree. On some issues, however, we differ, and this apparently is one of them. I did not see a single citation of an authoritative source supporting the argument that f is always set in serif type. Dick and I had a brief discussion (see Talk:Depth of field, under Fancy Italic “f”—I can't get the section link to work). He cited ANSI PH2.12-1961, Sect 3.4.2 as the basis. Indeed, that document called for the symbol for focal length to be a “long hooked f”; however,

1. That standard is set in serif typeface, so its oblique font is italic, and
2. In most italic fonts, the letter f is hooked—again, italic fonts are cursive as well as oblique.

Consequently, that document doesn't prove anything, though it probably implies that using a sans-serif font for the f symbol when the running text is in serif typeface would be deprecated. ANSI PH3.49-1971 states the same requirement, again in Sect. 3.4.2, and the result is the same: the f is simply set in the italic font of the primary typeface, as one might expect.

There aren't that many examples with sans-serif type for the running text, but the ISO standards and the NIST and BIPM documents would seem pretty authoritative. Were someone to cite an authoritative source that showed a serif f in sans-serif running type, there might be some question, but nothing even close has been cited so far. I'll concede that typographical practice is all over the map; it's easy to find f4, f/4 as well as f/4, but in many cases, other examples make it clear that the editor had little understanding of mathematics or typesetting. JeffConrad (talk) 06:54, 1 August 2008 (UTC)

You've raised a good point, and you may be right. I'm not clear on one thing, though: does ANSI PH2.12-1961, Sect 3.4.2 or one of the other sources explicitly call for a "long hooked f", or does it merely show an example of the symbol? A source that explicitly specifies how the symbol is to be formed is more relevant than one that merely uses the symbol or gives an example.--Srleffler (talk) 21:30, 1 August 2008 (UTC)

Both ANSI standards merely give examples rather than specifying a “long hooked f” or anything similar; I actually scanned the text from both and compared the specified symbols with italic fs from other parts of the documents, and could see no difference at the greatest magnification at which the letters held together. JeffConrad (talk) 21:57, 1 August 2008 (UTC)

The f in "f-number" is not a quantity symbol either. It obeys normal English rules, including that it will be capitalized if it occurs at the beginning of a sentence. "F-number" is just an ordinary English phrase.

What else could the f logically be, though? Here again, practice varies, but some of the better publishing houses treat it as a quantity symbol (e.g., Sidney Ray's Applied Photographic Optics by Focal Press, which is arguably pretty authoritative). Since logic suggests that indeed the f is a quantity symbol, the safest approach would seem to be to treat it that way. I'd rather follow Sidney Ray than some web expert. JeffConrad (talk) 06:54, 1 August 2008 (UTC)

Logically, the "f" in "f-number" could be a quantity symbol, but it could also be merely an abbreviation, since the "f" is not being used as a mathematical entity in this context. Whether "f-number" or "f-number" is correct is a style choice. I prefer to treat it as an abbreviation, allowing "f-number" to be formatted as normal English text. You'll find examples of both choices in the literature.--Srleffler (talk) 21:30, 1 August 2008 (UTC)

I was about to post this when I collided with your edit ... On rethinking my last sentence, I didn't mean to imply that you were relying on something off the web. I sometimes attribute more evil to the web than it merits; I really meant to say that some authors and publishers are more reliable than others. Of course, deciding who is “reliable” is somewhat subjective.

There is another possibility for the f; if it's not a quantity symbol, it's certainly a letter used as a letter, and as such, should be set in italic (or oblique) font—see The Chicago Manual of Style, 15th ed., Sec. 7.63. If this were the case, of course, the f would probably be capitalized at the beginning of a sentence. I don't suggest that CMS is infallible, but it's seldom a blunder to rely on it. I agree that both treatments of f-number are found extensively in the literature, but as I've said, there's a lot of strange stuff out there—in print as well as on the web. Of course, how f is treated in this context is arguably irrelevant to this template. JeffConrad (talk) 21:57, 1 August 2008 (UTC)

I agree that that is a valid third interpretation. I tend to think of "f-number" as a single concept. When I use the term, I'm not thinking about the f either as a symbol or abbreviation for "focal length". I notice that the article Student's t-test uses italics for the t.--Srleffler (talk) 05:56, 2 August 2008 (UTC)

I reviewed a number of my photo books and other publications, and just as I recalled, practice varies. But I did notice that among the more “technical” publications (e.g., Sidney Ray's Applied Photographic Optics, The Manual of Photography (9th ed.), and the OSA Handbook of Optics), the f is set in italics. Moreover, although the indexes of those publications capitalize the first letter of each entry, they use lower case for the entry f-number, so it's obvious they consider it a quantity symbol. The ISO photography standards follow the same practice, setting the f in oblique font (because they use sans-serif primary typeface). None of the ISO photography standards that I have includes an index, but they nonetheless use f-number in places where they otherwise use inital caps—so they also consider it a quantity symbol. Let's face it; the f-number is the denominator of an expression such as f4, strongly suggesting that the fs in both places represent the lens focal length. I don't claim that this absolutely establishes my position, but it does strongly suggest that there's nothing wrong with treating the f in f-number as a quantity symbol. JeffConrad (talk) 09:10, 2 August 2008 (UTC)

The only reference I have in hand is Greivenkamp's Field Guide to Geometrical Optics. Interestingly, he uses "F-number", but chooses "f-stop" (no italics in either). His "f/" appears to be in the italic form of the typeface used in the running text, which is serif.

A side issue not really related to your main point: you mentioned that most books are set in serif type for good reason, while talking about Wikipedia's default choice of a sans-serif font. There is actually a good reason for Wikipedia's choice. Sans-serif fonts are often more readable on a computer screen than serif fonts are. The reason is that computer screens don't have high enough resolution to display serif fonts really well. If you look closely at a typical serif font in a book, you'll notice that the strokes in the letters are not all the same width, and in particular the serifs are narrow. On a computer screen, there are not enough pixels across the width (or height) of each character, so serif fonts are rendered with all of the strokes the same width (for characters at typical sizes on screen, obviously). This dramatically decreases the readability advantage that serif fonts have over sans-serif in print. Sans-serif fonts suffer less from the limited resolution of typical computer displays.--Srleffler (talk) 02:41, 1 August 2008 (UTC)

At one time, this undoubtedly was the case, but it's probably less true today as monitor resolutions have increased. Perhaps my viewpoint is skewed as I look at a 24″ monitor in 1920×1200, and perhaps my eyes have degenerated to the point where I can't see the fuzzies any more. But this might simply suggest that use of a sans-serif typeface be an option rather than the default. In any event, if serif type is unsuitable for running text, it's every bit as unsuitable for mathematics and quantity symbols. JeffConrad (talk) 06:54, 1 August 2008 (UTC)

It is still the case, depending on how large you like your text on-screen. While display resolutions have increased over the years, screen sizes have increased as well, and the number of pixels per character has tended to stay about the same. (Windows, for example, by default makes characters smaller when the display resolution is increased.) It's pretty common for characters of convenient size on-screen to be only a dozen or so pixels high.

Assuming your monitor isn't widescreen, the size and resolution you mention give less than 100 dots per inch resolution. On paper, 300 dots per inch is considered "letter quality", and modern printers typically deliver at least twice that. Professional publishing uses higher resolutions still. Serif fonts are quite readable at 100 dpi, even at relatively small character sizes. The issue is just that they do not have the readability advantage over sans-serif that they would have if printed at higher resolution.--Srleffler (talk) 21:30, 1 August 2008 (UTC)

The monitor I mentioned is WUXGA, so it is wide screen. I agree that sans-serif type is probably the better choice if the objective is to read 4-point type, but I had trouble with that even when I was much younger. Comparing serif and sans-serif documents in an application such as Acrobat 9 (or Adobe Reader 9), I still find the serif document far more legible. The advantage may not be as great as when printed at 1200 dpi, but it is an advantage nonetheless. In any event, if serif is bad, it's just another argument for putting the f-number in sans-serif typeface :-). JeffConrad (talk) 09:10, 2 August 2008 (UTC)

See Talk:F-number#Revert, where I started out arguing the very same point you are making above. It was that discussion that resulted in me making this template.--Srleffler (talk) 02:51, 1 August 2008 (UTC)

As I mentioned, I think you had it right in the first place—certainly nothing authoritative was cited to refute your position. I certainly don't claim infallibility, but I think I've supported my position with pretty solid sources, and I've not seen anything even close supporting the alternative. Unless a credible counter is presented, I'd suggest that we go with what seemed obvious to both of us. JeffConrad (talk) 06:54, 1 August 2008 (UTC)

I'm hoping Dick will weigh in on this. I would like to hear his opinion before we make any changes. While looking at this, I noticed some typographical inconsistencies in f-number. For now, I'm going to fix these to make the article consistent (using this template). If we decide to go from f/ to f/, we can just change the template.--Srleffler (talk) 21:30, 1 August 2008 (UTC)

I'm also hoping he will comment. As I mentioned, he and I began a discussion on this a while back that we never quite finished.

Broader use of the template (specifically, by me) was my reason for starting this discussion. One big advantage of the template might be the ability to include a nonbreaking thin space ( ) to give something like f /4 rather than f/4 if deemed preferable. What's the big deal? For some reason, HTML doesn't treat a thin space as nonbreaking, so CSS is necessary to make the coding robust; e.g.,

<span style="white-space: nowrap"><var>f</var><span style="font-size: 40%">&thinsp;</span>/</span>4

Not exactly fun to type with any regularity.

We could also create an {{fnum}} template for those who wish to treat the f as a quantity symbol. JeffConrad (talk) 09:10, 2 August 2008 (UTC)

Template change

So, I think Jeff has made his case above. The question then is which do we prefer:

1. f/2: ''f''/2
2. f/2: <var>f</var>/2
3. $f$/2: <math>f</math>/2
4. $f/2$: <math>f/2</math>
5. f /2: <span style="white-space: nowrap"><var>f</var><span style="font-size: 40%"> </span>/</span>2

I'm sure I've missed some variants.--Srleffler (talk) 13:59, 2 August 2008 (UTC)

Hopefully, the choice rests more on what is correct than simply personal preference. It would seem to me that the fundamental choice is whether the f is set in the oblique (or italic if the user's skin or CSS page uses a serif typeface), or is specifically set in serif italic font. Examples 1, 2, and 5 above are variations of the former; examples 3 and 4 are variations of the latter.

With the oblique font of the primary typeface, the <var> is arguably of less value when using a template, so that for most purposes, 1 and 2 above are equivalent. The <var> tag would still be visible when viewing the page source, but would be of little help to an editor searching for all variables. The extra padding around the slash in example 5 is simply to avoid the problem most browsers have when switching from italic/oblique font to the upright style; the exact value probably should be tested with different font sizes and possibly even with a different standard skin, such as MySkin, which uses a a serif font. The idea was simply to provide the minimum separation for acceptable aesthetics, roughly emulating troff's 1/12-em space (\^), which also conveniently was nonbreaking.

A case could be made for using the LaTeX engine for consistency between symbols in the running text and those in displayed mathematics. But I think the argument is weak unless the same policy is used for all quantity symbols in the text. Moreover, unless each instance forces PNG rendering, the symbols still may not match. Some examples:

HTML (unless user preferences are set to force some other rendering):

• $f$/2
• $f/2$

PNG (via the TeX engine):

• $f\,\!$/2
• $f/2\,\!$

As can be seen, the first HTML rendering has the same problem with the serif f, and in fact, it's slightly worse. In the second HTML rendering, the spacing is excessive—the preprocessor inserts ordinary spaces on either side of the slash (this can be confirmed by viewing the source). The spacing with the PNG (TeX) rendering could be fixed with some negative spaces:

• $f\!/2$
• $f\!/\!$2

But it should be fairly easy to achieve reasonable aesthetics with either approach. The primary question is whether the f is a special entity or whether it's simply set in the italic/oblique font of the primary typeface. There is much to support the latter; I haven't seen anything to support the former. Unless some reasonable argument supporting the special treatment is presented, I think we should change the template to reflect normal practice. JeffConrad (talk) 22:11, 2 August 2008 (UTC)

I normally do mark quantity symbols in running text with the <math> tag, rather than italics. Wikipedia currently has inconsistent font rendering for math, but this is a software problem that will surely be fixed someday. In the meantime, it may be best to tag for semantic meaning and trust that good typography will come along later. This is a different idea about "what is correct": that quantity symbols should above all be tagged as mathematical entities in the hypertext, and that appearance is of secondary importance. Ideally, we might find a way to satify both concerns. --Srleffler (talk) 17:41, 4 August 2008 (UTC)

And I use the HTML <var> tag for much the same reason. I'm a strong believer in separating content from appearance, but in some cases, the software just doesn't do its part. Ideally, the <math> and <var> tags should be given the same rendering, but that's obviously not the case at present. From long experience, I have about as much faith in document processing systems providing good typography as I do in politicians doing what they say they will do. It well may happen, but the question is whether it will be in my lifetime. Ironically, some of the older systems such as troff and TeX still often do a better job than the newer, fancier systems. With the right macros, they also can do a better job of separating content from appearance. CSS is a big help for doing so in HTML, but a really good separation requires XML, which I don't see in the cards for Wikipedia—it would probably scare most potential contributors.

As much as I prefer the separation, when there's a conflict between appearance and the cleanest possible coding, I usually defer to appearance if it can be done without resorting to gross hacks. The reader has to come first; it's simply not fair to make software deficiencies his problem. Of course, in this context, that's one of the benefits of a template. If the rendering of mathematics and ordinary text is ever unified, it's easy to make a global change. At present, for the sake of appearance, I'd go with Example 5, keeping the <var> for the sake of form.

At present, the decision of whether to use the <var> tag or the <math> in the {{f/}} template also unavoidably goes back to the question of how to set quantity symbols in running text. If we use the latter, it most logically is done with the assumption that other quantity symbols will also be indicated with this tag. A quick examination of articles suggests that this is the exception rather than the rule; the most common approach seems to be simply using the normal Wikipeida italic idiom of two apostrophes. As I've noted, though, practice varies, even within articles and even by the same editor). In any event, a decision to use <math> for the sake of assumed consistency is in essence a decision to set all quantity symbols in serif italic font. Perhaps some day this will change, but I see nothing to indicate that such a change is imiment, or even that it ever will happen. Because of that, I'd opt for the <var> tag as the general choice, including the template. JeffConrad (talk) 23:38, 4 August 2008 (UTC)

I took a look through Wikipedia:Manual of Style (mathematics). I don't see any explicit documentation on how to handle variables in running text there. The MoS is agnostic about LaTeX vs HTML for formulas, however. I notice that they do favor standard Wiki italics markup over the <var> tag.--Srleffler (talk) 02:27, 5 August 2008 (UTC)

The MoS was one of the bases for my comment about the apparent preference for two apostrophes; other parts of the MoS recommend keeping markup to a minimum. In any event, the MoS doesn't address all of the issues that I mentioned, which is why I raised them. What is “correct” in the Wiki sense therefore is probably open to debate, but there is something to be said for consistency within a given article, whatever the choice. Again, I'd probably match the rest of the text; then even if the user specifies a different global font, everything will still match.

I suggested using the <var> only in response to your preference for <math> tags in general. As I mentioned earlier, I really don't have a strong preference, especially in a template where an editor can't even see it. Hiding the information in a template is probably just as good as indicating true content with the appropriate tag.

The preference for two apostrophes implies a preference for putting quantity symbols in the “italic” font of the primary typeface, much as you and I thought from the beginning. If the f is just another quantity symbol, which nearly all evidence suggests, it should be given the same treatment. My recommendation, again, is Door #5, with either the <var> tag or the regular “italic” markup. If that is the decision, we probably should give other inline quantity symbols the same treatment for the sake of consistency, though this entails some additional effort for complex entities. If that's deemed the preferred approach, though, I'll make the appropriate changes to the articles in which I've been involved. JeffConrad (talk)

There is one consideration that I overlooked. If the browser is set to zoom only the text (as I sometimes have it with Firefox 3), the combined TeX/HTML rendering (Example 3 above) changes the size of the f but not the 2. This might argue in favor of HTML rendering. I very quickly experimented with several serif and sans-serif typefaces in user CSS, and Example 5 seemed to give the best results with everything that I tried. So #5 would be my recommendation. As I mentioned, I don't have strong feelings about using the <var> tag. JeffConrad (talk) 04:42, 3 August 2008 (UTC)

My feeling remains that the sans-serif oblique is just not right. Even Sidney Ray specifically says "the italic letter f and an oblique stroke" ([1]). There are exceptions to this usage, and no reliable source to say exactly what the "convention" is, but in my studies of many sources, I was pretty convinced that the long italic f was most common in the f/#, but not in "f-number". I realize that's "original research", so we shouldn't make such a claim in article space, but I think it is reasonable justification for choosing a typographical conventional to use in the template. Dicklyon (talk) 03:59, 4 August 2008 (UTC)

Dick, how many sources have you examined that use sans-serif type for the running text but use f/#? Ray makes no mention of serif typeface; the book (which I actually cited in support of f-number) is set in serif typeface, so I don't think the comment cited proves anything. The only works that I've seen (several of which I've cited) that use sans-serif typeface for the running text use sans-serif oblique for quantity symbols. Were there specific directives from several reliable authors to always use serif type for quantity symbols (or publications from major publishers exhibiting such a practice), the proper approach might be open to discussion. But I don't think any such examples have been cited.

Strictly, there is the distinction between “italic” and “oblique” that I have repeatedly mentioned. But few people are aware of this distinction, and it's seldom made in most document processing systems (e.g., Microsoft Word and Wikipedia). When one calls for “italics” (e.g., by the use of two apostrophes in Wikipedia), the usual result is the oblique font of the current typeface. If the current typeface is serif, the font is true italic; if not, it's simply oblique. Every publication any of us has mentioned follows this practice. I think it's simply a matter of typesetting convention rather than anything more complex: use fonts that were designed to be used together. Absent a compelling reason, one changes fonts in the same typeface but does not change typefaces, at least in the same context (e.g., running text). Is there ever a reason to mix typeface families? Sure, and I do so to indicate various items in the tutorial for my Sun/Moon Calculator—but I think it's obvious that that's quite a different situation from what we're discussing here.

Exceptions are easy to find if one looks hard enough. One that quickly comes to mind is Merklinger (e.g., Focusing the View Camera)—he uses serif type for the running text but sans-serif bold for quantity symbols as well as displayed equations. I don't suggest that this is wrong, but simply that it is quite unconventional. And it should be noted that because he was self published, that book wasn't subject to review for conformance to publishing convention.

Again, I'd to see something that specifically says that quantity symbols are always set in a serif italic font—and I have seen nothing even close. My position, as well as the one Srleffler initially mentioned, is that quantity symbols are set in the oblique/italic font of the primary typeface, and publications from major technical publishers such as Elsevier (The Manual of Photography and Applied Photographic Optics), and standards organizations such as BIPM, ISO, and NIST all follow this practice. I think that, as Wikipedia editors, we have no choice but to follow clearly established practice. Toward that end, I think we should go with Example 5. JeffConrad (talk) 07:57, 4 August 2008 (UTC)

Please stop bringing "quantity symbols" into the discussion in this way. It mischaracterizes the issue. Nobody is proposing that all quantity symbols should be set in serif italic type. The issue is purely whether the f/ symbol is a special case with a distinct typographic rule. This is not uncommon in mathematical typography. One example that comes to mind is the finesse of an etalon, which is represented by the letter "F" in a script typeface: ${\mathcal {F}}$, never an italic capital F (which is the symbol for a related quantity, the coefficient of finesse.) There are many other examples of quantity symbols for which a special typeface is prescribed.

Now, I think you've made a good case for doubting that f/ should be treated differently from other quantity symbols, and there is a lack of sources that definitively support the other point of view. We should not get distracted, however, into talking as if the issue were how quantity symbols should be typeset in general. That will not help us reach a consensus. --Srleffler (talk) 17:29, 4 August 2008 (UTC)

I'd probably go a bit further than that and say that nothing has been presented to suggest that nothing has been presented that even remotely suggests that the f in f/ is anything other than a symbol for the lens focal length, and simple logic also suggests that is the case. I think this was the basis for your and my initial arguments; the counter argument in Talk:F-number#Revert was a citation that really just called for putting the f in italics, consistent with its being a quantity symbol.

I guess I was the one who originally raised the issue of setting quantity symbols in running text using the TeX engine, and conceded that I, like most others, have been less than consistent. It's sometimes a matter of expediency; for example, look at the mess in Scheimpflug#Changing_the_plane_of_focus. Admittedly, most of this arises from managing appearance rather than content, but unfortunately, that's sometimes necessary. In that particular case, TeX would have been much easier, though it probably would not have represented the best typographical practice. with troff, it was a common idiom to set mathematical symbols in running text using eqn, but it also was possible to set the default eqn font to match the typeface of the running text. I've not seen a way to do this with the Wikipedia TeX engine.

I was simply exploring a possibility; arguably, having the symbols in the running exactly match those in displayed equations would eliminate any possible confusion. But this only would work with forced PNG rendering, and that seems to have at least as many drawbacks as benefits. Perhaps I got a bit sidetracked. But as I note above, the decision on the template is unavoidably linked to the issue of how quantity symbols should be rendered.

I actually have seen instances of setting all quantity symbols in serif italic type when the primary typeface is sans serif. An example is ISO 12232:1998 (I haven't looked at the most recent version), which also sets everything other than quantity symbols (e.g., numerals) in sans-serif typeface, even in displayed equations. My thoughts on that practice would violate talk page guidelines. JeffConrad (talk) 23:38, 4 August 2008 (UTC)

Jeff, while I totally understand and respect the logical idea that the f is just the symbol for the focal length, a quantity, my point is that it seems to me, from a long history of perusing photography sources, that it is treated more specially than just as a quantity. I don't have sources that specifically say so, but I have seen that long-tailed italic f in photography in f-numbers where it appeared to be treated special, whereas I don't see it so much in other "quantity symbol" contexts outside of photography. I don't have the time or energy to search for good support for this right now; it's just my impression from a long time reading especially the older literature in the field. Dicklyon (talk) 05:45, 7 August 2008 (UTC)

Dick, you're far more the photo historian than I am. However, I've examined a fair number of photographic texts myself and have seen absolutely nothing that suggests that the f is anything but the symbol for focal length. I've looked at few texts that predate the 1930s, but I wonder if historical considerations would dictate even if they did indicate special treatment; isn't reasonably current practice what should be followed?

I agree that the focal ratio fraction is usually done with a long hooked f, but I have yet to see one that differs from the “italic” font of the primary typeface; this includes the example from ANSI PH2.12-1961 that you've cited several times—it's nothing but an italic f. Most true italic (i.e., in serif typefaces) fs are hooked; see Italic type#Examples for an example. I actually have some exceptions, but they have been to put the f in the roman or upright font of the primary face. Conversely, almost every example that I've seen where the primary typeface is serif (and I've cited several that are arguably authoritative), the f is set in the oblique font of the primary typeface, suggesting again that the f is nothing special. For example, ISO 2720:1974 (R1994) specifically states

“The symbol used to indicate relative aperture shall be 1 : A or f : A or f /A or f-A where A is the f-number.”

The source for that quote is in sans-serif type, and the f is shown in sans-serif oblique, just as it appears here. Should one take this to indicate that the f should always appear in sans-serif oblique? For example,

“The symbol used to indicate relative aperture shall be 1 : A or f : A or f /A or f-A where A is the f-number.”

I think not. But that is the same sort of claim made for the requirement given in ANSI PH2.12-1961 and repeated in ANSI PH3.49-1971.

I did mention an exception: ISO 12232:1998, which is in sans-serif type but uses serif italic type for every quantity symbol; however, this again suggests that the f is treated no differently than any other quantity symbol.

Incidentally, I have no problem with the type of “original research” to which you alluded earlier—technical typesetting can be tricky business, and absent specific direction from an authoritative style guide, there sometimes is no alternative to simply imitating good practice. As I've said, though, every practical example that I've ever seen suggests that f is simply a quantity symbol and should be treated accordingly.

In sum, I think we've reviewed every argument at least two or three times, and are left with

1. Logic strongly suggests that that the f in f/# is the same f in the thin-lens equation (u − f )(v − f ) = f ². Absent definitive direction to the contrary, what else could it possibly be?
2. I don't think anything has been presented, either specific prescription or typographical practice, that suggests other than the logical conclusion.

Absent some convincing additional evidence to the contrary, it seems sensible to me that we reach the simple and logical conclusion rather than the esoteric. The f is the symbol for focal length, neither more nor less. JeffConrad (talk) 08:21, 7 August 2008 (UTC)

I've looked at almost 75 technical books on photography and optics, plus a dozen or so ANSI and ISO standards, and I cannot find a single instance where the f in f/# is given special treatment. The vast majority of the books are set in serif type; most use a serif italic f, but a surprising number simply put it in roman type. Only a handful of the books are set in sans-serif type; most use sans-serif oblique for the f, but one simply uses upright type. One does use a hooked italic f for image captions, but it is nonetheless sans serif, and definitely not the same as the serif italic f used in the text. A few sans-serif typefaces do have true italics; but without the typeface name or an italic f in another context for comparison, I cannot determine whether the f here is a special symbol. Even if that proved to be the case, I'm not sure it would mean much in light of the overwhelming practice to the contrary. The treatment in the ISO standards has already been discussed to death, so I won't repeat it. I don't claim to have examined a random sample of what's published, but I'd say it's nonetheless a pretty comprehensive survey. Unless I've really missed something, I just can't reach the same conclusion as Dick.

This discussion could go on forever (if it hasn't already), but absent some new information, I can't see any purpose in doing so. I haven't seen anything to support the statement that began the discussion, and there is considerable evidence to contradict it, so I think we should conclude that Srleffler and I were correct in our initial impressions, and change the template accordingly. JeffConrad (talk) 23:19, 7 August 2008 (UTC)

Which format should we choose

Back to the question of which format to choose: I think we have ruled out the use of <var>, leaving the principal choice between HTML italic and <math> markup. Either choice will result in inconsistency with typography of quantity symbols in some articles. Jeff has proposed above to go through articles using this template and convert them to his preferred typography. I strongly oppose this, and note that it violates Wikipedia's editing guidelines. Articles should not be converted from Latex math to HTML math or vice versa. One option would be to add a parameter that allows the template to use either markup, so the typography can adjust to the article. Another option is to just accept the fact that Wikipedia does not allow consistent typography for math right now. Articles using more than trivial math inevitably use at least two of the three typesets (x², $x^{2}$, and $x^{2}\,$). It would not be grossly wrong to just pick one for the template and allow articles that use it to be inconsistent.

There is also the spacing issue. I'm pretty sure we can get either the HTML or latex markup to look good with some tinkering. I don't think the HTML version with the thin spaces is a good idea, however. I believe spacing adjustment can be done with CSS, and this is better than adding characters because it allows text to be copied and pasted from the Wikipedia article into other applications (such as a simple text editor), without relying on handling of unusual characters. Inserting a thin space also interferes with searching, etc.

I'm leaning towards the <math> markup assuming we can get proper spacing without forcing PNG rendering. I prefer this markup for quantity symbols anyway, since it provides a machine-readable indication that the symbol is mathematical, and the potential is there for the typography to improve in the future. A side benefit is that it generates a hooked $f$ of the type Dick prefers, while using a format that is definitely in common use on Wikipedia for quantity symbols in mathematical expressions.--Srleffler (talk) 05:44, 8 August 2008 (UTC)

On second thought, the LaTeX markup may cause problems with the "link" functionality of the template. Perhaps the HTML format is the way to go after all. The f/ symbol is rarely used in equations, anyway, so consistency with LaTeX markup is less important.--Srleffler (talk) 06:17, 8 August 2008 (UTC)

Feel free to attack anything I've said, but please don't attack what I haven't said. Nowhere did I suggest going through articles to convert them to my “preferred typography”. To the contrary, I suggested that provision be made for editors who prefer to use TeX rather than HTML for inline mathematical expressions; you raise a valid point that that this might lead to a problem in addition to ones I mentioned.

Wikipedia guidelines do not indicate a preference for either HTML or TeX, though they do say that, as with any other purely stylistic treatment, editors should defer to the existing style. If you look at my edits, I've think you'll see that I've generally done this, even the existing style wasn't the way I would have done it myself. I could point out several instances of where my f/#s have been replaced with the typographically incorrect f/#. My argument is simply that the treatment in any given article should be consistent, either HTML or TeX. But perhaps even this isn't that important. At present, there doesn't seem to be any way to reconcile the different typefaces in the default font and displayed (i.e., PNG-rendered) mathematics. I think I've made the case in spades for sticking with the primary font, and not one shred of evidence has been presented for deliberately doing otherwise. It's not as if I prefer the sans-serif f—nothing could be further from the truth, as I've repeatedly said. And it's not a matter of my preference vs. Dick's. I simply believe in following accepted typographical practice to the extent possible, and that is to not switch typefaces without a darn good reason. No such reason has been given.

There is arguably some merit to indicating mathematical material with the <math> tag, but the same argument could be made for the <var> tag. Again, though, with a template, neither argument really applies. In any event, I think it's wrong to favor markup over appearance, which would be saying the editors matter more than the readers. A true purist would insist on XML, which I don't think any of us think is a serious possibility. Again, it's about the reader, not the editor.

1. Ideally, all inline mathematics, including f/#, should match the primary typeface.
2. If this is impractical, e.g., complex expressions that are much more easily done with TeX, then the typefaces used for mathematical material, especially for quantity symbols, should be consistent as much as possible. If this means using TeX for everything, so be it. My suggestion of the m parameter was to allow the editor a choice, not to impose a format. One possibility might be to have the link ignored if this parameter is given (and mention this in the documentation). JeffConrad (talk) 02:25, 9 August 2008 (UTC)

Sorry if I mischaracterized what you had said. I didn't go back and reread your earlier comment before writing that. I should have.

A parameter to allow the editor to choose math markup should work. It seems a bit over the top layering all this code on a template to generate two characters, but I don't mind overly complicated solutions to simple problems. :)--Srleffler (talk) 03:00, 9 August 2008 (UTC)

And my comments have been sufficiently voluminous that finding just what I said could entail a significant investigation—never has so much been said about so little (and I've done most of the saying).

I've seen much trickier code for ostensibly simple things in troff macros, but at least troff macros are readable in comparison to Wiki templates :-). Never thought I'd live to say such a thing. One issue with the math parameter: wouldn't the recommended practice be to give the f-number as a parameter so that it's in the same typeface as the f (just like other instances of inline math using TeX)? JeffConrad (talk) 05:17, 9 August 2008 (UTC)

The template already allows the f-number to be given as a parameter, but also was designed to support the f-number being outside the template. i.e. both {{f/|2}} and {{f/}}2 work, yielding f/2 and f/2, respectively. I would like to keep both options functional if possible.--Srleffler (talk) 19:25, 9 August 2008 (UTC)

I agree. I'd also like to keep them looking like that; having them change to a crowded oblique sans-serif f would be a shame. Dicklyon (talk) 19:57, 9 August 2008 (UTC)

I could have sworn that giving a parameter rendered the numeral with TeX, but it obviously doesn't—so scratch the suggestion. If the option of TeX rendering is to match the predominant treatment elsewhere in an article, it would seem to me that the numeral should match the immediately preceding quantity symbol. But offhand, I guess don't see an easy way to do this with both options. As to forcing serif by default: it's not a matter of personal preference, but conformance to accepted practice (suppose that I preferred the f in upper-case Fraktur: ${\mathfrak {F}}/$2; this may seem absurd, but it's as easy to justify as simply forcing serif for the f). JeffConrad (talk) 11:39, 10 August 2008 (UTC)

Examples

1. f/2 (HTML unspaced:  ''f''/2)
2. f/2 (HTML spaced:    <span style="letter-spacing:0.1em">''f''</span>/2)
3. $f$/2 (LaTeX unspaced: <math>f</math>/2)
4. $f$/2 (LaTeX spaced:   <span style="letter-spacing:0.1em"><math>f</math></span>/2)

--Srleffler (talk) 06:06, 8 August 2008 (UTC)

I guess I have talked myself into #2 on the list.--Srleffler (talk) 06:17, 8 August 2008 (UTC)

It looks reasonable to me; it works to about the same effect as what I did but uses less markup. Here it is with a serif typeface:

1. f/2 (HTML unspaced:  ''f''/2)
2. f/2 (HTML spaced:    <span style="letter-spacing:0.1em">''f''</span>/2)
3. $f$/2 (LaTeX unspaced: <math>f</math>/2)
4. $f$/2 (LaTeX spaced:   <span style="letter-spacing:0.1em"><math>f</math></span>/2)

I think #2 still looks the best. I tried it with several other serif typefaces; it's a bit breezy (though acceptable) with Georgia, and quite acceptable with the others. It's simply impossible to have it perfect with every face. I'll second the choice of #2. There's still potentially an issue with editors who prefer to use TeX for inline mathematics (let's face it—some of the HTML coding in my last example was pretty ugly). An option might be to accept an m parameter that would use TeX, but this might just be asking for confusion. JeffConrad (talk) 07:29, 8 August 2008 (UTC)

It looks awful, wrong, and very crowded on my display; How do I tell what font it's using? Probably the default, which looks wrong due to using oblique sans-serif f (the one with serif typefact looks fine). The math/LaTeX versions definitely look preferable. Dicklyon (talk) 22:24, 8 August 2008 (UTC)

Dick, what kind of display are you using? On my display, it's just the opposite—the spaced TeX looks awful and crowded, and the unspaced TeX has the f overlapping the solidus. Moreover, the serif f looks wrong because it's in glaring contrast to the sans-serif 2 that follows it—mixing serif and sans-serif type in running text is something that normally just isn't done. Again, in the 73 books that I examined, I did not find a single such example. If you were to maintain that the error here is using sans-serif type as the default, you'd get no disagreement from me, but that's something beyond our control.

Just out of curiosity, does your display show a difference between the spaced and unspaced examples? And how do things look with serif type forced as the default? A very slight increase in letterspacing might help, e.g.,

• f/2 (HTML spaced:   <span style="letter-spacing:0.1em">''f''</span>/2
• f/2 (HTML spaced:   <span style="letter-spacing:0.15em">''f''</span>/2

• f/2 (HTML spaced:   <span style="letter-spacing:0.1em">''f''</span>/2
• f/2 (HTML spaced:   <span style="letter-spacing:0.15em">''f''</span>/2

But a little goes a long way; in the examples above, the spacing looks excessive with the default sans-serif typeface on my display. You might be able to fix it by letterspacing between the solidus (possibly with a different value), but this would be getting pretty tricky.

For reference, my display is a 24″ with 0.27 mm pixel pitch, run at its native resolution of 1920×1200 via the DVI input, and I'm using Clear Type for font smoothing. I'm using the default monobook skin with nothing in monobook.css. I've examined the samples using Firefox 3, Internet Explorer 7, and Opera 9.25, each at wide ranges of zoom, and the results hold up in all cases with both the default typeface and the generic serif face in the example that I added. JeffConrad (talk) 23:31, 8 August 2008 (UTC)

I forgot to mention that I'm running Windows XP, SP 3. I can't think of anything else that might be relevant to differences that Dick and I are seeing. JeffConrad (talk) 00:59, 9 August 2008 (UTC)

Here's how it looks on my Camino on Mac:

And here's mine using Firefox 3:

Dick, what are the specs on your display? I'm guessing that we have a Firefox/Camino (or, heaven forbid, a Windoze/Mac) issue, but it might help to compare all possibly relevant parameters. It looks to me that a slight increase in letterspacing might give something acceptable for both environments. And if there is an option to use TeX, each rendering could be separately optimized. And tweaked later if needed, magically fixing every article that uses the template. At the same time, it's really disheartening to have to fight the tools as part of writing articles; mathematical typesetting is unquestionably more challenging than that for a memo, but this is ridiculous ... JeffConrad (talk) 09:21, 9 August 2008 (UTC)

Interesting; I use a Powerbook Pro; but the size is determined by some html style stuff, not by the display; where is the size control? I use the default monobook wiki page style. I just checked Firefox, and it does a better job of spacing, and also use a sans-serif f with a bit of a tail, instead of just oblique, which look somewhat less wrong. I don't know why FF would be using different glyphs for the same html; maybe it interprets "italic" differently. Anyway, I suppose most of my problem is due to Camino, so forget about it. Dicklyon (talk) 16:43, 9 August 2008 (UTC)

Based on all the comparisons above, I like option 4, spaced math-mode version, best. Dicklyon (talk) 20:22, 9 August 2008 (UTC)

“... and also use a sans-serif f with a bit of a tail, instead of just oblique, which look somewhat less wrong”

We keep going back to this ... I guess there's an obvious question that I never directly asked: can you point to an example of a publication in sans-serif type that uses a serif f in the focal ratio? Or in either serif or sans-serif type and in which the f in the focal ratio differs from the “italic” f? I don't say that none exist, but I didn't find a single example in the nearly 100 works that I examined. Admittedly, my sample of sans-serif books was small—seven altogether, and two of them didn't even use the focal ratio (the Sinar people prefer 1:5,6 to f/5.6). One interesting example is the Kodak Professional Dataguide, publication R-28 (1986 version), which uses both, each matching the the base typeface. The running text is in a serif typeface; on p. 17, under Exposure, they use f/8. The tables are in sans-serif type; on p. 18, also under Exposure, they use f/8 (and the f in that sans-serif typeface is not a descender). As an aside, they use f-number in both serif and sans-serif faces. I don't claim that Kodak necessarily speak for the world here, but this does seem to strongly support what I've been saying.

Whether or not an oblique f is a descender is a characteristic of the typeface; on my system, the only typefaces in which I can find this are Gil Sans MT, Lucida Sans, and Trebuchet MS (with a hook; example below).

As for the different glyphs between Camino and Firefox, it seems obvious that they're chosing different typefaces, and Firefox is choosing a different face on your Mac than is mine on Windows. I don't know what the rules are for typeface selection, and I don't know how the typfaces normally available on Macs differ from those normally available on Windows machines, but it sounds as if the both the OS and browser affect what is displayed. To me, this would argue even further against presupposing an appearance and simply switching to “italics” using the double-apostrophe Wikipedia markup. It also raises questions about playing with the spacing, but if this is done in moderation, there probably is no harm. Again, it might be possible to slightly increase the letterspacing so that the appearance is at least acceptable with both browsers. It will never be perfect in every situation, but I think it's better not to sacrifice the acceptable for the perfect. JeffConrad (talk) 23:42, 9 August 2008 (UTC)

Jeff, you may be right that I've hallucinated the distinction that I thought I knew; I'm not able to find an example at this time. That doesn't change what I like, or what looks wrong to me, however. Dicklyon (talk) 04:23, 10 August 2008 (UTC)

And I don't think our preferences differ much, except that I think almost all running text in sans-serif typeface looks wrong; my dogged insistence on typographical consistency is definitely choosing the lesser of evils. If only seven of the books I examined were in sans-serif type, 67 must have been in serif type, and probably not by accident. Knuth developed TeX primarily for typesetting mathematics; had he seen a reason to provide a sans-serif font, he probably would have done so. Though I've frequently cited the ISO standards as examples of normal practice, I generally dread reading them, primarily because of the sans-serif typeface. It's less a matter of aesthetics than that I simply find the text very difficult to read. For a document that's sometimes barely comprehensible under any circumstances, another obstacle is the last thing I need. JeffConrad (talk) 10:27, 10 August 2008 (UTC)

Coding

I've figured out how to get the math mode rendering to work, and avoid forcing PNG output. Here are my current "best" versions of the HTML and math layouts. For now I've got 0.1em of space between the f and the solidus. We can adjust that up or down to find the best compromise.

HTML: f/2. With link: f/2

math: $f$${\mbox{/}}2$. With link: $f$${\mbox{/}}2$

I'm working on new code for the template that will allow both forms, so that the f-number can be rendered the same as other quantity symbols in each article. (Sorry Dick. I agree with you that f/ looks better, but Jeff has convinced me that making the symbol match the typeface of the surrounding text is correct typography. The sans-serif ISO standards and the lack of any examples of f/ in sans-serif surrounding text is pretty much definitive.--Srleffler (talk) 16:58, 10 August 2008 (UTC)

Both are slightly crowded in Firefox 3, more crowded in Internet Explorer 7, yet perhaps have room to spare in Opera 9.51. Again, Windows XP, SP 3. The characteristics seem fairly constant at different zooms, so the display probably isn't a factor. The choice of letterspacing over inserting spaces apparently was the correct one: zooming with IE 7 makes an incredible mess of the Newtonian form of the thin-lens equation that I coded above with thin spaces.

And I agree with both of you that the Georgia f looks much better; just in case it isn't already clear, I detest the look of the default sans-serif font in this context. But typographical practice dictates. Moreover, there are many folks, especially in Europe, who don't share my preference for serif type. JeffConrad (talk) 21:52, 10 August 2008 (UTC)

What about using the CSS class "texhtml", something like <span class="texhtml"><span style="font-style: italic; letter-spacing: 0.1em"> ... </span></span> for TeX/HTML? It's a bit familiar with the workings of the TeX processor, but possibly cleaner than just calling for a serif typeface. JeffConrad (talk) 08:03, 11 August 2008 (UTC)

That's a great solution. When I started coding the template I found that it isn't possible to put a parameter inside math tags. Your suggestion allows the whole notation to be put into the math font, without messing around. For a while I had a single template that did both the standard and math forms, but I think now that it's easier to just have two templates:

Code	produces
{{f/2}}2.5	<Template deleted>
{{f/2|2.5}}	<Template deleted>
{{f/2|2.5|link=yes}}	<Template deleted>
{{f/2|#}}	<Template deleted>
{{f/2|#|link=yes}}	<Template deleted>
{{f/m}}2.5	<Template deleted>
{{f/m|2.5}}	<Template deleted>
{{f/m|2.5|link=yes}}	<Template deleted>
{{f/m|#}}	<Template deleted>
{{f/m|#|link=yes}}	<Template deleted>

If this is acceptable, then we just need to get an admin to move the contents of {{f/2}} to {{f/}}. These still use 0.1em spacing, however. We should decide on exactly what spacing we want first.--Srleffler (talk) 17:57, 11 August 2008 (UTC)

The spacing still looks a bit tight to me, especially for the math and especially with IE 7; again, the spacing with Opera 9.51 is more than adequate. I wonder if a slight increase might be a good overall compromise (and with a template, it's easy to tweak in the future should that prove necessary). With the smattering of browsers we've looked at, the limiting cases seem to be Camino on Mac and Opera on Windows. If we got a spacing that was just barely acceptable for both of the others, we'd probably be fine with FF and IE. I noticed that many of the publications I looked at were fairly liberal on spacing, so opening up here would have plenty of precedent. I think it would be better to have something acceptable for many rather than perfect for a few.

Again, I think the second syntax of the math version looks much better than the first; the Wiki TeX/HTML rendering just isn't a very good match for the default font, and the direct juxtaposition makes the mismatch more obvious. It might be worth mentioning this difference in the two syntaxes (perhaps without any recommendation); editors, of course, will do as they please.

I'm playing with a couple of templates for handling mathematical subscripts and superscripts to make it easier to match the running typeface; this would seem to be the trickiest task for which HTML is really suited, and none of the existing templates seem quite tailored to mathematics. Even TeX/HTML has some real shortcomings, such as not reducing the type size when there are only subscripts or superscripts; because of this, I actually prefer plain HTML most of the time. But the coding to make it look right is messy. Although the templates probably would have more general applicability, this is the only area with which I'm familiar that's had an extensive discussion, so if people are interested, I'd be glad to show some examples if they ever seem ready for prime time. JeffConrad (talk) 22:29, 11 August 2008 (UTC)

The tight spacing in IE7 appears to be a bug. The following examples should have way excess space between the f and the solidus:

f/2

$f$${\mbox{/}}2$

Browsers that don't show a big space there are broken. The problem in IE7 is that the span in which there is a letter spacing adjustment must be at least a full line long. If the span is less than a full line, it dumps all the extra intraletter space at the end of each word.

Does the space show up in other browsers that have tight spacing on the template output? I'm using FF3 on Windows XP and Vista, and the template output looks fine although the math version is slightly tighter than the HTML. If anything, though, the HTML version has too much space for my taste.--Srleffler (talk) 05:00, 12 August 2008 (UTC)

The spacing is fine with Opera 9.51 on Windows XP, SP3. I've run into equivalent problems with IE 7 in my superscript/subscript template; when I set display to inline-block to handle combined superscript and subscript, I get a mess with IE 7 if I zoom—FF 3 and Opera work fine. So I accept the fact that it won't always work quite right with IE; unfortunately, it's over 80% of the market. The problem seems to be that with IE, the letterspacing applies only to characters within the letterspaced span; the spacing seems to work OK if the solidus is placed within the span; perhaps the same is true with Camino. With other browsers (at least FF and Opera), the letterspacing extends one character beyond the span, so the previous suggestion adds too much space between the solidus and the 2. Quite honestly, I'm not really sure which treatment is “correct”, though MS Word takes the same approach as FF and Opera. Word also has the same problem when switching between italic and roman fonts; I need to adjust the spacing to get f/ to look right. The desired visual effect can be achieved by inserting a space rather than letterspacing, but then searches for “f/” fail, as you noted. Of course, this is an issue for the reader rather than the editor, who only sees the template. I don't know how often a reader would make such a search, but I could understand a reader getting pretty irate if that happened.

Offhand, I don't have any good ideas. It's utterly ridiculous for editors to have to waste time with this sort of nonsense, though I'll concede that it's a long-honored tradition. JeffConrad (talk) 09:42, 12 August 2008 (UTC)

Actually, IE's usage share is below 80%, and falling. I'm not sure which implementation is correct. Maybe both are—the standard seems to allow browsers some latitude in determining how to interpret the letterspacing property. When I experimented with it yesterday, I couldn't get IE to do letterspacing properly on spans less than a full line of text. Today it seems to be working, but as you noted it doesn't add spacing after the last character in the span, while the other browsers do. I'm inclined to add the spacing to suit Firefox etc., since IE is known for poor CSS support.--Srleffler (talk) 03:36, 13 August 2008 (UTC)

Most unfortunate ... The current letterspacing looks OK in FF 3, Safari 3.1, and Opera 9.5. I don't have a problem with coding for FF 3. The very good argument can be made that with IE 7, you simply get what you would get with normal text; the slight visual improvement with other browsers is a bonus. Perhaps some day browsers will handle this issue automatically; it certainly arises in many other situations, as illustrated in Help:Formula. I've played with putting the solidus in italics (which creates as least as many problems as it solves) and with using ⁄ rather than the solidus (it doesn't work at all). As luck would have it, the solidus in the Georgia typeface has a fair amount of extra space on each side of the glyph, so it automatically compensates for the problem. I've also played with using the Georgia solidus, but in addition to representing marginal (at best) practice, it really doesn't look all that good with other typefaces. Spacing seems to present problems in addition to those already discussed (e.g., Opera treats all spaces the same, so the   doesn't work properly).

I don't know what other options exist, other than to just leave things as they are. Some web browsers have been written with less time and effort than we've put into this. I'd just do it; it's easy enough to fix if problems are discovered later. JeffConrad (talk) 07:27, 13 August 2008 (UTC)

Unicode ƒ?

Why not just use the Unicode ƒ, LATIN SMALL LETTER F WITH HOOK, available in most sans serif fonts (Arial, Verdana, Tahoma, Trebuchet MS, etc.)? It strikes me that this avoids complex markup, and doesn't have the nasty serif–sans mismatch problem that the current solution does. That is, we'd have ƒ/1.8, ƒ/8, ƒ/32, &c. —jacobolus (t) 06:06, 8 January 2009 (UTC)

Generally unicode glyphs that mix content and style are deprecated. It is cleaner and better to use an actual "f" character, with css specifying how the character is to be formatted for display.--Srleffler (talk) 06:18, 8 January 2009 (UTC)

There's no way to specify "use the unicode glyph with a hook added to the letter" in a stylesheet. ISTM me that this is no worse practice than dumping a bunch of proprietary wiki syntax into the document that generates all kinds of markup garbage to produce an output that doesn't even visually match the surrounding document. Besides, semantically this isn't just an "f". It's a special f-number symbol. I thought that was the whole point of the argument above. –jacobolus (t) 06:22, 8 January 2009 (UTC)

FWIW, this seems to be a common solution online. Here's an example where Tamron does it on their official site. —jacobolus (t) 06:47, 8 January 2009 (UTC)

I was going to disagree, but I noticed the google search you cited over at Ƒ. When we discussed this issue before (above), the one thing we couldn't find was any evidence of "f/" being used as a distinctive symbol, as opposed to a conventional mathematical notation (a letter "f" in italics, followed by a slash). The google search does seem to show many examples of a distinct character being used for the f, indicating that these authors interpret it as a distinct symbol, not merely an italic f. I still don't think we should use the unicode symbol here, because it would prevent searches for "f/" from working, but the existence of a custom of using a distinct symbol for f/ supports the existing template over the above-proposed f/. It would be better, of course, to have a reliable source that unequivocally discusses the issue of how the symbol should be treated.

Besides the impact on searches, there is another issue with the unicode glyph, which I allude to above. Unicode contains many characters that are not intended to be used in new documents, but rather exist to allow easy bidirectional conversions between Unicode and earlier character sets. Glyphs that combine style and content generally are of this type, such as precomposed superscript characters (²³). An italic (hooked) f might be one of these deprecated characters. I'm not a Unicode wonk, so I really don't know. If we were to consider using the glyph you propose, we would need to first check that its use in new documents is not deprecated. --Srleffler (talk) 05:04, 9 January 2009 (UTC)

I agree that it might give a reasonable appearance with either serif or sans-serif typeface, but it would be a completely capricious decision that's not in synch with recognized practice. I don't think that is the prerogative of Wikipedia editors. Moreover, most searches for it would fail mysteriously, as few people would think to search for U+0192. Why should they?

I'm guessing that Srleffler's comment on CSS was directed more at adjusting the spacing to compensate for most browsers' inability to properly handle it. I somewhat agree that it's ugly to do this, but the ugly details are hidden by the template, and in any event, it's no worse than most other templates. As far as I'm concerned, the only acceptable alternative would be to code manually to get f/8 and simply live with the tight spacing and hope that all editors would know what goes in italics and what doesn't.

I thought we had pretty much agreed (if perhaps reluctantly) that accepted practice is to set the f in the oblique font of the base typeface, whether we think this is the most attractive rendering or not. I repeat yet again: this is not a special f-number symbol—nothing whatsoever has been presented to support this, while overwhelming support has been cited for simply treating it as any other quantity symbol, as common sense would suggest.

I'm not sure that the editor of the cited Tamron page qualifies as an authoritative source on this; a quick glance reveals a lack of familiarity with other typesetting conventions as well. JeffConrad (talk) 07:03, 8 January 2009 (UTC)

My comment about CSS was relating to the way the current template works: the character is a normal letter f, with CSS code to force it to display as intended (a hooked f). I wasn't thinking of the spacing issue or the proposed newer templates.

See my reply to him above. Searching on Google for the unicode character and "aperture" finds many examples of the use of this glyph for f/. This is something we missed in the earlier discussion: it is evidence that some authors and publishers, at least, are thinking of the f as a distinct symbol, not merely as an italic f. One does not end up with the unicode hooked f symbol by accident, nor does one end up with it by thinking only about appearance (an italic serif f would do as well, otherwise). The only way you end up with many documents using the unicode hooked-f glyph, is if there is a community within which the f is considered a special symbol, not as conventional mathematical notation. This takes us right back to where we started in the discussion above, and justifies the use of a hooked f independent of the base font of the text.--Srleffler (talk) 05:04, 9 January 2009 (UTC)

“It would be better, of course, to have a reliable source ...”

Unless I misread WP:RS, a verifiable reliable source is not only better but mandatory.

“This takes us right back to where we started in the discussion above, and justifies the use of a hooked f independent of the base font of the text.”

I cannot agree. I'll concede that I was surprised by the number of hits, but only a handful could be considered even close to reliable. I only examined several dozen of the sites, but many of those examined demonstrated considerable lack of knowledge of proper typography, so I'd hesitate to rely on them for this issue. I'm not sure it's that hard for the use of U+0192 to have come from nowhere; a few people could easily have extracted it from a region in which the sunny 16 rule is inapplicable, and many others simply copied them. Obviously, that's speculative, but my point is that widespread use doesn't necessarily imply an authoritative origin.

Perhaps more to the point is that this usage is in direct conflict the professionally published literature, which shows no support for U+0192 but rather uses the oblique/italic f of the base font. The ANSI and ISO standards explicitly state that the symbol shall be “f”, using serif or sans-serif font as appropriate. I should think this alone would be enough to decide the question, but common sense further supports the argument for treatment as an ordinary quantity symbol. The diameter of the aperture when the lens is set to f/8 is the focal length divided by 8; f is the quantity symbol normally used for focal length. Were the symbol ƒ commonly used in optical mathematical expressions, the situation might be different, but that isn't the case. To argue that the meaning of f in f/8 is other than that quantity symbol for focal length is to argue for argument's sake.

I'll concede that I haven't found an authoritative source that specifically states that the symbol for focal length is a quantity symbol, and accordingly is set in the oblique or italic font of the base typeface, but the ANSI and ISO standards come very close, and professionally published literature (at least everything I've examined) shows this by example. A statement like “the symbol for focal length shall be f” is similar to the approach in almost every mathematical treatment I've seen. I'm not sure I've ever seen an instance of “this is a quantity symbol”; to do so would be comparable to a sign in a hotel bathroom indicating “this is a sink”.

When a law is open to two interpretations, one far fetched and the other sensible, the courts invariably and reasonably go with the latter. The same approach would seem applicable here. When the choice is between “I found it somewhere on the net” and numerous verifiable, authoritative sources, the latter is the obvious winner. I cannot believe that WP guidelines would allow otherwise. JeffConrad (talk) 06:43, 9 January 2009 (UTC)

A reliable source is mandatory to support statements in an article. Here, though, we are discussing what typography to use. WP:RS does not require us to have a reliable source to support that decision, but it would be nice to have such a source to rely on. You write above that widespread use does not necessarily imply an authoritative origin. I agree, but widespread use is an important factor in its own right. The fact that some people making documents and web pages relating to photography have gone out of their way to choose a distinct hooked-f symbol rather than using an italic f is evidence that some people consider the f in f/ to be a distinctive symbol, not merely an f in an italic font. This is precisely what we were looking for and did not find above. The number of uses of this unicode symbol is small, but so is the number of cases where a non-hooked f is used (eg. an oblique f when the base font is sans-serif).

We have three cases:

1. sources that use a hooked f that is distinct—not an oblique/italic f in the base font
2. sources that use a hooked f that is indistinguishable from an italic f in the base font
3. sources that use a non-hooked oblique f in the base font (eg. when the base font is sans-serif)

The majority of sources with decent typography probably fall into category 2. These don't really contribute much to the debate, since it's not clear whether they favor using a hooked f in all cases, or only when the base font's italic form happens to be hooked.

There may well be a divergence here between usage in scientific publications (where the f may be formatted the same as mathematical variables) and usage in photography publications, where there may well be no mathematical variables, and the f/ is treated as a symbol. It's not necessarily the case that there be a single correct answer here. Both approaches may well be correct, depending on context. I'm not sure which approach is best for Wikipedia. Keep in mind too, that Wikipedia already lacks consistent typography for mathematical variables. Variables are often written in base-font italics (f ), but just as often are typeset using Latex, which can render them in two distinct fonts: $f$ and $f\,$. Formatting the f like a mathematical variable produces less, not more, typographic consistency on Wikipedia.--Srleffler (talk) 05:06, 10 January 2009 (UTC)

“2. sources that use a hooked f that is indistinguishable from an italic f in the base font ... The majority of sources with decent typography probably fall into category 2”

This is wildly speculative. For even a chance of this being correct, it would need to be shown that there is such a thing as a “hooked f that is indistinguishable from an italic f”; the generic serif typeface certainly doesn't support this contention:

italic: f florin: ƒ

Even if a typeface could be found in which the two glyphs are indistinguishable (and there probably is one), it would be quite a stretch to maintain that the symbol in f/ used the “hooked f” merely because it's possible when there is absolutely nothing to support that it was actually done. Common sense suggests that without evidence of a difference, there is none, especially when common sense also suggests that absent some specific directive to give the f/ symbols special treatment, there is no reason to give special treatment.

“... WP:RS does not require us to have a reliable source to support that decision [typography]”

I agree that there is no specific requirement for a reliable source for typography, but common sense would suggest that unusual treatment would require a good reason. None has been given so far. From WP:V,

“Articles should rely on reliable, third-party published sources with a reputation for fact-checking and accuracy.”

To maintain that equivalent criteria would not apply to typography (or almost any other authoring practice) seems pedantic; were that indeed the case, any editor could do as he damn well pleased for almost anything. I think it's generally accepted that one does not arbitrarily change typefaces in the middle of running text without good reason. By the same logic that supports forcing a serif f, I could change typefaces in the middle of words because I think I may have seen someone do it. Or I could set the f in Fraktur because I think I saw some authoritative German source do it. This is utter nonsense. Recall that this discussion began with the practice of forcing a serif italic f; it seems that as that practice has failed to find support, another equally offbeat possibility has been proposed.

The WP:MOS does say that when no specific directive is given, editors should consult a good style guide, such as the Chicago Manual of Style. I haven't been able to find a specific proscription of changing typefaces in the middle of words in CMS (or any other style guide, for that matter), but I guess they assume it's sufficiently obvious that it need not be mentioned. If it's really not self-evident, perhaps the WP:MOS needs to address what seemingly no one else has felt necessary to address.

I question whether there is “widespread” use of the florin symbol for f; when the alternative is 4200 times as common. It is utterly fantastic to argue for such an extreme minority position, especially when it is at odds with nearly all authoritative publications.

“Many use a hooked f because that's what they have seen elsewhere, without knowing why it appeared that way.”

This probably explains the bulk of the usage. I would question relying on web examples of typography for guidance.

We've already discussed the typographical inconsistency that arises from using TeX for mathematical expressions. But as I recently suggested, this is simply a matter of convenience, and the use of TeX would seem hard to justify outside of a context in which there are mathematical expressions and the quantity symbols are set using TeX. WP style certainly doesn't require this, and many authors simply put quantity symbols in the oblique face of the running text. To force special treatment for f/ when other symbols are simply put in oblique face would be difficult to justify. If f/# is treated as a mathematical expression, there would seem no justification for not using TeX for the entire expresion (e.g., $f/8$ rather than $f/$); although the current template allows for the former usage, the latter has been far more common. If it is desired to treat f/# as a mathematical expression, TeX remains an option; the template should provide an alternative for authors who put quantity symbols in the oblique font of the running text.

If f/# is forced into serif typeface (or some other uncommon symbol), what then for f-number? Should this also be forced to the same symbol? I agree that practice here is less universal, but again, the majority of authoritative sources seem to do it, so it's hard to consider it bad or unusual practice.

“Both approaches [i.e., including treatment as a special symbol] may well be correct, depending on context.”

But to support the latter, at least some usage in credible sources would be needed. I don't think the insignificantly small minority of web pages qualifies.

“Formatting the f like a mathematical variable produces less, not more, typographic consistency on Wikipedia.”

I'm not quite sure what is meant here. I suppose that if every editor were to use the template, the typography for f/# would be consistent across articles. But the usage could be less consistent within articles, and there would be no effect in instances where editors choose not to use the template.

I remain puzzled by the argument to reject the common and logical for the offbeat and speculative, especially in light of the overwhelming numbers and quality of the sources. We have seen no support for forcing the f to serif italic; though we've seen some usage of ƒ, the comparative usage in insignificantly small, and we've seen no support in authoritative sources. Again, absent some good reason to do otherwise, the best approach would seem to follow common usage that additionally is in accord with that of authoritative publications. JeffConrad (talk) 03:19, 12 January 2009 (UTC)

Sorry, it seems I wasn't clear enough, and you have misread what I wrote and written this long reply that misses my point. What I meant by #2 on my list is that for most serif fonts, the italic f is a hooked f. The vast majority of published sources use a serif font, and render f/ with a hooked f. #2 on my list includes all cases where the hooked f in f/ is indistinguishable from the italic f. In most of these cases, the f is indistinguishable because it is the italic f in the base font. I just wanted to cover the possibility that there might be fonts where a hooked-f symbol could appear that is identical to the f glyph.

I'm not going to reply to most of what you've written above. You should probably reread what I wrote in the previous reply. In case it's not clear, I'm not arguing that we should use the unicode hooked-f character; I'm only arguing that the fact that some authors have used it is proof that at least some authors consider the f to be a distinctive symbol. That being the case, many of the authors who have used an italic f in a serif font may also have been considering "f/" as a distinctive symbol rather than as mathematical notation. This is especially true in documents that don't contain any mathematical variables. In such a context, an author might well be unfamiliar with the fact that variables are normally set in italics, and thus use an italic (hooked) f merely because that is "the symbol" used in f/.

About reliable sources for typography: I've seen too many arguments on MoS talk pages that hinge on the idea that Wikipedia sets its own house style. External sources are a guide but are not definitive. Sometimes the best style for Wikipedia differs from what is common in print.--Srleffler (talk) 04:09, 12 January 2009 (UTC)

(Copied from Talk:Ƒ#ƒ as a symbol for f-number): The number of Google hits is a meaningless statistic; see FGA: Google result counts are a meaningless metric for more details. And anyway, the cited Google search (ƒ aperture) returns only 11,100 results (currently), whereas "f" aperture returns 46,100,000 results, which would seem to indicate that the symbol "ƒ" is used less than 2.5 hundredths of one percent of the time, hardly what I would consider "commonly used". —Bkell (talk) 07:22, 9 January 2009 (UTC)

While the author of that essay makes a good case against trying to do anything precise with Google hits, it would be terribly foolish to argue that it is meaningless to distinguish between something that gets a few dozen hits, tens of thousands, or millions. This presumes, of course, that one constructs one's search string appropriately. Some of the cited author's complaints related to the fact that poor choice of search string will deliver results other than what the searcher intended.--Srleffler (talk) 05:06, 10 January 2009 (UTC)

I'm not quite sure what is meant by poor choice of search string, but if the reference is to my comment, I simply indicated that I had overlooked the obvious in not discovering the overwhelming difference in numbers myself.

I agree that it would be a mistake to say that ƒ is never used. But it also would be utterly absurd to ignore the overwhelming difference in usage. JeffConrad (talk) 03:19, 12 January 2009 (UTC)

I agree with you about the difference in usage, and I am not arguing that we should use the unicode symbol here. Clearly usage of an italic f in serif base font overwhelmingly dominates in numbers. We have smaller numbers of sources that use a distinctive hooked f symbol and sources that use an oblique sans-serif f. It's not clear to me which of the latter two is more common. It may well be that the distinctive hooked f is more common than the oblique sans-serif f. It's not really the numbers I am interested in, though. What I am interested in is what was in the mind of the authors. From our previous discussion, and from common sense, there are clearly many authors who are thinking of the f just as a mathematical variable. This will be particularly the case in scientific publications, where there are other variables being used. It's how I would have typeset it myself a few years ago. What has become clear, though, is that there are other authors who are thinking of the f as a distinctive symbol. I presume this is mostly the case in photography publications that aren't mathematical. The cases where the f is just an italic f in a document with a serif base font are not very informative, since the author could have been thinking about the symbol either way.

I'm not sure how to decide which path is best for Wikipedia, but I'm leaning toward the idea that the template should stay as it is. WP editors who are thinking of the f as a standard mathematical variable should probably enter the f using whichever markup is used for other variables in the article (''f'' or <math>f</math>). Editors who consider f/ to be a distinct symbol, not a mathematical notation, would then use the template.--Srleffler (talk) 04:22, 12 January 2009 (UTC)

I wouldn't claim the number of google hits is a meaningful metric. I just added it because there was a "citation needed" tag on the claim that many current authors use it that way. I think a google search link is a reasonable way to establish that it is indeed used for such purposes. The number of hits shouldn't really have any direct bearing on our discussion here. --jacobolus (t) 22:28, 11 January 2009 (UTC)

As Bkell mentioned, the operative word is “common”, and at 1:4200, I don't think “common” is appropriate. I think I agree that the number of hits doesn't really have a direct bearing here; however, I completely disagree if this is meant to say that that we cannot dismiss the usage of ƒ but can dismiss the overwhelmingly greater usage of the alternative. JeffConrad (talk) 03:19, 12 January 2009 (UTC)

Toward a resolution.

I began this discussion by challenging the statement

“This template produces the symbol for f-number, using an italic serif font for the letter f (as is conventional in photography)”

From WP:V#Burden_of_evidence:

“The burden of evidence lies with the editor who adds or restores material.”

I don't think any evidence supporting this statement has been presented, despite seemingly interminable discussion. To the contrary, considerable evidence from reliable sources has been presented showing that the f in f-number is not given special treatment. In addition, simple logic supports the latter position. Strictly speaking, a template isn't an article but I think it's obvious that the same logic applies.

Consequently, I think the current rendering by the template is wrong, and the template should be changed. Whether the spacing between the f and the solidus should be increased is a more subjective call (since there's already a template to hide the ugly details, I'd say “Why not?” just to address the concerns of those put off by the crowded appearance of the default spacing). In any event, there is no justification for continuing to set the f in serif font. JeffConrad (talk) 09:01, 9 January 2009 (UTC)

Jeff, I agree that we've failed to find reliable sources for the hooked or serif f style. On the other hand, I'm intrigued by the recent finding on the web of a few photography companies using the special hooked-f unicode character. One has to wonder what motivated them to do that. It accords with what I was always pretty sure I knew, the the f was conventionally written with such a glyph. Yet, as you point out, that's counter to standard math typography and to the statements in relevant international standards. I have the feeling we're still missing something important, which maybe the standards writers also missed, about the typographical history of this f-number concept; or maybe they didn't miss it but were trying to rectify it. But I have no new info to offer, so I'll stay out of it and let it go either way. Dicklyon (talk) 16:56, 9 January 2009 (UTC)

Dick, in a sense your recollection is correct—the f usually is hooked, but that's simply because the vast majority of books are set in serif type, and a serif f is usually a hooked descender. I'd be mighty leery of a comparatively small number of web pages that use the ƒ symbol; as I'm sure you are aware, folks who write ad copy and web pages often show little regard for typography (or the laws of physics or trademark). The ƒ glyph isn't that unusual—it's been in most extended-ASCII character sets for quite some time, usually identified as “florin”. For some reason, the HTML entity for this glyph is &fnof;, and this appears to have confused more than a few people (see Bkell's comment on Talk:Ƒ#ƒ as a symbol for f-number). Once again, simple common sense might have helped: if ƒ is the proper function symbol, what does one do for g(x) and h(x)? Again, that someone does it on the web doesn't necessarily mean much.

I agree it would be nice to have a detailed typographical history, but the chances are good that we never will, and it seems pretty shaky to base a position on something we think might exist (remember WMDs?). Standards writers aren't the only ones to follow normal practice—I've cited some other pretty solid publishers, such as Kodak. I've since found a few more examples: Sidney Ray's Applied Photographic Optics (the book is set in serif typeface but has a few figures in sans-serif, and they use a sans-serif f/#) and Bryan Peterson's recently published Understanding Shutter Speed (from a quick glance, it doesn't appear to address some of the questions raised in the shutter speed discussion :-) ). The publishers are Focal Press and Amphoto, both of whom are pretty solid. Again, there are comparatively few examples where the f is in sans-serif font because comparatively few books set in sans-serif face. There is good reason for this; as I've stated several times, I'd fix the problem by making the text match the serif f symbol, but I doubt this would be well received by the WP community.

I think Bkell makes a pretty convincing argument with the comparative results of Google searches. Although I agree the searches don't really prove anything, the numbers are overwhelming—results I just got were more than 4200:1 for f. Given those numbers, I just can't see opting for the minority position, especially when it's at odds with normal typographical practice, including that of authoritative photographic literature. JeffConrad (talk) 23:48, 9 January 2009 (UTC)

I don't think there is any single answer here. Some sources treat the f as a distinctive symbol, others treat it as a mathematical variable. Many use a hooked f because that's what they have seen elsewhere, without knowing why it appeared that way. How common each usage is probably differs between photography publications and scientific publications. This leaves us with five equally justifiable ways to typeset it on Wikipedia: ƒ/, f/, f/, f/, and $f/\,$. The first two treat it as a distinctive symbol, the last three as a variable. --Srleffler (talk) 05:29, 10 January 2009 (UTC)

I don't think there is a definitive answer in the sense of an unimpeachable source that explicitly says “it shall use this symbol and this typeface” (though the ANSI and ISO standards come very close). But I don't agree that there are five equally justifiable ways of doing it.

• ƒ/: aside from the results of the Google search, I haven't seen anything to support this. Most of the sources are far from authoritative, and the alternative using f is 4200 times as common; need I say more? Moreover, there is absolutely no logic for using the florin symbol. It would seem almost impossible to justify this usage.
• f/, f/: these seem minor variations on the same theme, forcing serif typeface, with the former choosing a specific font family. I've seen no support for it anywhere but on WP, so I can't see much justification for using it.

[Inserted reply: I should have made that clearer. The second is equivalent to <math>f/</math>, but uses direct font selection instead of the math tag. I took the code from one of the potential templates we discussed above. Quantity symbols on Wikipedia are often set using this font rather than the base font in italics. --Srleffler (talk) 17:32, 10 January 2009 (UTC)]

[Inserted reply] I see; it differs from the following example in not forcing TeX rendering. It appears to have the same effect as simply specifying a generic serif font family. JeffConrad (talk) 21:06, 10 January 2009 (UTC)

• $f/\,$: this approach is essentially a convenience for handling quantity symbols, especially if some contain superscripts, subscripts, or both. I think it might make sense in a section with equations that use f as the symbol for focal length; consistency, at least in such a section, would seem the key consideration. Some ISO standards seem to do this for quantity symbols (perhaps they also use TeX). Outside of a section where many quantity symbols are set using TeX, however, this usage would seem hard to justify, because it just isn't that hard to code f using ''f''.
• f/: This has far and away the most support in professionally published works, though it's not apparent because most usage occurs when the running typeface is serif. Of the sources I've seen that use sans-serif typeface for the surrounding text, all use a sans-serif f. One source, the Kodak publication that I cited, makes extensive use of both serif and sans-serif type, and sets the f to match the surrounding typeface. The extra spacing is an ugly way to deal with deficiencies in most browser's rendering, and would seem inadvisable outside of a template, where the ugly details can be hidden and the template revised if browsers get smarter in preventing glyph overlap. Expecting more than a handful of editors to use this coding and get it right is simply not realistic.
• f/: this is the most basic, and arguably the most justifiable. Nearly half of my sans-serif sources seem to do it this way, but I know Dick has strong issues with the crowded appearance, and I'm not too fond of it myself. But this is really one of only two options when hand coding (the other is Tex).

There are at least four options for handling the solidus: using either upright or oblique font with either the normal solidus or the fraction solidus. Practice in professionally published works varies, but the normal solidus seems to be the most common.

[Inserted comment] Upon further thought, the fraction solidus would confuse searches, so it's probably not a good idea. JeffConrad (talk) 21:06, 10 January 2009 (UTC)

Once again, I return to my initial premise. We'll never get proof beyond a reasonable doubt, but I don't think we require it—preponderance of the evidence should suffice to answer the question, as I assume it does elsewhere in WP. I'd argue that we have far more than this—clear and convincing evidence that the f should simply be set in the “italic” font of the base typeface, essentially treating it as an ordinary quantity symbol. Accordingly, the template should produce this rendering. Adjusting the spacing to keep the f from touching the solidus would be an additional nicety for sake of appearance, but since it's easily done with a template, why not? Hopefully, the appearance would be acceptable with either the default typeface or a generic serif typeface (getting best results from every possible typeface would probably be impossible). JeffConrad (talk) 08:24, 10 January 2009 (UTC)

Possible compromise

As I indicated above, I'm now thinking we should leave this up to the individual editors. Keep the template for those who are using f/ as a distinctive symbol. Those who are thinking of it as just the symbol for focal length divided by something should use whichever markup they are using for other variables in the article. I no longer support the idea of having a template for the latter cases nor special coding to adjust spacing. If f is just a variable, it should be typeset like any other variable. Problems with spacing of variables in mathematical expressions should be fixed in the math rendering routines, not via special-case templates.

I boldly adjusted the description at the top of the page to reflect this, with the thought that at least this is better than the text that was there previously, which implied that this template was the only way. I hope that this change is acceptable to the others involved here.--Srleffler (talk) 04:36, 12 January 2009 (UTC)

It's not a compromise, because nothing has really changed. I still take very strong issue with the wording “using a hooked f as is common in photography”, and especially with illustration using the Georgia typeface, because it implies substantial support for a premise that has not been supported. Technically, the statement may not be incorrect, but it's extremely disingenuous in the context of WP, where the running text is in sans-serif type rather than the serif type that is common in photography, and very few editors are likely to pick up on this subtlety. Again, absolutely no credible evidence has been shown for treating the f/ symbol as special, and considerable evidence, based upon very reliable sources, has been given in support of the alternative. The existence of a template implies a preferred method of coding, and yet again, no justification whatsoever has been shown for that preference. I think this sets a very bad precedent, saying in effect that that the burden of evidence falls upon those who challenge a statement, which is precisely the opposite of what's prescribed in the WP guidelines (I don't want to get into the lack of a specific requirement to use a reliable source for typography; nothing in the guidelines says I can't change typefaces in the middle of a word, either). This simply is nuts.

One other minor issue with the wording: the template does not produce the “symbol for f-number”; the f-number is the denominator of the fraction. I suppose we could quibble over whether the fraction is the aperture or the relative aperture, but it is most assuredly not the f-number.

In addition to overwhelming practice, common sense argues against special treatment. The expression f/N means focal length divided by N; I suppose that it's possible that the f has some meaning other than the obvious, but when I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck. By comparison, arguments for WMDs in Iraq and O.J.'s innocence seem rock solid.

I'm almost inclined to revert every edit that replaced my simple use of f/ with the template; if those edits were acceptable, so then would be my replacement of every instance of the template. But I'm not sure what that would really accomplish, and there are better uses for my time, so I probably won't bother.

In general, I have nothing but respect for the folks involved in this discussion, but I think most have missed the boat on this one. To be frank, this has been one of the silliest discussions in which I've ever been involved. I don't mean to be unnecessarily confrontational, but I'm disappointed that absolute illogic seems to rule the day. The evidence against special treatment is so overwhelming that it's tough to imagine the alternative prevailing in any other venue. Were a civil jury to return a verdict based on such insubstantial evidence, the judge would almost certainly overturn, and would almost certainly be reversed by a higher court if he declined to do so. It's not a matter of pushing for the way I would prefer it, but rather a desire to see things done properly. Were there a credible case for special treatment, I would be among the first to support it. But again, no credible evidence whatsoever has been given to support special treatment. JeffConrad (talk) 08:00, 12 January 2009 (UTC)

I respect you guys a lot, too, and agree that it's a silly argument. But Jeff, you go a bit far when you say "absolutely no credible evidence has been shown for treating the f/ symbol as special." In fact, it's quite clear that special treatment happens via the unicode hooked-f glyph, on at least a few photography sites; there's no overwhelming evidence to indicate that some other sites don't also treat it or think of it as a special symbol. I do agree that you pretty well shot down my original impression and recollection, via the standards docs and the various modern Kodak docs. Still, reasonable doubt exists, and I'm not the only one who saw it that way. That's all I have to say. Dicklyon (talk) 08:19, 12 January 2009 (UTC)

Me go a bit far? Impossible ... OK, “absolutely” is a pretty, well, absolute, term. But let's look at another simple example to illustrate why I don't give much credence to the Google hits for pages that use the florin symbol ƒ. A Google search for "vlave" gave 52,300 hits; does that mean it's an acceptable alternative spelling of valve? A search with the correct spelling gave 79,200,000 hits, or only about 1500:1 for the correct use. Obviously, this isn't the whole story, because many of the sites with the incorrect spelling also use the proper spelling elsewhere. The point is that an unqualified Google search can seem to justify almost anything. More important, it makes no sense to find in favor of one interpretation when usage for the alternative is 4200:1. I'd still call that ratio “overwhelming”.

There is at least a reasonable doubt that my assertion isn't correct. But that's largely irrelevant:

1. This isn't a criminal trial (or any sort of trial), so I doubt that the standard of beyond a reasonable doubt would apply. A standard comparable to preponderance of the evidence in civil matters would seem more appropriate. In other words, the better of the two arguments should prevail.
2. The burden of evidence is on the maker of an assertion, and the preponderance of the evidence (and then some; I'd say there is clear and convincing evidence) is against the contention that f/N is a special symbol.

My point once again is simply that the argument against special treatment is so much stronger than that for special treatment that it would be simply astonishing for the latter to prevail.

“I do agree that you pretty well shot down my original impression and recollection, via the standards docs and the various modern Kodak docs.”

Your recollection is probably correct. But more than anything else, this seems to indicate that you are fortunate enough not to have any photography books set in sans-serif type. JeffConrad (talk) 10:49, 12 January 2009 (UTC)

Some articles probably should move from the template back to standard math markup. I would support the switch in articles that already use non-negligable amounts of math, especially if the variable $f$ appears representing focal length. In such cases, the expression should be rendered using the same math markup as other expressions in the article. I took another stab at the wording in the "usage" section.--Srleffler (talk) 05:43, 13 January 2009 (UTC)

I agree that comparable treatment should be given to all quantity symbols (regardless of the quantities they represent), at least within a section that includes displayed mathematical expressions. But this is a general mathematical markup issue rather than one directly related to f/. The case for using TeX elsewhere is less strong; I'm not sure that TeX is appropriate in a section without displayed equations. This still doesn't resolve the situation with f-number; it seems mighty strange to have both f/ and f-number in the same context, yet $f$-number seems equally strange, especially since I'm unaware of its use anywhere else.

I cannot support the usage description because it is both wrong and disingenuous, for reasons I previously stated: the f-number is the denominator, and using a “hooked f″ is very uncommon when the base typeface is sans-serif, as in Wikipedia. The former issue is comparatively minor, the latter is not.

At the risk of further beating a dead horse that has already been resurrected and beaten to death again several times, this is one of the most absurd decisions I have ever seen. For some reason, the use of a special symbol on 0.02% of web pages is deemed more credible than usage on the other 99.98% of web pages that don't give special treatment. Moreover, the usage on this small minority of web sites, most of which are subject to no oversight of any kind, is deemed more credible than publications by ISO, Kodak, Focal Press, and Amphoto. I simply have never seen a situation where such an overwhelming minority position argues for its adoption. Topping it off is the decision to use a symbol for which we haven't found a single instance of usage. I'll comment no further lest I get carried away.

We're obviously at an impasse on this. We've discussed almost every conceivable on this, so I don't think additional discussion would lead anywhere. I'm not sure that there's procedure for marking a template as disputed, but I'm inclined to try it nonetheless. Perhaps I've missed something obvious, but I am simply exasperated by what seems a stubborn insistence on ignoring the facts. I don't mean this as a personal issue, but the practice embodied here is absolutely unsupportable and just plain wrong. Continuing to employ it does a disservice to Wikipedia readers in encouraging the propagation of misinformation. JeffConrad (talk) 07:35, 13 January 2009 (UTC)

What would Sidney Ray do?

The Manual of Photography (Ray 2000), p. 62, says "The numerical value of relative aperture is usually prefixed by the italic letter f and an oblique stroke, e.g. f/2, which serves as a reminder of its derivation.", which I would interpret in terms of Italic type (as opposed to Italic_type#Oblique_type). I would interpret "as a reminder of its derivation" as suggesting that the f can be though of as a quantity symbol, but is not necessarily to be literally taken that way; that is, when one says that they have an f/2 lens, they want you to take that as a symbol, not literally to be reduced to mean "a lens with aperture diameter equal to f over 2"; that's because the aperture diameter is not what they want to communicate -- the 2 is. So the notation is actually quite "special". I think this mention of "italic" and the explanation in Italic type, can be the basis of a convergence between our different points of view. Maybe we can use a template that forces the selection of a font that has an actual italic f in it, whether we have serifs or not? Dicklyon (talk) 23:46, 13 January 2009 (UTC)

What would Sidney Ray do? See p. 219 of Applied Photographic Optics, 3rd ed. (Ray 2002), Figure. 22.5. Let me guess ... it's at the office.

Strictly, Ray refers to “italic”, as does NIST Special Publication 811. But the latter also refers to “roman”, implying that the base font is a serif typeface, as is still the norm in published works. I think the section Italic_type#Oblique_type also suggests an answer:

“In many computing interfaces, the text leaning effect is called Italic, whether or not an italic font is used to render the text.”

It's certainly the meaning in the context of Wikipedia, as should be clear from WP:ITALICS. It's also the convention followed in the naming of most font files and the operation of most word processors (or at least MS Word), even though it's strictly not correct. I could easily count on one hand (with fingers left over) the number of people I've known who understood the difference between true italic and merely oblique type. In the context of f/N, Focal/Ray, Amphoto, Kodak, and ISO seem to agree with me. I don't think we've yet seen an authoritative example to the contrary.

I suppose it's possible that f/N is not intended to be taken literally, but since the aperture is exactly what the expression indicates, it sure seems like a struggle to reject the obvious. Again, when I see a bird that walks like a duck ... And I think the examples I just cited bear this out. I also have difficulty accepting that the f in f-number is distinct from that in f/N: what else could it be? But I realize that practice varies more than that for f/N.

It should be simple to make a template that changes to a sans-serif font in which the oblique f is a descender. This certainly is the exception rather than the rule with sans-serif fonts; so far, I've only found three on my computer; appearances are

f/8: Trebuchet MS

f/8: Candara

f/8: Corbel

Spacing could easily be adjusted if necessary. I'd say the Candara is an obvious mismatch; the others might be passable. Of course, the font(s) would need to be present on the user's computer for this to work. Although aesthetics might be acceptable, switching typefaces seems pretty marginal practice. Without very good reason, it normally just isn't done. The only common examples I can think of are tensors (set in sans-serif oblique) and computer instructions (or similar endeavors, as in WP:MOS). Perhaps switching to a sans-serif font would be less odious than switching to a serif font. But there's another problem: a user who changed skins to have a serif default typeface would have the f forced to sans-serif; I have no idea how many users use other than Monobook, but that a scheme would not be robust enough to accomodate this would seem to argue against adopting it.

I'll concede that we did find some examples of using the florin symbol ƒ (U+0192). But a closer examination of some of these sites indicates practice is all over the map, variously using ƒ, f, f, F, F. It's hard to take such a site as a reference. I did notice that Werner Publishing (Outdoor Photographer, Digital PhotoPro) seem far more consistent, and as professional publishers, they merit greater consideration than JoeSiksPak's home page. The print versions of OP are interesting; they have articles in serif text as well as some other articles in sans-serif text. Since at least 2000 (the oldest issue I had), the articles in sans-serif type appear to use the florin symbol in ƒ/N; without an oblique f for comparison, it's tough to make an absolute call, but because oblique sans-serif fs that are descenders are rare, I'd assume the florin symbol without good evidence to the contrary. Interestingly, the articles in serif type appear simply to use an italic f; again, it's tough to be sure, but after comparing both symbols for most of the serif typefaces on my computer, I was able to distinguish the two glyphs in every typeface but Euclid. I'm not really sure what this means; my initial impression is that of typesetting for appearance rather than content. I briefly discussed this with one of Werner's editors, who thought they regarded the ƒ as a special symbol, dictated by photographic convention, much as Dick suggested. I'm awaiting a more detailed answer (and yes, no one had asked such a question before).

In a sense, I have less difficulty using a particular symbol than with arbitrarily changing typefaces for the sake of appearance, though it still seems appearance for appearance's sake. From a practical standpoint, this would likely confound those searching for f/, as Srleffler and I have suggested. And I still question the logic for using this symbol without some persuasive reason.

At least we have some precedent for using the florin symbol ƒ, and we have found none at all for forcing and italic f. But I repeat what I have said several times: though there are a few arguably credible sources, the alternative usage of 4200:1 would seem a mighty persuasive argument, likely to carry the day in any other venue in which I've ever been involved. If quality rather than quantity is paramount, it's hard to imagine that following the lead of ISO, Kodak, Focal, and Amphoto would be a mistake. JeffConrad (talk) 02:50, 14 January 2009 (UTC)

Yes, all true. The actual meaning of "italic" has been severely diluted over the years, and an oblique font is commonly called italic when it's not. I think that explains a lot of the sources you refer to; I prefer to think of them as inadvertant failure to follow the convention; and I interpret Ray's statement as literal support for the convention. I realize the alternate interpretations are also quite possible. Going back to look for info about the italic f in old books, I find things like The American Printer by Thomas MacKellar (1870), which pretty much defines the italic f that I always thought was the right answer. I don't deny that the convention has been somewhat eroded since around 1960, but I still think we should respect it now that we have good evidence and explanation for what may be going on. Dicklyon (talk) 03:49, 14 January 2009 (UTC)

I cannot believe that Ray's statement was intended to literally specify true italics in other than a serif base font, especially when he doesn't follow that practice himself, but rather uses an oblique sans-serif font when the typeface is sans-serif, as illustrated in Figure 22.5(b) of Ray (2002). ISO, Kodak, Amphoto, NIST, and the BIPM do likewise; like Ray, the last two talk of italic (for all quantity symbols) but use oblique when the base font is sans-serif. We've still not found a credible example that does otherwise.

I am unaware of any tradition of inserting serif symbols into sans-serif running text; to the contrary, every one of the half dozen or so typography books that I've read said this just isn't done. We've noted the exception of rendering symbols with TeX in a context such as Wikipedia. In most cases, this is primarily a matter of convenience, as was using eqn for quantity symbols with troff; at least troff defaulted to serif typeface, and eqn could be forced to sans-serif if someone really thought it necessary. The argument could also be made for using TeX for symbols in running text to have them match the same symbols in displayed equations, but there's very little justification for doing so in other contexts. Aside from tensors and computer instructions, only one other example of mixing typefaces comes to mind: Merklinger, who uses serif type for running text and sans-serif type for symbols in running text and in displayed equations. Suffice it to say this is a bit unusual; recall that his books are self published.

I have no quarrel with MacKellar; modern books on typography give similar descriptions. But note once again that the book is set in serif type, and distinguishes between Roman and Italic (we seem to have subsequently lost the initial caps somewhere ...), terms inapplicable to sans-serif type, which has upright and oblique. The cited page in that book is simply not applicable to this discussion. I can see no justification for insisting on a meaning of “italic” different from that used throughout Wikipedia. Should we demand that the WP:MOS be revised to replace every instance of “italics” with “obliques”? Whether the colloquial use of “italic” to mean oblique as well as true italic is for good or for ill, that train left the station long ago, the track has been torn up, and the station has been demolished and burned as firewood. Given the current financial climate, I think rebuilding is contraindicated.

Again, you seem to urge allegiance to a tradition alleged but whose existence we can't even seem to demonstrate, while completely ignoring fairly widespread practice among authoritative sources.

What would Sidney Ray do? Why not just look at what he does and do likewise. As do ISO, Kodak, Amphoto, NIST, and the BIPM. JeffConrad (talk) 07:00, 14 January 2009 (UTC)

Some additional, though not quite complete indication of how Sidney Ray (or at least his publisher) might approach it. The Lens in Action (Focal Press, 1976) is set in sans-serif type, as are the fs. The typographical scheme isn't quite the same as we're talking about here, but rather f8 and f-number (the latter actually is the same). The Photographic Lens, 2nd ed. (Focal Press, 1992) is also in sans-serif type, and uses mainly f 8 but occasionally includes the solidus as in f/2.8 on p. 90. The book seems to use both f-number and f number; the occurrences aren't that many and I did not attempt to determine the relative frequencies. Perhaps the differences are due to changes in the 2nd edition, but of course there's no way of telling which is which. In both books, the fs are sans-serif oblique and are not descenders, much the same as the ISO standards. Interestingly, neither book seems to put other quantity symbols in oblique font, but rather leaves them in upright sans-serif like the rest of the text. So perhaps they did treat the fs as special. It's possible that only the publisher knows; what seems important, however the fs are regarded, is that they are in the same sans-serif typeface as the text.

I had not previously mentioned these works because of the inconsistencies in the use of the solidus (or complete lack thereof), but perhaps the punctuation is a minor issue. JeffConrad (talk) 09:08, 14 January 2009 (UTC)

They're way before he committed in writing to the italic f and oblique stroke; they also support my conjecture that he's thinking more of a special symbol than a literal math expression; you can't interpret the f there as a focal length quantity symbol. Sigma always just uses F8 on their stuff; just a symbol. Dicklyon (talk) 15:58, 14 January 2009 (UTC)

If you look at Figure 22.5(b) on p. 219 of Ray (2002), you'll see that he uses f/4, all in sans-serif type, in the figure. Now I suppose it could be argued that it was an old figure drawn for an earlier edition, but there's probably a way to dismiss almost anything as inapplicable.

I think the lack of the solidus is what led to the later comment about the “oblique stroke” to remind of the origin of the expression/symbol/whatever. As you noted, a fair number of people still use F8 or f8 or f-8; one logical explanation is that's it's the way it's usually pronounced. I know many photographers who utter “eff-eight” without a clue as to what it actually means; it would seem quite logical that Ray was simply urging a logical rather than phonetic rendering.

But let's back up a minute for a broader look. The use of the solidus elsewhere long predates the 9th ed. of the Manual of Photography; it's in ASA Z38.2.6-1948 in serif type, as is the case for later ANSI standards. ISO 2720:1974 has the solidus in sans-serif type (full disclosure: I have the 1994 edition, so I can't really say what it looked like when first issued). The Kodak Dataguide that I cited is from 1986, and uses both f/8 and f/8, so there's at least one example of a 22-year tradition of the f matching the typeface of the running text.

We probably could quibble all day (and then some ...) about whether the f/8 is a mathematical expression or just a compact way of expressing N = 8 or f-number = 8, but I think we'd really splitting hairs over the significance of the difference. I lean to the first interpretation because it's just the right-hand side of a rearraged version of the equation relating entrance-pupil diameter, focal length, and relative aperture that Ray repeats several times in the first few paragraphs of p. 62 of the MoP. But ultimately, I don't think it matters that much. The examples we've seen all seem to match the f (whatever it means) to the main typeface; it strikes me as driven by typography rather than some special logic. Again, I don't think it's any more than the well-established practice that one does not mix different typefaces in running text without good reason. JeffConrad (talk) 22:03, 14 January 2009 (UTC)

From Adams, Camera and Lens, rev. ed. (1970), p. 95:

“The focal ratio of the diameter of the lens aperture in relation to its focal length at infinity setting is its f/number. When we speak of an f/5.6 lens or an f/8 lens, we mean that the largest opening is 1/5.6 or 1/8 of the focal length at infinity setting.”

The fs are set in roman type, as are the symbols in displayed equations in the book. The other books in the original Basic Photo Series use the same typography.

From The Camera, 1980, p. 46:

“The lens aperture is simply the diameter of the lens opening, expressed as a fraction of its focal length.... The aperture designation is expressed as f/4, indicating that the aperture is the focal length/4.”

Again, all set in roman type. As with the earlier edition, symbols in displayed equations are in roman type.

It sure seems like Adams didn't treat this as a special symbol. Because the fs in this context are in the same font as symbols in displayed equations, they well could be ordinary quantity symbols; Adams's descriptions certainly lend themselves to that interpretation. But again, I'm not sure it really matters; the symbols appear as they appear, and there's nothing whatsoever to suggest that they are magical. JeffConrad (talk) 00:56, 15 January 2009 (UTC)

Erm, if you start looking at books from the 1940s and 50s (as Adams' books were), I can show you all sorts of math texts which use regular letters for things that are written as special symbols on a chalkboard and in modern typeset documents. I don't think that proves anything, except that whoever printed Adams' book in 1948 didn't use a special glyph, and that later editions didn't bother to change the convention. Whatever the glyph used for "f", "f/#" is clearly a typesetting convention which is unique to f-numbers. --jacobolus (t) 02:20, 15 January 2009 (UTC)

“"f/#" is clearly a typesetting convention which is unique to f-numbers.”

What can you cite to support this? If it's really the case, examples should be easy to come by. Yet none have been shown. Rather, everything we have seen supports that it is nothing special at all.

Adams's completely new books from the 1980s follow the same convention. The only significant difference in most of the other works from the 1940s, 1950s, 1960s, 1970s, 1980s, 1990s, and 2000s is that the f is set italic font (or in oblique font when the main font is italic); this is nothing other than the treatment given quantity symbols. Is x/2 then special as well? But as I've said, I really don't care whether it's a quantity symbol; it looks as it looks and it's nothing special. JeffConrad (talk) 06:01, 15 January 2009 (UTC)

Jeff, far be it from me to deny that f/N is a literal formula for aperture diameter; my point is just that it's not "only" that. It's also a funny notation for conveying the f-number, and it's in that context that my impression was that it was ALWAYS set in italic. Obviously, that's not true any more. You argue that it's always set in the oblique form of whatever font the surrounding text uses. That's apparently also not always true, as it's also set in Roman, or non-oblique type; also sometimes as f:N, FN, etc. Is there an historical or logical basis for my impression? I'm not sure any more. But it's not the open-and-shut case that you'd like it to be, either. So I think it comes down to what do we like. Our opinions on that are well known. Dicklyon (talk) 03:41, 15 January 2009 (UTC)

Does it convey the f-number or the aperture diameter? Adams seems to imply the latter; if that's the case, it's not a funny means at all. But for most practical purposes, the distinction is a matter of minor semantics. JeffConrad (talk) 06:01, 15 January 2009 (UTC)

We also have an article on the long-letter f; it was a special character on four early character sets, according to Western_Latin_character_sets_(computing)#Comparison_table, and it's "based on the italic form of f; or on its regular form with a descender hook added." Seems to me that's what it's there for, but I don't really know; maybe really for florin and folder only. Dicklyon (talk) 04:52, 15 January 2009 (UTC)

I've only seen it used for the florin and the folder, but I'm hardly an expert here. We do have the example of use in Outdoor Photographer, at least with sans-serif type. I think it's for appearance (would you pronounce it “hooked eff four”?), especially because they don't seem to use it with serif type. But I'm speculating. JeffConrad (talk) 06:01, 15 January 2009 (UTC)

Here's an old one where they say "f.4", no solidus, no italics, and ambivalent about f being a quantity symbol, not quite like the nearby italic a. The f. is just a symbol for the focal ratio. Doesn't prove much. Dicklyon (talk) 05:02, 15 January 2009 (UTC)

We agree here. Typography has been all over the map, much as with f-number. Incidentally, Ray and I seem to agree that the f-number is the denominator rather than the entire entity f/#.

I failed to cite Adams earlier because just as with the works by Ray that I recently added, it seemed irrelevant with the f in roman type. I also passed on books by George Lepp (self published), Art Wolfe, and various manufacturers (e.g., The Hand Exposure Meter Book) that put the f in upright type (the last work in sans-serif).

With all due respect, to say that inconsistent treatment means that we can do whatever we want is off the deep end. The case is not open and shut for many topics treated in Wikipedia; that doesn't mean that facts can be made up. The role of Wikipedia editors is documentation rather than invention.

An open-and-shut case shouldn't be needed here. Let's recall that this began from a statement that has proved impossible to substantiate. And the burden of evidence is on the maker of the statement; absent supporting evidence, the statement cannot stand if challenged. Not only has no evidence whatsoever for the proposed treatment been shown, but a pretty solid case has been made to do otherwise, citing works from authoritative third-party publishers.

A case could be made could be made for choosing among treatments in third-party published works; this would allow the option of setting the f in upright type or simply using something like F8 or f8 or f.8 or f-8. To me it would seem silly to follow the comparatively infrequent practice rather than that predominant in authoritative works, and everyone's comments suggest that none of these would be a preferred option. But there are probably enough examples, especially of putting the f in upright type, that it would be tough to say doing so is wrong.

Again, I think following the practice of the bulk of the professionally published works that we've discussed is the best approach; there are alternatives, but one that's bad typography and not seen anywhere else simply cannot be justified. JeffConrad (talk) 06:01, 15 January 2009 (UTC)

One counter-example

The Optical Society of America, a major publisher of optics journals, uses the unicode hooked-f character ƒ for "ƒ/#" in article titles and abstracts on their website.[2] I checked a half-dozen or so of the full-text articles and in every case an italic f was used in the full-text pdf. It appears that they are deliberately substituting the hooked-f character for an italic f when they convert the pdf text to html, presumably to preserve the hooked appearance of the italic f, even though the web pages use a sans-serif font. This indicates that at least one major optics publisher considers that a hooked f should be used regardless of whether the base font is sans-serif.--Srleffler (talk) 18:28, 15 January 2009 (UTC)

How strange, but interesting; it's clearly not about f-numbers per se, as they set all kind of "f" things this way. Dicklyon (talk) 18:45, 15 January 2009 (UTC)

As Dick notes, they seem to insist on forcing a cursive f-like symbol whenever f is used as a quantity symbol, e.g. “gf-value”. This sure looks like diddling the glyph for the sake of appearance; I don't have a good source that says this practice is deprecated, but I think it should be. Seems to me if they absolutely must have a cursive f, they'd be much better off putting the abstract in a sans-serif typeface that provides it (e.g., Corbel or Trebuchet). The downside, of course, would be that the font may not be present on the user's computer or the user may have set his browser to ignore CSS.

Another question is the amount of oversight for the OSA web pages: is it a conscious decision by someone in charge or did someone just get creative? JeffConrad (talk) 23:48, 15 January 2009 (UTC)

A less esoteric example not directly related to this issue is the appearance of “fi” and “fl” in many serif typefaces. Rendered normally (e.g., field, flow) these pairs, especially the former, do not give a very good appearance. The traditional solution in printed media is to substitute ligatures (U+F001 and U+F002) for these pairs, giving eld, ow. Older formatting programs like troff and TeX made these substitutions automatically; current word processors (at least MS Word) do not. It's easy enough to perform a manual substitution, but it's not so simple when the output medium is an electronic format, such as PDF. Unless some additional steps are taken, a search for “eld” may fail to match. Because use of these ligatures affects ordinary words, it's potentially a bigger issue than using U+0192 for f. A PDF file created with Acrobat PDFMaker apparently adds the equivalent ASCII pairs for searching; this doesn't seem to be the case when simply printing to the PDF drivers for Acrobat and a couple of others that I tried. If a document is prepared with MS Word and converted to PDF with Acrobat, a search for “field” using Windows Explorer will find the match in the PDFMaker-created PDF file but not in the source or the other PDFs.

Consequently, using the ligatures for appearance in MS Word can be dicey if the target is a searchable document. The practice is accordingly deprecated by some who maintain that employing it sacrifces content for appearance (as Srleffler commented earlier), and provides proper searching in some cases (e.g., PDFMaker output) only because of a gimmick; they suggest that the ligatures be handled in rendering (e.g., by the browser or other viewer such as Acrobat). I agree, but few viewers do this. I grew quite accustomed to the appearance of ligatures in printed output from troff, and have sometimes manually substituted ligatures in MS Word documents (e.g., my DoF paper). For now, this seems safe because I usually use PDFMaker, but perhaps its still a bit risky.

In any event, this demonstrates that diddling glyphs for appearance has unintended consequences and suggests that it may not be the best practice. JeffConrad (talk) 02:19, 16 January 2009 (UTC)

One example supporting keeping the same typeface family

See the Manual of Photography, 9th ed., p. 82. The figure uses sans-serif type and shows “f/8”; the figure caption is in serif type and shows “f/8”. I don't know that this really proves anything, but it certainly does suggest that Ray didn't mean “italic” to force serif typeface. To avoid clutter, I'll henceforth use “italic” to include non-cursive oblique, and “true italic” or “serif italic” when that's literally what I mean.

I'd still say the f is a quantity symbol, but I probably can't prove it. If it's not a quantity symbol, though what is it that justifies italics, using criteria in WP:ITALICS or similar guidance from another style guide such as the Chicago Manual of Style? One possibility might be a letter used as a word, as we've already discussed. To me, this makes more sense in “f-number” than in “f/#”, but if the “f/” is really just an ornament, as could be inferred from Ray (2000, 62), then I suppose it could apply in the latter case as well. Aside from these two, I can't offhand think of an interpretation that would indicate italics.

What always struck me as the most wrong (and still does) is changing typefaces in running text; perhaps I obscured this by focusing too much on the quantity-symbol issue.

I no longer have access to the typography books to which I alluded, and it's probably been 15 years, so perhaps my recollection isn't 100%. I did examine every style guide that I have, and about 50 web sites that discuss mixing typefaces. I was unable to find an express proscription of mixing typeface families in running text, but neither did I find any examples, save two situations: run-in side heads and emphasis; the latter was only mentioned on a few sites, and I've seen few examples in professionally published material. The only common exceptions I've encountered are instruction manuals, typographically illustrative examples such as in the first paragraph, and of course using TeX or an equivalent to format quantity symbols or inline equations. The latter, as we've discussed, is usually more a matter of convenience that adherence to typographical principles. Aside from these few specific exceptions, font switches seem to stay in the same typeface family.—Preceding unsigned comment added by JeffConrad (talk • contribs) 18:28, 15 January 2009

Nobody's arguing with you on that; if I'm right, the "right" thing would be to use the italic-form long-letter f that's in most fonts, the unicode fnof. Dicklyon (talk) 05:10, 16 January 2009 (UTC)

Actually, “&fnof;” is an HTML entity; the Unicode people made no such (incorrect) presumption :-).

I take this to mean you agree that it's wrong to force a serif italic f ... I'm afraid I can't agree with you on substituting “ƒ” for “f”, though. This is a symbol that has no tradition of support aside from 0.02% of web pages we found in Google searches. OK, it does seem to find some support in sans-serif articles in print versions of OP, but that they use italic f in articles in serif type raises questions. And what with f-number? Are we to use ƒ-number instead? OP do this (“ƒ-Stop”, top of the front cover, June 2008), but I've yet to see it anywhere else. How many editors would actually do this? And if we did not do it, we'd be the first to use different symbols for f/# and f-number. It seems as if some folks just can't accept that in most sans-serif typefaces, the italic f is a very ordinary character. I don't especially like the oblique f either, but that is the consequence of a decision that Wikipedians made and which we don't have much choice but to accept.

Incidentally, I'm now almost certain the cursive f-like symbol OP use with sans-serif typefaces is U+0192; the a in the italic font is the same basic glyph as in the upright font—sometimes it pays to look at the obvious. To me, this just doesn't look quite right, but I'm obviously now hyper-vigilant, and perhaps I've also just long expected the symbol to be an f.

As I indicated in my digression on fi and fl ligatures, glyph diddling isn't very good practice. In the case of ligatures, there at least is a long-established tradition (in printed media, anyway); in the case of ƒ, there isn't even a tradition. Again, I don't think much of a case has been made for forcing a serif italic f or using another symbol with a similar appearance, while I've presented quite a few examples from unimpeachable sources supporting my contention that the f is simply italicized. It seems as though every time I present another solid example, a new argument for rejecting it appears. Is it really that likely that ISO, Kodak, and Ray have it wrong? JeffConrad (talk) 06:54, 16 January 2009 (UTC)

I can agree that it's "wrong to force a serif italic f", but it also seems wrong to use a sans-serif oblique f. That's the problem; the ways of doing it "right" seem to need "glyph diddling" in a sans serif context. Dicklyon (talk) 06:58, 16 January 2009 (UTC)

But why is it wrong to use a sans-serif oblique f? This has always been the puzzler for me. ISO and Kodak do it ... Ray does it ... Jeff does it :-) ... JeffConrad (talk) 08:12, 16 January 2009 (UTC)

WP:IDONTLIKEIT, that's all. Dicklyon (talk) 08:26, 16 January 2009 (UTC)

So essentially, IWannaDoItThisWay ... INeverWouldaGuessed. It should be obvious that I have similar feelings about sans-serif type in general for running text, to a degree that I cannot describe without violating talk page guidelines. But as I grow older, I gradually come to acquiesce in my role in life ... occasionally to lead, often to follow the lead of others who may have reached the finish microseconds before I, but hopefully always to stay out of the way. Toward that end, I would probably do as Sidney Ray has done, but hope that some day my publisher, like his, would put the running text in serif type. JeffConrad (talk) 09:33, 16 January 2009 (UTC)

Jeff, it's a choice between bad alernatives. I think that you've made a good, but not perfect, case to do it your way. I'm just saying it's not that clear and I don't like it. Srleffler doesn't like it either. You're not going to make us like it; it's uglier that what we have now. Wikipedia already has a huge number of "math" style symbols inline in sans-serif text, so it's not like we're breaking all precedent the way we do it now. It looks OK, so why mess with it? Dicklyon (talk) 17:40, 16 January 2009 (UTC)

I'm not sure the choice is between bad alternatives. We all prefer the appearance of the serif italic f, but I think forcing it in sans-serif type is crap, as you've agreed. I'd fix the problem by making the default typeface serif. But that ain't gonna happen. And I think ugliness is irrelevant as well as in the eye of the beholder. My interest is in doing things right, and the current practice simply cannot be justified on any basis—we actually are breaking all precedent. It's just plain wrong. Doing something that's wrong but that we sorta kinda like is not the prerogative of Wikipedia editors. If the government becomes a lawbreaker, it breeds contempt for law; it invites every man to become a law unto himself; it invites anarchy. And when Wikipedia becomes the origin of urban legend, Wikipedia loses all credibility. JeffConrad (talk) 18:14, 16 January 2009 (UTC)

Don't you think that "It's just plain wrong. Doing something that's wrong but that we sorta kinda like is not the prerogative of Wikipedia editors. If the government becomes a lawbreaker, it breeds contempt for law; it invites every man to become a law unto himself; it invites anarchy." is a wee bit extreme? I mean, we're discussing minor variations of a typographical convention here. Ultimately, the purpose, like for any typography, is to clearly represent information. In this case, the use of an italic f in f/# arose out of some combination of authors thinking it was pretty & wanting to standardize usage & copying what others had done. The constraints we're dealing with are (a) conventionally an italic f is used, (b) it would be nice to allow searches for "f/", (c) using a completely separate style of typeface looks odd, (d) perhaps an oblique f is acceptable or even recommended or perhaps a true italic is always better, (e) forcing a true italic using a separate unicode glyph might be an abuse from standard of semantic purity. It strikes me that there's no real right answer in this case. I prefer the unicode hooked f glyph. It just looks better to me, and I think that it flows best in articles, setting off f/# notation without making it look completely foreign through the use of a serif typeface. But really it doesn't matter that much. I don't think there's enough information available to call one method definitively "correct" (these conventions arose in an age before widespread use of sans serif typefaces for extended text settings, and further in an age of printed output rather than digital documents with distinguishable unicode code points) and suggesting the picking the wrong method is "original research" that loses Wikipedia all credibility is just silly IMO. There are many typographic conventions in Wikipedia which are non-standard or non-optimal. --jacobolus (t) 01:39, 18 January 2009 (UTC)

A bit strong, perhaps, and perhaps also indicative of exasperation—a more reasoned approach just doesn't seem to work here. When I hear “I agree that it's wrong ...” but still hear urging to keep doing it, I have to wonder. I was not aware that personal preference was a valid reason for ignoring well-established convention. I've worked in several standards organizations, and have written or co-written several style guides. Except for unusual cases not covered by other sources, we relied on established practice, sometimes by other standards organizations but sometimes that in general style guide such as the Chicago Manual of Style, and except for basics, by reference rather than transcription if at all possible. It's quite a daunting task, and there was neither time nor justification for continually re-inventing the wheel. There always were a few who would attempt surveys such as “What do you use for emphasis: italic or bold?” The answer was invariably something like, “It's irrelevant; except for a few special cases not applicable here, italic is the accepted convention for emphasis”. When publishing a book of standards, it just isn't possible to have everyone doing as he pleases without making the publishing organization look amateurish. We had enough trouble making the content comprehensible ...

Perhaps there is no such thing as a “right” answer. But there is established practice that's usually followed; the WP:MOS gives rules for distinctive typographical treatment, and directs editors to other guides such as CMoS for cases that WP does not cover. Again, recall that this discussion began as a challenge to a statement about an unusual distinctive treatment, and that statement has proven impossible to substantiate. In any venue with which I've been associated, the statement consequently would not stand. I simply could not imagine WP:IDONTLIKEIT even getting an audience (and as that article indicates, it's not a persuasive argument for article deletion).

I'll stand by my comment (or at least the first two sentences; I included the quote of Brandeis “because I like it”). When the rules can be broken for no reason other than IDont'WannaFollow them, there' aren't any rules. And where does it end? The problem with indulging personal preference is that not everyone has the same preference, as demonstrated here—we have at least three. I've mentioned several times that I also prefer a serif italic f, but that's only in the context of serif surrounding type. I think it looks awful when surrounded by sans-serif type. So why can't I force serif type on my edits to give what I think is a far better appearance? The way silly and interminable discussions like this are avoided in almost every other similar context in which I am and have been involved is to follow accepted convention. I've more than once essentially imposed guides like CMoS and NIST SP 811 on staff simply because we could not have everyone doing as he pleased and could not spare the time to argue about it. And usually most of them would have made the same choices.

Not only has the original premise not been supported, but a fairly solid case has been presented that precisely the opposite is true. Is the case perfect? Of course not, but a perfect case is never required, even to convict of murder. And in cases other than criminal law, a much lower standard, usually just a preponderance of the evidence, suffices. We certainly have that here, and then some. And arguably, a case isn't even required—the burden of evidence is on whomever states a premise, as it is almost anywhere else. When no evidence is presented, the premise must fail.

I guess I just don't understand why what's good enough for ISO, Kodak, Elsevier, and Amphoto is not good enough for Wikipedia. Are we really that clever and they that stupid? JeffConrad (talk) 07:51, 18 January 2009 (UTC)

We have different problems to solve than they did. Unlike most other publishers, we use a sans-serif font because on screens with less than a hundred dots per inch these fonts look better and are more readable than the serif fonts that are traditional in dead-tree publishing. We have a rendering system that for no good reason renders mathematical symbols and equations in one of two serif fonts, with the distinction between the two determined by how complicated the expression is and how the reader's preferences are set. Editors frequently mark up mathematical symbols as if they were text to be emphasized rather than mathematical objects. This produces variables in sans-serif italics in running text, while the same variables appear in a serif font in equations. In some cases the same variable may appear in all three fonts in a single section of an article. So, you are arguing for typographic purity at the expense of aesthetics in an environment where our routine practices already lack typographic purity.

As I've said above, I think you guys have made a good case, and I support at least that mathematical articles should change to conventional math markup for f/. In particular, each article should mark up f/ using whichever notation is used in the rest of that article. No one will find $f/$ more aesthetically appealing than f/, but it's better typography if the article also has equations that use $f$ as a variable. As for the non-photography articles, if we make a change it should be by replacing the template calls with standard markup. Since you have argued that f should be typeset like any other variable, it should be typeset like any other variable. Perhaps this issue should be debated in a more public forum before the we start changing articles, however. Other editors may have an opinion on f/ vs f/.--Srleffler (talk) 05:23, 19 January 2009 (UTC)

Not sure I agree on the better legibility of sans-serif typeface on screens with less than 100 dpi; I have around 96 dpi and find serif type much more legible, provided that it's viewed at around 12 pt. It's not as nice at it appears on high-quality typeset on dead trees (e.g., the Manual of Photography), but still seems better. This may be but personal preference. Electronic media may have greater challenges, though, such as legibility on smart phones and similar devices—no question that sans-serif would be the winner there. My reference on practice incidentally was to the practice of dead-tree publishers when they use sans-serif type.

I think the reason math is always rendered in serif type is the I don't think TeX ever supported anything else.

I've come to agree with your observation that the predominant treatment of symbols in running text is simply to put them in italics; I've pretty much given up with the <var></var> tagging, because WP doesn't seem interested in content-indicative tagging (and in fact some of the WP editing tools, such as wikEd, simply replace these tags with double apostrophes). The use of <math></math> is helpful when doing something like combined superscript and subscript, which is almost impossible in HTML; I created a template, {{SubSup}} that does the job with current browsers but doesn't work with Firefox 2. But such a combination is rare, and the better approach is probably just the standard WP idiom of consecutive apostrophes. And the most important consideration is consistency, especially within a given section. I also suggest that it apply within a given expression, e.g., $f/8$ rather than $f/$8 (we'd probably say $N=8$ rather than $N=$ 8, though N = 8 might be even better). I've pretty much standardized on the {{nowrap}} template for expressions with spaces because I find it easier to read than nonbreaking spaces. I agree that few will find $f/$ more aesthetically appealing than f/, but many will find $f/8$ better than f/8, and may find f/8 even better (I asked a couple of folks who know something about book publishing but little about photography, and they immediately commented on the clash between the serif and sans-serif type).

In light of all this, I think my normal practice will be to directly code f/8, f-number, and use standard WP markup for other quantity symbols unless there is good reason to do otherwise, although consistency considerations could sometimes dictate otherwise. I realize that practice on f-number isn't perfectly consistent, though the bulk of sources I examined seem to use italics. The issue then arises of how to handle this when using <math></math> for $f/8$; forcing the serif f is unusual, though I must concede that I just found an instance of “$f$-number” in ISO 2720 (first paragraph in §4.1), so even ISO aren't perfectly consistent.

The template still could be used to adjust spacing, but the objection that this goes too far into diddling is probably well taken. There are some instances in which I've adjusted the spacing with thin spaces, and these probably should be replaced with simple markup.

The suggestion of talking with other editors before going nuts on changes is probably well taken, and it might touch on the more general issue of how to handle quantity symbols. In posing the question specific to f/, I think normal rules might guide:

1. What is the basis, if any, for using italics?
2. What is the basis, if any, for changing typefaces?

For the former, I might say that f is a quantity symbol (or perhaps a letter used as a word). Moreover, it seems to be common practice, for whatever reason. For the latter, it should be obvious that I'd say there is no basis, because one does not normally change typefaces, and we've not found examples specific to this issue in practice. JeffConrad (talk) 09:16, 19 January 2009 (UTC)

“In light of all this, I think my normal practice will be to directly code f/8,” — Please don’t do this. We have templates for several reasons, but one of the main ones is that it trivializes changing this sort of stylistic decision all at once and very easily if that is decided to be better. If you use f/8, etc. those will all need to be changed manually if a convention is established. –jacobolus (t) 20:27, 21 January 2009 (UTC)

In theory, I agree with you on the benefit of templates. If the template were used to adjust spacing, as was discussed at one time, its use would make sense, because the markup to to that properly is pretty messy. I still would have no problem with this. It's not without precedent; the eqn preprocessor to troff generates troff requests, some of which simply tweak spacing. The eqn syntax is simple and logical, whereas direct coding in troff is a mess the likes of which few people have ever seen. But in this case, if the decision is simply to use either standard WP italic markup or TeX rendering, it's hard to justify a template, especially in preference to ''f''/8. As nearly as I can tell, the direct markup follows typographical convention, while the template does not. I raised this issue here almost six months ago, and almost two years ago elsewhere. To date, nothing has happened, so I've continued to employ what seems to me the only correct option. JeffConrad (talk) 23:41, 21 January 2009 (UTC)

As for math, Wikipedia's convention of using sans serif typefaces for text and serif faces for math is stupid, ugly, and unconventional. Unfortunately, the alternatives aren't much better. MathML and friends just aren't widely enough supported to really use, and the primary goal of the encyclopedia is exposition, not stylistic purity. (TeX can certainly support sans-serif math faces, by the way.) —jacobolus (t) 20:30, 21 January 2009 (UTC)

I think we all agree that using two different typefaces is not a great idea. If indeed TeX supports sans-serif type, one approach would be to have the rendering in the same typeface as the text. It would not be as simple as having TeX render in sans-serif type; a user who set a serif typeface, either by changing skin or direct entry in a CSS file, would again see two different typefaces. Perhaps there is a way to have the rendering follow the default typeface for the text.

I agree that the primary purpose of an encyclopedia is communication of information. But using offbeat typography that simply reflects personal preferences of a handful of users does not improve the communication; I'd say the precise opposite obtains. Those who don't know better may assume that there is some convention for the current rendering; a similar situation seemingly arose from the claim that “light value” (LV) was the standard equivalent to exposure value (EV) for ISO 100 speed. Yet nothing to support that claim has been found. Those who understand typography are just a likely to see a nonstandard treatment and assume that Wikipedia editors just don't know what they are doing. As I mentioned, I've had a couple of people make just such comments.

As to what's “correct”, I think the only defensible approach is to seek guidance from the WP:MOS or other widely used style guide. There are many WP stylistic guidelines (e.g., sentence capitalization, and periods and commas outside closing quotes) that differ from my normal preferences; it is not my prerogative to ignore them, even though my normal practice finds wide support in published material. I would return to the two simple questions I posed above: if the answers support forcing a serif typeface, the current template is reasonable; if they don't, it is not. JeffConrad (talk) 23:41, 21 January 2009 (UTC)

Another Sidney Ray book

Sidney Ray, The Photographic Lens (1979) is entirely set in sans-serif font, and uses the oblique f as in f 4, with no solidus. Rather strange, I think, since in this form the f can't be interpreted as a quantity symbol -- and all of his quantity symbols are set in straight (non-oblique) sans serif, including the f in f/d. It argues that it's a somewhat "special" symbol, but also provides support for interpreting "italic" as allowing sans serif oblique, ugly though it is. Dicklyon (talk) 03:31, 24 January 2009 (UTC)

I had mentioned the 2nd edition (1992) of this book above. Most of the pages in the 2nd ed. are the same as Dick describes, but a few (e.g., p. 90, Autofocus Systems 1 and p. 206, Optics of the Compact Autofocus Camera) include the solidus. I assume that neither of these sections was in the 1979 edition, so the inclusion of the solidus may be a change that came with the second edition. The book also uses both “f-number” and “f number”. The fs in constructions such as “f 8” and “f8” are in sans-serif oblique font, but in equations, both inline and displayed, all symbols are in upright sans-serif font, so I'd say it's tough to discern what the author (or publisher) regarded as a quantity symbol. JeffConrad (talk) 07:46, 24 January 2009 (UTC)

Distinctive treatment and the distinction between “italic” and “oblique”

When the aperture is given as “f 8” or something similar (i.e., as it's usually pronounced), I'm not sure the f is anything more than a letter used as a word, in which case it would be set in italics. It's still tough for me to see f/8 as anything other than a fraction, with f the symbol for lens focal length, but since it would merit the same treatment as a letter used as a word, there would be no way to tell the difference from typography alone. The same would hold for f-number, which quite possibly is also a letter used as a word. I suppose it's possible that among f = 50 mm, f/8, and f-number, the fs are distinct entities, but it seems unlikely that all would choose the same symbol if they were unrelated; using just lower-case Latin letters, a chance occurrence would be 1/26³.

I re-examined three style guides that use both serif and sans-serif typefaces: the Chicago Manual of Style (15th ed., 2003), Words into Type (3rd ed., 1973), and Merriam-Webster's Manual for Writers and Editors (1998). All seem to apply “italics” to both true italics and to sans-serif oblique, using the former for italics when the main typeface is serif and the latter when the main typeface is sans-serif. Again, NIST and the BIPM follow the same practice, so I think distinctions between true italic and oblique fonts are rare except among type designers. Words into Type is interesting because it is one of the few style guides I've seen set in sans-serif typeface, and it uses sans-serif typeface even for displayed mathematical material. I had forgotten this, probably because the typeface is Optima, which although classified as sans-serif, has some characteristics of serif typefaces: it has hints of serifs, and is somewhat calligraphic, with variations in the width of the strokes. But the glyphs in the oblique font are essentially the same as those in the upright font, and the f is not a descender. JeffConrad (talk) 00:06, 25 January 2009 (UTC)

I notice that Linotype (owner of the Optima trademark) refer to the Optima fonts as “roman” and “italic”, so they apparently follow common informal practice; ITC do the same. Adobe use both “italic” and “oblique”, so they apparently consider the terms essentially interchangeable (or they're just a bit sloppy). JeffConrad (talk) 00:25, 25 January 2009 (UTC)

No, oblique = sloped roman, with double-story a & g, etc. italic = redrawn as a "cursive" face, with different letter forms than the roman. Adobe is quite consistent in their usage that I've seen, and do not use the two interchangeably. I believe some "italic" faces have an f without a descending stroke, but that's really neither here nor there. —jacobolus (t) 06:22, 28 January 2009 (UTC)

Whatever their normal practice, Adobe use the terms interchangeably in describing the Optima fonts—look at the link I provided. I have no disagreement with the strict definitions, but simply observe that the distinction is ignored (or unknown) in most contexts, including Wikipedia. And in this instance, Adobe. JeffConrad (talk) 06:35, 28 January 2009 (UTC)

A more literal interpretation

A further look at recent ISO standards suggests that ISO now to take “italic” literally. ISO standards are set in sans-serif typeface, but all quantity symbols, both inline and in displayed equations, are set in serif italic font; however, numerals and descriptive subscripts are set in upright sans-serif font. I am told this is also done in the soon-to-be-released ISO/DIS 80000-1 (which will supersede ISO 31-0). The results are not especially attractive. An example is ISO 12232; one sees equations such as

H =	πTvcos4θ LtF2	+ Hf .
	4A2i2

To be fair, the appearance in the actual ISO standard is slightly better than this HTML approximation, but I think this example is its own recommendation; it's tough to imagine a better argument for not mixing typefaces. The clash of the different typefaces in Wikipedia articles seems trivial by comparison. It's difficult for me to imagine anyone preferring the example above to the way it was done in ISO 2720-1974 (all sans-serif), which would give

H =	πTv cos4θ LtF2	+ Hf .
	4A2i2

But some folks at ISO obviously disagree.

I'm not especially fond of the latter treatment, but at least it doesn't look like a ransom note. In any event, it's not currently an option.

As nearly as I can tell, NIST don't have a policy on this; most of their sans-serif examples that I have seen seem to use sans-serif oblique, but those examples are comparatively few, so it's hard to draw a solid conclusion. For the most part, NIST avoid the problem by using serif type for the main text. Barry Taylor, formerly of NIST and co-author of Special Publication 811 (he's now retired and working unpaid as a Scientist Emeritus), thinks that scientific papers and documents should always be printed in serif type. But he also thinks quantities should always be in true italics for legibility of the symbols; he would put descriptive subscripts in a roman serif font to better match the symbols—much the same as using TeX in Wikipedia. I'm not sure I see legibility issues beyond the obvious problem with upper-case I and lower-case L, but ISO and Dr. Taylor are certainly two authoritative sources who argue for forcing serif type by design rather than just convenience in markup.

The general issue of quantity symbols doesn't directly address the treatment of the f in f/# and f-number. But it does suggest that proper treatment depends on how the f is regarded: if it's a quantity symbol, it should be given the same treatment as other quantity symbols in the article; if it's a letter used as a word, it should simply be set in the italic font of the main typeface. ISO 12232 has no instances of f/#, but it does have several instances of f-number, with the f in sans-serif oblique, suggesting that it's not considered a quantity symbol in that context (or perhaps that it just wasn't given much thought ...)

ISO 2720-1974 hasn't been revised in a long time, so perhaps its treatment of f/# doesn't reflect current ISO practice. A more recent standard, such as ISO 517:2008 might be more helpful.

I still don't think we've seen anything, either prescription or convincing example, that indicates special treatment for f/#, so the question goes back to whether or not the f is a quantity symbol. I think a credible argument could be made either way; appearance would suggest that it's a quantity symbol, while pronunciation would suggest that it's just a letter used as a word.

On perhaps a side note: ISO 2720 and ISO 517 deal with the markings on meters and lenses rather than practice in documentation. At least for meters, manufacturers seem to pay little attention to the standards: both of my Pentax spot meters designate the f-number scale by ‘F’; my Minolta Autometer IV-F uses ‘FNo.’

In any event, I think it's very difficult to justify forcing a third arbitrarily chosen typeface (actually, a fourth if we allow for both HTML and PNG rendering of TeX). JeffConrad (talk) 19:46, 27 January 2009 (UTC)

Change font list?

This isn't a resolution to the debate above, but a proposal that I hope will be uncontroversial. In the midst of the discussion above JeffConrad suggested using sans-serif fonts that have a hooked italic f. That seems like a good idea to me, but it got buried amidst all the other debate and never was implemented. It won't satisfy the purist arguments, but it at least can produce something that looks better with the default sans-serif typeface. The template already supports providing a list of fonts; the user's browser uses the first font on the list that it has available. I suggest the following fonts, in order:

1. f/8: Calibri
2. f/8: Corbel
3. f/8: Trebuchet MS
4. f/8: Candara
5. f/8: Georgia
6. f/8: Serif

All of these fonts have a hooked "italic" f. The first four are sans-serif. (If they do not display this way for you, you don't have the indicated font installed. No problem: the template would give you the first font on the list that you do have.) If there are Mac or other fonts that have sans-serif hooked f's we could add those to the list too.

Any dissent over this change, or suggestions to reorder the list? Let's not get the wider debate going, but rather just make this change for now.--Srleffler (talk) 04:05, 30 April 2009 (UTC)

No objection here. Dicklyon (talk) 04:55, 30 April 2009 (UTC)

I don't think this change is any improvement. The practice is still utterly capricious, and practiced nowhere other than here. Most of the difficulty derives from what someone considers to have a better appearance, and this is something on which reasonable (and unreasonable) people may differ; for example, I think the Trebuchet MS is a better match for the default sans-serif font (at least today). The reason is simple; with most of the other typefaces, the mismatch in x-height is severe; this is best illustrated by showing a few other characters in each typeface:

1. f/8: Trebuchet MS Trebuchet MS
2. f/8: GeorgiaGeorgia
3. f/8: Candara Candara
4. f/8: Calibri Calibri
5. f/8: Corbel Corbel
6. f/8: Serif Serif

The context is the greater issue. There's nothing inherently wrong with red tie or a pink shirt, but the two seldom make for a good combination.

I remain unaware of any organization whose publications make typeface changes without some reason, and the only reason presented here so far is, "I don't like it." The problem with this, of course, is that not everyone has the same likes.

Several alternatives at least have some support in publication, even if the reasons behind them are somewhat obscure.

• Using the oblique face of the main typeface, apparently treating the f as a quantity symbol or a letter used as a word. This is a common, though hardly universal practice, and is probably the most logically supportable.
• Using an upright f of the main typeface, i.e., giving no special treatment. This in fact was the recommendation I got from the editors of The Chicago Manual of Style, and is the practice followed by Merriam-Webster. In reviewing quite a number of publications, this practice is more common than I originally thought.
• Using an oblique serif f (i.e., true italic) of a typeface used elsewhere in the publication. Though no one has yet shown an example, it appears likely that this practice is followed in recent printings of ISO standards, and it was recommended by Barry Taylor (ret) of NIST, the primary author of NIST Special Publication 811 on use of the IS. ISO practice, apparently, is to use true italics for all quantity symbols, so it would seem valid here only if the practice were followed for all quantity symbols. But to impose this would seem to violate current MOS guidelines.
• Using the florin (ƒ). Though usage is comparatively infrequent, and there is little logic to support it, it nonetheless is done in a few publications, including those by Werner Publishing (Outdoor Photographer and Digital PhotoPro) and PhotoTechniques (who appear to have used it for the last ten years or so in both serif and sans-serif typeface). The florin is also possibly used in the Explanatory Supplement to the Astronomical Almanac (rev. ed., 1992) and online publications by OSA. The latter two examples seem to do this whenever f is used as quantity symbol, so to be justifiable here, the treatment would need to be uniform. Again, I think to impose it would violate MOS. There also might be confusion among readers whose searches for 'f/' mysteriously failed.

Again, I think practice here should follow some rational rule, or at least follow practice of some reliable publication. Changing the list is little more than rearranging deck chairs on the Titanic, but my rearrangement would put the Trebuchet MS first and Georgia second. It won't have much effect on me, because I'll continue to use f/8 absent some convincing reason to do otherwise. JeffConrad (talk) 03:13, 1 May 2009 (UTC)

Yes, this change does not address your principled objections to the template. Users who feel f/ should be treated as a quantity symbol should mark it up like a quantity symbol, using ''f''/ or <math>f</math>/, depending on how other quantity symbols are marked up in the article. The change makes the template no worse, though: it still chooses a font for appearance's sake—we just choose a font that is a better visual match to the default one.

I see your point about x height. Given that, I propose the order shown below. I put Candara at the bottom because, as you noted above (in January), it is a poor match to the default font. I agree on that point.

f/8: Trebuchet MS

f/8: Georgia

f/8: Corbel

f/8: Calibri

f/8: Candara

f/8: Serif

--Srleffler (talk) 04:08, 1 May 2009 (UTC)

I think Candara is a better match than Calibri or Corbel; not only are the x-heights closer, but the ascender height is a better match to the figure. After another look, I'm more inclined to the following:

1. f/8: Trebuchet MS Trebuchet MS
2. f/8: Candara Candara
3. f/8: GeorgiaGeorgia
4. f/8: Calibri Calibri
5. f/8: Corbel Corbel
6. f/8: Serif Serif

It's a close call between the Candara and the Georgia, but the former is slightly better because of the spacing. The spacing, of course, could be adjusted with letterspacing as discussed earlier (though it would need to be very slight to avoid problems with the other typefaces). Doing so would hardly be without precedent; every mathematical typesetting application that I've used (TeX, troff/eqn, and MathType) routinely requires some minor manual adjustments to spacing. Here's what 0.05 em letterspacing looks like with Trebuchet MS, Candara, and Georgia:

• f/8 Trebuchet MS
• f/8 Candara
• f/8 Georgia

With the spacing, I might return Georgia to second place. But it's not a big deal either way; I think the Trebuchet MS looks better unspaced, and on a low-res display, a spacing of 0.05 em might not have any effect.

Putting the solidus in italics (as is currently done) also handles the spacing (at least between the f and the solidus), but it's a very uncommon practice that seems difficult to justify. And the appearance isn't nearly as good with Trebuchet MS: f/8.

None of the alternatives above really matches the default sans-serif face: the Trebuchet MS is probably the closest, but the stroke weight is slightly heavier. For the other typefaces, the stroke is a bit lighter than the default font, and other features of the typefaces clash more with the default font. JeffConrad (talk) 06:41, 1 May 2009 (UTC)

On using <math>f</math>: I gave this up because several WP editing tools routinely replace it with ''f'', so I can't really see going to the extra trouble. JeffConrad (talk) 06:52, 1 May 2009 (UTC)

I find the light stroke of Candara distracting, personally, when placed alongside the default font. Otherwise I'm fine with your order. I'm not keen on using letter-spacing. As we found above, it is not supported the same by all web browsers.--Srleffler (talk) 04:35, 2 May 2009 (UTC)

No real disagreement. I find the heavy stroke of Trebuchet MS a bit distracting, the light stroke (as well as the general shape) of Canadara distracting, and the serifs on Georgia pretty distracting as well—so it remains a tossup for second place. This, of course, is why one generally does not change typefaces midstream without a compelling reason. There is probably a face similar to Trebuchet MS that's a better match, but it's almost certainly one that's not available on most users' computers. Of the lot, the Trebuchet MS clashes the least and is the least of the evils. Of course, the lousy spacing with the default font is also distracting.

The rub with forcing the typeface, of course, is that a user who specifies a serif typeface in a .css file gets a mess with the Trebuchet. But I'd guess that not all that many people do this, so it's probably not a big issue. JeffConrad (talk) 05:38, 2 May 2009 (UTC)

Requested edit

{{editprotected}} Please replace both occurrences of "<span style="font-style:italic;font-family:Georgia,serif">f/</span>" with "<span style="font-style:italic;font-family:Trebuchet MS,Candara,Georgia,Calibri,Corbel,serif">f</span>/". --Srleffler (talk) 04:43, 2 May 2009 (UTC)

 Done. — Martin (MSGJ · talk) 07:56, 2 May 2009 (UTC)

{{editprotected}} The admin who did the edit above omitted the trailing slash "/". It goes after each of the two </span> tags.--Srleffler (talk) 13:03, 2 May 2009 (UTC)

Sorry about that. Is that okay now? — Martin (MSGJ · talk) 14:07, 2 May 2009 (UTC)

{{editprotected}}

NO. As shown in the text to substitute, and as specifically stated in my message above, the slash needs to be after the </span> tags.--Srleffler (talk) 14:55, 2 May 2009 (UTC)

Sorry, I'm not normally this stupid. — Martin (MSGJ · talk) 15:00, 2 May 2009 (UTC)

Transition to TemplateStyles

FYI, in mid-January 2024, I transitioned this template to use TemplateStyles rather than the hard-coded embedded CSS in the emitted <span> tag surrounding the "f/". Additionally, the entire emitted "f/2.8" (for example) string is now wrapped in <span class="fnumber">...</span>, and uses the CSS ::first-letter pseudo-element to stylize the font for the 'f'.

The documentation is updated to reflect the changes and rationale. Additionally, {{f//testcases}} exists to test the parameters.  — sbb (talk) 03:41, 11 February 2024 (UTC)

Firefox bug

Moved from User talk:Sbb § f-stop template

 – This is the correct venue.  — sbb (talk) 05:36, 11 February 2024 (UTC)

The CSS ::first-letter implementation is buggy in Firefox. The bounding box (the <span class="fnumber">...</span> around the entire emitted output) is too narrow to display the content. Without white-space: nowrap; applied to the <span>, longer output (such as an f-number range, like 'f/2.8–5.6') can overflow the <span>, and thus cause an inline line-break for just the f-number. While white-space: nowrap; prevents the wrapping, it doesn't fix the problem entirely. Apparently Firefox uses the width of the ::first-character to determine the base character width of the remaining content? So narrow or font-size reduced first characters make the box width smaller than needed.

• See Is there a CSS workaround for Firefox' bug: inline-block + first-letter with changed size (StackOverflow)
• Also see 2007 Bugzilla bug

 — sbb (talk) 05:36, 11 February 2024 (UTC)

The original hard-coded css worked fine, and was developed on Firefox and tested on a variety of browsers.--Srleffler (talk) 07:43, 11 February 2024 (UTC)

@Sbb Sorry for the delayed reply - looks like your changes have worked for me. I can no longer replicate it breaking with any of the versions on Template:F//testcases or elsewhere. Thanks! Andrew Gray (talk) 18:38, 16 February 2024 (UTC)