Vorlage Diskussion:Unicode

Die Löschung der Vorlage „Unicode“ wurde ab dem 25. April 2015 diskutiert und abgelehnt. Für einen erneuten Löschantrag müssen gemäVorlage:SS den Löschregeln neue Argumente vorgebracht werden.

Änderungsvorschlag

Mein Änderungsvorschlag betrifft die Reihenfolge, in der die verschiedenen Schriften aufgelistet werden. Möchte man möglichst viele Unicode-Zeichen mit dieser Vorlage ermöglichen, dann sollte Arial Unicode MS dort an erster Stelle stehen. Denn den Internet Explorer 7 verwendet nur die erste Schriftart, die auf der font-family-Liste steht und die er im System des Users findet. Diese Schriftart benutzt er dann auf jeden Fall, und zwar völlig unabhängig davon, ob er die Zeichen auf der Seite damit darstellen kann oder nicht. Kann er sie nicht anzeigen, sieht der User halt einen leeren Platzhalter. Aber die restlichen Schriftarten in der Liste verwendet der IE nicht. Da kann man so viele von installiert haben wie man will, das ist ganz egal. Es nützt auch gar nichts, die font-family-Liste länger zu machen.

Nicht zu glauben? Hier eine Demo (+ weitere Erläuterungen und Überlegungen, warum Microsoft die entsprechende W3C-Empfehlung missachtet): Font-Family-Problem
Das Problem betrifft nur den IE. Der Firefox hat sowieso keine Probleme. Der braucht diese Vorlage aber auch sowieso nicht.

Fazit: Die Nennung von Lucida Sans Unicode an erster Stelle in dieser Vorlage

• ermöglicht es einerseits, 1765 Unicode-Zeichen darstellen
• schließt aber andererseits mehr als 97 000 Unicode-Zeichen von der Darstellung aus.

Bei Arial Unicode MS fällt die Bilanz positiver aus. Sie in font-family anzugeben bewirkt, dass man fast 39.000 Zeichen darstellen kann und "nur" 60.000 Zeichen von der Darstellung ausschließt.

Außerdem halte ich auch eine CSS-Klasse für geeigneter. --Björn Klippstein 23:56, 26. Aug. 2007 (CEST)

Kleine Korrektur: Der Internet Explorer verwendet die erste vorhandene Schriftart. Für übliche Zeichen, also die Zeichen aus ISO 8859-1 oder maximal WGL4, ist das auch genau das, was sich ein Webdesigner vorstellt. Beispiel: font-family: 'Meine Lieblingsschriftart ohne Serifen', 'Meine Alternativschriftart', Arial, Helvetica, sans-seriv;. Leider hört der Internet Explorer dann auch schon auf und verwendet diese Schriftart für alle Zeichen. Andere Browser sind da viel besser und suchen solange, bis sie eine passende Schriftart mit dem Zeichen gefunden haben. Da font-family die einzige Möglichkeit ist, dem Internet Explorer zu helfen, die richtige Schriftart zu wählen, wird dies bei Vorlage:Unicode verwendet.

Über die beste Reihenfolge der Schriftarten will ich keine Aussage machen, denn das ist abhängig von dem Zeichen und von den Schriftarten, die in Windows installiert sind. Eine statische Angabe, so wie bisher, kann nie perfekt sein. Wenn die Schriftarten ausschließlich über die CSS-Klasse Unicode angegeben werden, hätte zumindest jeder angemeldete Benutzer selbst die Möglichkeit die Klasse zu überladen und eine eigene Reihenfolgen anzugeben. Außerdem kann damit die Wirkung auf den Internet Explorer beschränkt werden. Um alle Zeichen richtig auszugeben, muss für jedes Zeichen eine eigene Schriftartenfolge angegeben werden. Für Wikipedia wäre das auf mehrere Arten denkbar. Die einzig sinnvolle universelle Lösung ist meiner Meinung nach die #JavaScript-Lösung. Ich habe dafür auch schon einen fleißigen Mitstreiter. Ich werde mich demnächst wieder an die Implementierung setzen und das „Problem“ lösen. --Fomafix 10:03, 27. Aug. 2007 (CEST)

Ja genau, die erste vorhandene Schriftart, das meinte ich doch und das ist ja auch der Kern des Problems. Daher macht es auch Sinn, die Reihenfolge zu ändern. Nennt man Lucida Sans Unicode als erstes, kann man maximal 1765 Zeichen darstellen. Nennt man aber Arial Sans Unicode als erstes, kann man maximal 38 917 Zeichen darstellen. Kleine Änderung, große Wirkung.

--Björn Klippstein 14:14, 30. Aug. 2007 (CEST)

Wofür?

Wofür gibt es diese Vorlage? Man kann doch auch so beliebige Zeichen aus dem Unicode-Zeichensatz einfügen. -- Felix Wiemann 19:51, 17. Jul 2006 (CEST)

