Definitionen und Algorithmen in TeamSpeak 3

Dieses Dokument enthält einige allgemeine Funktionen aus TeamSpeak. Das meiste bezieht sich aufs Query-Interface.

Inhaltsverzeichnis

Codecs

Zunächst einmal ein paar Formeln. Diese setzen MathML-Unterstützung in deinem Browser voraus und enthalten folgende Größen (unter der Annahme, der Codec sei eine feste aber beliebige Kombination aus Codecname und Qualität):

Da die Darstellung von MathML bei Verwendung von Klammern im Firefox nicht richtig funktioniert, habe ich einfach mal drauf verzichtet, Parameter zu verwenden. Man denke sie sich bitte entsprechend der obigen Liste dazu.

Bitraten-DreisatzAnwendungspaketgrößePaketgrößengrenzwert (MTU)Opus-MaximallatenzSpeex/CELT-Maximallatenz
b Offiziell = b Roh + 45 Byte t d = b Roh t + 45 Byte d Max d Max = lim t t Max b Roh t + 45 Byte = 527 ± 1 Byte t Max = 20 ms t Max = 527 ± 1 - 45 b Roh 50 20 ms

Zur MTU von etwa 527 Byte: Im TeamSpeak-Client vor 3.0.10 ergibt sich für die dort vorhandenen Codec-Latenz-Kombinationen stets d≤526. Dies wird nur ein einziges Mal erreicht, und zwar bei Speex Ultra-Breitband, Qualität 4, Latenz 260 ms. Das nächsthöhere denkbare d bei bRoh aus der Tabelle unten wäre 529. Auch diese Kombination wäre einzigartig (Speex Ultra-Breitband, minimale Qualität, Latenz 880 ms), aber im Client nicht vorhanden. Also muss die MTU zwischen 526 und 528 liegen.

Warum diese Zahl? Erst einmal gibt es eine andere seltsame Zahl, die immer wieder auftaucht: 45. Nennen wir es die Overhead-Konstante. Der Overhead eines Voice-Pakets beträgt 16 Byte auf Anwendungsebene (dazu kommen noch 12 Byte IPv4, 8 Byte UDP), ist also viel geringer. Die 45 werden in obiger Formel allerdings pro Voice-Paket gerechnet, weshalb ich das nicht wirklich verstehe.

Aber warum jetzt 527±1? Zu Zeiten von Modem und ISDN gab es eine MTU von 576 Byte (Ethernet hat 1500, PPPoE 1492). Nehmen wir jetzt eine TS-MTU von 528 an und dass Transportschicht-Header nicht Teil davon sind. Nehmen wir außerdem an, dass TeamSpeak IPv6 verwendet. Dessen Headergröße ist 40 Byte, die von UDP 8. 528 und 48 macht zusammen 576 Byte.

Werte für bRoh in Byte/s:

Codecname \ Qualität012345678910
Speex Schmalband (8 kHz)30050075010001400190023003100
Speex Breitband (16 kHz)500750100012501600210026003000350043005300
Speex Ultra-Breitband (32 kHz)550950120014501850235028003200370045005500
CELT Mono (48 kHz)400050006000800012000
Opus Voice5501050155020502600310036004100465051505650
Opus Music9001800270036004500540063007200810090009900

Die Bitrate von Opus ist nicht konstant sondern variabel. Sein Hintergrundrauschen zu übertragen benötigt etwas weniger Bandbreite als beispielsweise zu sprechen oder zu summen. Beim Standard-Opus-Voice-Preset (Qualität 6) wichen die Bitrate beispielsweise um jeweils etwa 250 Byte/s von bOffiziell ab. Vermutlich hat man deshalb die Maximallatenz auf 20 ms festgesetzt, da man keinen exakten Grenzwert angeben kann. Die maximal denkbare nominale Paketgröße d beträgt 243 Byte, bis zur Grenze von 528 Byte ist somit noch genug Platz – sehr viel mehr als an Abweichung realistisch wäre: Im erwähnten Fall waren die Codecdaten je Paket laut obiger Tabelle 72 Byte groß und die genannten Abweichungen betrugen 5 Byte pro Paket. Das entspricht etwa ca. ±7 %, während man selbst bei Opus Music Qualität 10 eine Abweichung bei den Codecdaten um ca. +144 % benötigen würde, um dMax zu erreichen.

Rechteberechnung

Wer die offizielle Dokumentation des Rechtesystems nicht mag (z.B. weil sie zu lang ist) oder gerne ein paar Spezialfälle erklärt bekommen möchte, findet hier meine technisierte Erklärung des Rechtesystems.

