Hilfe Diskussion:TeX

[[:]]

Archiv

2003 bis 2012 ab 2013

Wie wird ein Archiv angelegt?

Auf dieser Seite werden Abschnitte ab Überschriftebene 2 automatisch archiviert, die seit 14 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Parser-Fehler mit \mathrm bei Umlauten

Der Befehl \mathrm{} führt in Formeln zu Parser-Fehlern, wenn im Argument deutsche Umlaute enthalten sind. Dies allerdings nur dann, wenn die Formel auf dem Wikimedia-Server interpretiert wird. Wenn sie lokal vom Browser mittels MathJax ausgewertet wird, dann ergibt sich ohne Fehlermeldung das erwartete Formel-Bild. MathJax ist offenbar toleranter als der Parser von Mediawiki. Das ist besonders unangenehm, weil auf diese Weise ein Autor, der MathJax bei sich aktiviert hat, nichts vom Fehler merkt.

Ich habe in der Tabelle mit den verschiedenen Schriftstilen eine Andeutung ergänzt. Das Problem erscheint mir allerdings gravierend genug, dass deutlicher darauf hingewiesen werden sollte. Wie wäre es mit einem Abschnitt zur Entscheidung, wann \mathrm und wann \text sinnvoll ist?---<)kmk(>- (Diskussion) 16:16, 20. Jan. 2014 (CET)

Einen solchen Abschnitt halte ich auch für gut. Es ist immer grausig, wenn Fließtext mit \mathrm (mathematisches Symbol aufrecht innerhalb mathmode im TeX) statt mit \text (Fließtext außerhalb mathmode aber noch im TeX) gesetzt wurde. --Stefan 17:53, 17. Feb. 2014 (CET)

array mit Position

Nach dieser Seite gilt

\begin{array}[Position]{Spalten} ... \end{array}

Der [Position]-Part ist bei uns nicht beschrieben. Er kann wohl nur top oder bottom enthalten. Habe heute einige mit h repariert. Vielleicht sollte man das auf der Vorderseite entsprechend einarbeiten. (Die Fehlermeldung bei den [h] war sehr irreführend, da einfach die Funktion nicht bekannt war …) Der Umherirrende 19:22, 10. Jun. 2016 (CEST)

Die Shortcut-Syntax für die Spalten *{<num>}<col spec> wird auch nicht erklärt. Der Umherirrende 20:13, 10. Jun. 2016 (CEST)

„Mit dem optionalen Parameter Position wird entschieden, ob die Oberkante [t], die Unterkante [b] oder die Mitte des Feldes auf die laufende Zeile ausgerichtet wird.“ Ein [h] ist somit gar nicht vorgesehen und sollte entfernt werden. --Boehm (Diskussion) 23:11, 12. Jun. 2016 (CEST)

Umlaute in Formeln sind fehlerhaft

Aus: Wikipedia:Technik/Werkstatt#Umlaute_in_Formeln_fehlerhaft

• Umlaute in PNG sehen gut aus, sind aber nicht accessible
• Umlaute in SVG werden im Browser ggf. durch andere FOnts ersetzt
• MathML sieht gut aus, erfordert aber Plugin.

Zusammen mit dem folgenden Abschnitt ergibt sich hier die unschöne Situation, dass keine Einstellung richtig funktioniert: --Alturand (Diskussion) 22:17, 7. Feb. 2017 (CET)

Ein dreiviertel Jahr später ist die Lage unverändert. Hier als schneller Test <math>\text{UüöäÄeßzet}</math>

${\text{UüöäÄeßzet}}$

Mit Firefox 52.4.0 und dem Plugin "Native MathML" sieht das bei mir gut aus. Ohne das Plugin erscheinen die Umlaute deutlich zu groß.

Außerdem habe ich bemerkt, dass \mathrm zu einem Parser-Fehler führt. Wobei der Fehler noch nicht einmal mit "<nowiki>" unterdrückt werden kann. Auch nicht wirklich schön.---<)kmk(>- (Diskussion) 23:45, 14. Okt. 2017 (CEST)

„Umlaute in SVG werden im Browser ggf. durch andere FOnts ersetzt“: Deswegen gehen Autoren wieder einen Schritt zurück und zerstören das „accessible“. Siehe: https://de.wikipedia.org/w/index.php?title=Fall_mit_Luftwiderstand&diff=170484341&oldid=165943062

Das ist doch keine Lösung. Sehr ärgerlich. Da kann man doch lieber bei PNG bleiben und der Quälcode sieht genau wie das Ergebnis gut aus. --Boehm (Diskussion) 20:48, 30. Okt. 2017 (CET)

Hier eine mögliche Abhilfe: <math>\frac{x^2}{x}=x \quad \text{f}\ddot{\text{u}}\text{r } x \ne 0</math>

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \frac{x^2}{x}=x \quad \text{f}\ddot{\text{u}}\text{r } x \ne 0}

-- Gruß von der Wassermaus (Diskussion) 21:01, 27. Dez. 2017 (CET)

Stolz habe ich das soeben im Hilfetext eingefügt, aber ich hatte nicht bis zum Ende gelesen. Danach sah ich in Abschnitt 4 ("Was nicht geht"), dass man genau das nicht tun soll. Also habe ich meine Änderung mit der Lösung erst mal rückgängig gemacht. Toll! Ist mbox bzw text mit Parameter "für" besser, wenn das Ergebnis "f r" ist? Freunde, das geht doch nicht! Man sollte ddot zulassen -- Wassermaus (Diskussion) 02:46, 28. Dez. 2017 (CET)

Jain: Früher habe ich „fuer“ im Mathe-Modus durch \mathrm{f\ddot ur} ($\mathrm {f{\ddot {u}}r}$) ersetzt. Ist kein schöner Quälcode, aber es geht. Dann konnte man endlich \text{für} (Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \,\text{für}} , siehe Bild: https://upload.wikimedia.org/math/b/3/d/b3db1b1bd9a51b83badcfcbba103aae8.png) verwenden. Das ist deutlich besser und funktionierte für alle Leser. Dann erfolgten viele Verschlimmbesserungen. In der Tat scheint es pragmatisch zu sein auf die Ausgangsposition zurückzukehren. Besser wäre es allerdings endlich die neuen Fehler beim Rendern zu beheben. Allerdings ist das auf der Prioritätenliste der Wikipedia nicht sehr weit vorne: https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Reading#Functional_and_beautiful_math_for_everyone also Platz 38 https://meta.wikimedia.org/wiki/Special:MyLanguage/2017_Community_Wishlist_Survey/Results wobei nur die ersten 10 Plätze im nächsten Jahr bearbeitet werden. Die wissen Alle bescheid, bauen aber erst einmal Stalk-Werkzeuge und Klicki-Bunti-Editoren und anderen Unsinn. Da hilft nur warten. Bis dahin habe ich auf „Mathe nur als png-Bilder darstellen“ umgeschalten und meine Nerven sind geschohnt. --Boehm (Diskussion) 11:23, 28. Dez. 2017 (CET)

\oiint wird nicht korrekt gerendert

s. Diskussion:Elektrische Ladung#Parser

• PNG macht schöne aber nicht behindertengerechte Umlaute, unterstützt aber \oiint nicht
• SVG rendering macht unschöne aber behindertengerechte Umlaute, aber unterstützt \oiint
• MathML hat nicht jeder

Wie kann das am besten aufgelöst werden?--Alturand (Diskussion) 22:17, 7. Feb. 2017 (CET)

MathJax

