Template talk:Infobox typeface

Comic Sans (Taste)

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)

Some thoughts

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)

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)

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)

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)

Conditionals, et al.

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)

Infobox Font Edits

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)

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)

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)

Font preview

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

variants field

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)

Sample characters shown in info box

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)

License parameter

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)

Good point, it now seems to have one. Palosirkka (talk) 08:56, 6 February 2012 (UTC)

Calling with imagesize or explicit image

I've updated the documentation to include the imagesize parameter and have fixed about 50 of the fonts that transclude Infobox typeface 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 [[Image:{{{image|}}}|....]]? One option would be to do:

{{#ifexist: Image:{{{image|}}}
| [[Image:{{{image|}}}|{{{imagesize|300px}}}]]
| {{{image|}}}}
}}

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)

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)

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)

It appears that {{#ifexist: ...}} 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)

Style changes

There is absolutely no need for this template to override the default styling provided by {{infobox}}, yet The Obento Musubi (talk · contribs) 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)

Version information

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

Template:Infobox software has these parameters:

• |released=
• |latest release version=
• |latest release date=

If there is consensus that font version information should be added to {{Infobox typeface}}, then I think using the from code another infobox is the easiest way to implement it here.  Senator2029 ➔ “Talk”  04:38, 14 July 2013 (UTC)

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)

There has been no discussions since 2013, I am assuming there is no rejection to adding the "Latest release version" field, so I will going ahead and try to add it. Afshinarefi (talk) 21:58, 16 May 2016 (UTC)

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

parameter suggestion

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)

Add parameter metrically_compatible_with

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)

• Support. What about multiple values, zazpot? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:46, 24 June 2017 (UTC)

• 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)

@Zazpot and Pigsonthewing: Now that the value is in place, it may be a good idea to provide pre-filled templates for large, well-known metric compatibility "groups". The Helvetica/Arial group, for example, is one of the large groups: Monotype made Arial to match the Helvetica's metrics; the open source world then made Liberation Sans and its cousin Arimo to match Arial's metrics. The group is also extended by many other metric-compatible branches, notably Nimbus Sans, FreeSans (Latin part based on Nimbus), TeX Gyre Heros (also based on Nimbus), and StarOffice's Albany. Times and Courier also form some similarly large groups. --Artoria2e5 contrib 22:16, 6 October 2017 (UTC)

@Artoria2e5: 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)

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)

Extend the Coverage blocks

I propose to adding | emoji = {{version}} 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)

Add a thai = parameter

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)

Designer

The argument label 3 currently reads

• label3 = [[List of type designers|Designer(s)]]

I propose to change this to

• label3 = [[Type design#Profession|Designer(s)]]

which seems to me to be rather more relevant (and as type design#Profession begins with {{see also|List of type desingers}}, nothing is lost).

Any reason why I should not? --John Maynard Friedman (talk) 11:58, 15 March 2022 (UTC)

 Done --John Maynard Friedman (talk) 11:11, 20 March 2022 (UTC)