Wert

Es gibt fünf Gründe, warum ein Client Rechte haben kann, die der folgenden Liste entsprechend von oben nach unten abgearbeitet werden (sprich der unterste ist der wichtigste).

  1. Servergruppen: siehe dazu den übernächsten Abschnitt zum Negiertflag
  2. Client (Serverebene)
  3. Channel: gilt nicht, wenn ein Skipflag gesetzt wurde
  4. Channelgruppe: gilt nicht, wenn ein Skipflag gesetzt wurde
  5. Client (Channelebene)

Alle folgenden Erklärungen gelten immer nur für ein einzelnes Recht. Für jedes Recht wird einzeln bestimmt, was wirkt.

permoverview und permfind benennen die Tiers nullterminiert.

Skip

Mit Skip werden Channel- und Channelgruppenrechte übersprungen. Um zu bestimmen, ob ein Client nach der Auswertung von Servergruppen- und Server-Clientrechten ein Skipflag bei einem Recht hat, geht man für jedes einzelne Recht wie folgt vor:

  1. Ist ein Clientrecht gesetzt, gilt dessen Skipflag.
  2. Ist kein Clientrecht gesetzt, zählt das Skipflag der wirkenden Servergruppe.
  3. Gibt es Gruppen mit Negiertflag, fallen alle anderen Gruppen weg.
  4. Wirken immer noch mehrere Servergruppen, zählt die Gruppe mit der niedrigsten ID.

Skip überspringt keine Channel-Clientrechte.

Negiert

Normalerweise gilt bei Servergruppen der jeweils höchste Wert.

Ist bei irgendeiner Servergruppe eines Clients das Negiertflag gesetzt, zählen für das Recht nur die Servergruppen mit Negiertflag bei diesem Recht. Von diesen Gruppen wirkt die niedrigste. Dies gilt insbesondere auch dann, wenn Servergruppen ohne Negiertflag niedriger sind als das die niedrigste mit Negiertflag. Damit gilt auch folgender Spezialfall: Hat ein Client nur bei einer seiner Gruppen ein Negiertflag, wirkt diese immer.

Vergabe

Gibt an, wie viel i_client_permission_modify_power man braucht, um ein Recht zu ändern. Das Vergaberecht erhält man, indem man den ersten Buchstaben des Originalrechts durch i_needed_permission_modify_power ersetzt. Da sich das Vergaberecht immer auf sein Originalrecht der dazugehörigen Quelle bezieht, sind Skip und Negiert sinn- und wirkungslos. permget führt die Berechnungen aber trotzdem durch.

b_client_skip_channelgroup_permissions

Wird dieses Recht in den ersten beiden Tiers gesetzt (die Berechnung erfolgt wie zuvor genannt), werden alle Channelgruppen- sowie – entgegen des Namens – alle Channel-Rechte ignoriert. Es funktioniert also genau wie wenn jedes Skip gesetzt wäre.

Widersprechen sich für ein Recht Skip und b_client_skip_channelgroup_permissions, wird stets geskippt.

Query-Verbindung

Verbindungsauf- und abbau

Query benutzt eine einfache TCP-Verbindung. Man kann zwar einen Telnet-Client verwenden, die über das bloße Austauschen von Zeichen herausgehenden Funktionen von Telnet werden jedoch vom TeamSpeak-Server nicht unterstützt.

Wenn man 10 Minuten lang nichts sendet, wird man vom Server geschmissen. YaTQA sendet deshalb alle 5 Minuten 0x0A (neue Zeile) an den Server.

Trennt man die Verbindung regulär mittels TCP und hat einen Server ausgewählt, bekommen die anderen Clients sofort ein Timeout mitgeteilt, auch wenn das nicht stimmt, da man die Verbindung ja normal getrennt hat. Daher sollte man quit verwenden.

Zeichensatz

TeamSpeak unterstützt Unicode nicht richtig. Es wird lediglich UCS-2 unterstützt. Viele Piktogramme, beispielsweise fast alle Smileys, auf denen auch Messenger-Apss wie WhatsApp aufbauen, sind in UCS-2 nicht enthalten.