Es gibt Browser, die sich in der gerade verwendeten Schriftart fehlende Zeichen nicht (zuverlässig) aus anderen installierten zusammensuchen, namentlich der Internet Explorer bis mindestens Version 6. Für alle anderen führt das allzu häufig zu hässlichen Schriftartvermischungen – vor allem an den Serifen zu erkennen. Außerdem wird diese Vorlage vielfach ohne gegebene Notwendigkeit eingesetzt oder die angegebenen Schriftarten sind selbst nicht optimal oder nicht in dieser Reihenfolge geeignet. Meiner Meinung, wie gerade unter Vorlage Diskussion:Okina geschrieben, wäre eine Klasse die bessere, weil einfach übeschreibbare Lösung. CSS-Angaben im style-Attribut lassen sich in einigen Browsern nicht einmal über das browsereigene Benutzer-Stylesheet überschreiben und schon gar nicht im Wikipedia-eigenen. Christoph Päper 16:34, 15. Sep 2006 (CEST)

In der engischen WP werden bereits entsprechende Klassen („unicode“ etc.) eingesetzt, die keinen Effekt in anderen Browsern als dem IE haben. Christoph Päper 17:48, 27. Sep 2006 (CEST)

Redundanz von Vorlage:Polytonisch?

Ist Vorlage:Polytonisch, welche eigentlich für fehlerhafte Browser wie den Internet Explorer zum korrekten Darstellen von speziell altgriechischen Sonderzeichen gedacht war, eine Spezialversion der hiesigen Vorlage:Unicode? Machen die beiden evtl. sogar dasselbe und heißen nur verschieden? Sollte ggf. eine Vorlage vollständig durch die andere ersetzt und deaktiviert werden und wenn ja, welche? Wer weiß Rat? -- marilyn.hanson 11:54, 13. Sep 2006 (CEST)

Die Vorlage tut in etwa dasselbe, soll aber etwas spezialisiert sein. Unter anderem setzt sie die Sprache auf Altgriechisch (GRC) und eine Klasse polytonic, über die stattdessen die Schriftzuweisung laufen könnte. Die Wahl der Schriftarten(reihenfolge) dort ist natürlich suboptimal, weil das häufig installierte 20-MB-Monster Arial Unicode MS vor spezialisierten Schriften wie den Athenas kommt. Christoph Päper 16:34, 15. Sep 2006 (CEST)

Arial Unicode MS ist vielleicht doch ganz sinnvoll, da auf den meisten Systemen für Browser doch eine Arial-Schriftart voreingestellt und somit in Benutzung ist und so auch das Schriftbild der "problematischen" polytonischen Zeichen am ähnlichsten bleibt (im Idealfall vielleicht gar nicht sichtbar abweicht)? Ist die schiere Größe der eingestellten Schriftart ein Problem, und wenn ja, warum bzw. wo treten Schwierigkeiten auf? -- marilyn.hanson 09:48, 26. Sep 2006 (CEST)

Ich habe lange keinen Browser mit Standardeinstellunginstalliert, aber IIRC ist schon seit Mosaic die voreingestellte Schrift eine mit Serifen, oft Times oder (insbesondere unter Windows) Times New Roman. Arial ist eine serifenlose Schrift! (Mal davon abgesehen, dass AUMS etwas anders aussieht als Arial und nur über einen Schnitt verfügt.) Ich weiß nicht, welche (IIRC serifenlose) Schriftart der Wikipedia-Standardstil Monobook verwendet, da er mir zu hässlich und unpraktisch ist.

Auf schwächeren Rechnern machen sich die rund zwanzig Megabyte, die AUMS im (ggf. ausgelagerten) Arbeitsspeicher belegt, wenn sie aktiv ist, durchaus bemerkbar. Wenn es einigermaßen weit verbreitete, gute spezialisierte Schriftarten gibt, sollten diese immer vor AUMS angegeben werden. Christoph Päper 17:08, 27. Sep 2006 (CEST)

TITUS Cyberbit Basic?

Ich finde diese Schrift in meiner eingestellten Schriftgröße schwer bis völlig unleserlich schwer bis gar nicht lesbar – zumindest bei lateinischer und griechischer Schrift (zum Beispiel: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!). Außerdem hebt sie sich stark vom sonstigen Text ab. Und ich dürfte an meinen Einstellungen nicht soviel geschraubt haben, dass es daran liegt – zumal das Problem auch im Internet Explorer auftritt, den ich nicht konfiguriert habe und nur für solche Tests benutze. Da ich mich nicht mit den genauen Gründen für die Wahl der Reihenfolge (die wohl in der Inkompetenz des IE und Dateigrößen der Schriften vergraben liegen) auskenne, möchte ich nicht ungefragt in der Vorlage rumschrauben, werde es aber tun, sollte es keine Einwände geben.--Wrzlprmft 20:23, 9. Mär. 2007 (CET)

habe auch die Schriftart Code2000 rausgenommen, die führt zu einem sehr seltsamen J: Jj --androl 10:36, 11. Mär. 2007 (CET)

