Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird das Feature VML beschrieben, das seit Windows Internet Explorer 9 veraltet ist. Webseiten und Anwendungen, die auf VML basieren, sollten zu SVG oder anderen umfassend unterstützten Standards migriert werden.
Hinweis
Dieser Artikel wurde im Dezember 2011 archiviert. Daher wird er nicht mehr aktiv verwaltet. Weitere Informationen finden Sie unter Archivierte Inhalte. Informationen, Empfehlungen und Anleitungen zur aktuellen Version von Windows Internet Explorer finden Sie unter Internet Explorer Developer Center.
Contents
Einführung
Dieser Vorschlag verwendet eine kleine Anzahl grundlegender Typen, die in der folgenden Tabelle aufgeführt sind.
| Typ | Element | Grundlegende Darstellung | Beschreibung |
|---|---|---|---|
| boolean | 1 Bit | Boolescher Wert: wahr oder falsch. | |
| Bruch | Zahl 2 6 | Ein numerischer Wert, skaliert um 2 6 (65536) und als signierte ganze Zahl gespeichert. | |
| Ordinate | 30-Bit-Ganzzahl plus Vorzeichen | Teil einer Koordinate (z. B. in einem Pfad), die durch „coord“ definierten Werte. | |
| length | EMU | Eine physische Länge, z. B. die Breite einer Linie oder die Größe einer Schriftart. | |
| Measure | EMU oder Zahl 2 6 | Eine physische Länge, einschließlich einer Anzahl von Gerätepixeln, oder ein Bruchteil einer anderen Menge. | |
| Winkel | Grad 2 6 | Ein Winkel; positiv ist im Uhrzeigersinn. | |
| color | c | complex | Ein Element, mit dem eine Farbe abgeleitet werden kann. |
| Schriftart | Schriftart | complex | Eine Beschreibung einer Schriftart. |
| Bitmap | Bitmap | href | Ein Verweis auf eine externe Bilddatei. |
| vector | v | complex | Eine Beschreibung eines Vektorpfads |
Die „grundlegende Darstellung“ ist die präziseste Darstellung, deren Beibehaltung der Vorschlag von einer konformen Implementierung erfordert; Daten gehen verloren, wenn die Implementierung die Daten nicht mit der erforderlichen Genauigkeit darstellen kann. Die Farb-, Schriftart- und Vektortypen entsprechen Elementen, die selbst Struktur haben – in gewisser Weise sind sie keine grundlegenden Typen; es ist jedoch praktisch, sie in diesem Vorschlag als solche zu behandeln.
Jeder nicht komplexe Basistyp weist ein zugeordnetes Element mit demselben Namen auf. Diese Elementnamen sind reserviert und dürfen nicht für andere Zwecke innerhalb von Erweiterungen verwendet werden, auch wenn sich die Verwendung innerhalb eines onview="skip"-Erweiterungselements befindet. Aus diesem Grund ist es möglich, dass eine Implementierung, die auf eine unbekannte XML stößt, einen effizienten internen Speicher der unbekannten XML bereitzustellen, solange die Werte in die „Typ“-Elemente eingeschlossen sind.
<new:tag>1.578</new:tag>
<new:tag><v:fraction>1.578</v:fraction></new:tag>
Im ersten Beispiel oben muss die Zeichenfolge „1.578“ als Abfolge von Zeichen gespeichert werden (die Implementierung weiß nicht, ob es sich um eine Zeichenfolge oder eine Zahl handelt); im zweiten Beispiel gibt das Bruchelement an, dass der Inhalt eine Zahl ist, daher kann es in die hochpräzise Bruchdarstellung konvertiert werden.
Komplexe Typen (einschließlich Bitmap) verfügen über zugeordnete Elementnamen, die zum Trennen des Werts verwendet werden. Dadurch wird die Analyse vereinfacht, indem sichergestellt wird, dass die komplexeren Analyseaufgaben eindeutigen Elementtags zugeordnet sind.
Zurück nach obenboolean
boolean
<!entity % boolean "#pcdata" -- or nmtoken in an attribute -- >
Ein boolescher Wert wird als Schlüsselwort dargestellt, das den Status der Kennzeichnung angibt. Die folgenden Schlüsselwörter sind definiert.
| Wert für „true“ | Wert für „false“ |
|---|---|
| true | false |
| ja | Nein |
| on | aus |
| t | f |
| 1 | 0 |
Eine Implementierung kann einen beliebigen Wert schreiben und muss alle Werte erkennen. Eine Implementierung kann Werte von einer Darstellung in eine andere ändern.
fraction
fraction
<!entity % fraction "#pcdata" -- or nmtoken in an attribute -- >
Alle numerischen Werte (d. h. Werte von dimensionslosen Mengen) innerhalb dieses Vorschlags können als ganze Zahlen gespeichert werden, indem sie um 2 6 (65536) skaliert werden. Eine Zahl kann entweder in dieser Form mit dem Suffix f oder als Dezimalzahl ohne Suffix angegeben werden. Somit stellen die folgenden hypothetischen Elemente denselben Wert dar.
<fillwidth>0.25</fillwidth>
<fillwidth>16384f</fillwidth>
Eine Menge mit dem Suffix „f“ muss eine ganze Zahl sein; Bruchzahlen sind nicht zulässig. Die resultierende ganze Zahl muss als 32-Bit-Zweierkomplement mit Vorzeichen darstellbar sein; somit beträgt der effektive Bereich der Darstellung 32768 (um genau zu sein, kleiner als 32768 und größer als oder gleich -32768.)
Eine konforme Implementierung ist erforderlich, um Werte beizubehalten, die als f-Werte ausgedrückt werden. Werte, die als Dezimalzahlen dargestellt werden, können in einen f-Wert konvertiert und auf diese Weise gespeichert werden. Eine Anwendung darf intern generierte Werte in jeder geeigneten Einheit aufzeichnen; ein aus einem vorhandenen Dokument gelesener Wert muss jedoch entweder in der vollständigen ursprünglichen Genauigkeit beibehalten oder in einen f-Wert konvertiert werden.
Wenn die Implementierung dies nicht tun kann, muss sie den Benutzer warnen, dass möglicherweise Daten verloren gehen. (Es ist akzeptabel, eine solche Warnung einmal ausstellen, wenn extern generierte Daten zum ersten Mal gefunden werden.)
Wenn ein Dezimalwert in das f-Format konvertiert wird, kann die Implementierung jeden arithmetischen Rundungsmodus verwenden; eine ganze Zahl muss jedoch genau in das f-Format konvertiert werden. Es wird empfohlen, dass Implementierungen durch Runden auf minus unendlich konvertieren und dass die Konvertierung immer genau ist.
Ordinate
ordinate
<!entity % ordinate "#pcdata" -- or nmtoken in an attribute -- >
Die Einheiten des Koordinatensystems, das durch „coord“ festgelegt wird, weisen einen nominalen Typ auf, der als Ordinate bezeichnet wird. Dies ist ein Längenmaß, aber es wird nur in Bezug auf das Rechteck verwendet, das „coord“ etabliert. Jeder Wert des Typs Ordinate wird durch die Werte w und h des „coord“ und des resultierenden Verhältnisses skaliert, mit dem eine tatsächliche Messung auf dem Ausgabegerät hergestellt wird.
Eine konforme Implementierung muss in der Lage sein, Ordinatenwerte von bis zu 30 Bit plus Vorzeichen (d. h. eine 31-Bit-Ganzzahl mit Vorzeichen, keine 32-Bit- und keine 32-Bit-ganzzahlige Vorzeichen) zu verarbeiten. Es wird jedoch empfohlen, dass Implementierungen versuchen, Koordinaten für Pfade und ähnliche Elemente mit etwa 16 Bit Genauigkeit zu erzeugen. Dadurch wird die Wahrscheinlichkeit eines Unterlaufs oder eines Überlaufs in einer nicht konformen Implementierung minimiert.
Ordinatenwerte sind immer integral. Ein Dezimalpunkt (Dezimalkomma) wird möglicherweise nicht in einem Wert vom Typ Ordinate angezeigt. Es können keine Einheitenbezeichner an Werte des Typs Ordinate angefügt werden.
length
length
<!entity % length "#pcdata" -- or nmtoken in an attribute -- >
Eine Länge ist eine reale Messung oder manchmal eine Maßeinheit in Gerätepixeln. Es wird empfohlen, dass Implementierungen die Verwendung von Gerätepixeln (px) vermeiden.
Alle standardmäßigen CSS1-Einheitenqualifizierer sind für eine Länge zulässig. Darüber hinaus kann der Qualifizierer „emu“ verwendet werden. Dieser Qualifizierer bezieht sich auf eine Einheit – die EMU (Englische Metrische Einheit) – die ein gängiger Nenner der Messgrößen ist, die in Computergrafiken weit verbreitet sind. Die EMU ist Zoll / 914400, d. h. es gibt 914400 EMU pro Zoll. In der folgenden Tabelle ist die Anzahl der EMUs in einer kleinen Anzahl häufig auftretender Einheiten aufgeführt.
| Anzahl der EMUs | Zahl pro Zoll | Zahl pro Millimeter | Beschreibung |
|---|---|---|---|
| 360 | 0.01 | Win32 HIMETRIC | |
| 12700 | 72 | "point" | |
| 635 | 1440 | Win32 TWIP | |
| 762 | 1200 | Hochauflösender Drucker |
Bruchzahlen von EMUs sind nicht zulässig. Jedes Maß muss als eine ganze 32-Bit-Zahl mit Vorzeichen von EMUs dargestellt werden – dies begrenzt die Größe eines Maßes auf 2348 Zoll – etwa 59 Meter oder 65 Yards. Da die Maße immer auf die Größe eines Renderings auf einem nominalen Ausgabegerät für Bildschirm- oder Seitengröße verweisen, befinden sie sich immer innerhalb dieses Bereichs.
Beachten Sie jedoch, dass die Darstellung für reale Messungen ungeeignet ist und dass, wo diese aufgezeichnet werden (z. B. um die reale Größe eines Pfads aufzuzeichnen), eine andere Darstellung verwendet werden muss.
Eine konforme Implementierung muss Werte beizubehalten, die eine genaue Anzahl von EMUs sind. Auf andere Weise dargestellte Werte können in einen EMU-Wert konvertiert und auf diese Weise gespeichert werden. Eine Anwendung darf intern generierte Werte in jeder geeigneten Einheit aufzeichnen; ein aus einem vorhandenen Dokument gelesener Wert muss jedoch entweder in der vollständigen ursprünglichen Genauigkeit beibehalten oder in einen EMU-Wert konvertiert werden.
Wenn die Implementierung dies nicht tun kann, muss sie den Benutzer warnen, dass möglicherweise Daten verloren gehen. (Es ist akzeptabel, eine solche Warnung einmal ausstellen, wenn extern generierte Daten zum ersten Mal gefunden werden.)
In der Praxis werden physische Längen für relativ wenige Messungen in diesem Vorschlag verwendet. Die Daten, die normalerweise am wichtigsten sind, sind die Pfaddaten, und diese werden im Koordinatensystem codiert, das auf einer Pro-Form-Basis von „coord“ definiert wird.
Alternative Darstellungen
Die standardmäßigen Längendarstellungen von HTML werden durch CSS1 definiert. Relative Einheiten, mit Ausnahme des Pixels, sind im Kontext, in dem Längen in diesem Vorschlag verwendet werden, nicht sinnvoll und dürfen nicht verwendet werden. Wenn das Dokument die beabsichtigte Pixelgröße (Ziel) aufzeichnet, definiert dies die Übersetzung von Pixeln in EMU; andernfalls sollte der von CSS1 definierte Standardwert von 90 DPI verwendet werden.
Mit Ausnahme der EMU kann jeder Wert als Dezimalbruch angegeben werden. Wenn ein Dezimalwert in EMU konvertiert wird, kann die Implementierung einen beliebigen arithmetischen Rundungsmodus verwenden. (Die einzige Möglichkeit für eine Erstellungsanwendung, um ein bestimmtes Ergebnis zu garantieren, besteht darin, es in EMU anzugeben.)
Wenn kein Einheitenbezeichner in einem Längenwert angegeben wird, muss die Implementierung von EMU ausgehen.
Measure
measure
<!entity % measure "#pcdata" -- or nmtoken in an attribute -- >
Bei einem Measure handelt es sich um eine Menge, die entweder eine Länge oder eine Bruchzahl sein kann. Dies ähnelt stark den HTML- und CSS-Längenmaßen, die in vielen Fällen physische Messungen oder Prozentsätze anderer Mengen sein können. Wenn kein Einheitenbezeichner angegeben wird, muss der Wert als Dezimalbruch angenommen werden (daher wird dieses Verhalten von Bruch geerbt, nicht von der Länge.)
Im Gegensatz zur Länge hat ein Pixelwert eine kontextdefinierte Bedeutung, sodass die Konvertierung in emu normalerweise unangemessen ist. Es gibt drei mögliche grundlegende Darstellungen, die die Implementierung beibehalten muss (d. h. eine Darstellung kann nicht ohne Informationsverlust in eine andere konvertiert werden).
- Ein Bruchwert sollte im Bruch-Format beibehalten werden (ein „f“-Wert).
- Eine physische Länge sollte in der EMU beibehalten werden.
- Ein Pixelwert sollte als ganze Anzahl von Pixeln beibehalten werden.
Bruchzahlen von Pixeln sind nicht zulässig.
Alternative Darstellungen
Alle alternativen Darstellungen von Bruch und Länge sind zulässig.
angle
angle
<!entity % angle "#pcdata" -- or nmtoken in an attribute -- >
Die grundlegende Darstellung eines Winkels ist eine Anzahl von Grad, die mit 2 6 (65536) multiziert und als ganze Zahl gespeichert wird. Da der Koordinatenraum invertiert ist (positive Y-Achse ist nach unten), ist ein Winkel im Uhrzeigersinn positiv. Eine konforme Implementierung ist erforderlich, um die volle Genauigkeit eines solchen Werts beizubehalten.
Eine Implementierung darf einen beliebigen Bereich für Winkel verwenden und einen Winkel normalisieren (z. B. -180 bis +180 oder 0 bis 360). Implementierungen müssen nicht konsistent sein; die integrale Darstellung eines Winkels darf jedoch den Bereich einer ganzen 32-Bit-Zahl mit Vorzeichen nicht überschreiten.
Das Suffix fd wird verwendet, um diese Darstellung eines Winkels (Bruchgrad) zu identifizieren. Beachten Sie, dass sich dies von dem Suffix f für einen dimensionslosen Bruch unterscheidet, obwohl identische Arithmetik verwendet werden kann, um es zu unterstützen. Der Standardwert für einen Winkelwert ist einfache Grad, d. h. ein nicht skalierter Wert. Dies kann auch mit dem Suffix „ “ (das Gradsymbol) signalisiert werden; dies hängt jedoch davon ab, dass eine geeignete Dokumentcodierung vorhanden ist - folglich wird das Suffix deg auch auf mittlere Grad definiert. Der vollständige Satz möglicher Suffixe lautet wie folgt.
| Suffix | Umrechnungsfaktor | Kommentare |
|---|---|---|
| fd | 1 | Präzise interne Darstellung |
| none, deg, | 65536 | Degrees |
| rad | 65536pi/180 | Radians |
Alternative Darstellungen
Die Skalierungstransformation hat Diskontinuitäten bei ungeraden Vielfachen von 45 . Daher ist es äußerst wichtig, dass die Umwandlung einer ungenauen Menge gut definiert ist. Aus diesem Grund ist die Arithmetik der Konvertierung so definiert, dass sie auf minus Unendlichkeit gerundet wird.
Da dies in einigen Implementierungen möglicherweise schwierig oder unmöglich ist, ist die Verwendung der folgenden Funktionen als Feature der Ebene 3 definiert:
- Jeder Bruchgradwert.
- Jeder Bogenmaßwert
Daher müssen als fd qualifizierte Werte und unqualifizierte integrale Werte oder als deg qualifizierte integrale Werte oder genau durch eine konforme Implementierung der Stufe 0 behandelt werden; andere Werte müssen dies nicht. Es wird dringend empfohlen, dass jede Implementierung die Konvertierung von einem Bruchgradwert in einen skalierten (fd)-Gradwert genau behandelt. Dies kann ohne Gleitkommaunterstützung erfolgen.
Die genaueren Anforderungen für die Konvertierung unterscheiden fd von f.
color
c
<!element c %color;>
Farben sind ein wesentlicher Bestandteil moderner Computergrafiken. Der Vorschlag verwendet die etablierten Methoden zum Angeben fester Farben. Farben in Diagrammen sind jedoch selten einfache statische Farben; sie werden häufig von anderen Elementen im Diagramm abgeleitet. Viele dieser Informationen sind sehr anwendungsspezifisch, daher bietet dieser Vorschlag zwei sehr grundlegende Mechanismen zur Angabe dieses Verhaltens:
- Eine Farbe kann von einer anderen Farbe in derselben Form abgeleitet werden.
- Eine kleine Anzahl von arithmetischen Vorgängen wird zum Ableiten oder Ändern einer Farbe definiert.
Der Prototypformmechanismus ergänzt dies, indem Prototypen definiert werden können, von denen Farben geerbt werden können.
color
<!entity % color "( %color-unit; | pure | %color.adjustment; )*">
Ein Farbwert ist ein Superset der CSS1-Farbdefinition . Mit den Erweiterungen kann der RGB-Farbwert aus anderen Farben innerhalb der Form oder aus einem allgemeinen Farbschema bestimmt werden, das mithilfe von CSS1 definiert wird.
Wenn der Wert eines Elements als Farbe definiert ist, definiert der Inhalt eines Elements den Farbwert mithilfe eines einzelnen Farbtokens, optional durch einen arithmetischen Vorgang in der entsprechenden RGB-Farbe geändert.
Farbeinheiten
Der vollständige Satz von Farbtoken stammt aus einer Vielzahl von Quellen: HTML, CSS1 und diesem Vorschlag. Sie werden wie folgt mithilfe der Notation aus CSS1 oder der für die XML-Verknüpfung definierten XPointer-Notation definiert.
In den XPointer-Definitionen ist die Speicherortquelle das Element, das den Farbwert enthält, und der Ausdruck verweist auf den gesamten Elementsatz der Form, als ob alle Basisprototypelemente mit der Form zusammengeführt wurden. Wenn das entsprechende Element nicht vorhanden ist, wird der Standardwert für dieses Element an seiner Stelle verwendet.
| Color | Definition | Ebene | Beschreibung |
|---|---|---|---|
| name | Siehe unten | 0 | HTML-Farbname, wie in der folgenden Tabelle aufgeführt. |
| #rr'gg'bb' | #rr'gg'bb' | 0 | Standardmäßige CSS1/sRGB-Farbdarstellung mit Werten im Bereich 0..255 dargestellt mit jeweils 2 Hexadezimalziffern. |
| #rgb | #rrggbb | 1 | Gekürzte CSS1-Form mit nur drei hexadezimalen Ziffern. |
| rgb(r,g,b) | #(r)(g)(b) | 1 | CSS1-rgb-Form; die Elemente des RGB-Werts werden wie in CSS1 definiert konvertiert. |
| fill | ancestor(1,shape) child(1, fill) child(1, color) |
1 | Die Vordergrundfüllfarbe der Form. |
| fillBack | ancestor(1,shape) child(1, fill) child(1, back) child(1, color) |
1 | Die Hintergrundfarbe der Formfüllung. |
| line | ancestor(1,shape) child(1, line) child(1, color) |
1 | Die Vordergrundlinienfarbe der Form. |
| lineBack | ancestor(1,shape) child(1, line) child(1,back) child(1, color) |
1 | Die Hintergrundlinienfarbe der Form. |
| lineOrFill | line, fill | 1 | Der Linienwert, wenn nicht standardmäßig, andernfalls der Füllwert. Dadurch wird die Farbe, die sich am Rand der Form befindet, effektiv zurückgegeben. |
| fillThenLine | fill, line | 1 | Der Füllwert, falls nicht standardmäßig, andernfalls der Linienwert. Dadurch wird die Hauptformfarbe effektiv zurückgegeben (wenn die Form nicht ausgefüllt ist, ist das Ergebnis die Linienfarbe). |
| shadow | ancestor(1,shape) child(1, shadow) child(1, color) |
2 | Die Farbe des Schattens (dies ist ein Feature der Ebene 2). |
| scheme | Siehe unten | 1 | Eine Schemafarbe aus dem für das Dokument definierten Schema; siehe unten. |
| scheme(index) | Siehe unten | 1 | Schemafarbindex, beginnend bei 0; siehe unten. |
| this | Impliziert | 2 | Der Vorgang (Ausfüllen oder Zeichnen eines Pfads) wird auf andere Weise definiert (z. B. als Bitmap), und die Farbe gibt eine „Änderung“ an den Farben an, die so impliziert sind. |
| palette(index) | Impliziert | 3 | Verhält sich auf die gleiche Weise wie dies, mit der Ausnahme, dass genau ein Eintrag in einer Bitmapfarbtabelle identifiziert wird. Nur zulässig, wenn explizit angegeben. |
| Keine | - | 2 | Gibt das Fehlen einer Farbe an; kann verwendet werden, um einen Zeichnungsvorgang abzubrechen, der die Farbe verwendet. |
| system | Siehe unten | 3 | Eine Farbe, die von der Benutzeroberfläche des Systems definiert wird. |
Diese Farbe ermöglicht es einem Farbwert, eine Änderung an einer Farbe anzugeben, die auf andere Weise abgeleitet wird. Insbesondere kann ein einzelner Vorgang für alle Farben in einer Bitmap angegeben werden. Die palette(index)-Farbe identifiziert einen bestimmten Eintrag in einer palettenzugeordneten Bitmap. Dies ist nur für die Aufzeichnung eines Farbtabelleneintrags definiert, der in einer solchen Bitmap als transparent angesehen werden sollte.
Die Definition eines Farbwerts darf sich nicht direkt oder indirekt auf sich selbst beziehen. Wenn eine solche Definition gefunden wird, wird empfohlen, es ist aber nicht erforderlich, dass die Implementierung den nicht definierten Wert als Schwarz behandelt.
HTML-Farben
HTML definiert die folgenden sechzehn Farbnamen:
Farbnamen und sRGB-Werte
Schwarz = "#000000"
Grün = "#008000"
Silber = "#C0C0C0"
Lindgrün = "#00FF00"
Grau = "#808080"
Olivgrün = "#808000"
Weiß = "#FFFFFF"
Gelb = "#FFFF00"
Kastanienbraun = "#800000"
Marineblau = "#000080"
Rot = "#FF0000"
Blau = "#0000FF"
Lila = "#800080"
Blaugrün = "#008080"
Fuchsia = "#FF00FF"
Türkis = "#00FFFF"
Schemafarben
Die Schemafarben, auf die nach Schema verwiesen wird, werden auf Dokumentebene mithilfe des Metatags mit einem Namensattribut von „Theme Color Scheme“ definiert.
<meta name="Theme Color Scheme"
content="rrggbb, rrggbb, rrggbb, rrggbb, rrggbb, rrggbb, rrggbb, rrggbb">
Mit diesem Tag können bis zu acht Schemafarben definiert werden. Nicht definierte Farben sollten standardmäßig schwarz sein. Mit den Schemafarben kann das Farbschema, das für ein vollständiges Dokument verwendet wird, nur geändert werden, indem der Inhalt des Designfarbschemas geändert wird. Um sicherzustellen, dass Grafiken, die aus unterschiedlichen Erstellungsanwendungen importiert wurden, die Schemafarben einheitlich verwenden, werden die folgenden Interpretationen definiert. Die „Nutzung“ ist eine kurze Beschreibung des Zwecks, und die Spalte „Beschreibung“ enthält zusätzliche Details.
| Index | Name | Verwendung | Beschreibung |
|---|---|---|---|
| 0 | scheme.background | Hintergrund | Die Farbe, die für den Hintergrund einer Grafik verwendet wird (und häufig für die gesamte Seite). |
| 1 | scheme.text | Text und Linien | Die Farbe für Text, der an eine Form angefügt ist, und die Standardlinienfarbe. |
| 2 | scheme.shadow | Schatten | Standardschattenfarbe – die Farbe, die in der Regel für Formenschatten verwendet wird. |
| 3 | scheme.title | Titeltext | Die Farbe, die für Überschriften- oder Titeltext verwendet werden soll. |
| 4 | scheme.fill | Füllungen | Standardfüllfarbe – die Farbe, die normalerweise zum Ausfüllen von Formen verwendet wird. |
| 5 | scheme.accent | Akzent | Normale „Hervorhebungsfarbe“, die verwendet wird, um ein wichtiges Element einer Grafik hervorzuheben. |
| 6 | scheme.hyperlink | Akzent und Link | Hervorhebungsfarbe, die für Links verwendet wird. Kann für andere Zwecke verwendet werden, bei denen die Farbe einen Link zu anderen Informationen kennzeichnet. |
| 7 | scheme.followed | Akzent und gefolgter Link | Hervorhebungsfarbe für gefolgte Hyperlinks; auch für „Rückwärts“-Links geeignet. |
Eine Schemafarbe kann entweder anhand des Namens oder des Indexes bezeichnet werden, somit sind scheme.fill und scheme(4) dieselbe Farbe.
Schemafarben nehmen nicht am Standardschema teil, wenn keine Farbe angegeben ist. Eine nicht angegebene Füllfarbe muss unabhängig von der Farbe der Schemafarbe 4 immer als weiß interpretiert werden. Die Akzentfarben sollten sowohl mit der Hintergrundfarbe (0) als auch mit den Füllfarben (4) kontrastieren, und Text- und Titeltextfarben sollten dieselbe Eigenschaft aufweisen. Eine Standardtechnik besteht darin, die Akzente farbig und den Standardtext farblos zu gestalten (in der Regel schwarz oder weiß).
Systemfarben
Anwendungen zeichnen manchmal Farben basierend auf den Betriebssystemeinstellungen in Grafiken auf. Normalerweise sind diese vorübergehend und müssen nicht ausgeschrieben werden; die Systemfarbdefinitionen sind ausschließlich zur Unterstützung dessen vorhanden. Es wird eine Systemfarbe eingeführt, indem ein geeignetes Tag in einem neuen Namespace definiert und die entsprechenden Informationen in den Elementinhalt eingefügt werden.
Dieser Vorschlag definiert ein solches Tag, um die In der winuser.h-Headerdatei definierten Windows-Benutzeroberflächenfarben zu codieren.
win.color
<!element win.color #pcdata>
Der Inhalt des Elements ist eine einzelne ganze Zahl, die den Wert der relevanten COLOR_define aus winuser.h enthält. Eine ähnliche Technik kann für jede system- oder anwendungsspezifische Farbspezifikation übernommen werden. Es wird dringend empfohlen, dieses Feature nur aus Gründen der Abwärtskompatibilität zu verwenden.
Reine Farben
pure
<!elementpure empty>
Wenn das Element <pure/> in einem Farbwert angezeigt wird, ist es ein Hinweis darauf, dass die Farbe nicht von einem Dithermuster angenähert werden soll. Dies ist ein Feature der Ebene 1, und eine konforme Implementierung muss es nicht berücksichtigen. Die Bezeichnung ist wichtig für Grafiken, die auf Geräten mit mittlerer Auflösung angezeigt werden, z. B. Videoanzeigen, bei denen kleine Merkmale (z. B. Linien) zu einem schlechten Aliasing mit geditherten Farben führen können. Auf Geräten wie Druckern, die normalerweise alle Farben außer den wenigen voll gesättigten Farben dithern, ist das Dithering normalerweise ausreichend fein, um dieses Problem zu vermeiden.
Farbanpassungen
Die Basisfarbe kann durch arithmetische Vorgänge für den RGB-Wert angepasst werden. Diese Vorgänge werden mithilfe zusätzlicher Elemente innerhalb des Farbwerts definiert. Solche Anpassungen sind nur dann nützlich, wenn sie auf Farben angewendet werden, die von anderen Elementen abgeleitet sind. Es ist gültig, eine solche Anpassung für einen festen Farbwert anzugeben; eine Implementierung darf dies jedoch auf den entsprechenden RGB-Wert reduzieren und diesen anstelle des Originals speichern.
Alle in diesem Abschnitt beschriebenen Farbanpassungsfeatures sind Features der Ebene 1.
color.adjustment
<!entity % color.adjustment -- change to make to a color --
"( %color.op; )?, ( %color.adj; )*"
>
color.op
<!entity % color.op -- arithmetic operation --
"( darken | lighten | add | subtract | reverseSubtract |
blackWhite )"
>
<!element darken %color.parameter;>
<!element lighten %color.parameter;>
<!element add %color.parameter;>
<!element subtract %color.parameter;>
<!element reversesubtract %color.parameter;>
<!element blackwhite %color.parameter;>
color.parameter
<!entity % color.parameter "#pcdata" >
color.adj
<!entity % color.adj -- additional adjustment to color --
"invert | invert128 | gray"
>
<!element invert empty>
<!element INVERT128 empty>
<!element gray empty>
Der Parameter der ersten sechs Vorgänge ist ein einzelner integraler numerischer Wert im Bereich 0 bis 255. Die Anpassung erfolgt wie folgt für den RGB-Wert von 3x8bit:
Wenn <gray/> angegeben wird, wird der RGB-Wert durch yyy ersetzt, wobei y der Leuchtdichtewert (y') ist, der aus dem sRGB-Wert im Anschluss an die ITU-r BT.709 berechnet wird. Diese Berechnung lautet:
y = 0 2125xr + 0 7154xg + 0 0721xbWird eine Color.op-Änderung angegeben, wird jede Komponente gemäß der nachstehenden Tabelle separat angepasst. c ist der Komponentenwert, und p ist der Wert „color.parameter“.
Vorgang Formel darken c := cxp/255 lighten c := 255 - (255-c)xp/255 add c := c + p Subtrahieren c := c - p reversesubtract c := p - c blackwhite if c < p thenc := 0elsec := 255 In jedem Fall gilt: Wenn der berechnete Komponentenwert c 255 überschreitet, dann wird 255 verwendet, und wenn er kleiner als 0 ist, wird 0 verwendet.
Wenn <INVERT128/> angegeben wird, wird der Wert 128 subtrahiert oder jeder Komponente hinzugefügt, je nachdem, ob die Komponente kleiner als 128 ist oder nicht.
if c < 128 then c := c + 128 else c := c - 128Wenn <invert/> angegeben wird, wird jede Komponente durch 255 minus den Wert der Komponente ersetzt.
c := 255-c
font
font
<!element font any>
<!attlist font
style cdata #implied>
Eine Schriftart wird mithilfe eines Style-Attributs identifiziert, wie in CSS1 Abschnitt 5.2 (Schriftarteigenschaften) definiert . Der Textkörper des Schriftartelements ist derzeit undefiniert, kann aber in Zukunft verwendet werden, um Standardschriftarteninformationen zu codieren. Die anfänglichen Implementierungen dieses Vorschlags sollten die Informationen beibehalten, sie jedoch nicht interpretieren.
Es ist denkbar, dass zukünftig Unterstützung für Out-of-Line-Schriftartinformationen (herunterladbare Schriftarten oder freigegebene Schriftartenressourcen) hinzugefügt wird. Dies geschieht durch ein XML-Link-Element innerhalb des Inhalts des Schriftartelements, wodurch die Abwärtskompatibilität mit anfänglichen Implementierungen sichergestellt wird.
Bitmap
bitmap
<!element bitmap empty>
<!attlist bitmap
XML-link cdata #fixed "simple"
href cdata #REQUIRED
title cdata #implied
behavior cdata #implied
show (embed|replace|new) #fixed "embed"
inline (true|false) #fixed "true"
actuate (auto|user) #fixed "auto"
>
Das Bitmapelement ermöglicht einen Verweis auf eine Out-of-line-Bildressource (normalerweise eine Bitmap), die in eine Grafik eingeschlossen werden soll.
Bitmap ist ein Feature der Ebene 1.
Das Verhaltensattribut kann verwendet werden, um anzugeben, wie die Bitmap von einer Bearbeitungsanwendung gehandhabt werden soll. Der Wert kann einer oder beide der folgenden Token sein.
| Token | Beschreibung |
|---|---|
| separate | Kennzeichnet die Bitmap als separate Entität, die nicht als integraler Bestandteil des Dokuments angesehen werden sollte. Die Bitmap sollte nicht mit dem Dokument aufbewahrt werden. Wenn das Dokument kopiert wird, sollte die Bitmap nicht kopiert werden. Wenn das Dokument verschoben wird, sollte die Bitmap nicht mit ihm verschoben werden. |
| original | Das Titel-Attribut identifiziert den ursprünglichen Speicherort der Bitmap als URL; andernfalls wird die Bedeutung des Titels nicht angegeben. |
Diese Werte sind beide Hinweise auf das erwartete Verhalten. Die Option „separate“ bezieht sich auf das Verhalten der Daten, auf die von href verwiesen wird. Wenn sowohl „separate“ als auch „original“ angegeben werden, wird erwartet, dass die Anwendung den href-URI ignoriert und die Bitmap aus den ursprünglichen Daten neu generiert. Wenn nur „original“ angegeben wird, wird erwartet, dass die Anwendung den href-URI verwendet, um die Bitmap zu finden, dem Benutzer jedoch die Möglichkeit geben kann, sie neu zu generieren.
Es ist gültig, den href-URI und das Titelattribut zum gleichen (lexikalischen) Wert zu machen. Dies ist angemessen, wenn die referenzierte Bitmap nicht mit dem Dokument gespeichert ist („stored with“). Es ist vorgesehen (aber nicht erforderlich), dass href für die eigene Kopie der Bitmap des Dokuments verwendet wird – die möglicherweise gelöscht wird, wenn die verweisenden Formen gelöscht werden – und dieser Titel verwendet wird, um eine freigegebene Kopie anzugeben. Wenn also beide denselben Wert enthalten, gibt es keine dokumentspezifische Kopie.
Anwendungen können den Hinweis ignorieren, wenn er nicht mit dem tatsächlichen Speichermodell der XML-Daten kompatibel ist.
Bilddateiformate
Im Rahmen dieses Vorschlags sind externe Daten entweder eine Bitmap oder eine Datei, die verwendet wird, um eine Bitmap zu erzeugen. Auf Renderebene 0 muss kein externes Bitmapformat unterstützt werden. Pfade können nur mit Volltonfarben gefüllt werden. Um den vollständigen Satz von Füllungen der Renderebene 1 zu rendern, müssen Bitmaps unterstützt werden. Renderebene 1 enthält (nur) die folgenden Formate:
- JFIF, d. h. ISO/IEC 10918-Formatdaten, die in einer Datei mit dem JFIF-Header eingebettet sind (die als eine bestimmte APP0-Markierung nach dem SOI-Maker betrachtet werden können) und (nur) die vom IJG v6-Code unterstützten JPEG-Formate enthalten.
- PNG, wie in der Spezifikation der PNG-Version 1.0 definiert.
Renderebene 2 enthält auch Unterstützung für Folgendes:
- GIF, wie von der GIF-Spezifikation definiert, die 1987 von CompuServ veröffentlicht wurde (normalerweise als „GIF87a“ bezeichnet). GIF89a muss auch auf dieser Ebene unterstützt werden, vorbehaltlich der Einschränkung, dass die Daten keine Erweiterungsblöcke enthalten dürfen, die eine Interpretation benötigen, um die Bitmap anzuzeigen, mit Ausnahme von Grafiksteuerelementerweiterungen, die keine Benutzereingabe oder eine Verzögerungszeit erfordern. Auf diese Weise können Kommentare eingeschlossen werden, aber nicht die Nur-Text-Erweiterung. Eine Anwendung kann Anwendungserweiterungen (0x21, 0xFF) einfügen, aber unter Verwendung der Terminologie dieses Vorschlags dürfen diese nur Bearbeitungs- und keine Rendering-Daten enthalten.
Jedes andere Datenformat, das in der Grafik verwendet wird, erzwingt, dass die Grafik mindestens die Bearbeitungsebene 3 und möglicherweise die Rendering-Ebene 3 ist (wenn die Daten zum Rendern der Grafik erforderlich sind). Es wird empfohlen, dass eine Anwendung die von ihr unterstützten Formate veröffentlicht. Microsoft Office unterstützt z. B. die folgenden zusätzlichen Formate nativ und kann daher Bearbeitungsdaten in diesem Format schreiben:
- WMF – Windows-Metadatei (Win 3.1-Format)
- EMF – Windows-Metadatei „erweitert“ (Win32-Format)
- PICT – Mac OS QuickDraw PICT-Datei (alle Versionen, jedoch ohne QuickTime-Datensätze oder andere Erweiterungen)
- BMP – Windows-Bitmapdateiformat, „os/2“ (BITMAPCORE)-, BITMAPINFO-, BITMAPV4- und BITMAPV5-Formate
Vektor
v
<!element v "( #pcdata | p )*">
Ein Vektorgrafikpfad wird als pcdata codiert. Der Inhalt des v-Elements wird gemischt und enthält optional eine Vektorpfadbeschreibung, die mit p-Elementen parametrisiert wird.