"Bis Mitte 2015 war es auch möglich, MathJax in den Benutzereinstellungen auszuwählen." Wo wurde eigentlich kommuniziert, dass und warum das nicht mehr möglich ist? -- Wolfgang Rieger (Diskussion) 23:11, 14. Okt. 2017 (CEST)

@Wolfgang Rieger: phab:T99369. Da die gesamte Math-Erweiterung ausschließlich von Freiwilligen programmiert wird kann ich ihnen keinen Vorwurf machen, wenn sie es nicht mehr unterstützen können bzw. wollen. Die WMF scheint leider andere Prioritäten zu haben, zumindest kenne ich niemand offizielles, der sich mit der Math-Erweiterung auskennt oder sich für diese verantwortlich fühlt.--Debenben (Diskussion) 00:05, 15. Okt. 2017 (CEST)

Das halte ich für ein ziemlich peinliches Bild von Seiten der WMF. Naturwissenschaftliche Themen und damit auch Formeln gehören schließlich zum unverzichtbaren Kern einer Enzyklopädie. ---<)kmk(>- (Diskussion) 18:36, 29. Okt. 2017 (CET)

Das um einen, zum anderen, dass es nicht kommuniziert wird, sondern das die Option sang- und klanglos verschwindet. -- Wolfgang Rieger (Diskussion) 21:49, 29. Okt. 2017 (CET)

Die Abstimmung läuft zwar noch nicht, aber demnächst gäbe es die Möglichkeit/den Versuch am aktuellen Zustand etwas zu ändern: m:2017_Community_Wishlist_Survey/Reading/Functional_and_beautiful_math_for_everyone. Außerdem habe ich mal ein paar Optionen getestet: Etwas wie Benutzer:Debenben/MathJax.js funktioniert, wenn man in den Einstellungen LaTeX-Quelltext wählt. Leider weiß ich nicht wie man am Besten vorgeht, wenn man :<math> als Blockformeln formatiert haben möchte. Außerdem scheint MathJaX keine spezielle Mathe-Schriftart zu unterstützen, wo die Oberlänge der Buchstaben zu Wikipedias Helvetica passt, aber im Vergleich zu svg ist es mMn trotzdem schon wesentlich besser.--Debenben (Diskussion) 21:07, 11. Nov. 2017 (CET)

OT: Wikipeida gibt für die Schriftart nur sans-serif vor, welche Schriftart damit gewählt wird ist entscheidet der Nutzer :-) --nenntmichruhigip (Diskussion) 17:54, 12. Nov. 2017 (CET)

Angstrom

Bei mir zeigt <math>\mathrm{\AA}</math> als Ergebnis Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \mathrm{\AA}} , also nicht das erwünschte Ergebnis. Madyno (Diskussion) 10:24, 29. Okt. 2017 (CET)

Bei mir wird ein großes A mit einem Kringel drauf angezeigt: https://upload.wikimedia.org/math/6/8/c/68c86f1649a7153be6943741e2e4e989.png Wie sieht es denn bei Dir aus, bzw. was erwartest Du für eine Ausgabe? (Ich verwende: Einstellungen -> Aussehen -> Mathematische Formeln -> PNG-Bilder). --Boehm (Diskussion) 11:58, 29. Okt. 2017 (CET)

Ich hätte jetzt gesagt, dass ich (SVG) ein 'Ä' sähe, das rechts am Ende des waagerechten Strichs abgeschnitten ist. Da im SVG-Quelltext aber ein 'Å' steht habe ich nochmal sehr genau hingeschaut, und bemerkt, dass es auch oben abgeschnitten ist und der Kreis deshalb wie zwei Punkte aussieht. Mit MathML – dessen Darstellung mir als Firefox-Nutzer normal leider von MediaWiki verborgen wird – funktioniert es übrigens… @Madyno: Da es von der nutzerseitigen Konfiguration abhängt, was genau da passiert: Was siehst du? Bitte Beschreibung oder Screenshot :-) --nenntmichruhigip (Diskussion) 17:26, 29. Okt. 2017 (CET)

Ich sehe als Firefox-Nutzer unter linux und ohne spezielles Plugin ebenfalls ein zu großes, dafür aber oben und rechts abgeschnittenes Å. ---<)kmk(>- (Diskussion) 18:32, 29. Okt. 2017 (CET)

Ich benutze auch Firefox (Version 48.0.2), und habe in meiner Einstellungen unter Aussehen MathML angekreutzt, und she genau dasselbe was KaiMartin hieroben beschreibt.Madyno (Diskussion) 22:12, 29. Okt. 2017 (CET)

Ich sehe (mit Firefox 56.0.2 ohne MathML-AddOn) das Gewünschte. Vielleicht hängt Clipping-oder-nicht bei Inline-Math von Skin-Einstellungen ab. Ich benutze Vector ohne SchnickSchnack. --Rainald62 (Diskussion) 15:59, 30. Okt. 2017 (CET)

Leute, schaut mal weiter oben in die Diskussion “Umlaute in Formeln sind fehlerhaft” - das beantwortet die Fragen (bei mir kommt übrigens mit Safari statt Angström und Umlauten einfach leerer Space) — Wassermaus (Diskussion) 12:06, 29. Dez. 2017 (CET)

Also alle Fragen sind noch nicht beantwortet:

• Geben wir klein bei und fricken uns die Symbole zurecht? Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \stackrel{\scriptstyle{\circ}}{\mathrm{A}}} (Also bei mir sieht es zumindest ähnlich aus). Und wenn alles wie es soll mit dem Mathematik-Modus funktioniert, dann stellen wir alles wieder zurück? Das ist bei Angstrom nicht wild, aber bei „für“ und co. eine Heidenarbeit.
• Warten wir geduldig bis jemand der sich damit auskennt ein wenig Zeit dafür nimmt?
• Stellen wir auf „PNG-only per Default“ zurück bis alle Browser und die Wikimedia-Software soweit sind?
• Sammeln wir akribisch alle Fehler, sodass den Technikern geholfen wird und man die Ausmaße der Probleme besser erkennen kann?

--Boehm (Diskussion) 21:24, 29. Dez. 2017 (CET)

• Die Frickelei mit stackrel führt bei mir zu einem Kringel, der ein Stück über dem A schwebt. Das finde ich eher unbefriedigend. Mein Set-Up sind Firefox, oder Chromium unter Linux in aktueller Version. In meinen Wikipedia_Einstellungen habe ich für Formeln "'MathML mit SVG- oder PNG-Rückgriff'" aktiviert.
• Warten wir geduldig bis jemand der sich damit auskennt ein wenig Zeit dafür nimmt? --- Dieser "jemand" sollte die Wikimedia-Foundation (WMF) sein. Meiner unbedeutenden Meinung nach gehört die Entwicklung der Software für eine vernünftige Darstellung von Formeln zu den Kernaufgaben der Stiftung. Es ist schon mehr als nur ein wenig peinlich, dass die Community die WMF extra dazu auffordern muss, endlich ihren Job zu tun. Genug Geld wird mit der Spendenkampagne gerade in die Kassen gespült.
• PNG bis alle Browser soweit sind. --- Wenn man "alle" ernst nimmt, dann wird man nie zu einer Umstellung kommen. Dafür gibt es einfach zu viele Browser im großen, weiten Internet. Die Wikipedia ist natürlich nicht die erste WWW-Seiten mit diesen Problemen. Also gibt es seit diversen Internet-Ewigkeiten erprobte Lösungen. Die klassische Variante besteht darin, dass der Server unterschiedliche Varianten ausliefert, abhängig davon, welcher WWW-Browser die Seite abfragt.
• akribisch alle Fehler sammeln --- Mein Eindruck ist, dass es seit langem Phabricator-Tickets für all die Probleme mit der Darstellung von Formeln gibt. Es sind ja auch schon mehr als 10 Jahre ins Land gegangen seit die WMF Bug-Management-Tools einsetzt. Und bei der Umstellung 2014 von Bugzilla auf Phabricator wurde der Bestand an Fehler-Meldungen natürlich nicht der digitalen Tonne übergeben, sondern ins neue System migriert.