Offiziellen Angaben zufolge verwendet TeamSpeak UTF-8. Das ist gelogen. TeamSpeaks Handy-Apps verwenden ausdrücklich kein UTF-8 sondern CESU-8. Bis Serverversion 3.0.11.3 akzeptiert TeamSpeak auf diese Weise auch Zeichen, die von UCS-2 nicht abgedeckt werden, kann damit jedoch nicht umgehen und zerstört sich somit die Datenbank, sodass ihr Snapshots von solchen Servern nicht mehr einspielen könnt.
CESU-8 ist ein nachträglich standardisiertes Fehlverhalten von Software, die nur UCS-2 unterstützt und versucht, mithilfe von UTF-16-Surrogates kodierte Zeichen in UTF-8 umzuwandeln. Da UTF-16 und UCS-2 inzwischen nicht mehr dasselbe sind, entsteht statt UTF-8 ein Text in CESU-8. Gibt sich Query-Client einen Namen, der CESU-8-kodierte Zeichen außerhalb von UCS-2 enthält, fliegen alle Clients mit „convert error“ vom Server, auch wenn sie den Query-Client nicht sehen können.

Als Absatzzeichen wird die Folge 0x0A 0x0D benutzt, also die Windows-Folge falschrum. Warum das so ist, ist mir schleierhaft.

Die maximale Länge einer Zeile beträgt (ohne Absatz) 9203 Bytes. Dieses Limit gilt nicht für die 12 Befehle zum Hinzufügen und Entfernen von Rechten sowie serversnapshotdeploy. Es gibt ein paar Befehle, wo das stört.

Bilder

TeamSpeak unterstützt folgende Formate:

bmp
Windows Bitmap
gif
Graphics Interchange Format
jpg, jpeg
Joint Photographic Experts Group
png
Portable Network Graphics (APNG wird nicht unterstützt)
pbm
Portable Bitmap (ASCII und binär)
pgm
Portable Graymap (ASCII und binär)
ppm
Portable Pixmap (ASCII und binär)
xbm
X BitMap
xpm
X PixMap (nur Version 1)

Die Liste gilt für alle Orte, an denen TeamSpeak Bilder unterstützt.

Icons

Icons können nicht animiert sein. Die maximalen Abmessungen betragen 16×16.

Der Dateiname eines Icons ist sein CRC32. Der Algorithmus ist mit dem aus PNG und ZIP identisch. YaTQA ruft deshalb auch einfach die CRC-Funktion in pngdelphi auf. Das Unix-Programm cksum verwendet ein anderes Polynom.

Der Name kann vom Client allerdings frei bestimmt werden. Es gibt Software, die für Icon-Dateinamen Zufallszahlen nimmt. Das ist aber nicht empfehlenswert.

Datentypen

Die Datentypen, die für Icon-IDs verwendet werden, sind nicht einheitlich, sondern je nach Kontext unterschiedlich.

KontextParameterLesenSchreiben
*permlist
*addperm
permsid=i_icon_id value=VorzeichenVorzeichen
clientlist -icon
clientinfo
client_icon_id=Vorzeichennur über clientaddperm
clientdbinfoclient_icon_id=0 (defekt)nur über clientaddperm
serverinfo
serveredit
virtualserver_icon_id=Vorzeichenvorzeichenlos
channellist -icon
channelinfo
channeledit*
channel_icon_idVorzeichenvorzeichenlos*

* = channeledit bewirkt eine semipermanente Änderung, die bei einem Neustart des Servers verloren geht. Benutze lieber die Rechtefunktion.

channelcreate kann keine Icons schreiben (1538 invalid parameter).

Avatare

Die maximalen Abmessungen betragen 300×300.

Der Client lädt den Avatar eines Nutzers immer dann herunter, wenn dessen client_flag_avatar einen neuen Wert erhält. Dies ist der MD5-Hash und kein Flag. Query-Clients, die eine normale UID haben, können ihren eigenen Avatar hochladen und diesen String für sich mit clientupdate setzen.

Die Avatare liegen platt im Channel mit der ID 0 rum. Der Dateiname leitet sich von der Globalen ID des Besitzers ab (nicht von client_flag_avatar). Man dekodiert den Base64-String (also die Globale ID) und stellt diese 20 Bytes ähnlich der Hex-Darstellung dar. Allerdings wird nicht das normale [0-9a-f] sondern [a-p] zum Anzeigen genommen. clientinfo und clientdbinfo geben diese Darstellung als client_base64HashClientUID zurück, eine Bezeichnung die völliger Schwachsinn ist.