Das komplette Entfernen von Schriftarten ist nicht sinnvoll, da sie eventuell die einzigen sind, die gewisse exotische Zeichen überhaupt darstellen können, was der Sinn dieser Vorlage ist. Wenn, dann weiter nach hinten stellen. Ich habe das Ganze jetzt wiefolgt angeordnet:

1. Microsoft Sans Serif: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
2. Lucida Grande: Lorem ipsum dolor sit amet, consectetur adipisici elit. (kein Griechisch)
   
3. Lucida Sans Unicode: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
4. Arial Unicode MS: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
5. Bitstream Cyberbit: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
6. Bitstream CyberBase: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
7. Bitstream Vera Sans: Lorem ipsum dolor sit amet, consectetur adipisici elit. (kein Griechisch)
   
8. Gentium: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
9. GentiumAlt: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
10. TITUS Cyberbit Basic: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
    
11. Doulos SIL: Lorem ipsum dolor sit amet, consectetur adipisici elit. (kein Griechisch)
    
12. Thryomanes: Lorem ipsum dolor sit amet, consectetur adipisici elit. (kein Griechisch)
    
13. Visual Geez Unicode: Lorem ipsum dolor sit amet, consectetur adipisici elit. (kein Griechisch)
    
14. Code2000–2002: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
    
15. Chrysanthi Unicode: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
    

Also erst mehrere kleine, gut lesbare Schriften, dann der fette Brummer Arial Unicode MS und dann der ganze Rest, einigermaßen nach Lesbarkeit sortiert. --Wrzlprmft 13:10, 11. Mär. 2007 (CET)

Übertragung nach Mediawiki:Common.css

In der englischen Wikipedia sind die Schriften von Vorlage:Unicode (en) nach en:MediaWiki:Common.css ausgelagert. Das hat drei Vorteile:

1. Die Schriften wirken nur auf den Internet Explorer. Andere Browser werden durch die Schriften nicht beeinträchtigt. Erreicht wird das durch einen „Fehler“ im Internet Explorer: The inherit declaration resets the font for all browsers except MSIE6. The empty comment must remain.
2. Das erzeugte XHTML ist deutlich kleiner, da nicht bei jeder Verwendung der Vorlage:Uniode alle Schriften angegeben werden.
3. Jeder angemeldete Benutzer kann sich seine Schriftarten selbst aussuchen, indem in seiner eigenen CSS-Datei die Schriften angibt.

Sollten wir diese Änderung nicht übernehmen? --Fomafix 14:13, 10. Mär. 2007 (CET)

Ich habe als ersten Schritt class="Unicode" hinzugefügt. Damit können angemeldete Benutzer ihre Schriften selbst auswählen. --Fomafix 18:50, 10. Mär. 2007 (CET)

Spricht m. E. nichts dagegen – ich kenne mich allerdings wenig mit den technischen IE-Problemen aus. Wichtig ist, dass sich die Benutzer vernünftiger Browser nicht mit hässlichen oder ungewollten Schriften abgeben müssen, ohne dass sie dafür an Stylesheets rumschrauben müssen. Zumindest werden bei mir in der englischen Wikipedia Texte mit {{Unicode}} in meiner Schriftwahl dargestellt. Vielleicht könnte man bei der Übernahme an der Schriftenreihenfolge schrauben, s. o. Jeder IE-Benutzer dürfte ja MS Sans Serif installiert haben. Vergiss bitte nicht, dass die Unicode-Klasse wohl noch nicht in MediaWiki:Common.css (de) implementiert ist, was zu tun aber kein Problem darstellen sollte. --Wrzlprmft 13:10, 11. Mär. 2007 (CET)

Die Veränderung führte zu Problemen mit der Vorlage:Okina, die ich daraufhin vorerst von Vorlage:Unicode abgekoppelt habe. Da ich selbst nicht so tief in der Materie stecke: kann mir jemand sagen, woran das liegt? --ThT 12:07, 16. Mär. 2007 (CET)

Das liegt daran, dass der Internet-Explorer (zumindest die Version 6) nicht in der Lage ist, eine andere Schrift zu verwenden, wenn ein Zeichen fehlt, selbst wenn man ihm eine Liste vorgibt. (Argh!) Deswegen war Deine Änderung voll berechtigt, da die letzte Änderung ohne Berücksichtigung dieses Problems geschehen ist. In diesem Sinne habe ich die Vorlage daraufhin verändert, dass Lucida Sans Unicode jetzt an erster Stelle steht. Das ist klein und einigermaßen lesbar. So oder so: höchste Zeit, eine bessere Lösung zu finden, s. o. --Wrzlprmft 13:23, 16. Mär. 2007 (CET)

Vielen Dank, jetzt scheint es wieder in Ordnung zu sein. Habe Vorlage:Unicode erst mal wieder angekoppelt, bitte aber vor weiteren Veränderungen zu prüfen, wie sich das auswirkt. Wegen eines laufenden Vermittlungsausschusses, in dem die Vorlage:Okina eine Rolle spielt, ist dies einigermaßen wichtig. --ThT 17:46, 16. Mär. 2007 (CET)