-<)kmk(>- (Diskussion) 09:01, 30. Dez. 2017 (CET)

Schriftart

Es wäre schön, zu den verschiedenen Fonts, die teilweise gezielt in der math-Umgebung angewählt werden können, als da sind \boldsymbol, \mathrm, \mathbf, \mathcal, \mathit, \mathtt, \mathfrak, \mathbb, \text, „math-italic“, „bold math-italic“, auch die christlichen Namen zu kennen. So dass man sie sich ggf. für andere Zwecke, bspw. für Graphiken, ebenso gezielt anwählen kann.

Habe ich da was übersehen? --Nomen4Omen (Diskussion) 12:03, 29. Jan. 2018 (CET)

Keine Ahnung, was Du mit „christlich“ meinst. Aber das sind ganz normale TeX-Fonts. Man kann diese beispielsweise in inkscape, gnuplot oder xfig einfach als Latex-Fonts auswählen. --Boehm (Diskussion) 12:40, 29. Jan. 2018 (CET)

Vielen Dank erstmal. Eine gewisse Hilfe war's.

Natürlich wusste ich, dass man in Inkscape Schriften anwählen kann. Und zwar unter einem gewissen Namen (aber nie! sowas wie \mathbf etc.). Oft heißen sie "Times New Roman", "Arial", "Courier New", "Bookman Old". Diese Namen sind dann auch unter anderen Textverarbeitungssystemen verwendbar und gebräuchlich. (Sorry, dass ich da christlich dazu gesagt habe, Taufname wäre vllt besser gewesen.)

Mir scheint, dass die im LaTeX verwendete Familie auf den Namen "Computer Modern" hört. Aber so richtig zugreifbar und vollständig implementiert scheint die nicht zu sein? Oder?

Kommt zweitens die Frage auf, warum man nicht andere Schriftarten (als "Computer Modern") im LaTeX verwenden kann. --Nomen4Omen (Diskussion) 13:03, 29. Jan. 2018 (CET)

Ok, bleiben wir zunächst bei Inkscape: Um Latex-Texte einzubinden wählt man „Erweiterungen“ -> „Rendern“ -> „Latex-Formeln“ -> „Eingabe dessen, was hier im Wiki in math-Klammern steht“. Und schon hat man ein identisches Schriftbild zu Wikipedia (wenn man Mathematikformeln in Wikipedia bspw. als png-Bilder rendern lässt). Welche Fonts ein Browser nimmt, wenn man andere Rendermethoden verwendet, weiss ich nicht. --Boehm (Diskussion) 15:25, 29. Jan. 2018 (CET)

PS: „Eingabe dessen, was hier im Wiki in math-Klammern steht“: Man benötigt den Mathematik-Modus, d. h. ein $-Zeichen vor und nach dem Text. Dann kann man auch \mathbf \mathrm etc. direkt verwenden. --Boehm (Diskussion) 15:33, 29. Jan. 2018 (CET)

In Inkscape finde ich „Erweiterungen“ -> „Rendern“, aber dann kein „Latex-Formeln“ (nur bspw. "L-System"). Ich habe INKSCAPE 0.91. Brauche ich ein Neueres ? Oder fehlt mir ein Add-On ? --Nomen4Omen (Diskussion) 15:49, 29. Jan. 2018 (CET)

"Extensions->Render->LaTeX" verwende ich auch immer. Ich glaube, es ist ein Add-On, allerdings habe ich es bei mir nie gesondert installieren müssen weil es bei diversen latex-paketen für debian standardmäßig mit-installiert wird [1].

Die Schriftart in LaTeX lässt sich beliebig ändern. Wie genau ist bei pdflatex xelatex lualatex usw. leicht unterschiedlich. Wenn man einigermaßen sichergehen will, dass es keine probleme mit fehlenden zeichen usw. gibt würde ich eine hiervon wählen: [2]. Bei "Computer Modern" gibt es eine ganze Reihe ähnlichen Schriften, insbesondere w:en:Latin Modern und w:en:STIX und je nachdem welche Methode zum Rendern der Formeln in Wikipedia verwendet wird können es theoretisch auch ganz andere Schriftarten sein.--Debenben (Diskussion) 16:50, 29. Jan. 2018 (CET)

Also auf jeden Fall erstmal vielen Dank Euch beiden.

Dass ich aber so viel kapieren muss, hätte ich nicht gedacht und nicht für möglich gehalten. Vielmehr hätte ich für möglich gehalten, dass man in den Artikel Hilfe:TeX bei jedem Schlüsselwort \mathxx ganz simpel dazuschreiben könnte, \mathxx ist der Font CMXXxxyyzz, den man von http://www.sonstwas.org herunterladen kann. Denn ich bin mir irgendwie sicher, dass \mathxx jeweils genau ein Font ist und nicht hunderte. Und man könnte den Hinweis schon haben, weil die Fonts sich ja auch so ähnlich sind, dass es schwierig ist, nicht danebenzugreifen. --Nomen4Omen (Diskussion) 18:15, 29. Jan. 2018 (CET)

Das sind eben nicht bestimmte Fonts, sondern Versionen der voreingestellten Fonts, sozusagen relative Namen. Ich glaube z.B. nicht, dass mein Firefox-MathML die üblichen Computer-Modern-Fonts verwendet. --Digamma (Diskussion) 18:46, 29. Jan. 2018 (CET)

Babel-Bausteine

Ansicht	Code
Dieser Benutzer arbeitet mit LaTeX	{{Benutzer:Max Vallender/Vorlage/LaTeX}}
LaTeX-0 Dieser Benutzer erstellt seine Dokumente mit einer WYSIWYG-Textverarbeitung.	{{Benutzer:Dti/Vorlage:User LaTeX-n}}
LaTeX-1 Dieser Benutzer hat grundlegende LaTeX-Kenntnisse.
LaTeX-2 Dieser Benutzer hat fortgeschrittene LaTeX-Kenntnisse.
LaTeX-3 Dieser Benutzer hat sehr gute LaTeX-Kenntnisse.
LaTeX-4 Dieser Benutzer ist happiest when he's at work typesetting beautiful documents.
LaTeX Dieser Benutzer ignoriert jegliche Office-Quasistandards und setzt seinen Kram begeistert mit {\bfseries\LaTeX}.	{{Benutzer:Fimp/Vorlage:LaTeX}}
LaTeX-Logo Dieser Benutzer ist LaTeX-Fetischist.	{{Benutzer:Tacado/Vorlage:User mag LaTeX}}
Datei:LaTeX logo.svg Dieser Benutzer denkt in LATEX.	{{Benutzer:Patrixx/Vorlage:latex}}
LaTeX Dieser Benutzer denkt in LaTeX.	{{Benutzer:imde/Vorlage:user_latex}}
LaTeX-0 Dieser Benutzer hat keine ausreichenden LaTeX-Kenntnisse.	{{Benutzer:imde/Vorlage:user_latex-n}}
LaTeX-1 Dieser Benutzer hat grundlegende LaTeX-Kenntnisse.
LaTeX-2 Diese Person hat fortgeschrittene LaTeX-Kenntnisse.
LaTeX-3 Dieser Benutzer hat sehr gute LaTeX-Kenntnisse.
LaTeX-4 Dieser Benutzer beherrscht LaTeX annähernd auf Muttersprachniveau.
Latex Dieser Benutzer besitzt hervorragende Latex-Kenntnisse.	{{Benutzer:Ruebsal/Vorlage:Latex}}

ergänzt aus Diskussion:LaTeX/Archiv#Babelbausteine--2003:77:4E58:1400:4005:61E6:7112:5D58 23:53, 16. Feb. 2018 (CET)

Entspricht-Zeichen

Bei den Vergleichsoperatoren sollte noch das Entspricht-Zeichen eingefügt werden, auch wenn es nur in Deutschland verbreitet ist. ${\widehat {=}}$ \widehat{=} --Thirunavukkarasye-Raveendran (Diskussion) 08:50, 11. Mai 2018 (CEST)

Na, dann: Wikipedia:Sei_mutig und füge es ein. --Boehm (Diskussion) 10:08, 11. Mai 2018 (CEST)

Zwischenraum nach \operatorname?

Hier findet sich als Beispiel \sin x + \ln y + \operatorname{supp} \, z, meines Erachtens ist das \, aber überflüssig, \operatorname{supp} z wird ja schon mit entsprechendem Zwischenraum gesetzt: Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \operatorname{supp} z} . -- IvanP (Diskussion) 23:39, 9. Aug. 2018 (CEST)

