Template talk:Infobox typeface

message: Made an infobox for fonts. It's pretty basic at the moment - feel free to refine it. See Comic Sans for an example of the infobox in use. DynaBlast 16:35, 12 January 2006 (UTC)
thread_title: Comic Sans (Taste)

message: I like this very much. DynaBlast: Thanks for desiging this! It's nice to see some standardization being introduced for typefaces.
A couple thoughts about the "style" section. "Style" when referring to fonts generally means "italic", "bold", etc. What we mean here is "category". Any objections to my changing that?
Also, we should try to stick to an established list of categories. I just redid the categories on the Typeface page, so currently we have:
* Serif
* Sans-serif
* Script
* Blackletter
* Display
* Monospaced
* Symbol
I think this is a reasonably comprehensive and encompassing list, so I would argue that we should try to only use these categories in the infobox. Again, let me know your thoughts. —Chowbok 19:01, 11 February 2006 (UTC)
replies: text: I would have no problems with these changes. I know little about typefaces, and was hoping someone would come along and correct any little mistakes I made. :P DynaBlast 20:26, 11 February 2006 (UTC)

text: I would remove "Monospaced" from that list, as it's more a description of the proportional width of the font characters, not the style of the face itself. For example, a font like "Bitstream Vera Sans Mono" is a sans-serif face but it is also a monospaced font. —Down10 TACO 23:45, 16 July 2006 (UTC)
replies: text: That's a reasonable point, but if that's taken out, I would request that another field be added to indicate whether the typeface is proportional or monospaced, as that is important information. —Chowbok 04:39, 17 July 2006 (UTC)
thread_title: Some thoughts

message: I went ahead and put conditionals into the infobox, and cleaned up the docs — because I can! ;-) Let me know if you like it. If not, it should be easy enough to fix. —Down10 TACO 07:12, 13 July 2006 (UTC)
thread_title:  Conditionals, et al. 

message: I've been making some changes to the infobox, these include adding some attributes: based_on, foundries, comissioned_by. i have also implemented the creationdate and releasedate attributes. i have restructured the infobox, but need some help to restructure further as per the requests on my user talk page. i'm sorry if i have tread on any toes in making these changes, i suppose these can always be rolled back if they're unwanted. any feedback on what has been done is welcome as well. pablohoney 21:47, 13 December 2006 (UTC)
replies: text: I've duplicated this template with my changes at Template:Infobox typeface, so that if my recent edits are found unacceptable, I can continue to use the format that I've developed over the course of the past several hours.pablohoney 23:36, 13 December 2006 (UTC)
replies: text: Hi Pablohoney. yep, I uderstnad the blue is a link. the idea was to make it more unfied by having the link all one color (blue) rahter than reading one word blue, one word black, if the virgule followed by name doesn't work, why not just drop name, sort of self-explanatiory. category doesn't really show up in typebooks, have taken a look at 6, Jaspert & Berry, Macmilliam, Lupton, Friedl, Kane, and Blackwell. All use "classification." I agree some people ae throwing inaccurate terms around. I think here's our chane to clean it up and echo what ATypI (Association Typographique International) and other type organizations and writers publishers do. I'm starting to impliment, going back to faces that don't yet have the infobox. Thanks for tightening the space around rules. CApitol3 23:55, 14 December 2006 (UTC)
thread_title:  Infobox Font Edits 

message: What is the purpose of the Font preview section? — The Storm Surfer 21:20, 24 August 2007 (UTC)
thread_title:  Font preview 

message: Is this where you list typefaces that are basically clones of, or closely derived from, the one in the article?  That's how I interpreted the description.  If so, should there be a parameter (maybe "variantof") for the reverse relationship—or should we make those articles redirect to the "original" as is done for the Helvetica example?  If we redirect, should we have a standard article section to detail whatever small differences these variants may have?  Charcoal is one reason I ask these questions: are Truth and Virtue variants? ⇔ ChristTrekker 21:51, 7 September 2007 (UTC)
thread_title:  ''variants'' field 

message: I realize it would be quite an effort to update; but I think it would be useful to include in the sample text of characters which are known, in some fonts, to be used to trick computer users in phishing or other scams (either in web addresses, email addresses, or user names).  The two most common substitutions that I can think of are:
* "l" and "I" (a lower case "L" and an upper case "i")
* "O" and "0" (an upper case "o" and the number zero)
Does anyone else have an opinion on this? --161.88.255.139 (talk) 21:11, 18 December 2007 (UTC)
thread_title:  Sample characters shown in info box 

message: I think this infobox should include a mandatory categorizing license parameter. Currently, many font articles lack licensing information. -- Gordon Ecker (talk) 04:18, 24 June 2008 (UTC)
replies: text: Good point, it now seems to have one. Palosirkka (talk) 08:56, 6 February 2012 (UTC)
thread_title:  License parameter 

