Template talk:Unicode

Used idle for a purpose?

In Advertising (at least today's version [1]), the template is used like this: {{unicode|}} (early in the source text). Is this useful for some reason? -DePiep (talk) 19:28, 19 November 2010 (UTC)

Font override

I'm trying to override the fonts used in this template by using custom CSS. My code is:

html, body, .Unicode, .IPA {
  font-family: Torid !important;
}

It works with normal text, but not when this template is used; e.g. {{Unicode|Ᵹ}} renders as Ᵹ, using Arial Unicode MS (which lacks insular G) instead of my font.

Does anyone know what I am doing wrong here? Laricaney (talk) 15:35, 15 February 2011 (UTC)

You need to add the !important; keyword. I added it in your code above. — Edokter (talk) — 16:15, 15 February 2011 (UTC)

It worked, thanks! Laricaney (talk) 16:55, 15 February 2011 (UTC)

font list

FYI, the font list for the .Unicode CSS is now is MediaWiki:Common.css/WinFixes.css. Took me awhile to track that down, so I thought I'd save others the time.

As an aside, the order of these fonts was decided several years ago. Is there any need to review and possible update it? ⇔ ChristTrekker 20:27, 27 June 2011 (UTC)

Patently useless

This template is essentially useless, as there is no guarantee that it will cause the desired character to be displayed in one's browser. For example, I'm running Linux with the GNOME desktop. All I see in place of the template are little rectangles with flyspeck-sized hexadecimal digits, supposedly representing the hexadecimal value of the Unicode character. Maybe it can be made to work with a limited set of font files that Wikipedia visitors may or may not have available on their machines, and may or may not know how to utilize to get the characters to display. A better approach would be to use in-line graphics, perhaps SVG icons, derived from PostScript or True Type files that contain the character to be illustrated. — Quicksilver^{T @} 22:37, 29 November 2011 (UTC)

It is not useless. A guarantee is overasked. It does, quite good, provide a best possible solution for situation wiki cannot guarantee, but can only foresee. If your situation does not show the right glyph sometimes, that says: "too little Unicode fonting", not "drop Unicode fonting". -DePiep (talk) 22:54, 29 November 2011 (UTC)

Plus, note that the associated CSS with the fontstacks is located in MediaWiki:Common.css/WinFixes.css, and that file is only loaded if you have... Windows. So this template would indeed have no effect on Linux. (And we expects Linux to show everything perfectly.) — Edokter (talk) — 23:36, 29 November 2011 (UTC)

AIUI the template is a reaction to deficiancies in IE (not sure if these have been fixed in later versions). Most other browsers will automatically search other fonts if the glyph they need isn't in the currently selected font. Of course if you don't have a suitable font at all you won't get the glyph on any OS. Plugwash (talk) 13:32, 2 December 2011 (UTC)

These font declarations are probably going to be trimmed, sorted and moved back to Common.css to make it multi-platform again. Most of these font are never found on Windows machines anyway (except for those few geeks that install them). — Edokter (talk) — 13:44, 2 December 2011 (UTC)

Why trim the list? If someone does have a superior font installed, why not use it? The fonts specified should be those with the best coverage, in order of coverage, period. If it's uncommon and most people don't have it installed, so what? The browser will continue down the list until it finds the best one that is installed. ⇔ ChristTrekker 14:20, 5 December 2012 (UTC)

I expressly do not want graphic replacements of text. It breaks copy-and-paste. In cases where illustration of a glyph appearance is needed, sure, provide an image. But not in text. ⇔ ChristTrekker 14:23, 5 December 2012 (UTC)

suggestions for extending/improving this template outside the BMP

The fonts selected here are woefully inadequate outside the BMP. I was hoping to do something to make the emoticons (and other symbols) I frequently use show up in more browsers, but since {{Unicode}} (currently) specifies "Arial Unicode MS", "Lucida Sans Unicode" as its fonts, I'm out of luck. Those fonts have terrible coverage in the blocks I'm interested in.

The two fonts that seem to do pretty well in the three SMP-1 blocks I care about are Segoe UI Symbol and Brampton. They cover 458⁄533, 63⁄76, 34⁄70 and 129⁄533, 57⁄76, 7⁄70 of them, respectively. In the case of Brampton that's still not great, but yet far, far better than anything else I have installed (only a couple have even one or two characters).

What I'd like to suggest is a {{unicode1}} template for SMP-1 that specifies a different class, with different fonts. Alternatively, extending this template with a plane parameter. By default it would be plane 0, the BMP. ⇔ ChristTrekker 14:17, 5 December 2012 (UTC)

I think the underlying problem is that the vastness of Unicode is inherently unsuited to specifying a single list of fonts to handle every required character set.

Rather than attempt to make one size fit all with this template, or create the same problem with a similar untargeted unicode template, I suggest that you create a template specifically suited to the range(s) of characters that you want to handle. (If the characters are only used on one or two pages, you could of course simply apply a font-family style attribute using <span> tags manually.)

See {{Script}} and, for example, {{Script/Coptic}}, for an existing series of subtemplates which seek to do this.

In case the browser already has a suitable default font, it might also help to specify a generic fallback as the last item in the font-family list, e.g. <span style="font-size-adjust:0.54; font-family:'P22 Declaration Script','American Scribe','National Archive', Ovidius, 'Ovidius Script', Horizon, 'Final Frontier Old Style', Charcoal, Virtue, sans-serif;">...</span>

— Richardguk (talk) 17:48, 5 December 2012 (UTC)

{{Script}} mixes up scripts and languages. It should not do when used for this purpose. -DePiep (talk) 19:05, 5 December 2012 (UTC)

I'm not sure I'm following what you're saying about {{script}} being problematic. I glanced very briefly at it, and abstracting the font choice away from the technical underpinnings of Unicode and instead toward the language/script being used, seems fairly reasonable. ⇔ ChristTrekker 19:53, 5 December 2012 (UTC)

We only need the script name to serve the right font-family. {{Script/Coptic}} is a good example because Coptic is a script name (so we can look for fonts that are good in Coptic script, which is in two blocks btw). But sister template {{Script/Slavonic}} is named after a language (Slavic_languages, there is no Slavonic script), which can be written in many scripts (Serbo-Croatian has both Latin and Cyrillic as official writing system). In short: to supply a good font-family in a template, we need to know the script and find matching or specialised fonts.

Now to help the edtiors that use the {{script}} template, we could accept a language-id as input when that leads to a single script (and font-family from there). Still, that should be unambiguous. Basically this can be done in a single #switch set.

As the template is now, there are exceptions and forkings for languages too which complicates the logic unnecessarily.

If a language class is required for other reasons, that can be added independent of the font-family. -DePiep (talk) 02:48, 6 December 2012 (UTC)

It is worse. {{Script}} sets the lang= value once or twice, and not always the same. First in the subtemplate (sometimes), second (always) in the second half of the main template (#switch lang=... part). -DePiep (talk) 03:50, 6 December 2012 (UTC)

I agree with your initial statement. Unicode is too big for just one font. If you are suggesting something along the idea of a {{UnicodeBlock}} template (or |block= with this template) instead, I can see that. It does however require that users have even more technical knowledge of Unicode than my original "plane" suggestion. ⇔ ChristTrekker 19:53, 5 December 2012 (UTC)

In general, individual Unicode blocks and/or planes will not necessarily correspond to particular scripts or fonts. Conversely, some scripts and fonts are likely to be scattered across more than one block or even across more than one plane. So the script-based approach is generally more robust – and also more comprehensible to editors interested in the relevant subject, who might not know or care about the underlying code points. — Richardguk (talk) 20:20, 5 December 2012 (UTC)

OK, true. So are you suggesting something like {{unicodelatin|ʧ}} or {{unicode|ʧ|script=latin}} to deal with obscure Latin (in this case) characters, that in turn sets a style class that has good coverage over all Latin blocks of Unicode? This does seem to be what {{script}} does; I still don't understand DePiep's objection. What happens with characters not associated with a particular script in the usual sense, like the emoticon block? ⇔ ChristTrekker 21:51, 5 December 2012 (UTC)

Well the example you give uses the character ʧ U+0207 LATIN SMALL LETTER TESH DIGRAPH which is part of the IPA extensions Unicode block, so {{IPA}} might be sufficient. If you instead want to display characters not generally related to IPA, the best approach would depend on the details. But {{Script}} is designed to handle a range of scripts, with a subtemplate for each. So you could, perhaps, edit {{Script}} to handle an additional script name. But the template currently only uses four-letter ISO 15924 script codes and it's not clear to me whether an four-letter ISO code exists for your intended purpose. Can you clarify what range(s) of characters you want to display? — Richardguk (talk) 22:50, 5 December 2012 (UTC)

Sorry about the IPA char; I used Character Map in Windows and plucked something random from its "Latin" Unicode range. Mea culpa. As for specific ranges, see the links in my original post.

I've done just a bit of reading about ISO 15924, and maybe the "Zsym" code could be utilized here. Connect it with a font that has good coverage of dingbats, and it's done.

If arbitrary codes could be used, I was thinking that a code per "subject" would perhaps be useful. For example, font Foo might have good coverage of all symbols, but an uninspired design, while font Bar only covers the sports-related dingbats with really nice glyphs. If we allowed {{script/sports}} you could show the nicer one, but someone else could still use {{script/symbol}} for the same char and have it appear correctly. Just a thought, but probably moot if it's sticking to ISO 15924 codes. ⇔ ChristTrekker 23:30, 5 December 2012 (UTC)

Certainly "symbol" (and, in its looser senses, "dingbat") would be too broad a classification to be any more helpful than the general class applied {{Unicode}}, so more specific subsets such as "sports" would make sense. However, as you've seen, that would depart from the ISO scheme and is not a script in the ordinary sense, so {{Script}} would also be inappropriate. Perhaps each group of symbols needs a separate template, or {{Unicode}} could have a parameter added so that it used a subtemplate if a particular type of symbol were specified. But it's still difficult to judge without knowing the specific character ranges, proposed font-family list and which articles would be affected. If the symbols are very obscure and part of a relatively small block, creating new templates might cause more confusion than simply styling the symbols manually with <span> tags. Are you sure that there is a big enough problem at present to justify template changes? — Richardguk (talk) 00:22, 6 December 2012 (UTC)

On IPA: {{IPA}} is used for IPA characters as is the topic here. IPA is not defined as a separate script in Unicode. Those weird IPA characters are in special blocks, see Phonetic symbols in Unicode, but regular Latin, Greek and Cyrillic characters are used too. It seems to me that for IPA, the problem is solved. -DePiep (talk) 02:48, 6 December 2012 (UTC)

I'm working in the {{script/sandbox}}. Basic trick: write font-family in subpage {{Script/Cyrs}}. Tests in {{Script/testcases}} for Cyrl, Cprt, Cyrs. Not yet finished, but basics are there. -DePiep (talk) 04:36, 6 December 2012 (UTC)

I see {{IPA}} doing essentially the same thing as {{script}}, the only difference being that IPA≠"script" so it's outside the definition of {{script}}. 😒 Though I understand that reasoning, it bothers me a bit because it introduces a technical redundancy through (debatably) over-narrow scope. Is there a template for using specific fonts for mathematical symbols? ⇔ ChristTrekker 14:10, 6 December 2012 (UTC)

I'm not sure how widely the proposed template(s) would be used. What I do know is that I use the symbols fairly often, and going around multiple places later to clean up font choices in spans is a real drag. I like to think that having a template for using them well would encourage their use, and since they are potentially very handy, I see that as a good thing. ⇔ ChristTrekker 14:10, 6 December 2012 (UTC)

You two talking describes all issues very clear, IMO. Let me classify the issues (situations), as I see them.

• Presumption: we want to use {{script}} to allow for preferred fonts in rare character sets. We can accept a first parameters to identify that char set. So far, it is broadly defined and we like that. Article code would look like: {{script|Domino tiles|<tile 5-1><tile 1-4>}} and use a suggested font.
• For Unicode defined scripts i.e., a writing system for a language (ISO 15924 script codes and Unicode, below in Template:Unicode navigation are: 1. a few generic character sets like diacritics. 2. ~80 modern scripts, used today. 3. ~25 ancient and historic scripts. All identified by an ISO alpha-4 code.
• Unicode defined symbols: math, playing cards, music, etc. Unicode does not use an ISO alpha-4 code for them (although they do exist, like Zmth for mathematical notation).
• Language and style variants, like Nastaliq (calligraphic Arab).
• Useful groupings like the IPA.

Our job is to serve the preferred (and fall-back) font-family to each situation.

It would be great if the average editor can enter a meaningfull (any meaningfull) id into {{script}} and then will be served the specific font-family (out of sight). So my inroads in the sandbox is: allow any input, derive an internal script code for that (ISO 15924, or "Unicode block Sora Sompeng", and return the right font-family. -DePiep (talk) 16:53, 6 December 2012 (UTC)

I've started a template based on the ideas generated so far. It's just the template; corresponding classes need to be added to the CSS for it to actually do anything. Basically, I went through some of the "major" symbol blocks I'd been thinking about (Miscellaneous Technical, Miscellaneous Symbols, Dingbats, Domino Tiles, Playing Cards, Miscellaneous Symbols and Pictrographs, Emoticons, Transport and Map Symbols, Alchemical Symbols) and grouped them by subject area. It's only a first attempt, but I think you can see where it's going. ⇔ ChristTrekker 14:49, 6 December 2012 (UTC)

I see. So one can use class=... (and add the class) instead of style=font-family:...? I've asked this at WP:VPT.

Other templates: {{music}} is about this, but works totally different (you won't like it). It's old and using graphs. And there is {{lang}}. -DePiep (talk) 15:24, 6 December 2012 (UTC)

You can put the style (font choices) inline, but if at some point in the future you change your mind (e.g. Windows 10 comes out with a better font included) all your old stuff is stuck using your old choice. If you used a class, you change the definition there and everything everywhere gets the update. If you're only talking about one template it's not too bad, you'll only miss the places where it was subst'd in. But if you've used this font choice in 30 templates, you have 30 places to update (and you still miss those who subst'd). ⇔ ChristTrekker 15:37, 6 December 2012 (UTC)

OK then. In your situation you'd have to change the classes, inmy plan you'd have to change the subtemplates (both could be 100). I too do not want specific templates for each character set-to-font-family (like {{IPA}} is now). -DePiep (talk) 16:57, 6 December 2012 (UTC)

Eh, but exactly where is that list class-to-fontfamily administered? ~-DePiep (talk) 00:23, 7 December 2012 (UTC)

I'd reckon mediawiki:common.css. I'm using User:ChristTrekker/vector.css for testing right now. All the fonts are the same; I haven't made any effort to hunt down SMP-1 fonts and figure out best coverage. What I should probably do is, for all the character groups, generate a complete list of the characters in each. ⇔ ChristTrekker 13:12, 7 December 2012 (UTC)

Yep. The good news is: this is WP, it doen't have to be right 1st version. If you have the right font-family for say Domino tiles, that could be put into class while all the others (like mahjong tiles) keep using the "Unicode" generic class. It's just that the class encoders don't like instable propositions. So what we need is stable a font-family per script/block/subset. -DePiep (talk) 23:39, 7 December 2012 (UTC)

You may want to check on my progress. I've listed the major character groupings (in my interpretation of course), and have started to evaluate fonts. Feedback encouraged. ⇔ ChristTrekker 20:23, 11 December 2012 (UTC)

I've been following the discussion from the sideline, and I think I should say something. Currently, the template only targets XP, as it has less-refind support for unicode then Vista/7/8 and other OSes. For anything else, nothing special is done and the browser is responsible for proper font support. Now, to the idea of UnicodeSymbol, I like the idea, but I feel it is headed for disappointment. That is because at it's core, it will depend on the user being required to install specialized fonts. Any solution should not work on the premise that it might work for some users that happen to have a certain font installed; it should work for all users without any user intervention. Currently, the only technical option to offer this is webfonts. Any CSS font declarations that only work for those with the fonts installed is simply not a viable solution. — Edokter (talk) — 22:48, 12 December 2012 (UTC)

First, my work does not target XP. My thought at this point is to create a new template that is universally available. Other than that, I don't disagree. The idea is to give the user the best experience he can realistically hope to have. (I stop short of saying it should work for all users; that's flatly impossible.) For now, it's still partly in the conceptualization phase, with tentative implementation (which is thus far influenced by my MSWin use) that may change. I don't object to using web fonts, and feel they should definitely be considered as options in the font stack. I've installed a couple libre fonts for testing; if they are available gratis as web fonts that would be fantastic. OTOH, I don't want to require web fonts, as many browsers currently in use don't support it. ⇔ ChristTrekker 23:36, 12 December 2012 (UTC)

Errr, to clarify, this template could be extended with the ideas I've been working on. But the new CSS would go in a non-XP-specific place, not loaded via the browser-sniffing JS it currently is. ⇔ ChristTrekker 23:38, 12 December 2012 (UTC)

(edit conflict)Happy to read you, Edokter, in this. I have to do research. -DePiep (talk) 23:43, 12 December 2012 (UTC)

We really need to come to a consensus about this. Do we want to implement this idea, and if so, in this template (who will do it?) or a new one? Who will add classes to common.css? ⇔ ChristTrekker 21:50, 20 December 2012 (UTC)

Anyone still following this thread? Or development? ⇔ ChristTrekker 19:47, 31 December 2012 (UTC)

Support seems to be in favor of adding the new functionality here rather than creating another template. Any additional opinions? ⇔ ChristTrekker 16:20, 14 January 2013 (UTC)

Request

Can someone please make the proposed changes here and in mediawiki:common.css? This involves adding a subject parameter here, about two dozen .UnicodeSubject classes in the CSS, and some logic here to make the CSS class be .Unicode by default but .UnicodeSubject if a valid subject is specified. The list of subjects, and related list of fonts to use, are listed. The fonts used by .Unicode can be supplied as last-choice fallbacks, as well. ⇔ ChristTrekker 16:15, 15 May 2013 (UTC)

@ChristTrekker: Sorry for the delay. It's likely that this is still waiting because the request is not completely clear. Please clarify what exactly is needed, preferably by making sandbox copies of the template and CSS which can be copied and pasted over. Thanks — Martin (MSGJ · talk) 20:06, 21 May 2013 (UTC)

See Template:Unicode/sandbox, Template:Unicode/doc/sandbox, and User:ChristTrekker/vector.css (additions for Mediawiki:Common.css). ⇔ ChristTrekker 13:50, 23 May 2013 (UTC)

Okay, I have made the changes. Can you check if everything is working okay and let me know of any problems? — Martin (MSGJ · talk) 14:10, 23 May 2013 (UTC)

I see it has {{ucfirst:{{lc:{{{subject}}}}}}}. Is that different from {{ucfirst:{{{subject}}}}}? -DePiep (talk) 14:20, 23 May 2013 (UTC)

And how can this produce: UnicodeUI, UnicodePoliticsReligion for class names, wrt capitalisation? -DePiep (talk) 14:26, 23 May 2013 (UTC)

The goal is just to standardize them somehow—I think it's enough to ask people to spell them right; we should correct for capitalization. {{ucfirst:{{{subject}}}}} won't deal with cases where someone puts, for example, |subject=CHEM. And, my mistake, I overlooked the UI and PoliticsReligion cases. (Too anxious to push this forward after waiting for five months, I guess.) That was one of the earlier subjects I'd thought of, when I was trying to keep the number of them relatively small. Since there are about two dozen now, it's probably okay to split to .UnicodePolitics and .UnicodeReligion, though if anyone prefers the combined group with .UnicodePoliticsreligion for a class name I guess I don't object. The other should just be changed to .UnicodeUi. In any event, Mediawiki:Common.css will need an update. ⇔ ChristTrekker 17:22, 23 May 2013 (UTC)

1. Your standard suggestion is good.

2. My {{ucfirst:{{lc:{{{subject}}}}}}} says that the code is double up. Twice the same. As I said; it does lc and uc again and again.

3. No reason for this to split up PoliticsReligion. Just manage the capitals.

4. My UnicodeUI, UnicodePoliticsReligion examples say you won't get an uppercase UI from that {{lc:}} thing. Ever. So your UnicodeUI class won't get hit ever. Try entering: subject=UI

-DePiep (talk) 19:46, 23 May 2013 (UTC)

Ahum: somehow input CHEM produces CHEM. What is this? I do not ever wonna have to do with this. -DePiep (talk) 20:28, 23 May 2013 (UTC)

Right—as it stands, the "UnicodePoliticsReligion" and "UnicodeUI" classes never get used. I goofed. I don't understand what you mean about it doing "lc and uc again and again" though.

The code I supplied was designed to give an initial capital, so that "UnicodeSubject" was an easily-readable class name. At this point, there are several options to fix this.

1. My earlier suggestion, rename the classes, splitting PoliticsReligion into two and fixing UI. Just a css change.
2. Similar, rename the classes, but not splitting PoliticsReligion. One class name not very readable. Just a css change.
3. Just remove the "ucfirst" bit. Class names would be like .Unicodeemoticon. Not very readable. Changes template and css.
4. Remove the "ucfirst" bit and reformat to something like .Unicode_emoticon. More readable. Changes template and css.
5. Remove the "ucfirst" and "lc" both. Requires editors to use exactly the right param value, but we could keep unusually-capitalized names like "UnicodePoliticsReligion". Just a template change.

Your thoughts? I think User:MSGJ would make one or both edits for us, so I don't know if being concerned about having to touch two pages rather than one is even relevant. ⇔ ChristTrekker 21:53, 23 May 2013 (UTC)

Oops: I found out. {{ucfirst:cheM}} → CheM (not Chem as intended). So your nesting is to the point: set all to lc first.

• Propose: all to lc for simplicity (and if I get it well, not an uncommon class-naming habit).
• Add hyphen for readability: class name would be Unicode-animal
• Could we make it to be: class="Unicode Unicode-animal" (or class="Unicode-animal Unicode"). That would give the basic Unicode class as a fall-back. Otherwise, that class is not invoked at all when a subject is entered (maybe even misspelled). The sequqnce may say something about the priority.
• Yes, do split PoliticsReligion. No problem when they have the same font-family set. Should we add "Culture" too?

-DePiep (talk) 09:34, 24 May 2013 (UTC)

The order of the classes says nothing about the priority. I think it is more stylistically common to write the “superclass” (i.e. Unicode) before the “subclass” (e.g. Unicode-ui). Gorobay (talk) 13:17, 24 May 2013 (UTC)

Both classes affect the same thing (font-family), the styled elements would have the same specificity, and the classes are not meant to be used in conjunction (i.e. the style rule isn't .Unicode.Animal { /* style info */ }) to get higher specificity, so I think which gets applied would depend on the last definition read in the CSS, not the style attribute by the browser. ⇔ ChristTrekker 16:06, 24 May 2013 (UTC)

Ok then: in this the proposal is class="Unicode Unicode-animal". -DePiep (talk) 18:39, 24 May 2013 (UTC)

It's not necessary to use both—the .UnicodeSubject classes already contain the same fonts as .Unicode does as last resorts. Which characters would you suggest putting in a "Culture" group? Are you thinking Cultural, political, and religious symbols in Unicode without the ones already listed in Politics or Religion? ⇔ ChristTrekker 16:10, 24 May 2013 (UTC)

They may have the same font-family today, but your solution implies a maintenance task ("make sure font-families are copied"). So I suggest to keep the two-class option. -DePiep (talk) 18:39, 24 May 2013 (UTC)

Which characters in the culture group?: I/we do not put them in there, the article editor does, most likely! My point is, that when an editor wants to use that class (|subject=), he/she would be better helped with that subject name. Political/religious subject might not cover all. (simply said: "politics" and "religion" does not cover all the intended characters). -DePiep (talk) 18:51, 24 May 2013 (UTC)

But we—speaking as the template maintainers—need to decide which fonts to apply to which classes. We do that by surveying the coverage of fonts over the characters in each group. So we need to know which characters "culture" nominally covers so that we can suggest the right fonts. ⇔ ChristTrekker 13:25, 28 May 2013 (UTC)

I thought this way: cultural, political and religious characters all get the same font-families, covering all of them. The class names are split up to give more intuitive class-options. The editor does not have to know or decide whether a symbol is "political" or "cultural" - both will work out fine. But hey, this single issue can be dropped without much harm. -DePiep (talk) 14:09, 28 May 2013 (UTC)

Subject example table

I've added a table that should show the examples in three options. I must say that my browsers (Firefox, Safari) on top of WinXP do not show a difference between any of these three. -DePiep (talk) 14:18, 30 May 2013 (UTC)

Most probably becuase you don't have any of the needed fonts installed. I already wasn't a fan, but this proves my point. This is quite a pointless addition. — Edokter (talk) — 18:29, 30 May 2013 (UTC)

No it does not disprove anything (only two specific sitiations, right?). The "maybe" does not solve anything. My point was and is: I, DePiep, do not have done the full testing. Jee, IE was not even involved. -DePiep (talk) 22:53, 30 May 2013 (UTC)

I see significant differences. Anyone who cares about glyphs of this sort will likely have a supplemental font installed. This template helps those users. I would be interested to hear from a Mac user, as Apple's emoji font is likely the most mainstream of those listed here. ⇔ ChristTrekker 19:16, 3 June 2013 (UTC)

I think that is a pretty bold assumption. I believe those user constitute less then 0.1% of our readers. I hove done some testing on my own, on XP and all major browsers. With XP's default fonts, the difference is zero; I see all squares. I also have a gazillion other fonts installed, including FreeSans and the like, so that says something. The fact is that XP's default fonts are simply outdated. I then updated the basic fonts to those from Windows 8. Low and behold... all tables showed the correct glyphs! Not suprisingly, as those fonts are twice in size. The moral is, your OS will hunt for the correct font and use the appropriate glyph when available. Otherwise, you're just out of luck. So this template adds nothing in functionality. That is the reason I cleared out the multitude of fonts for .Unicode a year ago, as they simply did not do what was expected of them. I am inclined to do the same here; the massive extra load of CSS in Common.css, loaded by all users, does not justify the few users that might have the proper font. — Edokter (talk) — 19:38, 3 June 2013 (UTC)

re Edokter: thanks, I am getting the essense of CSS better again.

re ChristTrekker: maybe you saw the improvements/differences on your own computer: which probably has all the fonts. That is not a full test I say.

Also, ChristTrekker, you wrote someone will likely have a supplemental font installed. That says it: that is not the way WP works.

I must add, CT: I admire you tough working in this, I hope it can add to WP in other ways. -DePiep (talk) 19:56, 3 June 2013 (UTC)

DePiep, yes, I do have some of the fonts installed. I have not done testing in the sense of "does the average user perceive an improvement", though. It really depends on how good the UA's font-subst algorithm is, and the fonts the user has installed. Speaking from a technical standpoint, there's no reason (that I know of) we couldn't use webfonts, then it wouldn't matter if it is installed locally or not. ⇔ ChristTrekker 22:07, 3 June 2013 (UTC)

re CT: you've lost me. I do lots of Unicode things, but I never have "installed" (or "downloaded") a font. I only just programmed the template test. I am interested in good fonts, but only as far as the WP-reader is. I won't go into the Edokter-wiseness on how "installed fonts" and classes work. -DePiep (talk) 23:15, 3 June 2013 (UTC)

Edokter, on this Win7 system, Firefox's font matching does not find suitable glyphs for all the characters on its own, even though I know I have fonts installed that contain the glyphs. With this template applied as it is now, the display is improved. This is evidence that font-matching "gives up" before it checks all available fonts. Regarding "massive extra load", it's a one-time download of another 3870 bytes. That could be trimmed by eliminating the Arial and Lucida from the end of each stack, as they are essentially worthless in this context. ⇔ ChristTrekker 22:07, 3 June 2013 (UTC)

3.8 KB is a lot in terms of CSS, cached or not. Considering the share of raeders that would benefit from it, it is wasted bandwidth. There is also a lot of duplication, so maybe one fontstack for all may be better suited. — Edokter (talk) — 22:42, 3 June 2013 (UTC)

I am intent to remove the huge fontstack from Common.css. I am appealing to all to present some test cases on a per-platform basis that proves this code is needed. The ammount of CSS is not in any way justified for the intended effect. At least, it should be reduced to one line (.UnicodeSymbol) stating only the most common fonts available. — Edokter (talk) — 21:43, 22 June 2013 (UTC)

The problem is that all the common fonts have horrible support for these characters. (The only ones that are included in a default OS install are Apple Color Emoji and Segoe UI Symbol, and they are helpful in only a handful of the character categories here. FreeSerif and FreeSans come in the Linux distro I checked, but they are highly variable.) That's the whole point of extending this template to use additional CSS classes that specify alternate fonts—fonts that have good support for those characters. Simply removing the fallbacks ”"Arial Unicode MS", "Lucida Sans Unicode"“ from each stack would save quite a bit of bandwidth, and have virtually no negative impact. If you're determined to make a drastic slash based only on "standard fonts", my recommendation would be .UnicodeAnimal, .UnicodeAstro, .UnicodeChem, .UnicodeCommunication, .UnicodeDentistry, .UnicodeEducation, .UnicodeEmoticon, .UnicodeEnclosed, .UnicodeEvent, .UnicodeFood, .UnicodeGame, .UnicodeMap, .UnicodeMedicine, .UnicodeMoney, .UnicodeMusic, .UnicodePerson ,.UnicodePicto, .UnicodePlant, .UnicodePolitics, .UnicodeRegion, .UnicodeReligion, .UnicodeSport, .UnicodeTechnology, .UnicodeTime, .UnicodeUi, .UnicodeWarning, .UnicodeWeather { font-family:'Apple Color Emoji', FreeSerif, 'Segoe UI Symbol'; } That would allow the template to continue to be used as extended, and logged-in users could put the current stacks in their personal CSS to get the full effect. ⇔ ChristTrekker 22:07, 25 July 2013 (UTC)

I conclude as Edokter does, finally. I see no demonstration of this usage per platform. -DePiep (talk) 23:59, 25 July 2013 (UTC)

Removed

The font stacks have been removed and the template reverted. Usage was virtually nil, and did not justify the bloat in Common.css. If this is to have a future, its implementation needs a drastic overhaul... if there is a need to begin with. While unicode seems a good platform for symbols, this implementation was no better then using Webdings. — Edokter (talk) — 09:59, 27 July 2013 (UTC)

Well of course usage was virtually nil. It was still practically a brand-new feature. The only way to "implement this properly" is to let time pass until more fonts contain the characters, so that we don't really have to do anything. Which may take a decade or two. 😛 But for the record, you are incorrect in your analogy to Webdings. The two problems are completely different things. I still disagree that a one-time bandwidth usage isn't worth the benefit, but I guess that's not my decision. ⇔ ChristTrekker 17:40, 29 July 2013 (UTC)

Is this template still necessary?

The template page indicates that it is only for Windows XP; since XP will be unsupported soon, shouldn’t we remove it? We have no excuse for supporting a defunct operating system after its deadline. � (talk) 19:54, 21 March 2014 (UTC)

XP will not simply cease to function after April 8. Its install base is still significant, along with IE8 and all browsers that are still being released for XP. Let's give it some time. — Edokter (talk) — 22:25, 21 March 2014 (UTC)

@Edokter: Do you think this is still useful now we're in 2016? This was only for IE6, right? —Ruud 22:28, 25 February 2016 (UTC)

@Ruud Koot: Maybe a WP:TFD request to test the waters?Jo-Jo Eumerus (talk, contributions) 22:39, 25 February 2016 (UTC)

I'd trust Erwin's judgement on this a little more than the average voter at TFD ;) —Ruud 22:45, 25 February 2016 (UTC)

MS ended support for XP over a year ago, so the template has little use, other then assigning the Unicode class, which is handy for those wanting to use their own Unicode font. But I think the font assignment (in Common.js) has outlived its usfullnes. -- [[User:Edokter]] {{talk}} 17:10, 26 February 2016 (UTC)

If nearly all browsers do proper fallback substitution then this template is just adding a lot of unnecessary clutter to 60 000 articles. And as this template isn't even used consistently anymore more nowadays (people don't notice anything going wrong if they don't use it) then the "someone might want to use a different font for Unicode characters" scenario seems a little far-fetched as well. So should we just replace this template with {{{1}}} and have a bot substitute it? —Ruud 21:40, 26 February 2016 (UTC)

I think a TfD is is in order proposing this approach. -- [[User:Edokter]] {{talk}} 10:04, 27 February 2016 (UTC)

@Jo-Jo Eumerus and Edokter: I've nominated this for deletion at Wikipedia:Templates for discussion/Log/2016 March 16. —Ruud 21:08, 16 March 2016 (UTC)

Template-protected edit request on 24 March 2016

Please undo the recent edit removing all functionality of this template ([2]), as there is not yet a consensus to turn this into a pass-through and substitute. See the ongoing TfD. That would need to be closed as consensus to delete before this edit would be appropriate. ~ Rob^Talk 17:14, 24 March 2016 (UTC)

Was it not this change that removed the functionality and you want reverted? Bazj (talk) 17:29, 24 March 2016 (UTC)

Done Bazj (talk) 17:35, 24 March 2016 (UTC)

@Bazj: You appear to have linked the same thing I did? Either way, looks good now. Thanks! ~ Rob^Talk 17:47, 24 March 2016 (UTC)

BU Rob13, You're right. I was looking at the diff in the popup where they appear different. Follow the link through and they're the same. Bizarre! Bazj (talk) 14:20, 26 March 2016 (UTC)

Template-protected edit request on 11 April 2016

Please undo Bazj's last edit. The TfD has now closed, and so the removal of the span is appropriate. The template will be substituted shortly as per the TfD outcome. ~ Rob^Talk 17:43, 11 April 2016 (UTC)

Done Izno (talk) 17:54, 11 April 2016 (UTC)