Das sehe ich auch so. --Digamma (Diskussion) 23:48, 9. Aug. 2018 (CEST)

Habe das \, entfernt. --Digamma (Diskussion) 23:52, 9. Aug. 2018 (CEST)

Das Leerzeichen war früher notwendig, wenn 4 Buchstaben im operatorname standen, nicht aber bei 3. Dieser Bug scheint nun behoben. Jetzt ist es auch ohne Leerzeichen ok. Danke fürs Richtigstellen. --Boehm (Diskussion) 00:03, 10. Aug. 2018 (CEST)

n-Wurzel auch im Wurzelteil

Da ich schon Mal nach der n-Wurzel Darstellung hier gesucht und nicht gefunden habe, finde ich es nicht überflüssig, die Darstellung hier zu wiederholen. In der Hoch und Tiefstellungen kann man sie nur dann finden, wenn man schon weiß, dass eine Wurzel durch eine Bruchhochzahl dargestellt werden kann. Mir war das schon bekannt, trotzdem musste ich in der Seite von Kubikwurzel suchen, um die Darstellung zu entdecken. Ich glaube, sie konnte in beiden Teilen bleiben, im Wurzelteil allerdings unbedingt.Yomomo (Diskussion) 09:46, 9. Dez. 2018 (CET)

Kurioser Parser-Effekt: Formelnummerierung - Zeilenumbruch erfolgt nicht vor Gleichungsnummer (16)

Bei Populationsdynamik weigert sich der wiki-Parser die Gleichungsnummer (16) auf die neue Zeile zu ziehen. Und zwar exakt bei nur dieser Gleichungsnummer (16). Bei allen anderen Gleichungsnummern geht das prima. Irgendeine vorhergehende Zeichenfolge scheint da zu stören.

Siehe hier: https://de.wikipedia.org/w/index.php?title=Populationsdynamik&type=revision&diff=183799047&oldid=183798646 .

Es geht um folgenden wiki-Text, die Gleichungsnummer (16) soll in diesem Fall am Anfang der neuen Zeile erscheinen:

die folgende Gleichung:
(16){{center|<math>\dot B = c_1N(t)</math>}}

Die Gleichungsnummer (16) erscheint hier im wiki-Code-Schnipsel zwar wunschgemäß am Anfang der Folgezeile, im zugehörigen Wikipedia-Artikel Populationsdynamik jedoch in unsinniger Weise am Ende der vorhergehenden Zeile. Der wiki-Code ist doch eigentlich sauber - was hab ich da übersehen ? (Und, nein, es ist keine gute Idee jetzt die ganzen Gleichungsnummern rauszulöschen.)

--Wurzel (Diskussion) 21:47, 21. Feb. 2019 (CET)

Ich habe das Problem notdürftig behoben. Aber es ist in der Tat ein seltsames Verhalten. Mal sehen, ob jemand das Rätsel löst. --Boehm (Diskussion) 10:41, 22. Feb. 2019 (CET)

PS: Im Artikel wäre vielleicht die Vorlage Vorlage:NumBlk sinnvoll? --Boehm (Diskussion) 10:46, 22. Feb. 2019 (CET)

"Haken" der Versicherungsmathematik

[[Hilfe:Cache|Fehler beim Thumbnail-Erstellen]]:

Sauber sieht es so aus. (3)

Hallo,

weiß jemand, wie man den "Haken" in der Versicherungsmathematik hier bei WP in TeX realisiert?

Als einzigen halbwegs gangbaren Weg habe ich das gefunden: Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \,A_{\overline{n|}}} was allerdings eine unschöne Lücke lässt. Ich kenne es eigentlich als \angln, was hier aber nicht funktioniert. Braucht es dazu ein spezielles Paket, was in der Wikipedia nicht implementiert ist? --Alabasterstein (Diskussion) 08:47, 25. Apr. 2019 (CEST)

Gemeint ist bestimmt en:Actuarial notation. Die englischsprachige WP löst das genauso wie Du es vorgeschlagen hast. Leider habe ich keinen besseren Vorschlag. Vielleicht jemand anderes? --Boehm (Diskussion) 09:32, 25. Apr. 2019 (CEST)

Es gibt bereits einen Phabricator-Eintrag: https://phabricator.wikimedia.org/T175673 --Boehm (Diskussion) 10:35, 25. Apr. 2019 (CEST)

Na, der Eintrag ist ja 2,5 Jahre her. Das bedeutet dann wohl warten :-) Danke für die Rückmeldung/ für's Nachforschen. --Alabasterstein (Diskussion) 10:48, 25. Apr. 2019 (CEST)

Schön ist es nicht, aber vielleicht etwas besser: Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle _{m|}\overline{A}_{x:{\overline{n\,}\!|}}} --Boehm (Diskussion) 21:27, 26. Apr. 2019 (CEST)

Sinn und Unsinn von Verwendung der TeX-Formeln

Hallo Leute,
ich finde, die math-Umgebung wird häufig auch dann verwendet, wenn sie eher störend wird, und damit meine ich speziell Formeln im Fließtext. Man vergleiche: (das folgende Beispiel ist zusammengestoppelt aus Bruchstücken von Ölfleckversuch, Josephson-Effekt und Atomradius)

Die Schicht hat eine Dicke von rund Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 10^{-10}} Metern. Das berechnete Ergebnis für Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle N_\mathrm{A}} liegt zwischen Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 5 \cdot 10^{23}} und Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 7 \cdot 10^{23}} . Weil $e$ (Elementarladung) und $h$ (plancksches Wirkungsquantum) zur Definition der Maßeinheiten dienen, sind sie genau bekannt und es ergibt sich für die Spannung von Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 1\,\mu\mathrm{V}} beispielsweise die Frequenz von Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 483{,}597\,8\,\ldots\text{MHz}} .
Beim Element Polonium (Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle A=208,983} ; Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \rho=9,196} ) beträgt das Volumen dieses Würfels Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 37,737\,\text{cm}^3} und die Kantenlänge Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 3,354\,\text{cm}} . Daraus folgt ein Atomradius von $167,7\,{\text{pm}}$; in Datensammlungen angegeben werden Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 167,5\,\text{pm}} .