message: I've updated the documentation to include the imagesize parameter and have fixed about 50 of the fonts that transclude  with an actual image rather than the name of the image for the image parameter, but there are lots left (such as Copperplate Gothic).  Is it possible to detect if the parameter is already an image and use it directly rather than wrapping the template argument in ....?  One option would be to do:

Would this work or is there a better way to detect if the image parameter is a simple name?  --Autopilot (talk) 23:22, 1 January 2009 (UTC)
replies: text: I tested this with my own template and it seems to work.  Rather than update the rest of the fonts, I'll update the template to do the check before it calls the Template:Infobox template. -- Autopilot (talk) 23:28, 1 January 2009 (UTC)
replies: text:  Hmm, it didn't work in the template, so I have backed out the change and am experimenting in the sandbox to see if I can make it work. --Autopilot (talk) 23:38, 1 January 2009 (UTC)
replies: text:  It appears that  only works on images that are in wikipedia proper and returns false for ones that come from wikimedia commons.  Since most of the font images are there, this technique won't work.  Is there a parser function to do regular expression type matching?  m/^\s+\[\[Image:/ would weed out all of the cases that seem to be left in the list of fonts using the template. --Autopilot (talk) 23:53, 1 January 2009 (UTC)
thread_title:  Calling with imagesize or explicit image 

message: There is absolutely no need for this template to override the default styling provided by , yet  continually re-adds overrides without a rationale or discussion. I have raised this with him before, but it doesn't appear that a rationale is forthcoming. For this reason I have reverted this change again. This should be discussed before arbitrary changes are made to the layout. Chris Cunningham (not at work) - talk 10:13, 5 February 2009 (UTC)
thread_title:  Style changes 

message: I think there should be an optional field for the latest (stable) version number.  
—DIV (138.194.11.244 (talk) 09:51, 15 September 2011 (UTC)
replies: text:  I also think there should be such an optional field. Indeed, I came to this template to look for the relevant syntax, assuming such a field existed already. It would be very handy to be able to find out at a glance what the most recent version was. As it is, the information is often hidden deep in the article text in various places where it's not obvious to search for it. --Pinnerup (talk) 01:47, 17 July 2013 (UTC)

text: Update: I've just added the corresponding latest_release_date parameter as well. --Waldir talk 10:37, 22 May 2018 (UTC)
thread_title:  Version information 

message: Would it be beneficial to add a parameter for the aspect ratio? As a web developer, legibility is a concern, and given roughly similar designs the larger aspect ratio is more legible. ⇔ ChristTrekker 15:02, 28 May 2013 (UTC)
thread_title:  parameter suggestion 

message: It would be nice to add a "metrically_compatible_with" parameter to this infobox.
In case anyone reading this thinks that the existing "based_on" parameter is sufficient, please see this explanation of the completely different semantics of "based on" and "metrically compatible".
I would be grateful for expressions of support. Alternatively, if anyone objects to this proposal, please do state your reasons, and please also WP:PING me in your reply, as I may not be WP:WATCHing this page. Thanks! zazpot (talk) 18:32, 23 June 2017 (UTC)
replies: text: * Thanks for the support! Maybe Template:Plainlist could be used in cases where multiple values are needed? Open to better suggestions if you have them :) zazpot (talk) 16:51, 26 June 2017 (UTC)

text: thanks, I agree that would be nice. Now it's just a matter of someone finding time and energy to do it! ;) Zazpot (talk) 23:01, 6 October 2017 (UTC)
replies: text: On Archlinux's Wiki there's a rough, installer-orientated list for metric-compatible families (https://wiki.archlinux.org/index.php/Metric-compatible_fonts). Well, the juicy part is really just the three big families; most of URW's GhostScript fonts don't have enough notability on their own. --Artoria2e5 contrib 23:36, 6 October 2017 (UTC)
thread_title:  Add parameter '''metrically_compatible_with''' 

message: I propose to adding 
| emoji = 
and to the template/doc
; emoji :Set valid Version numeral ie. 4, 5, 11... or yes if unknown.
GSMC(Chief Mike) Kouklis U.S.NAVY Ret. ⛮🇺🇸 / 🇵🇭🌴 16:36, 17 March 2018 (UTC)
thread_title:  Extend the ''Coverage'' blocks 

message: To go along side the other language entries, how about a thai = that automatically adds a font page to the Category: Thai typefaces? Currently there are only three entries in that category. Inferno986return (talk) 15:20, 12 April 2019 (UTC)
thread_title:  Add a <code>thai =</code> parameter 

message: The argument  currently reads
* 
I propose to change this to 
* 
which seems to me to be rather more relevant (and as type design#Profession begins with , nothing is lost).
Any reason why I should not? --John Maynard Friedman (talk) 11:58, 15 March 2022 (UTC)
replies: text: --John Maynard Friedman (talk) 11:11, 20 March 2022 (UTC)
thread_title:  Designer