Die fremden Avatare können nicht per ftinitupload überschrieben werden, der eigene aber schon, wenn man sich in TS mit „Server Query Login“ einen Account erstellt hat und diesen nutzt. Man kann auch den Avatar auf Servern ändern, die nicht der eigene Heimatserver sind, wenn man mit der UID des Query-Accounts schon mal dort war. Ist der Parameter size als serveradmin größer 0, wird eine Fehlermeldung zurückgegeben. War er 0, stürzte bis Version 3.0.1-pre1 die gesamte Instanz ab.

War ein Benutzer lange Zeit inaktiv und wurde sein Datenbankeintrag gelöscht, ist der Besitzer übrigens auch nicht mehr auffindbar (man kann ja einfach die oben genannte – bijektive – Abbildung rückgängig machen und über die dann erhaltene globale ID die Datenbank-ID und danach widerum die Datenbank-Infos abrufen). Die Avatare bleiben in dem Fall allerdings erhalten und nehmen Platz auf dem Server weg. Seit 3.0.3 kann man Avatare aktiver(!) Benutzer löschen und ab 3.0.5 werden bei der Datenbanksäuberung auch die Avatare inaktiver Benutzer gelöscht. Eine Lösung für Avatare von Benutzern, die vor dieser Aktualisierung (auf Version 3.0.5) wegen Inaktivität gelöscht wurden, bleibt uns TeamSpeak allerdings schuldig.

Beispiel für die Berechnung einer client_base64HashClientUID

Hier ein Beispiel für die Berechnung anhand meiner eigenen UID yGRWD2BOWPC6xSROXoi7U8NAljI=.

UID y G R W ... l j I =
Binär 1 1 0 0 1 0 0 0 0 1 1 0 0 1 0 0 0 1 0 1 0 1 1 0 ... 1 0 0 1 0 1 1 0 0 0 1 1 0 0 1 0 0 0
Dezimal 12 8 6 4 5 6 ... 9 6 3 2
Hex C 8 6 4 5 6 ... 9 6 3 2
Datei m i g e f g ... j g d c

Der Algorithmus ist somit auch problemlos umkehrbar.

Schnappschüsse

Schnappschüsse enthalten am Anfang der Datei einen Hash. Hierbei handelt es sich um einen SHA1-Hash der restlichen UTF-8-kodierten Daten (ohne Absatz am Ende).

Beim Einspielen von Schnappschüssen laufen intern offenbar normale Query-Befehle ab. Werden diese geändert, kommt es zu Fehlern. Packt man beispielsweise serveradmin in eine Servergruppe, kann ein solcher Schnappschuss auf neueren Servern nicht mehr eingespielt werden, die es serveradmin mehr erlauben, einer Servergruppe beizutreten. Da er bestehende Mitgliedschaften nicht kontrolliert werden, produzieren Server, die nach dem Hinzufügen von serveradmin zu einer Servergruppe aktualisiert wurden, ungültige Schnappschüsse.

Client-Cache

Die Benennung der Unterordner von cache und chats ist die in Base64 kodierte Server-UID, welche an sich bereits Base64-kodiert ist. Durch die erneute Kodierung können die nicht alphanumerischen Zeichen 62 und 63 nicht mehr auftreten. Damit wird verhindert, dass Zeichen 63 (Schrägstrich) zu ungültigen Dateinamen führt. Für Zeichen 63 müssten nämlich in der Binärkodierung des ursprünglichen Base64 in ASCII sechs Einsen aufeinanderfolgen können, es gibt aber nicht einmal die Möglichkeit für fünf Einsen hintereinander, sodass auch das Plus nicht auftreten kann.

In den Unterordnern befinden sich bei cache Avatare (clients) und Icons (icons). Bei den Chats befinden sich private Chats im Unterordner clients. Die dortigen Dateinamen sind die ebenfalls (ein weiteres Mal) in Base64-kodierten UIDs der Gesprächspartner. Bei reinen Query-Accounts wird entsprechend einfach serveradmin oder ServerQuery in Base64 kodiert, da es sich dabei um die UIDs handelt.

TXT-Chatlogs enthalten nur Chats und dazugehörigen Informationen, HTML-Dateien hingegen alle möglichen Benachrichtigungen aus dem Log. Da den HTML-Dateien ein Header (und auch sonst alles außer dem Inhalt) fehlt, musst du deinen Browser ggf. manuell auf UTF-8 stellen, um sie zu lesen. Bilder zu Beginn der Zeilen werden fehlen.

BBcode

Ein vor die öffnende eckige Klammer gestelllter Backslash verhindert das Parsen des darauffolgenden Tags.

Inline-Elemente