Die Schicht hat eine Dicke von rund 10^–10 Metern. Das berechnete Ergebnis für N_A liegt zwischen zwischen 5·10²³ und 7·10²³. Weil e (Elementarladung) und h (plancksches Wirkungsquantum) zur Definition der Maßeinheiten dienen, sind sie genau bekannt und ergibt sich für die Spannung von 1 µV beispielsweise die Frequenz von 483,5978… MHz.
Beim Element Polonium (A=208,983; ρ=9,196) beträgt das Volumen dieses Würfels 37,737 cm³ und die Kantenlänge 3,354 cm. Daraus folgt ein Atomradius von 167,7 pm; in Datensammlungen angegeben werden 167,5 pm.

Manche Autoren verwenden in solchen Fällen TeX-Formeln, andere nicht. Aus meiner Sicht

• stören TeX-Formeln den Lesefluss,
• erfordern zudem jedes Mal unnötigerweise das Laden von Graphiken
• und verhindern copy-&-paste.
• Sie sollten daher im Fließtext nur dann verwendet werden, wenn es sinnvoll ist, d.h. wenn es ohne sie nicht oder nur unzureichend geht. Beispiel: "[...] Das Integral ${\textstyle \int _{0}^{1}f(x)dx}$ hat einen endlichen Wert..."
  aber nicht bei Mini„formeln“ à la $167,5\,{\text{pm}}$ oder gar für Einzelbuchstaben.

Ich würde gerne den Satz: "Da TeX-Formeln im Fließtext den Lesefluss stören können, sollten sie dort nur dann verwendet werden, wenn ihre Verwendung erforderlich ist." in die Bescheibung einfügen. Am besten mit den Beispielen: "10^–10 Meter" und "die Elementarladung e", aber: ${\textstyle \int _{0}^{1}f(x)dx}$ und $\nabla \times \mathbf {A} (\mathbf {r} )$

Was meint ihr? -- Wassermaus (Diskussion) 22:32, 21. Jul. 2019 (CEST)

Das Problem ist lange bekannt und kann nur technisch gelöst werden: [3] Leider hat die technische Lösung keine Priorität bei der Abarbeitung. Die Autoren wollen lieber vorher Überwachungswerkzeug und viel Klickibunti haben. Dieses Problem scheint noch zu wenige zu stören. Mach bitte bei der nächsten Abstimmungsrunde mit. Bis zur technischen Optimierung würde ich nicht alles auf Latex-frei zurücksetzten, um dann, wenn die Technik soweit ist, wieder alles zurück zu konvertiern. --Boehm (Diskussion) 23:40, 21. Jul. 2019 (CEST)

Ja, aber warum überhaupt LaTeX verwenden? Angenommen, es gäbe die technische Lösung. Was wäre dann an LaTeX-freiem 10^–10 Meter oder 3,35 cm suboptimal? -- Wassermaus (Diskussion) 00:35, 22. Jul. 2019 (CEST)

Wenn alles irgendwann einmal so gut funktioniert, wie es seit jahrzehnten bei mit komplett mit Latex erstellten Dokumenten oder Büchern funktioniert ist es bei so „kleinen“ Sachen in der Tat egal. Es sollte identisch aussehen. Da es verschiedene Methoden gibt die Mathe-Umgebung zu rendern, ist es vermutlich schwierig für alle Möglichkeiten das perfekte Aussehen sicherzustellen. Wenn man aber trotzdem ein einheitliches Schriftbild für Variablen haben will, sollte man es zumindest immer gleich rendern. Also, wenn ein Buchstabe in einer Math-Formel vorkommt, dann sollte er auch im Fließtext in der Math-Umgebung stehen. Das sieht zwar nicht immer perfekt aus, aber es ist wenigstens einheitlich. --Boehm (Diskussion) 09:56, 22. Jul. 2019 (CEST)

Datei:Screenshot from 2019-07-23 21-30-50.png

Leider hat Wikipedia die Rechte geändert, sodass man nicht mehr so einfach ein Skript ausführen kann um alles mit MathJax zu rendern, daher dieser Screenshot wie es bei mir in Firefox aussieht. Aber die gleiche Qualität, vielleicht sogar besser, wäre auch mit MathJax möglich.

Wenn Formeln gut gesetzt sind, darf man als normaler Leser keinen Unterschied zwischen Text und Formel sehen. Da gäbe es höchstens winzige Unterschiede bei den Abständen, Zeilenumbrüchen und für Screenreader. Leider ist das aktuell bei Wikipedia nicht der Fall. Aus meiner Sicht gäbe es technische Lösungen, vielleicht nicht 100% perfekt, aber extrem viel besser als die Bilder die im Moment den meisten Lesern angezeigt werden. Warum es für die normalen Leser nicht 100% perfekt sein kann hat auch den Grund, dass Wikipedia standardmäßig sans-serif als Schriftart definiert und die normalen sans-serif Schriftarten für Formeln ungeeignet sind, weil Buchstaben wie I $(I)$ und l $(l)$ gleich aussehen.

Die Funktionalität, dass "kleine" Formeln mit HTML als einfacher Text gerendert wurde gab es übrigends vor vielen Jahren schon mal in Wikipedia. Sobald die Formeln "komplizierter" wurden, wurden sie dann mit LaTeX gerendert und als png-Bilder angezeigt. Einige Autoren war Einheitlichkeit der Formeldarstellung wichtiger, sodass sie Befehle wie \!\, in jede Formel eingefügt haben um die png-Bild Erzeugung zu erzwingen. Die "simple Math" rendering Option wurde dann abgeschafft um die Einführung von MathJax HTML rendering zu ermöglichen. Die damit unnötigen Befehle wie \!\, waren bis vor einem Jahr oder so noch sehr häufig zu finden, dann haben wir sie weitestgehend gelöscht. MathJax HTML rendering wurde dann allerdings nicht eingeführt, insbesondere weil man nicht von externem CDN abhängig sein wollte, gleichzeitig aber kein Geld in eigene Server investieren wollte um die nötigen Webfonts bereitzustellen. Das hat dazu geführt dass alle Freiwilligen, die sich damals um die math Erweiterung (die damals übrigends keine Erweiterung war sondern zum Mediawiki-core dazugehörte) gekümmert haben, aufgehört haben bzw. sich anderen Projekten gewidmet haben. Seitdem gibt es quasi nur noch einen einzigen freiwilligen Softwareentwickler, Benutzer:Physikerwelt, der sich gelegentlich um die math Erweiterung kümmert. Die als opt-in für angelmeldete Benutzer verfügbare MathJax rendering option wurde dann entfernt weil sie niemand mehr gewartet hat und mit dem Verweis dass man in Zukunft natives MathML rendering nutzen will, was allerdings z.B. von Chrome nicht unterstützt wird.

