Template talk:F/

message: 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)
replies: text: 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)
thread_title:  Another Sidney Ray book 

message: 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
:
= 	πcos42	 + f .
= 	         	 + f .
= 	422      	 + f .
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 .
H = 	                       	 + Hf .
H = 	4A2i2                  	 + Hf .
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)
thread_title:  A more literal interpretation 

message: Please replace both occurrences of "f/" with "f/". --Srleffler (talk) 04:43, 2 May 2009 (UTC)
replies: text: . — Martin (MSGJ · talk) 07:56, 2 May 2009 (UTC)

text: Sorry about that. Is that okay now? — Martin (MSGJ · talk) 14:07, 2 May 2009 (UTC)
replies: text: 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)
replies: text: Sorry, I'm not normally this stupid. — Martin (MSGJ · talk) 15:00, 2 May 2009 (UTC)
thread_title: Requested edit

message: FYI, in mid-January 2024, I transitioned this template to use TemplateStyles rather than the hard-coded embedded CSS in the emitted  tag surrounding the "f/". Additionally, the entire emitted "f/2.8" (for example) string is now wrapped in , and uses the CSS  pseudo-element to stylize the font for the 'f'.
The documentation is updated to reflect the changes and rationale. Additionally,  exists to test the parameters.  — sbb (talk) 03:41, 11 February 2024 (UTC)
thread_title:  Transition to TemplateStyles 

message: The CSS  implementation is buggy in Firefox. The bounding box (the  around the entire emitted output) is too narrow to display the content. Without  applied to the , longer output (such as an f-number range, like 'f/2.8–5.6') can overflow the , and thus cause an inline line-break for just the f-number. While  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)
replies: text: 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)

text: @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)
thread_title:  Firefox bug