[b]Text[/b]
fett
[i]Text[/i]
kursiv
[u]Text[/u]
unterstrichen
[color=X]Text[/color]
Farbe (siehe unten)
[url=URL]Text[/url]
[url]URL[/url]
Link

Block-Elemente

Block-Elemente können nur in Channelbeschreibungen verwendet werden.

[hr]
Horizontale Trennleiste
[size=X]Text[/size]
Ändert die Größe zu einer bestimmten Höhe in Punkten (siehe unten).
[img]URL{/img]
Bild
[left]Text[/left]
linksbündig
[center]Text[/center]
zentriert
[right]Text[/right]
rechtsbündig
[list][*]Text[/list]
Liste (Schachtelung möglich)

(Wird noch ergänzt.)

Namen sind in UTF-8 zu kodieren und anschließend URL-Encoding zu verwenden. Яedeemer + Kiwi wäre also %D0%AFedeemer%20%2B%20Kiwi. Client-UIDs (nicht jedoch Server-UIDs!) werden unverändert übernommen, selbst wenn sie URL-Encoding haben müssten.

client://{Client-ID}/{Client-UID}~{Name}
Client-ID: Client-ID im Serverbaum, 0 beim Einfügen in Channelbeschreibungen.
Client-UID: Globale ID des Clients
Name: Name. Keine Ahnung, was das soll.
Diese Links können durch Drag und Drop von Clients in Eingabefelder erstellt werden.
channelid://{Channel-ID}
Channel-ID: Channel-ID, 0 für Server
ts3file://{Serveraddresse}?port={Serverport}&serverUID={ServerUID}&channel={ChannelID}&path={Pfad mit Schrägstrich am Ende und Anfang}&filename={Dateiname}&isDir={0=Datei, 1=Ordner}&size={Größe in Bytes}&fileDateTime={Änderungsdatum, Unix-Timestamp}
Keine Ahnung, wofür man das alles braucht. Man kann diesen Link extern verwenden, es öffnet sich aber lediglich der TeamSpeak-Client. Mehr passt nicht.
ts3image://
Wird noch ergänzt.

Diese werden bei Installation von TeamSpeak in der Registry angelegt.

ts3server://{Serveradresse}?port={Serverport}&nickname={Nickname}&password={Serverpasswort}&channel={Channel-Name}&cid={Channel-ID}&channelpassword{Channel-Passwort}&token={Token}&addbookmark={Favoriten-Name}
Nickname: Namen des Benutzers setzen, den dieser auf dem Server haben soll, wenn er sich mit dem Link verbindet
...
Channel-ID: Laut TeamSpeak-FAQ geht die Channel-ID vor, wenn sowohl sie als auch der Channel-Name angegeben ist.
...

(Quelle)

Der notwendige Grad des Escapings unterscheidet sich zwischen intern und extern: Und-Zeichen werden mit vorangestelltem Backslash escapet. Zwingend zu escapen sind für externe Programme (oder beim Einfügen in Windows+R) nur in UTF-8 zu kodierende Zeichen (UTF-8 allein ohne Escaping funktioniert nicht), Prozentzeichen und Und-Zeichen. Auch die Escape-Sequenz des Und-Zeichens muss selbst nicht noch in URL-Encoding escaped werden. Innerhalb des TeamSpeak-Clients muss aber zumindest das Und-Zeichen escapet werden, eventuell auch noch weitere. Zudem erkennt der Client keine intern verwendeten Links mit nicht escapeten Leerzeichen (auch nicht mit URL-Tag), die man bei einem externen Aufruf weglassen kann, wenn man Anführungszeichen als umschließende Quantifizierer verwendet. Wird der TeamSpeak-Client neu gestartet, verschwinden allerdings die Quantifizierer und solche Links funktionieren nicht mehr, obwohl der Client sich neu verbindet. Die Nutzung als Quantifizierer, die man beim Aufruf eines Links nicht so einfach verhindern kann, dürfte auch der einzige Grund sein, warum Anführungszeichen überhaupt zu escapen sind. Links, die nicht zu quantifizieren sind, dürften als direkte Parameter des Prozesses nicht erfordern, dass Anführungszeichen escapet werden.

