Template talk:f/

{{DISPLAYTITLE: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,

::# That standard is set in serif typeface, so its oblique font is italic, and

::# 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.,

:::::f /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: f/2
  3. f/2: f/2
  4. f/2: f/2
  5. f/2: f/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 is arguably of less value when using a template, so that for most purposes, 1 and 2 above are equivalent. The 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 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 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 and 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 for the sake of form.

:::At present, the decision of whether to use the tag or the 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 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 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 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 only in response to your preference for 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 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 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" ([http://books.google.com/books?id=HHX4xB94vcMC&pg=PA62&dq=f-number+italic+aperture&lr=&as_brr=0&ei=nXyWSMnuO4i8tAOpuZzUDA&sig=ACfU3U06tQJ3sdBG1Q3Jb2aZqbFqyXojlQ]). 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 [http://www.largeformatphotography.info/sunmooncalc/SMCalcTutorial.htm 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

:::::::# Logic strongly suggests that that the f in f/# is the same f in the thin-lens equation (uf )(vf ) = f2. Absent definitive direction to the contrary, what else could it possibly be?

:::::::# 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 , leaving the principal choice between HTML italic and 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 (x2, 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 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 tag, but the same argument could be made for the 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.

:# Ideally, all inline mathematics, including f/#, should match the primary typeface.

:# 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:    f/2)
  3. f/2 (LaTeX unspaced: f/2)
  4. f/2 (LaTeX spaced:   f/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:    f/2)
  3. f/2 (LaTeX unspaced: f/2)
  4. f/2 (LaTeX spaced:   f/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:   f/2

::*f/2 (HTML spaced:   f/2

::*f/2 (HTML spaced:   f/2

::*f/2 (HTML spaced:   f/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:

Image:F number template temp test.png

::::And here's mine using Firefox 3:

Image:F_number_template_temp_test_jeff1.png

::::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).

Image:Trebuchet_italic_f_temp.png

: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 ... 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