JavaScript-Lösung

Die Vorlage:Unicode und weitere ähnliche Vorlagen werden hauptsächlich verwendet, weil der Internet Explorer nicht selbstständig eine geeignete Schriftart wählt, wenn ein Zeichen in der Schriftart nicht vorhanden ist. Dazu müssen die problematischen Zeichen alle im Quellcode durch die Vorlagen markiert werden. Der Quellcode sieht damit unübersichtlich aus und auch die erzeugte XHTML-Datei ist durch die zusätzliche Fontangaben deutlich aufgebläht.

Ich denke, es wäre möglich, dies auch durch eine reine JavaScript-Lösung zu ersetzen. Ich stelle mir das so vor, dass im Wiki-Quellcode und in der erzeugten XHTML-Datei keine Sonderbehandlung für die Sonderzeichen eingefügt wird. Nach dem Laden der Seite geht der Browser per JavaScript über alle Texte und ersetzt die Schriftart bei den üblicherweise nicht darstellbaren Zeichen.

Die Realisierung in JavaScript sollte nicht all zu schwer sein. Bei Gelegenheit werde ich einen Prototypen implementieren.

Vorteile

• Man muss sich nicht mehr um die Einbindung der Vorlagen kümmern. Es werden alle problematischen Zeichen automatisch ersetzt.
• Es kann eine zentrale Liste angelegt werden, die die problematischen Zeichen enthält.
• Der Wiki-Quellcode ist frei von den Vorlagen.
• Die erzeugte XHTML-Datei enthält keine Font-Angaben mehr und wird kleiner.
• Die Server werden weniger belastet, da die Vorlagen nicht mehr eingebunden werden.
• Die Ersetzung geschieht nicht nur im Artikeltext, sondern auch in der Überschrift. Daher können auch als Lemma Zeichen verwendet werden, die sonst Darstellungsprobleme bereiten. (Wikipedia:Liste der Artikel, deren korrekter Titel von MediaWiki nicht erlaubt wird#Seltene Unicodezeichen)
• Die Ersetzung kann Browserspezifisch programmiert werden und wirkt damit nur bei Browsern mit Darstellungsfehlern.
• Die JavaScript-Lösung kann individuell aktiviert oder deaktiviert werden.

Nachteile

• Bei deaktiviertem JavaScript werden die Zeichen nicht ersetzt und es erscheinen wie bisher Ersatzzeichen. Die Zeichen sind aber weiterhin korrekt.
• Der Browser wird stärker belastet.
• Die Ersetzung wirkt für alle Artikel. Es wäre aber möglich dies durch eine Markierung im Quellcode, die an das JavaScript weitergereicht wird, zu unterdrücken, falls Bedarf besteht.

Was haltet ihr davon? --Fomafix 13:09, 25. Mai 2007 (CEST)

Wie es bei anderen Zeichen aussieht, weiß ich nicht. Beim ʻOkina hat die Vorlage:Okina auch den Nebenzweck, daß im Quelltext leicht erkennbar ist, ob das richtige Unicode-Zeichen (02BB) verwendet wurde (siehe hier). --ThT 09:06, 29. Mai 2007 (CEST)

Die Vorlage:Okina könnte weiterhin existieren und beinhaltet dann nur noch das Zeichen ʻ. Alles andere wird per JavaScript erledigt. Die Vorlage könnte dann auch per {{subst:Okina}} verwendet werden. Allerdings denke ich, dass die Vorlage dann nicht mehr notwendig ist, denn ʻ im Quellcode finde ich sinnvoller als {{Okina}}. Das besondere an diesem Zeichen ist nur, dass es vom Internet Explorer in den Standardeinstellungen nicht angezeigt wird und dass es mehrere ähnliche, aber nicht richtige Zeichen gibt. Die JavaScript-Lösung ist also unabhängig von den Vorlagen und hat also nicht direkt damit was zu tun. Bei der Verwendung der Vorlagen ändert sich nichts, auch die Darstellung bleibt gleich. Nur das Einfügen der Schriftarten geschieht im Browser und nicht im Webserver. --Fomafix 21:25, 2. Jun. 2007 (CEST)

Dann wäre es wohl trotzdem besser, die Vorlage beizubehalten und auch nicht {{subst:Okina}} zu empfehlen. Wenn ich das richtig verstanden habe, ist die JavaScript-Lösung so unabhängig davon, daß das kein Problem wäre. ʻ im Quellcode fände ich zwar auch besser, aber nach dieser Diskussion halte ich das kaum für durchsetzbar. --ThT 09:37, 4. Jun. 2007 (CEST)

Wenn ich die Diskussion recht verstanden habe, dann ist das Hauptproblem bei einem ʻOkina, dass es im Internet Explorer nicht angezeigt wird. Mit einer JavaScript-Lösung wäre genau dieses Problem beseitigt. Daher denke ich dass sich die Voraussetzungen dann geändert haben und nun nichts mehr gegen ʻ oder ʻ im Quellcode spricht. Aber wie gesagt, die JavaScript-Lösung wäre davon unabhängig und muss erst separat untersucht werden. --Fomafix 13:22, 4. Jun. 2007 (CEST)

Ich habe hier einen einfachen Vorabtest, um die prinzipielle Möglichkeit von JavaScript zu zeigen:

function fixunicode()
{
	unicode = "\u02bb\u2200-\u22ff";
	re = new RegExp('[' + unicode + ']+', 'gm');
	c = document.getElementById('content');
	c.innerHTML = c.innerHTML.replace(re, '<span style="font-family: \'Arial Unicode MS\'; background-color:red;">$&</span>');
}

addOnloadHook(fixunicode);

Dieser Code wird in die Spezial:Mypage/monobook.js aufgenommen und wird damit automatisch nach dem Laden einer Seite ausgeführt. Die Variable unicode gibt an, welche Zeichen ersetzt werden sollen. Hier sind einzelne Unicode-Codepoints \u02bb oder ganze Ranges \u2200-\u22ff möglich. Die Zeile mit dem replace enthält den HTML-Code, der eingefügt wird. Zum besseren Anschauen habe ich neben der Schriftart auch noch die Hintergrundfarbe auf rot gesetzt. Jetzt müssen zu problematischen Unicode-Zeichen passende Schriftarten gesucht werden. Diese Funktion hat derzeit eine ziemliche Laufzeit. Vielleicht kann der Code noch verbessert werden. --Fomafix 13:22, 4. Jun. 2007 (CEST)

Die obige Umsetzung macht Fehler, wenn das zu ersetzende Zeichen in einem Attribut vorkommt. Daher habe ich die Umsetzung verbessert: --Fomafix 23:51, 5. Jun. 2007 (CEST)

function fixunicode()
{
	unicode = "\u02bb\u2200-\u22ff";
	fontFamily = "Arial Unicode MS";
	element = '<[^<>]*>';
	text = '[^<>]*?';
	html = text + '(' + element + text + ')*';
	re = new RegExp('^(' + html + ')([' + unicode + ']+)(' + html + ')$', 'gm');
	c = document.getElementById('content');
	c.innerHTML = c.innerHTML.replace(re, '$1<span style="font-family: ' + fontFamily + '; background-color:red;">$3</span>$4');
}

addOnloadHook(fixunicode);

Die obigen Implementierung hat ein Problem, wenn ein TEXTAREA-Feld vorhanden ist, also die Seite bearbeitet wird. Der folgende Code umgeht dieses Problem, indem jeder Knoten einzeln bearbeitet wird. --Fomafix 13:08, 12. Jun. 2007 (CEST)

function fixhtml(str)
{
	var unicode = "\u02bb\u2118\u2111\u211C\u0080-\u00ff€";
	var fontFamily = "Arial Unicode MS";
	var re = new RegExp('[' + unicode + ']+', 'gm');
	return str.replace(re, '<span class="unicode" style="font-family: ' + fontFamily + '; background-color:red;">$&</span>');
}

function traverse (node)
{
	for (var child = node.firstChild; child; child = child.nextSibling) {
		switch (child.nodeType) {
		case 1: // ELEMENT_NODE
			switch (child.nodeName) {
			// bei folgenden Elementen nicht absteigen und ersetzen.
			case "APPLET":
			case "BASE":
			case "BR":
			case "FRAME":
			case "FRAMESET":
			case "HR":
			case "IFRAME":
			case "IMG":
			case "INPUT":
			case "LINK":
			case "OBJECT":
			case "SCRIPT":
			case "STYLE":
			case "TEXTAREA":
			case "TITLE":
				break;
			default:
				traverse(child); // Rekursiv absteigen.
				break;
			}
			break;
		case 3: // TEXT_NODE
			var html = fixhtml(child.nodeValue); // ergänze HTML-Code.
			if (html == child.nodeValue) break; // es wurde nichts ersetzt. Fertig.
			var span = document.createElement('span');
			span.innerHTML = html; // Neuen HTML-Code unter ein span hängen.
			var last = span.firstChild;
			if (!last) break;
			for (var next = last.nextSibling; next; next = next.nextSibling) {
				node.insertBefore(last, child);
				last = next;
			}
			node.replaceChild(last, child);
			child = last;
			break;
		}
	}
}


function fixunicode()
{
	traverse(document.getElementById('content'));
}

addOnloadHook(fixunicode);

Ich habe an obiger Implementierung Verbesserungen eingebaut, damit keine zusätzliche span-Umgebungen eingefügt werden. Damit müsste die Implementierung vom Prinzip fertig sein. Nun kann das Testen beginnen. Ich habe es bereits mit Mozilla Firefox 2, Opera 9.2 und Internet Explorer 6 erfolgreich überprüft. Jetzt muss für die problematischen Unicode-Zeichen die passenden Schriften gesucht werden. Hat da jemand Erfahrung und kann da Informationen beisteuern? --Fomafix 17:29, 12. Jun. 2007 (CEST)

Kenne nur das, was hier empfohlen wird:

• UTF-8-Probleme
• Browser-Hinweise des Wikiwörterbuches
• Umstellung auf Unicode
• Bekannte Browserprobleme (meta) (englisch)

Lucida Sans Unicode hat mir bisher gute Dienste geleistet. --ThT 07:41, 13. Jun. 2007 (CEST)

Diese Seiten kenne ich, bzw. sie bringen nicht weiter. Ich benötige Informationen darüber welche Schriftarten welche Zeichen(bereiche) enthalten, bzw. nicht enthalten und durch eine andere Schriftart ersetzt werden sollten. Hier kann nachgeschaut werden, wofür Vorlage:Unicode bisher verwendet wird. Das Ziel am Ende sollte eine Definition von Variablen sein, aus denen der JavaScript-Code sinnvolle Schriften ersetzt. Beispielsweise: --Fomafix 14:03, 13. Jun. 2007 (CEST)

greek = '\u0370-\u03ff';
notWGL4 = '^…';
arialUnicodeMS = '\u0000-\ufffe';

JavaScript ist keine gute Lösung, da es generell ein Sicherheitsrisiko darstellt und deshalb von erfahrenen Benutzern meist ausgeschaltet ist. Das heißt, der Benutzer müsste zuerst den Quellcode überprüfen, um sicherzugehen, dass keine gefährdenden Skripte vorhanden sind. Meiner Meinung nach ist es anwenderfeindlich. --Gruß, Con^structor 11:52, 20. Jun. 2007 (CEST)

PS:Sorry, zu spät gelesen, dass es in das monobook.js soll. Aber auch da besteht das Problem, dass jeder die Datei editieren könnte. --Gruß, Con^structor 11:53, 20. Jun. 2007 (CEST)

Ein Sicherheitsrisiko sehe ich nicht. Zum testen muss es in die persönliche Benutzer:BenutzerID/monobook.js. Diese Datei darf übrigens nur der Benutzer selbst bearbeiten. Wenn alles perfekt funktioniert und so gewollt ist, dann könnte es nach MediaWiki:Common.js übernommen werden. Vielleicht wäre auch http://de.wikipedia.org/skins-1.5/common/IEFixes.js die richtige Datei, da es sich nur ein Problem des Internet Explorer handelt. Erst wenn es damit für alle Benutzern aktiviert ist, könnte die Vorlage:Unicode deaktiviert werden. Ganz klar, vorher muss aber alles gedatet und getestet werden. Bei Internet-Explorer-Benutzer mit deaktiviertem JavaScript werden wie bisher ohne die Vorlage:Unicode Ersatzzeichen angezeigt. Die Seite funktioniert also weiterhin. Auch ein kopieren in die Zwischenablage funktioniert. Sicherlich wäre es auch sinnvoll eine Möglichkeit einzubauen, diese Funktion zu deaktivieren ohne gleich JavaScript deaktivieren zu müssen. Denkbar wäre sogar, dass die Funktion standardmäßig nicht ausgeführt wird, aber mit einem Klick einmalig oder per Cookie dauerhaft aktiviert wird. Es könnte ein Hinweistext mit Beispielzeichen und Buttons angezeigt werden, sobald ein die Seite problematische Zeichen enthält. Es ist nämlich per JavaScript nicht überprüfbar, ob der Internet-Explorer-Benutzer bereits seine Schriftart auf Arial Unicode MS oder ähnlich umgestellt hat und damit diese Funktion nicht benötigt wird. Zunächst müssen aber die problematischen Zeichen identifiziert und dazu passende Schriftarten ausgesucht werden. --Fomafix 13:04, 20. Jun. 2007 (CEST)

Diese Datei darf übrigens nur der Benutzer selbst bearbeiten. - Ok, ich ziehe meinen Einwand zurück. --Gruß, Con^structor 13:33, 20. Jun. 2007 (CEST)

Ich habe hier eine Beschreibung aller Schriftarten mit den jeweils enthaltenden Unicodezeichen gefunden. Daraus müsste sich eine passende Ersetzungsregel erarbeiten lassen. Die Ersetzungsregel soll für jedes Zeichen beschreiben, welche Schriftarten geeignete sind. Die Schriftarten sollen nach absteigender Schönheit sortiert angegeben werden. --Fomafix 13:07, 26. Jun. 2007 (CEST)

Danke an Prince Kassad für die Hinweise und eine sehr umfangreiche Beispielimplementierung.

Ich habe mir den JavaScript-Code angeschaut und ausprobiert. Wenn ich unter Firefox den Code ausführe, dann bleibt der Browser komplett hängen. Wenn ich nur Teile des Codes verwende, so läuft der Code. Der Code ist sehr umfangreich und so nur schlecht auf Fehler durchsuchbar. Ich vermute den Grund für das hängenbleiben schlicht in der Codegröße mit den vielen Variablen. Vielleicht liegt aber auch irgendwo ein Tippfehler drin.

Ich habe den Code erst mal vereinfacht und die Beziehung zwischen Zeichenbereich und Schriftarten in ein Array gepackt:

var range2font = [
[ "\u0180-\u02af", "Doulos SIL,Sun-ExtA,Quivira,Code2000,serif"],
[ "\u02b0-\u02ff", "Doulos SIL,Sun-ExtA,Code2000,serif"],
[ "\u1e00-\u1fff", "Arial Unicode MS,Microsoft Sans Serif,Tahoma,serif"],
];
 
function fixhtml(str)
{
	for (var i = 0 ; i < range2font.length; i++) {
		var range = range2font[i][0];
		var fontFamily = range2font[i][1];
		var re = new RegExp('[' + range + ']+', 'gm');
		str = str.replace(re, '<span class="unicode" style="font-family: ' + fontFamily + '; background-color:red;">$&</span>');
	}
	return str;
}

Damit können passende Regeln leicht eingetragen werden. --Fomafix 00:33, 29. Aug. 2007 (CEST)

Die Übernahme der Einstellungen, die im alten Script direkt auf Prozessbasis eingebaut war, müsste da noch irgendwo eingebaut werden. Ich schätze, das ist mit concat() oder push() realisierbar, da müsste ich aber im Code herumstochern. -- Prince Kassad 14:59, 30. Aug. 2007 (CEST)

Nachtrag: Die Einstellungen werde ich direkt mit Kommentaren einbauen (spart wertvolle Prozesszeit), fehlt nur noch die Vista-spezifische Schrifteinstellung, die macht mir so etwas Sorgen. -- Prince Kassad 15:01, 30. Aug. 2007 (CEST)

optionales title-Attribut

Die Vorlage:Unicode könnte mit einem optionalen Parameter erweitert werden, mit dem das title-Attribut des span-Elements gesetzt werden kann. Damit wäre es möglich einen beschreibenden Text mitzugeben, der das Zeichen erklärt, wenn der Mauszeiger darauf zeigt. Wenn der Leser im Browser keine passende Schriftart für das Zeichen hat, so bekommt er zumindest eine Erklärung.

Ich sehe dazu zwei Möglichkeiten:

• Benannter Parameter: {{Unicode|€|title=U+20AC Eurozeichen}}
• Unbenannter Parameter: {{Unicode|€|U+20AC Eurozeichen}}

Der benannte Parameter hat den Vorteil, dass er nicht das Problem mit Gleichheitszeichen hat.

Dargestellt wird das in beiden Fällen so: €. --Fomafix 11:03, 29. Jun. 2007 (CEST)

DejaVu-Schrift

Hallo!

Ich habe mir die Vorlage mal angesehen und die DejaVu-Schrift „DejaVu Sans“ vor „Bitstream Vera“ eingefügt. Der Grund ist, dass das DejaVu-Projekt (siehe http://dejavu.sourceforge.net/) die Bitstream Vera-Schrift um einige fehlende Unicode-Zeichen erweitert, also nun auch Grichisch unterstützt.

Neue Reichenfolge:

1. Lucida Sans Unicode: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
2. Arial Unicode MS: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
3. Bitstream Cyberbit: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
4. Bitstream CyberBase: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
5. DejaVu Sans: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
6. Bitstream Vera Sans: Lorem ipsum dolor sit amet, consectetur adipisici elit. (kein Griechisch)
   
7. Gentium: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
8. GentiumAlt: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
9. TITUS Cyberbit Basic: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
   
10. Doulos SIL: Lorem ipsum dolor sit amet, consectetur adipisici elit. (kein Griechisch)
    
11. Thryomanes: Lorem ipsum dolor sit amet, consectetur adipisici elit. (kein Griechisch)
    
12. Visual Geez Unicode: Lorem ipsum dolor sit amet, consectetur adipisici elit. (kein Griechisch)
    
13. Microsoft Sans Serif: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
    
14. Lucida Grande: Lorem ipsum dolor sit amet, consectetur adipisici elit. (kein Griechisch)
    
15. Code2000–2002: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
    
16. Chrysanthi Unicode: Lorem ipsum dolor sit amet, consectetur adipisici elit. Μη μου τους κύκλους τάραττε!
    

Gruß, Andreas 09:26, 15. Jul. 2007 (CEST)

Beobachtungen im Konqueror 3.5.8

Diese Vorlage hindert mich daran IPA Zeichen zu sehen, so dass ich hier [1] nur Kästchen sehe. Bei der Entfernung der Vorlage wird es richtig dargestellt. Alternativ tut auch die Vorlage:IPA. --chrislb disk 12:19, 23. Jan. 2008 (CET)

Bei meinem Konqueror 3.5.5 werden die Zeichen sowohl mit Vorlage:Unicode, als auch mit Vorlage:IPA korrekt angezeigt. Du hast in Deiner monobook.css eine Schriftart ohne Ersatzschrift angegeben. Vielleicht wirkt sich das auf den Konqueror aus, weil Arial Unicode MS nicht zu den linuxtypischen Schriftarten gehört.

Vorlage:Unicode macht eigentlich nichts anderes, als eine Reihe von Schriftarten zu definieren. Diese Definition wird meines Wissens nach aber nur beim Internet Explorer bis Windows XP benötigt, um dem Browser zu helfen eine andere Schriftart zu verwenden, wenn ein Zeichen nicht in der Standardschriftart vorhanden ist. Alle anderen Browser sind selbst so intelligent und wählen eine passende Schriftart aus. Die zusätzlich definierte CSS-Klasse Unicode ist derzeit nicht verwendet. Um andere Browser als dem Internet Explorer durch die unnötige Definition nicht zu stören, sollte die inline-Schriftartangabe style="font-family:…" entfernt werden und nach MediaWiki:Common.css ausgelagert werden, wie ich oben bereits vorgeschlagen habe. Bei en:Common.css/Unicode ist das auch so. --Fomafix 13:05, 23. Jan. 2008 (CET)

Bevormundung von Usern, welche eine andere Schrift haben wollen.

Diese Vorlage formatiert den Text direkt im Span-Tag. Das verhindert, dass User die Schrift per CSS für ihre Bedürfnisse (sprich: installierte Schriften) anpassen können. Ich halte es daher für notwendig, die Schriften in der Common.css zu deklarieren, damit User sie bei Bedarf in Ihrer CSS-Datei (meist monobook.css) anpassen können. Cäsium137 08:41, 5. Feb. 2008 (CET)

Prince Kassad hat – gewissermaßen zurecht – die Vorlage:Unicode aus dem Artikel Uluṟu entfernt. Bei meinem Internet Explorer 6 wurde der Artikel zuvor auch nicht richtig angezeigt, weil ich sowohl die Schriftart Lucida Sans Unicode, als auch Arial Unicode MS installiert habe. Arial Unicode MS hat zwar das richtige Zeichen, aber Lucida Sans Unicode steht zuerst drin und enthält das Zeichen nicht. Richtig wäre demnach style="font-family: 'Arial Unicode MS', Code2000, Gentium" Eine einfache Festlegung einer Schriftartenreihenfolge reicht einfach nicht aus und ist obendrein störend für die Browser, die bereits alles richtig machen. Der erste Schritt sollte demnach unbedingt eine eigene CSS-Klasse sein, über den die Schriftarten ausschließlich für den IE6 definiert werden. Aber darauf reagiert wohl kein Admin. Eigentlich sollte man gleich einen Löschantrag für die Vorlage stellen, denn sie sorgt so nur für Probleme. --Fomafix 23:23, 11. Feb. 2008 (CET)

In solchen fällen muss man immer die Admins direkt im Chat anschreiben und etwas anstubsen, weil sie oftmals Angst haben etwas falsch zu machen und dann lieber nichts machen. Die Intension ist schon die richtige, vielleicht kann man ja auch auf en:MediaWiki:Common.css verweisen (ab „/* Support for Template:IPA, Template:Unicode and Template:Polytonic“). Mein Ansatz war ja noch weitreichender, wurde aber ignoriert... --Revolus Echo der Stille 07:10, 12. Feb. 2008 (CET)

Vorlage funktioniert nicht mehr

Aus irgendeinem Grund funktioniert die Vorlage bei meinem IE nicht mehr, sie ist wirkungslos geworden (während im Opera noch alles funktioniert). Weiß jemand, warum? -- Prince Kassad 18:02, 27. Mär. 2008 (CET)

Kann eigentlich nur an unterschiedlichen Standardschriften in den Browsern liegen. Stell mal den IE auf eine passende Standardschrift um. Die Vorlage benutzt im übrigen jetzt für jede Plane eine eigene Klasse. Cäsium137 (D.) 19:00, 27. Mär. 2008 (CET)

Funktioniert auch nicht. Interessanterweise funktioniert Vorlage:IPA weiterhin, nur diese Vorlage will nicht so richtig. -- Prince Kassad 19:10, 27. Mär. 2008 (CET)

Vielleicht liegt es am Block oder Plane. Schreibe mal (du hast doch Babelpad ? ) eine Textdatei, welcher viele Blöcke in Plane 0 benutzt und eine, welche Zeichen aus Plane1 benutzt. Hast du die verschiedenen CSS-Klassen berücksichtigt ? Cäsium137 (D.) 19:16, 27. Mär. 2008 (CET)

P.S. Ich muss jetzt hier Schluss machen, da ich noch was kaufen will. Cäsium137 (D.) 19:17, 27. Mär. 2008 (CET)

Den Fehler hab ich soeben gefunden und er wurde auch schon beseitigt - ein Schreibfehler in der Common.css. -- Prince Kassad 19:52, 27. Mär. 2008 (CET)