Zeichenextern/minimalintern minimalFreund einladen
LeerzeichenLeerzeichen%20%20
!!!%21
"%22" oder %22%22
#%23#%23
$$$%24
%%25%25%25
&\& oder %26%26 oder \%26%5C%26
'''%27
(((%28
)))%29
***%2A
+++%2B
,,,%2C
/ (Name)\/ oder \\/\/ oder \\/%5C%5C%2F
/ (Trenner)//%2F
:::%3A
;;;%3B
===%3D
???%3F
@@@%40
[[[%5B
\\\%5C%5C
]]]%5D
{{{%7B
|||%7C
}}}%7D
UCS-2ist verpflichtend in UTF-8 zu kodieren und mit % zu escapen

Zum Schrägstrich: Der mit „Name“ bezeichnete Schrägstrich ist Teil eines Channelnamens. Der als „Trenner“ bezeichnete Schrägstrich trennt Channel und Subchannel. Channelnamen sind nur pro Ebene eindeutig.

Das Anführungszeichen nicht zu escapen bricht automatisch erkannte Links an dieser Stelle ab. Manuell erzeugter BBCode funktioniert. Er scheint Zeichen zu geben, bei denen das umgekehrt ist. Die obige Tabelle bezieht sich zunächst einmal auf die automatische Erkennung.

YaTQA verwendet das extern-minimale-System aus der ersten Spalte.

Farben

Als Schreibweise eignen sich #123456 und #123 sowie folgende Namen:

FarbnameFarbrepäsentation
aliceblue
antiquewhite
aquamarine
azure
beige
bisque
black
blanchedalmond
blue
blueviolet
brown
burlywood
cadetblue
chartreuse
chocolate
coral
cornflowerblue
cornsilk
cyan
darkblue
darkcyan
darkgoldenrod
darkgray
darkgreen
darkgrey
darkkhaki
darkmagenta
darkolivegreen
darkorange
darkorchid
darkred
darksalmon
darkseagreen
darkslateblue
darkslategray
darkslategrey
darkturquoise
darkviolet
deeppink
deepskyblue
dimgray
dimgrey
dodgerblue
firebrick
floralwhite
forestgreen
gainsboro
ghostwhite
gold
goldenrod
gray
green
greenyellow
grey
honeydew
hotpink
indianred
ivory
khaki
lavender
lavenderblush
lawngreen
lemonchiffon
lightblue
lightcoral
lightcyan
lightgoldenrodyellow
lightgray
lightgreen
lightgrey
lightpink
lightsalmon
lightseagreen
lightskyblue
lightslategray
lightslategrey
lightsteelblue
lightyellow
lime
limegreen
linen
magenta
maroon
mediumaquamarine
mediumblue
mediumorchid
mediumpurple
mediumseagreen
mediumslateblue
mediumspringgreen
mediumturquoise
mediumvioletred
midnightblue
mintcream
mistyrose
moccasin
navajowhite
navy
oldlace
olivedrab
orange
orangered
orchid
palegoldenrod
palegreen
paleturquoise
palevioletred
papayawhip
peachpuff
peru
pink
plum
powderblue
purple
red
rosybrown
royalblue
saddlebrown
salmon
sandybrown
seagreen
seashell
sienna
silver
skyblue
slateblue
slategray
slategrey
snow
springgreen
steelblue
tan
thistle
tomato
turquoise
violet
wheat
white
whitesmoke
yellow
yellowgreen

Vor (nicht eingeschlossen) Clientversion 3.0.0 gab es wesentlich mehr Farben, basierend auf den X11-Farbnamen. Die meisten dieser wurden mit genanntem Update entfernt, sodass nur noch die W3C-Farbnamen blieben.

Schriftgrößen

Mit Clientversion 3.0.3 wurde die BBcode-Interpretation geändert, nämlich von HTML-Größeneinheiten wie in <font size="X"> zu Punkten (<span style="font-size:Xpt;">).

Die angekündigte Legacy-Interpretation [size=+X], X ∈ {1, ..., 7}, funktioniert nicht. Fängt der Parameter mit + an, wird die Schriftgröße zurückgesetzt, egal was danach kommt (ob gar nichts, eine Zahl, ein kleiner Roman, ...).

Größen von Clients vor (nicht eingeschlossen) Clientversion 3.0.3 (erste Spalte):

alt (HTML)Pixelneu (Punkt)
-19px7pt
andere negative Werte8px6pt
08px6pt
18px6pt
29px7pt
311px (Standard)8pt
413px10pt
517px13pt
622px17pt
andere positive Werte26px19~20pt
+ gefolgt von irgendwas11px (Standard)8pt

Da die Größen einer Pixelgröße entsprechen, die etwas genauer als die dann eingeführten Punktgrößen sind, ist im Falle von HTML-Größe 7 keine verlustfreie Umrechnung in das Punkt-System möglich!