Das Hauptproblem ist bis heute, dass es von der WMF keinerlei Unterstützung gibt, und sei es nur um ein Konzept aufzustellen welche Technologien man verwenden will. Ohne Konzept und irgendwelche Zusagen dass man Unterstützung bei Hardware oder Änderungen im Parser, VisualEditor usw. bekommt gibt es auch keine neuen freiwilligen Softwareentwickler. Wer will schon an seiner Freizeit an einem der schlechtesten Renderingsysteme arbeiten oder Prototypen und Konzepte erstellen die dann sowiso abgelehnt werden? Bzw. es gibt bei der WMF auch niemanden der überhaupt irgendetwas ablehnen oder kommentieren würde, schon alleine weil sich niemand damit beschäftigt und daher auch niemand Ahnung davon hat. Und externe Experten bezahlen um eine Grundlage für so ein Konzept zu erarbeiten wollen sie auch nicht [4]. Das Thema scheint auch für die meisten Leute absolut keine Priorität zu haben, anders kann ich mir es nicht erklären, dass sie z.B. "lazy loading" von Bildern in der mobilen Ansicht auch für Formeln aktiviert wird, die ja für die meisten leider Bilder sind, dabei die Ausrichtung kaputt gemacht wird und es seit fast einem Jahr niemanden gibt der es für nötig hält es wieder in Ordnung zu bringen. [5]--Debenben (Diskussion) 23:49, 23. Jul. 2019 (CEST)

Danke für diese Zusammenfassung! --Christian1985 (Disk) 10:40, 24. Jul. 2019 (CEST)

Danke. Ich gebe nicht auf und versuche Finanzierung für eine Entwicklerposition zu aquirieren sowie die Wünsche der Community auch international zu sammeln und die Sichtbarkeit der Gruppe zu erhöhen. Siehe meta:Wikimedia_Community_User_Group_Mathphysikerwelt (Diskussion) 12:54, 24. Jul. 2019 (CEST)

Promillezeichen

Der derzeit hier vorgeschlagene Ersatz (Fehler beim Parsen (Konvertierungsfehler. Der Server („https://wikimedia.org/api/rest_“) hat berichtet: „Cannot get mml. Server problem.“): {\displaystyle {}^{0\!}\!/\!_{00}} ) ist mir zu unsymmetrisch und die Nullen zu groß. Was haltet ihr von ${}^{_{^{^{_{0}}}}}\!\!\!/_{^{_{_{\!00}}}}\!\!\!\!\!\;\;$? Vielleicht geht es mit \diagup oder sonst wie noch eleganter? Siehe auch: Some issues. -- IvanP (Diskussion) 11:58, 25. Jul. 2019 (CEST)

Auch ein Bogen wie beim Prozentzeichen (Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \%} ) lässt sich einigermaßen hinkriegen: Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle {}^{_{^{^{_0\!\!\!\;{_{^\smallsmile}}\!\!}}}}\!\!\!/_{^{_{_{\!00}}}}\!\!\!\!\!\;\;} . -- IvanP (Diskussion) 13:24, 25. Jul. 2019 (CEST)

Bei mir (MathML) sieht die derzeit hier vorgeschlagene Version am besten aus. --Digamma (Diskussion) 17:30, 25. Jul. 2019 (CEST)

Ich speicher mal ein paar Versionen untereinander, um sie mit verschiedenen Browsern anzuschauen und zu vergleichen:

1. Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \text{‰}}
2. Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle {}^{0\!}\!/\!_{00}}
3. Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle {}^{_{^{^{_0}}}}\!\!\!/_{^{_{_{\!00}}}}\!\!\!\!\!\;\;}
4. Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle {}^{_{^{^{_0\!\!\!\;{_{^\smallsmile}}\!\!}}}}\!\!\!/_{^{_{_{\!00}}}}\!\!\!\!\!\;\;}
5. ${}^{_{^{^{_{0}\!\!\!\;{_{^{\smallsmile }}}}}}}\!\!\!\!\!/_{^{_{_{\!00}}}}$

--Boehm (Diskussion) 17:40, 25. Jul. 2019 (CEST)

TeX-Fehlermeldungen

Die Fehlermeldungen bei TeX sind manchmal echt verstörend banal. Insbesondere, wenn man eine \begin{array} oder \begin{align} hat. Da muss man dann die Formel à la binäres Suchen wiederholt halbieren, um an die beanstandete Stelle zu kommen. Andererseits darf man doch sicherlich annehmen, dass er ganz genau weiß, was ihn stört. Warum, Deubel auch, hält er mit seinem Wissen so hinterm Berg? --Nomen4Omen (Diskussion) 11:49, 2. Okt. 2019 (CEST)

mathrel defekt

Auf der Seite ist der Relationsoperator \mathrel{\hat=} angegeben. Ich habe aber das Gefühl, dass die Abstände in TeX dabei dann nicht wie bei dem normalen = gesetzt werden. Kann es sein, dass \mathrel in Wikipedia nicht funktioniert? Beispiel: Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle a=b} und Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle a\mathrel{\hat=}b} . --Geek3 (Diskussion) 14:40, 4. Apr. 2020 (CEST)

Ist mir auch aufgefallen. Beispiel: in der Infobox von Gauß (Einheit) steht

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \mathrm{1 \; Gs \,\mathrel{\widehat=}\, 10^{-4} \; \frac{kg} {A \, s^2} = 0{,}1 \; mT}}

codiert als \mathrm{1 \; Gs \,\mathrel{\widehat=}\, 10^{-4} \; \frac{kg} {A \, s^2} = 0{,}1 \; mT}, also mit \, davor und dahinter. Sonst wäre es zu eng. -- Wassermaus (Diskussion) 10:22, 27. Mai 2021 (CEST)

Kategorie:Wikipedia:Seiten, die ein veraltetes Format des math-Tags verwenden

Syntax	Wirkung	Status
<math>%</math>	${}\%$	Mathfehler
<math>\%</math>
<math>\mathrm{ % }</math>
<math>{}\%</math> <math>{\%}</math>	Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle {}\%} Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle {\%}}	Ok
<math>X \%</math>	Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle X \%} Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 10 \%}	Datei:Yes check.svg Ok

• Weiß jemand wie man diese Vorlage reparieren kann? Oder ist da etwas in der Abfrage für die Kategorie schief gelaufen?
• Auch das \Complex scheint irgendwie Probleme zu haben <math>\Complex \mathbb{P}^n</math> wird hier Sphärensatz als Fehler angezeigt. Auch beim Vektorbündel war es ein Complex, aber da ist der Eintrag nach einem Seitenpurge verschwunden Es steht aber noch in der Kat. Mag sich das mal jemand ansehen. --Liebe Grüße, Lómelinde Diskussion 15:02, 12. Mai 2020 (CEST)

@Physikerwelt: kannst du vielleicht helfen?--Debenben (Diskussion) 20:46, 13. Mai 2020 (CEST)

• • Ja. Kann ich;-) Leider handelt es sich hier um ein Fehler den ich selbst nicht verstehe. Man kann unter https://en.wikipedia.org/api/rest_v1/#/Math/post_media_math_check__type_ testen was passiert wenn die Formel <math>\%</math> gerendert wird. Durch Linksklick auf das Formelbild https://wikimedia.org/api/rest_v1/media/math/render/svg/e5a85b333ac4e07604aff5d6d89bba8c2341802b in Chomre oder durch view sourch in Firefox kommt man auf den String der an die rendering-engine übergeben wird. Hier {\displaystyle \%}. Wenn man in das Formular oben einträgt und die \ durch \\ ersetzt also

{
  "q": "{\\displaystyle \\%}"
}

erhält man die Antwort:

{
"success": true, 
"checked": "{\\displaystyle \\%}", 
"requiredPackages": [],
"identifiers": [],

 "endsWithDot": false,
 "warnings": [
   {
     "type": "texvc-deprecation",
     "details": {
       "error": {
         "message": "Deprecation: % and $ need to be escaped.",
         "expected": [],
         "found": "%\n",
         "location": {
           "start": {
             "offset": 15,
             "line": 1,
             "column": 16
           },
           "end": {
             "offset": 17,
             "line": 2,
             "column": 1
           }
         },
         "name": "SyntaxError"
       },
       "success": false,
       "warnings": [],
       "status": "S",
       "details": "SyntaxError: Deprecation: % and $ need to be escaped.",
       "offset": 15,
       "line": 1,
       "column": 16
     }
   }
 ]
}

Das bedeutet, dass hier die Kategorie getagt wird. Das sollte nicht so sein. Ich hab ein Ticket erstellt phab:T252753. --physikerwelt (Diskussion) 10:57, 14. Mai 2020 (CEST)

Seltsamkeit im Artikel Terence Tao

Hallo liebe fellow Wikipedians, die Formel (2-\sqrt{2})(n-4)+3 (im Original in korrekten math-Klammern) bei der Kakeya-Vermutung im Artikel Terence Tao wird zumindest auf meinem Rechner (Laptop gut 1 Jahr alt, MS Windows & MS Edge) fehlerhaft dargestellt: Die beiden Minuszeichen fehlen. Macht Ihr diese Beobachtung auch? Noch seltsamer: Wenn ich im Abschnitt „Leistungen“ auf „Quelltext bearbeiten“ klicke, nichts ändere und mir die Vorschau angucke, wird es plötzlich richtig. Wenn ich hingegen im Gesamtartikel auf „Quelltext bearbeiten“ gehe und mir die Vorschau betrachte, bleibt der Fehler in der Darstellung erhalten. Ich habe die Formel samt math-Umgebung per copy/paste in andere Bereiche der Wikipedia übertragen und betrachtet (natürlich nicht editiert), und es geschehen ähnliche Seltsamkeiten.

Formelreiche Artikel wie z. B. Quadratische Gleichung stellt mein Rechner hingegen fehlerfrei dar. Auch alte Fassungen des Terence-Tao-Artikels bis mindestens Ende 2019 werden korrekt dargestellt. Tsor und ClaudeJ konnten den Anzeigefehler nicht replizieren (siehe von mir begonnenen Thread auf ClaudeJ's Diskussionsseite).

--Himbeerbläuling (Diskussion) 16:15, 6. Dez. 2020 (CET)

Korrektur: Auch in Quadratische Gleichung werden einige wenige Minuszeichen nicht angezeigt. --Himbeerbläuling (Diskussion) 16:23, 6. Dez. 2020 (CET)

@Himbeerbläuling: Benutzt du Chrome? Siehe phab:T269222.--Debenben (Diskussion) 16:31, 6. Dez. 2020 (CET)

Danke für die Antwort, Debenben. Ich verwende MS Edge, aber beim letzten automatischen update erzählte mir mein Rechner, dass seit dieser Version MS Edge und Chrome auf derselben Technologie aufbauen oder so ähnlich. In der von Dir verlinkten Seite steht (wahrscheinlich erst seit neuestem) ganz oben, dass auch Edge betroffen ist. Echte Lösung scheint noch nicht zu bestehen, wenn ich das richtig gelesen habe. Aber die Fachwelt ist dran. --Himbeerbläuling (Diskussion) 18:21, 6. Dez. 2020 (CET)

Darstellung von Matrix-Variablen

Ich stolpere gerade über die unterschiedliche Formatierung der Bewegungensgleichungen von Mehrkörpersystem und en:Multibody system - im Englischen sind die Matrixvariablen (via \mathbf) gefettet, in der deutschen Version nicht. Ich würde die Formatierung der englischen Variante bevorzugen. Auf jeden Fall sollte man die Formatierung auch in der deutschen Wikipedia irgendwie regeln. In Mehrkörpersystem geht das fröhlich durcheinander. Schön wäre es, wenn man ein TeX-Makro \matrix oder \mtx definieren würde, statt es via \mathbf in das Belieben eines jeden Autors zu stellen. (nicht signierter Beitrag von Whugemann (Diskussion | Beiträge) 19:58, 29. Mär. 2021 (CEST)) --Wolfgang Hugemann 19:59, 29. Mär. 2021 (CEST) (unvollständig signierter Beitrag von Whugemann (Diskussion | Beiträge) )

Formeln werden in iPadOS mit Displayhilfe Farben intelligent umkehren unsichtbar

Gemeldet in Phabricator
Task T111222

Formeln werden in iPadOS und iOS mit Displayhilfe Farben intelligent umkehren unsichtbar Das betrifft mathematische wie chemische Formelm in Wikipedia.

zuerst ist hier die Frage der Diagnose. iPhones und iPads sollten auch bei Ihnen verfügbar sein. Die Funktion Displayhilfe Farben intelligent umkehren (ab iOS 11+) ist leicht in den Einstellungen zu finden.

https://iphone-tricks.de/anleitung/2602-iphone-bildschirm-farben-invertieren

Mit der Wikipedia App habe ich dieses nicht getestet, weil die App mich zu stark limitiert gegenüber der Ansicht im Browser.

Jetzt Safari oder anderen Browser im iOS oder iPadOS aufrufen.

1. normale Ansicht iPadOS 14.6: Formeln sichtbar, formula black on white

eine Seite mit Formeln aufrufen wie „Gleichung“.

2. Displayhilfe Farben intelligent umkehren angeschaltet -> schwarzer Hintergrund: Formeln unsichtbar, formula black on black

3. Displayhilfe Farben intelligent umkehren wieder abgeschaltet: Formeln auch unsichtbar, formula white on white

Um wieder zu 1. zu kommen muss ein neues Fenster in einem Browser, hier Safari, geöffnet werden.

Warum ist für mich und viele andere diese Displayhilfe wichtig? Mit schwarzen Hintergrund und dann hellen Buchstaben wird das Einschlafen nicht stark negiert und die Augen geschont. Bei jüngeren wird die Gefahr der Brille mit Kurzsichtigkeit gemindert. Bei älteren sind es alle Augenkrankheiten, die die Netzhautzellen betreffen, durch die Überlastung mit weißen Hintergründen.

„Kurzsichtigkeit: Warum wir zukünftig mehr weiß auf schwarz lesen sollten“ Konsistenter schwarzer Hintergrund mit einem schwarzen Thema in Betriebssystem und den Programmen gegen Kurzsichtigkeit und Überlastung der Augennetzhautzellen https://www.geo.de/wissen/gesundheit/19282-rtkl-kurzsichtigkeit-warum-wir-zukuenftig-mehr-weiss-auf-schwarz-lesen und https://www.nature.com/articles/s41598-018-28904-x

Ich habe auch Fotos davon, aber keine Lust extra einen Login zu erstellen. (nicht signierter Beitrag von 2A02:810B:C940:4798:A941:8650:5D14:B3C9 (Diskussion) 11:33, 26. Mai 2021 (CEST))

Hallo IP, danke für die Beschreibung deines Problems. Es wird als Task 111222 behandelt, leider bisher ohne Lösung :-( Raymond ^Disk. 13:31, 26. Mai 2021 (CEST)

Parser-Fehler bei Android, mobile Ansicht, Chrome

Hallo, vielleicht ist das schon bekannt: Bei Android, mobile Ansicht, Chrome-Browser wird mit <math>(\tfrac 56)^{n-1}\cdot\tfrac 16</math> der Zähler im letzten Bruch nicht richtig dargestellt: Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle (\tfrac 56)^{n-1}\cdot\tfrac 16} . Mit einem einfacheren Exponenten ohne geschweifter Klammer funktioniert es: <math>(\tfrac 56)^n\cdot\tfrac 16</math> Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle (\tfrac 56)^n\cdot\tfrac 16} . Die klassische Ansicht unter Android mit Chrome zeigt übrigens keinen Fehler. Bei Firefox unter Android funktionieren beide Ansichten. Grüße --W like wiki ^{good to know} 11:46, 5. Okt. 2021 (CEST)

Wenn man angemeldet ist, kann man unter Einstellungen das Aussehen der Math-Umgebung einstellen. Einfach auf PNG-Bilder stellen, und schon sollte es wieder hübsch aussehen.

OT: Quälkode lesen vs. Quellkode schreiben: Natürlich ist einfacher \frac 12 zu schreiben, insbesondere weil auf deutschsprachigen Tastaturen die Klammern den Umlauten weichen musten. Aber \frac{1}{2} liest sich leichter, insbesondere in komplexeren Ausdrücken. Da der Kode im Gemeinschaftprojekt auch von anderen Autoren einigermaßen verstanden werden sollte, würde ich die längere Schreibweise bevorzugen. --Boehm (Diskussion) 12:31, 5. Okt. 2021 (CEST)

Das sehe ich nicht so. Klammern machen einen Quellcode unübersichtlicher. Es hat schon seinen Grund, warum man in der Mathematik Regel über die Operatorrangfolge vereinbart hat, die einem erlauben, Klammern wegzulassen. --Digamma (Diskussion) 20:09, 5. Okt. 2021 (CEST)

Ja, das ist richtig, wenn es viele Klammerebenen gibt. Im obigen Beispiel ist das nicht der Fall. Es gibt zwar Operatorrangfolgen, aber leider sind einige Menschen bereits bei Punkt vor Strich überfordert. Eine theoretisch unnötige Klammer kann die Lesbarkeit auch für Laien erhöhen. Also, dass z. B. nicht die Zahl 56, sondern die Zahl 5 und dann die Zahl 6 gemeint sind. --Boehm (Diskussion) 20:30, 5. Okt. 2021 (CEST)

Da tut es aber auch ein Leerzeichen. --Digamma (Diskussion) 21:01, 5. Okt. 2021 (CEST)

Es ist schlicht ein Bug im Browser. Eine reguläre, erlaubte Schreibweise im Quellcode nicht zu verwenden, um einen Bug in der aktuellen Version eines spezifischen Browsers zu umgehen, kann nicht die Lösung - und schon gar nicht eine offzielle Empfehlung - sein. -- Wassermaus (Diskussion) 10:50, 13. Okt. 2021 (CEST)

Ich glaube, das ist ein Missverständnis. Damit hat das Problem nichts zu tun. Die Diskussion von Boehm und mir war off topic. --Digamma (Diskussion) 18:54, 13. Okt. 2021 (CEST)

Komplexe Zahlen mit oder ohne Punkt auf dem i/ı

Angesichts des umseitigen EW und dieser VM (später dann irgendwann mal hier) starte ich hier mal einen Diskussionspunkt zum Thema, ohne selber dazu was groß beitragen zu können. Der Dissens besteht wohl, so wie ich das verstehe, darin, ob es überhaupt zulässig ist, das i ohne Punkt als ı zu schreiben (oder eben irgendwie mit diesen geschwungenen Dingens in Latex), sprich, ob die Erwähnung irgendeinen Mehrwert bringen kann. --Grüße vom Sänger ♫ ^(Reden) 10:13, 22. Dez. 2021 (CET)

Zu dem Thema läuft gerade eine nicht abgeschlossene (!!) Diskussion Portal_Diskussion:Mathematik#Schreibweise_imaginäre_Einheit. Ich finde es gänzlich inakzeptabel, die zentrale, Wikipedia-weit gültige Hilfe:TeX eigenmächtig zu ändern.

Von dieser grundsätzlichen Überlegung ganz absehen: \dot\imath heißt: "nimm das mathematische i ohne Punkt und setze den Punkt wieder drauf, aber diesmal mittig, also ohne zu berücksichtigen, dass im math-Modus die Buchstaben (sowohl i also auch imath) per default mathit-kursiv sind. Dis sogenannte Verbesserung von i (Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle i} ) nach \dot\imath (${\dot {\imath }}$) ist also, dass im letztgenannten Fall der Punkt schief sitzt.

Wassermaus (Diskussion) 11:28, 22. Dez. 2021 (CET)

Kollaboration bedeutet, dass wir stets eigenmächtig etwas erarbeiten, was wir dann nach bestem Wissen und Gewissen veröffentlichen. Und natürlich können dabei auch Fehler entstehen, wie hier die Fehlinterpretation der semantischen Bedeutung von \imath. Und weil wir Energie und Herzblut in unsere Arbeit stecken, wollen wir auch nicht, dass das dann jemand einfach so weglöscht. Wenn ich so etwas tue und eine kaum begründete Löschung meines Werkes revertiere, dann wünsche ich mir doch sehr, dass ich mit vernünftigen Argumenten auf meinen Fehler hingewiesen werde. Das kann in der Artikel-Disk, oder meiner Benutzer-Disk geschehen. Entscheidend ist hier, dass Belege, oder zumindest Argumente geliefert werden. Sofort mit EW-Anklage um sich zu hauen ist in jedem Fall inakzeptabel - selbst wenn man in der Sache 1000x recht hat. --Vollbracht (Diskussion) 02:47, 23. Dez. 2021 (CET)

Ich schlage vor, diese Nebendiskussion zu beenden und lade im Gegenzug zur sachlichen(!) Teilnahme an der Diskussion im Portal ein. ÅñŧóñŜûŝî (Ð) 12:37, 23. Dez. 2021 (CET)

Überschriften und PNG-Erzwingung

Formeln sahen im Inhaltsverzeichnis noch nie sonderlich gut aus, jetzt werden sie nur noch als '"`UNIQ--postMath-00000009-QINU`"' angezeigt. 83 Artikel sind betroffen, das Problem ist seit November 2021 bekannt.

Außerdem gibt es noch 108 Artikel, die <math>\! beinhalten, vermutlich ein Relikt aus der Zeit, als es nötig war, PNG-Darstellungen zu erzwingen. Leider wird die Formel dadurch Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \!\,\text{zu weit links}} dargestellt, auch wenn \! teilweise durch \, kompensiert wird.

Ich werde die Formeln in Überschriften demnächst durch HTML ersetzen oder ganz entfernen. \! am Anfang eines <math>-Tags werde ich löschen, wenn mir das Resultat unschön auffällt. —Dexxor (Diskussion) 12:10, 4. Mai 2022 (CEST)

Fehler beim Parsen

Im Artikel Howard Garland erscheint bei mir im Abschnitt Schriften

Fehler beim Parsen (SVG mit PNG-Fallback (MathML kann über ein Browser-Plugin aktiviert werden): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „/mathoid/local/v1/“:): K_{2}

Wenn ich aber in den Abschnitt rein gehe wird in der Verschauansicht das K_2 korrekt dargestellt. Hat dafür jemand eine Erklärung? --Alabasterstein (Diskussion) 12:53, 17. Jun. 2022 (CEST)

Gerade geprüft: das scheint browserabhängig gewesen zu sein. --Alabasterstein (Diskussion) 18:13, 19. Jun. 2022 (CEST)