DE102016015381A1

DE102016015381A1 - Verwendung von Bloom-Filtern zur Vereinfachung der Erweiterung und Unterteilung eines dynamischen Fonts

Info

Publication number: DE102016015381A1
Application number: DE102016015381.4A
Authority: DE
Inventors: Gregory A. Kaplan; Bram Stein
Original assignee: Adobe Systems Inc
Current assignee: Adobe Inc
Priority date: 2016-02-29
Filing date: 2016-12-22
Publication date: 2017-08-31
Also published as: CN107133199A; AU2016277770A1; AU2016277770B2; US20170249286A1; CN107133199B; US10503811B2; US20200089737A1; GB2547756A; US11030389B2; GB201622018D0; CN116757157A

Abstract

Beschrieben wird der Erwerb eines Fontteiles unter Verwendung eines Kompressionsmechanismus. Bei gewissen Ausführungsformen bestimmt eine Endnutzervorrichtung mehrere Zeichen, die angezeigt werden sollen, jedoch in einem lokalen Font fehlen. Die Endnutzervorrichtung berechnet eine komprimierte Darstellung der mehreren Zeichen auf Grundlage von mehreren Codepunkten, die den mehreren Zeichen entsprechen. Die Endnutzervorrichtung überträgt eine Fontanforderung, die die komprimierte Darstellung beinhaltet, an einen Fontvorrat. Die Fontanforderung kann als einheitliche Ressourcenadresse (Uniform Resource Locator URL) implementiert sein. Der Fontvorrat, so beispielsweise ein Server, decodiert die komprimierte Darstellung zum Identifizieren der wenigstens mehreren Codepunkte, die von der Endnutzervorrichtung codiert worden sind. Der Fontvorrat präpariert eine Fontbeschreibung, die Glyphendaten beinhaltet, die den mehreren Codepunkten entsprechen, und gibt die Fontbeschreibung aus. Die Endnutzervorrichtung erzeugt einen lokalen Font, der wenigstens mehrere Glyphen beinhaltet, die den mehreren angeforderten Zeichen entsprechen. Die Erzeugung des lokalen Fonts kann eine Fonterweiterung beinhalten.

Description

Hintergrund
Das Internet, insbesondere das World Wide Web (WWW) oder einfach Web, ermöglicht, dass weltweit zahlreiche Dienste angeboten werden. Zwei Beispiele für derartige Dienste sind Kommunikation und Handel. Diese und weitere Dienste werden für Webnutzer, die eine Vielzahl von verschiedenen Ausbildungsniveaus, ästhetischen Präferenzen, sprachlichen Fähigkeiten und dergleichen mehr aufweisen, und zwischen diesen bereitgestellt. Insbesondere ist das Web dafür konfiguriert, der großen Vielfalt von Menschen, die aus verschiedenen Ländern stammen oder in verschiedenen Kulturen leben, gerecht zu werden.
Ein Aspekt, dem das Web gerecht werden muss, betrifft die Fähigkeit, viele verschiedene Fonts bzw. Zeichensätze (fonts) zu verwenden. Fonts sind digitale Dateien oder Code zur Darstellung von Beispielen für digitale Typen. Beispiele für Typen beinhalten Courier, Helvetica, Literata, Times New Roman und Bookerly. Ein Beispiel für einen Font ist eine Datei (beispielsweise „Helvetica-Bold.otf”), die den Stil einer Type darstellt, so beispielsweise Helvetica-Fett. Jeder Font verkörpert einen einzigartigen Stil und ist oftmals für eine oder wenige verwandte Sprachen konzipiert. Ein gegebener elektronischer Font oder eine Familie von Fonts kann Optionen für verschiedene Punktgrößen, Effekte, beispielsweise „fett” (bold) oder „kursiv” (italics), und dergleichen mehr aufweisen. Unter Verwendung eines ausgewählten Fonts kann eine Rechenanwendung bewirken, dass Zeichen auf einem Anzeigeschirm einer elektronischen Vorrichtung als Glyphen, die jeweils den Zeichen entsprechen, präsentiert werden. Ein Webbrowser kann beispielsweise auf dem Schirm eines Smartphones Text von einer Webseite unter Verwendung eines lokal gespeicherten Fonts anzeigen.
Um der Vielfalt von Sprachen und Kulturen der Menschen weltweit gerecht zu werden, sind viele verschiedene Fonts erstellt worden. Die Vielzahl von bestehenden Fonts ermöglicht, dass Menschen verschiedener Sprachen und Kulturen das Web jeweils nach ihrem Gusto nutzen können. Zu diesem Zweck können Fonts beträchtlich voneinander abweichen. Des Weiteren beinhaltet eine Definition eines Fonts gegebenenfalls nicht nur eine Erklärung, wie einzelne Zeichen gebildet werden, sondern auch eine Erklärung, wie jedes Zeichen mit anderen Zeichen in Beziehung steht oder wechselwirkt. Eine Fontdefinition kann daher beträchtliche Datenmengen beanspruchen, was Anforderungen sowohl an Speicher- wie auch Übertragungsbandbreitenkapazitäten einer elektronischen Vorrichtung stellt. Infolgedessen können einzelne elektronische Vorrichtungen nur eine begrenzte Anzahl von Fontdefinitionen speichern. Des Weiteren bewirkt das Bereitstellen einer Fontdefinition für eine Endnutzervorrichtung zur Ermöglichung dessen, dass Zeichen unter Verwendung des Fonts angezeigt werden, merkliche Zeitverzögerungen, die beim Endnutzer kulminieren. Zudem behindern bei einer gebührenpflichtigen Verbindung, wie dies bei vielen zellenbasierten Dienstsystemen der Fall ist, finanzielle Rahmenbedingungen gegebenenfalls das Herunterladen und damit die Nutzung von verschiedenen Fonts.
Zusammenfassung
Beschrieben wird der Erwerb eines Fontteiles unter Verwendung eines Kompressionsmechanismus. Eine Endnutzervorrichtung kann auf textartigen Inhalt stoßen, der mehrere Zeichen eines spezifizierten Fonts aufweist, die an der Endnutzervorrichtung lokal nicht vorhanden sind. Jedes einzelne Zeichen weist eine optisch erkennbare Form auf, die für einen Betrachter einer Glyphe, die dem Zeichen entspricht, eine Bedeutung trägt. Beinhalten kann ein Zeichen beispielsweise einen Buchstaben eines Alphabets, ein Bildzeichen, eine Satzzeichen, ein Emoji, eine textartige Einheit oder eine beliebige von Menschen lesbare oder verstehbare Form, die unter Verwendung einer Rechenvorrichtung als Text codiert werden kann. Im Gegensatz hierzu ist eine Glyphe eine spezifische Wiedergabe oder grafische Darstellung eines codierten Zeichens so, wie es ein Font bereitstellt.
Anstatt dessen, dass der spezifizierte Font als Ganzes bezogen wird, erwirbt die Endnutzervorrichtung einen Teil des Fonts unter Verwendung eines Kompressionsmechanismus für eine Fontanforderung, um Zeit zu sparen und die Übertragungsbandbreite zu verringern. Die Endnutzervorrichtung sendet sodann an einen Fontvorrat eine Fontanforderung, die eine komprimierte Darstellung aufweist, die die fehlenden Zeichen auflistet. In Reaktion hierauf gibt der Fontvorrat für die fehlenden Zeichen eine Fontbeschreibung aus, die Daten beinhaltet, die die Glyphen, die den angeforderten Zeichen entsprechen, beschreiben. Ist ein Teil des spezifizierten Fonts nicht schon an der Endnutzervorrichtung vorhanden, so werden die Daten für die entsprechenden Glyphen verwendet, um einen neuen lokalen Font für den spezifizierten Font einzurichten. Ist jedoch ein gewisser Teil des spezifizierten Fonts bereits an der Endnutzervorrichtung vorhanden, so werden die Daten für die entsprechenden Glyphen hinzugefügt, um so einen bestehenden lokalen Font zu erweitern.
Insbesondere bestimmt bei gewissen exemplarischen Ausführungsformen einer Endnutzervorrichtung ein Fontinstanziierungsmodul mehrere Zeichen, die einen Teil einer Fontdefinition für einen bestimmten Font bilden und zur Wiedergabe von entsprechenden Glyphen verwendet werden. Das Fontinstanziierungsmodul ermittelt mehrere Codepunkte, so beispielsweise Unicode-Codepunktwerte, die jeweils den mehreren Zeichen entsprechen. Eine komprimierte Darstellung der mehreren Zeichen wird auf Grundlage der mehreren Codepunkte berechnet. Das Fontinstanziierungsmodul kann die komprimierte Darstellung beispielsweise unter Verwendung einer oder mehrerer Hashing-Funktionen, die in Bezug auf die Einbeziehung verlustfrei sind, berechnen. Damit kann das Decodieren der komprimierten Darstellung falsche Positiva in einem Fontvorrat erzeugen, wobei falsche Negativa nicht zugelassen sind. Mit anderen Worten, jedes Zeichen wird so, wie es durch einen Codepunkt, der von der Endnutzervorrichtung angefordert werden soll, dargestellt ist, von dem Fontvorrat in Form entsprechender Glyphendaten in Reaktion auf die komprimierte Darstellung ausgegeben. Glyphendaten für zusätzliche unbeabsichtigte Zeichen können jedoch ebenfalls ausgegeben werden. Die komprimierte Darstellung kann beispielsweise als wahrscheinlichkeitsbasierte Datenstruktur, so beispielsweise als Bloom-Filter, implementiert werden.
Die Endnutzervorrichtung kommuniziert an den Fontvorrat eine Fontanforderung, die die komprimierte Darstellung beinhaltet. Die Fontanforderung kann beispielsweise als URL implementiert sein, in der die komprimierte Darstellung eingebettet ist. In Reaktion auf die Übertragung der Fontanforderung empfängt die Endnutzervorrichtung von dem Fontvorrat eine Fontbeschreibung, die der komprimierten Darstellung entspricht. Das Fontinstanziierungsmodul an der Endnutzervorrichtung verwendet die Fontbeschreibung zum Erzeugen eines lokalen Fonts, der Glyphendaten wenigstens für die angeforderten Zeichen beinhaltet. Die Fontbeschreibung kann zum Einrichten eines neuen lokalen Fonts verwendet werden, der einen Teilsatz einer vollständigen Fontdefinition aufweist, oder es kann die Fontbeschreibung dafür verwendet werden, einen bestehenden lokalen Font zu erweitern, indem Glyphendaten zu dem bestehenden lokalen Font entsprechend einer Erweiterungsanweisung, die als Teil der Fontbeschreibung empfangen wird, hinzugefügt werden.
Bei gewissen exemplarischen Ausführungsformen einer Servervorrichtung empfängt die Servervorrichtung von einer Endnutzervorrichtung eine komprimierte Darstellung, die mehreren Zeichen entspricht, die für eine bestimmte Fontdefinition angefordert werden. Ein Fontinstanziierungsmodul decodiert die komprimierte Darstellung zum Identifizieren von mehreren Codepunkten. Das Fontinstanziierungsmodul kann beispielsweise einen Codierprozess auf jeden Codepunkt eines Satzes von Codepunkten in einer Fontdefinition anwenden und bestimmen, ob ein Codierergebnis zu der komprimierten Darstellung passt. Passt das Codierergebnis des entsprechenden Codepunktes eines Zeichens zu Feldern, die in der komprimierten Darstellung beinhaltet sind, so gilt das Zeichen als angefordert. Obwohl jedes Zeichen oder jeder Codepunkt, das/der als angefordert gilt, gegebenenfalls nicht wirklich von der Endnutzervorrichtung angefordert worden ist, soll jeder analysierte Codepunkt für jedes Zeichen mit einem passenden Codierergebnis als solcher gelten. Mit anderen Worten, die Servervorrichtung soll Glyphendaten ausgeben, die jedem Codepunkt entsprechen, der aktuell angefordert werden soll, und zwar auch dann, wenn Glyphendaten auch für zusätzliche, nicht angeforderte Codepunkte ausgegeben werden.
Das Fontinstanziierungsmodul der Servervorrichtung ermittelt mehrere Zeichen, die den mehreren Codepunkten mit passenden Codierergebnissen entsprechen. Das Fontinstanziierungsmodul greift auf die Fontdefinition zu, um mehrere Fontattribute für die mehreren ermittelten Zeichen zu extrahieren. Vektordarstellungen von Glyphen, geeignete Abstände zwischen Glyphen oder eine Reihenfolge von Glyphen in der Fontdefinition können beispielsweise als Fontattribute extrahiert werden. Das Fontinstanziierungsmodul präpariert eine Fontbeschreibung entsprechend der komprimierten Darstellung auf Grundlage der mehreren extrahierten Fontattribute. Die Fontbeschreibung beinhaltet Glyphendaten, die ermöglichen, dass die Endnutzervorrichtung die mehreren Zeichen als Teil eines lokalen Fonts an der Endnutzervorrichtung wiedergibt. Bei einem Szenario der Fonterweiterung kann die Fontbeschreibung auch wenigstens eine Erweiterungsanweisung zum Aufnehmen von zusätzlichen Glyphen in einen bestehenden lokalen Font beinhalten, um die Nutzbarkeit des Fonts insgesamt zu bewahren. Nach dem Präparieren der Fontbeschreibung überträgt die Servervorrichtung die Fontbeschreibung an die Endnutzervorrichtung.
Die vorliegende Zusammenfassung bietet in vereinfachter Form eine Auswahl von Konzepten, die nachstehend in der Detailbeschreibung weiter beschrieben werden. Als solches soll die vorliegende Zusammenfassung wesentliche Merkmale des beanspruchten Erfindungsgegenstandes weder identifizieren, noch soll sie als Hilfe beim Bestimmen des Umfangs des beanspruchten Erfindungsgegenstandes verwendet werden.
Kurzbeschreibung der Zeichnung
Die Detailbeschreibung erfolgt anhand der begleitenden Figuren. In den Figuren identifiziert die am weitesten links stehende Ziffer eines Bezugszeichen/identifizieren die am weitesten links stehenden beiden Ziffern eines Bezugszeichen diejenige Figur, in der das Bezugszeichen erstmalig auftritt. Die Verwendung derselben Bezugszeichen an verschiedenen Stellen in der Beschreibung und den Figuren kann ähnliche oder identische Objekte bezeichnen. Objekte, die in den Figuren dargestellt sind, können auf ein oder mehrere Objekte verweisen, weshalb ein Verweis auf eine oder mehrere Formen der Objekte in der Beschreibung gleichwertig vorgenommen werden kann.
1 zeigt eine Umgebung für exemplarische Ausführungsformen, die dafür betreibbar sind, die hier beschriebenen Techniken einzusetzen, die mit dem Erwerb eines Fontteiles unter Verwendung eines Kompressionsmechanismus in Zusammenhang stehen.
2 zeigt ein Anzeigeszenario bei einer Endnutzervorrichtung mit einer exemplarischen Anwendung, die Zeichen in verschiedenen Fonts als entsprechende Glyphen wiedergibt.
3 zeigt ein exemplarisches Szenario, bei dem eine Endnutzervorrichtung einen Teil eines Fonts von einer Servervorrichtung in Reaktion auf eine Fontanforderung erwerben kann.
4 zeigt einen exemplarischen Lösungsansatz zum Erzeugen einer Fontanforderung durch eine Endnutzervorrichtung.
5 zeigt einen exemplarischen Lösungsansatz zum Erzeugen einer Fontbeschreibung in Reaktion auf eine Fontanforderung durch eine Servervorrichtung.
6 zeigt ein exemplarisches Szenario, bei dem eine Endnutzervorrichtung einen Teil eines Fonts von einer Servervorrichtung in einer Fonterweiterungssituation erwerben kann.
7 ist ein Flussdiagramm zur Darstellung einer exemplarischen Prozedur für eine Endnutzervorrichtung entsprechend einer oder mehreren exemplarischen Ausführungsformen.
8 ist ein Flussdiagramm zur Darstellung einer exemplarischen Prozedur für eine Servervorrichtung entsprechend einer oder mehreren exemplarischen Ausführungsformen.
9 zeigt ein exemplarisches System, das verschiedene Komponenten von zwei exemplarischen Vorrichtungen beinhaltet, die für eine oder mehrere Ausführungsformen beim Erwerb eines Fontteiles unter Verwendung eines Kompressionsmechanismus eingesetzt werden können.
Detailbeschreibung
Übersicht
Webseitenersteller, so beispielsweise Webdesigner und Webentwickler, streben danach, Webseiten zu konzipieren, die dem Zielpublikum gefallen. Webseitenersteller passen eine Webseite oftmals an die Kultur, das Land oder die ästhetischen Empfindlichkeiten eines Zielpublikums an. Ein Lösungsansatz beim Einsetzen einiger der neuesten Webtechnologien besteht darin, dass die Webseite Inhalt dynamisch auf eine Weise darstellen kann, die die modern erscheint und den neuesten webbezogenen Trends folgt. Ein anderer Lösungsansatz beinhaltet das Einsetzen eines Fonts, der einem Zielpublikum vertraut ist oder zu einer gewissen Erwartungshaltung passt. Das Zielpublikum kann mit Blick auf Alter, Hobbys, bevorzugte Sprache, Geburtskultur, Wohnsitzland oder Herkunftsland, erworbenes Ausbildungsniveau, ökonomische Gruppe und dergleichen mehr definiert werden.
Die Auswahl eines geeigneten Fonts kann Erwägungen hinsichtlich vieler verschiedener Faktoren einbeziehen. Ein Stil, der ein gewisses Bild prägt, oder eine Sprache, die von einem Zielpublikum gelesen wird, können beispielsweise einbezogen werden. Als weiterer Faktor kann ein Kompromiss zwischen der Einzigartigkeit eines Fonts und der einfachen Lesbarkeit gefunden werden. Des Weiteren müssen zu erwartende verbraucherseitige Vorrichtungen, so beispielsweise Smartphones oder Desktopcomputer, einbezogen werden. Es ist eine Vielzahl von Fonts erzeugt worden, um diesen verschiedenen Faktoren gerecht zu werden. Heutzutage werden in der Tat Abertausende von verschiedenen Fonts im Web verwendet. Damit eine Vorrichtung Glyphen (das heißt spezifische Formen von Zeichen) entsprechend einem gegebenen Font wiedergeben kann, verwendet die Vorrichtung eine lokal gespeicherte Version einer Fontdefinition für den Font. Eine vollständige Fontdefinition kann jedoch viele Megabyte von Daten beanspruchen. Eine vollständige Fontdefinition für eine bildzeichenbasierte Sprache kann beispielsweise annähernd 20 MB beanspruchen. Infolgedessen kann eine verbraucherseitige elektronische Vorrichtung, insbesondere wenn sie tragbar ist oder geringe Ressourcen aufweist, die vollständige Fontdefinition für mehrere Fonts nicht ohne Weiteres speichern, und dies umso weniger angesichts all der Fonts, die im Web verwendet werden.
Es sind daher Vorkehrungen dahingehend getroffen worden, dass Webtechnologien eingesetzt werden, die das bei Bedarf erfolgende Herunterladen von Fontdefinitionen für eine gegebene Webseite ermöglichen. In der Praxis werden vielerlei Fontdefinitionen in der Cloud in einem Fontvorrat, so beispielsweise auf einem Webserver, der Zugriff auf eine viele Fonts speichernde Datenbank hat, gespeichert. Ein Bruckstück (snippet) eines Codes, das als Teil einer Webseite vorhanden ist, kann wenigstens einen Teil einer Fontdefinition aus einem Fontvorrat anfordern. Ein Teil einer Webseite kann beispielsweise JavaScript beinhalten, das bei Ausführung durch einen Browser wenigstens einen Webserver kontaktiert, um eine Fontdefinition zur Verwendung durch den Webbrowser bei der Wiedergabe von Glyphen zur Anzeige der Webseite abzurufen.
Ist eine vollständige Fontdefinition gewünscht, so kann das Codebruchstück den angeforderten Font rein anhand des Namens, eines alphanummerischen Codes oder eines ähnlichen Fontidentifizierers identifizieren. Ist jedoch ein Teilsatz eines Fonts oder eine Fonterweiterung gewünscht, so werden die angeforderten einzelnen Zeichen aufgelistet. Sind lediglich wenige Zeichen gewünscht, so sind eigentlich kaum Schwierigkeiten dabei vorhanden, an einen Webserver eine Anforderung zu richten, die die angeforderten spezifischen Zeichen auflistet. Demgegenüber treten Schwierigkeiten auf, wenn zahlreiche Zeichen angefordert werden. Eine Situation, in der zahlreiche Zeichen angefordert werden, tritt wahrscheinlich dann auf, wenn eine Webseite verschiedene Fonts verwendet oder wenn ein Font Tausende von Zeichen enthält, was beispielsweise bei bildzeichenbasierten asiatischen Sprachen wie Chinesisch, Koreanisch und Japanisch der Fall ist.
Unter Verwendung von Webtechnologien wird eine Ressource oftmals mittels einer einheitlichen Ressourcenadresse (Uniform Resource Locator URL) angefordert. URLs weisen jedoch – zumindest bei zuverlässigem Einsatz – eine begrenzte maximale Länge auf. Die Begrenzung ergibt sich daraus, dass einige Webserver und Proxyserver im Web immer noch mit älteren Standards arbeiten und auch einige ältere Browser immer noch in Gebrauch sind. Sind beispielsweise 400 einzelne Zeichen eines Fonts gewünscht und wird jedes Zeichen durch vier Zahlen (beispielsweise eine Zahl mit vier Ziffern) identifiziert, so überschreitet eine URL-basierte Anforderung der gewünschten Zeichen die maximale Länge der URL bei älteren Webservern und Proxyservern. Es sind mehrere verschiedene Lösungsansätze vorhanden, die sich dieser Begrenzung widmen, wobei jeder dieser Lösungsansätze jedoch neue Probleme aufwirft. Nachstehend beschrieben werden zwei spezifische problematische Lösungsansätze wie auch Gründe, die gegen diese beiden Lösungsansätze sprechen.
Beim ersten problematischen Lösungsansatz können die gewünschten einzelnen Zeichen in mehrere Gruppen getrennt werden, die gemeinsam oder in Kombination alle gewünschten einzelnen Zeichen beinhalten. Eine getrennte Anforderung einer jeden der mehreren Gruppen kann sodann an einen Fontvorrat gestellt werden. Derartige mehrere getrennte Anforderungen vergrößern jedoch die Verzögerung, die durch das Beziehen eines Fontteiles von einer entfernten Quelle bewirkt wird, vor der Anzeige einer Webseite. Insbesondere vergrößern mehrere getrennte Anforderungen die Wahrscheinlichkeit, dass ein Fehler auftritt, da mehrere Fontteile empfangen und in einen lokalen Font an der Endnutzervorrichtung aufgenommen werden.
Beim zweiten problematischen Lösungsansatz kann eine Anforderung eines Fonts effektiv in zwei Phasen unterteilt werden. In einer ersten Phase listet ein Webbrowser bei einer Endnutzervorrichtung die gewünschten Zeichen für einen ersten Webserver mittels einer ersten Kommunikation auf. In einer zweiten Phase richtet der Webbrowser eine Anforderung mittels einer zweiten Kommunikation an einen zweiten Webserver, der als Fontvorrat dient, unter Verweis auf die Auflistung der gewünschten Zeichen, die auf dem ersten Webserver vorhanden ist. Nach dem Kontaktieren des ersten Webservers mittels einer dritten Kommunikation kann der zweite Webserver die angeforderten Zeichen für den Webbrowser bereitstellen. Daher impliziert dieser zweite Lösungsansatz mehrere Kommunikationen, die zusätzliche Verzögerungen bedingen, bevor ein Fontteil heruntergeladen und verwendet werden kann. Darüber hinaus werden zwei verschiedene Webserver kontaktiert, was den Prozess noch komplizierter macht und zu Fehlern führen kann.
Aus einer stärker technischen Perspektive heraus sind ältere Webserver und Proxyserver im Internet nicht in der Lage, URLs, die 2048 Zeichen überschreiten, zu verarbeiten. Da der Weg einer Kommunikation im Internet nicht vorherbestimmt ist, sind die Proxyserver, über die die Kommunikation läuft, nicht vorhersagbar. Entsprechend muss, um ein verlässliches Schema zum Fonterwerb zu implementieren, an der Grenze von 2048 Zeichen festgehalten werden. Eine Vorgehensweise beim Identifizieren von verschiedenen Zeichen besteht in der Verwendung des Unicode-Codepunktes, der jedem jeweiligen Zeichen entspricht. Die Unicode-Codepunktwerte können eine Einheit aus vier Zeichen sein, die durch Kommata getrennt sind. Eine Liste von 400 eindeutigen Unicode-Codepunkten ergibt daher, wenn sie in eine URL aufgenommen ist, eine URL von nicht weniger als 2000 Zeichen. Infolgedessen erzeugt das direkte Aufnehmen von Unicode-Codepunkten in eine URL kein verlässliches Schema mit Blick auf ältere Web- und Proxyserver, denen man im Web immer noch begegnen kann.
Beim zweiten problematischen vorbeschriebenen Lösungsansatz wird eine Auflistung der Unicode-Codepunkte, die zum Erfüllen einer Anforderung eines Fontteiles verwendbar sind, von einer Clientanwendung, so beispielsweise einem Webbrowser, der ein Skript von einer Webseite ausführt, kompiliert. Da die Länge dieser Anforderung gegebenenfalls zu groß ist, als dass sie sicher in eine URL aufgenommen werden könnte, richtet der Webbrowser anstatt dessen zunächst eine HTTP-POST-Anforderung (Hypertexttransferprotokoll HTTP) an einen ersten Webserver, um die Unicode-Auflistung als Teil der erste Phase zu definieren. Eine HTTP-POST-Anforderungsmitteilung bittet darum, dass ein Webserver die Daten, die im Inhaltsteil (body) der Anforderungsmitteilung beinhaltet sind, annimmt und speichert. Die HTTP-POST-Anforderungsmitteilung unterliegt nicht denselben Größenbeschränkungen wie die URL, da die Daten nicht in der eigentlichen URL beinhaltet sind. Die Unicode-Auflistung kann gehasht und sodann mit einem Schlüssel als Teil der HTTP-POST-Anforderung gebündelt werden. Der Schlüssel kann anschließend dafür verwendet werden, einen spezifischen Fontteil von einem zweiten Webserver als Teil der zweiten Phase anzufordern. Der zweite Webserver kann die Unicode-Auflistung von dem ersten Webserver unter Verwendung des Schlüssels beziehen. Dieser zweiphasige Prozess ist jedoch nachteiligerweise nicht effizient.
Im Gegensatz hierzu kann entsprechend einer oder mehreren Ausführungsformen, die hier beschrieben werden, ein einphasiger Lösungsansatz eine URL verwenden, um einen Teil eines Fonts auf Grundlage eines Kompressionsmechanismus zu erwerben. Bei einem Webbrowseszenario erstellt ein Webbrowser eine Liste von gewünschten Zeichen, so beispielsweise solcher Zeichen, die Glyphen entsprechen, die auf einem Anzeigeschirm wiedergegeben werden sollen. Der Webbrowser komprimiert eine Auflistung von identifizierenden Codepunkten entsprechend den gewünschten Zeichen, um eine komprimierte Darstellung der gewünschten Zeichen zu erzeugen. Der Webbrowser bettet die komprimierte Darstellung in eine URL ein und sendet die URL an einen Webserver, der als Fontvorrat dient. Der Fontvorrat empfängt die URL und extrahiert und decodiert die komprimierte Darstellung im Anschluss. Der Webserver ermittelt diejenigen Zeichen, die den decodierten Codepunkten entsprechen, und präpariert eine Fontbeschreibung mit Glyphendaten zur Wiedergabe derjenigen Glyphen, die den ermittelten Zeichen entsprechen. Der Webserver überträgt die Fontbeschreibung an den Webbrowser zur Verwendung bei der Wiedergabe von Text, der die angeforderten Zeichen beinhaltet.
Insbesondere bestimmt bei gewissen exemplarischen Ausführungsformen einer Endnutzervorrichtung eine Rechenanwendung, dass mehrere Zeichen, die einen Teil einer spezifischen Fontdefinition bilden, erwünscht sind, um eine elektronische Datei, so beispielsweise eine Druckschrift, wiederzugeben. Die Rechenanwendung ermittelt (beispielsweise durch Sammeln) die mehreren Codepunkte, so beispielsweise mehrere Unicode-Codepunktwerte, die jeweils den mehreren gewünschten Zeichen entsprechen. Eine komprimierte Darstellung der mehreren Zeichen wird auf Grundlage der mehreren Codepunkte berechnet. Die komprimierte Darstellung kann beispielsweise unter Verwendung einer oder mehrerer Hashing-Funktionen, die in Bezug auf die Einbeziehung verlustfrei sind, berechnet werden. Damit kann das Decodieren der komprimierten Darstellung falsche Positiva in einem Fontvorrat erzeugen, wobei falsche Negativa jedoch unzulässig sind. Mit anderen Worten, jedes gewünschte angeforderte Zeichen wird von dem Fontvorrat ausgegeben, wobei jedoch gegebenenfalls auch zusätzliche unbeabsichtigte Zeichen ausgegeben werden. Die komprimierte Darstellung kann als wahrscheinlichkeitsbasierte Datenstruktur, so beispielsweise als Bloom-Filter, implementiert sein.
Die Endnutzervorrichtung kommuniziert an den Fontvorrat eine Fontanforderung, die die komprimierte Darstellung beinhaltet. Die Fontanforderung kann beispielsweise als URL, in der die komprimierte Darstellung eingebettet ist, implementiert sein. In Reaktion auf eine Übertragung der Fontanforderung empfängt die Endnutzervorrichtung von dem Fontvorrat eine Fontbeschreibung entsprechend der komprimierten Darstellung. Die Rechenanwendung verwendet die Fontdarstellung zur Erzeugung eines lokalen Fonts, der Glyphendaten wenigstens für die absichtlich angeforderten Zeichen beinhaltet. Die Fontbeschreibung kann zum Einrichten eines neuen lokalen Fonts, der einen Teilsatz einer vollständigen Fontdefinition aufweist, verwendet werden, oder es kann die Fontbeschreibung verwendet werden, um den lokalen Font zu erweitern, indem Glyphendaten zu einem bestehenden lokalen Font hinzugefügt werden.
Darüber hinaus empfängt bei gewissen exemplarischen Ausführungsformen einer Servervorrichtung die Servervorrichtung von einer Endnutzervorrichtung eine komprimierte Darstellung entsprechend mehreren Zeichen, die einen Teil einer Fontdefinition bilden. Die Servervorrichtung decodiert die komprimierte Darstellung, um mehrere Codepunkte zu identifizieren. Die Servervorrichtung kann beispielsweise einen Codierprozess auf jeden Codierpunkt eines Satzes von Codepunkten anwenden und bestimmen, ob ein Codierergebnis zu der komprimierten Darstellung passt. Passt ein Codierergebnis zu einem in der komprimierten Darstellung beinhalteten Codepunkt, so gilt das entsprechende Zeichen als angefordert. Obwohl jedes Zeichen, das als angefordert gilt, auch unabsichtlich von der Endnutzervorrichtung angefordert worden sein kann, sollte jedes Zeichen, das einem geprüften Codepunkt mit einem passenden Codierergebnis entspricht, als solches gelten. Mit anderen Worten, die Servervorrichtung soll jedes Zeichen mit scheinbarer Anforderung mit Blick auf die komprimierte Darstellung auch dann ausgeben, wenn zudem zusätzliche, unbeabsichtigt angeforderte Zeichen ausgegeben werden.
Die Servervorrichtung ermittelt mehrere Zeichen, die den mehreren Codepunkten mit passenden Codierergebnissen entsprechen. Die Servervorrichtung greift auf die Fontdefinition zu, um mehrere Fontattribute für die mehreren Zeichen zu extrahieren. Vektordarstellungen von Glyphen, geeignete Abstände zwischen Glyphen oder eine Reihenfolge von Glyphen in der Fontdefinition können beispielsweise als Fontattribute extrahiert werden. Die Servervorrichtung präpariert eine Fontdarstellung entsprechend der komprimierten Darstellung auf Grundlage der mehreren Fontattribute. Die Fontbeschreibung beinhaltet Glyphendaten, die ermöglichen, dass die Endnutzervorrichtung Glyphen entsprechend den mehreren Zeichen als Teil eines lokalen Fonts der Endnutzervorrichtung wiedergibt. Die Fontbeschreibung kann zudem wenigstens eine Erweiterungsanweisung zum Aufnehmen von zusätzlichen Glyphendaten in einen bestehenden lokalen Font beinhalten, um die Nutzbarkeit des Gesamtfonts bei einem Fonterweiterungsszenario zu bewahren. Die Servervorrichtung überträgt die präparierte Fontbeschreibung an die Endnutzervorrichtung.
Auf diese Weise kann ein Teil eines Fonts an einer Endnutzervorrichtung aus einem Fontvorrat unter Verwendung eines Kompressionsmechanismus erworben werden. Der Erwerb kann in einer Phase mit einer einzigen Anforderung bei einem einzigen Server erfolgen. Eine Auflistung der gewünschten Zeichen, die den Teil des Fonts bilden, kann zu einer komprimierten Darstellung verdichtet werden, die zur Einbeziehung als Teil einer URL geeignet ist. Die Länge der URL kann ausreichend kurz sein, sodass auch ältere Webserver und Proxyserver mit den URLs, die als Anforderungen von Fontteilen dienen, umgehen können. Die Verzögerungen und Komplexitäten beim Erstellen von mehreren Anforderungen oder Kommunizieren mit mehreren Servern können vermieden werden. Darüber hinaus kann eine große Vielzahl von Fonts zur Verwendung in verschiedenen elektronischen Dateien, so beispielsweise auf verschiedenen Webseiten, verfügbar gemacht werden.
In der nachfolgenden Diskussion wird, nachdem einige exemplarische terminologische Begriffe beschrieben worden sind, eine exemplarische Umgebung beschrieben, in der die hier beschriebenen Techniken eingesetzt werden können. Sodann werden Systeme, Maschinen und Techniken der exemplarischen Ausführungsform beschrieben, gefolgt von einem Abschnitt, der Prozeduren und Prozesse der exemplarischen Ausführungsform erläutert. Die Prozeduren und Prozesse können in der exemplarischen Umgebung und den exemplarischen Systemen wie auch in anderen Umgebungen durchgeführt werden. Die Leistungsfähigkeit der exemplarischen Prozeduren ist nicht auf die exemplarische Umgebung beschränkt, und die exemplarische Umgebung und die exemplarischen Systeme sind nicht auf die Leistungsfähigkeit der exemplarischen Prozeduren beschränkt.
Beispiele für die Terminologie
Nachstehend folgen exemplarische Beschreibungen oder Erläuterungen von bestimmten Begriffen, die nachfolgend auftreten. Jeder Begriff ist bei einer oder mehreren, jedoch nicht notwendigerweise bei allen Ausführungsformen, die hier vorgestellt werden, anwendbar. Einige Begriffe werden anhand eines oder mehrerer Beispiele weiter erläutert.
Ein „Font” (font) bezeichnet eine digitale Darstellung (beispielsweise eine Datei oder einen bestimmten Code) einer Type oder eines spezifischen Stils hiervon. Beispiele für Typen beinhalten Times New Roman, Helvetica, Calibri, Baskerville Old Face, Britannic Bold, Neuropol, Vladimir Script und Courier New. Historisch entsprach jede Type einer bestimmten Punktgröße, da Buchstaben aus einzelnen physischen Marken bestehen. In modernen digitalen Umgebungen kann ein Font jedoch Zeichen in vielen verschiedenen Punktgrößen beinhalten oder zur Erzeugung hiervon verwendbar sein. Ein Font kann auch derart betrachtet werden, dass er grundlegende Stilvariationen oder Effekte, so beispielsweise „kursiv” oder „fett” beinhaltet. Alternativ können verschiedene Punktgrößen und grundlegende Effekte als getrennte Fonts erstellt werden. Mehrere verschiedene Fonts können auf eine einzelne Sprache zugeschnitten sein, oder es kann ein einzelner Font mehrere verschiedene Sprachen, so beispielsweise mehrere verschiedene westeuropäische Sprachen, abdecken. Ein „Fontvorrat” (font repository) bezeichnet einen Ort bzw. eine Stelle, eine Entität, ein Modul, einen Dienst, eine Vorrichtung oder eine Kombination hieraus mit Zugriff auf mehrere Fontdefinitionen und der Fähigkeit, wenigstens Teile der Fontdefinitionen an anfordernde Nutzer, Module, Vorrichtungen und dergleichen zu verteilen.
Ein „Zeichen” (character) bezeichnet das Konzept oder die Abstrahierung einer Texteinheit. Beispiele für Zeichen beinhalten einen Buchstaben eines Alphabets, ein Symbol, ein Bildzeichen, ein Satzzeichen, ein Emoji, ein Logogramm oder eine beliebige andere von Menschen lesbare oder verstehbare Form, die unter Verwendung einer Rechenvorrichtung als Text dargestellt werden kann. Ein Zeichen entspricht einer Glyphe (glyph). Eine „Glyphe” bezeichnet die physische Gestalt oder Form, die vom menschlichen Auge wahrnehmbar ist und das entsprechende Zeichen verkörpert. Eine Rechenvorrichtung gibt eine Glyphe auf einem Anzeigeschirm oder als Papierausdruck wieder. Eine Glyphe ist dahingehend spezifisch, wie ein bestimmter Font die Glyphe wiedergibt, wobei jedoch ein Zeichen allgemeiner als mehrere Fonts ist. Ein Zeichen oder eine Glyphe können einem Codepunkt zugewiesen sein oder diesem entsprechen. Ein „Codepunkt” bezeichnet eine definierte oder akzeptierte Darstellung eines gegebenen Zeichens oder einen Code oder eine Codierung hierfür. Beispiele für Codepunkte beinhalten Zahlen, alphanummerische Zeichen, binär codierte Ziffern, eine allgemeine Zeichenidentifizierung, einen Unicode-Codepunkt, Big5, ShifJIS, ASCII oder eine Kombination hieraus. Ein Codepunkt kann in digitaler Form beispielsweise als nichtnegative ganze Zahl, als Zeichenfolge und dergleichen mehr realisiert sein. Da enge Entsprechungen zwischen „Zeichen”, „Glyphe” und „Codepunkt” bestehen, werden diese Begriffe gegebenenfalls bisweilen gleichwertig verwendet. Obwohl Codepunkte beispielsweise eigentlich zum Erstellen einer komprimierten Darstellung verwendet werden, kann die komprimierte Darstellung auch derart, dass sie angeforderten Zeichen entspricht, beschrieben werden. Bei einem weiteren Beispiel beinhaltet, obwohl Zeichen unter Verwendung entsprechender Codepunkte angefordert werden, die entsprechende Fontbeschreibung Daten, die Glyphen entsprechen und deren Wiedergabe ermöglichen. Verwirklicht sein kann in gewissem Sinn das abstrakte Konzept eines Zeichens als computerverwertbares Zeichen, das Codepunkt genannt wird, oder als von Menschen erkennbare Form, die Glyphe genannt wird, die jedoch auch fontspezifisch sein kann.
Eine „Fontdefinition” (font definition) bezeichnet Anweisungen oder andere Informationen, die zum Erzeugen oder Wiedergeben von Glyphen eines entsprechenden Fonts verwendbar sind, so beispielsweise Anweisungen für eine vektorbasierte Verkörperung der Glyphen. Eine Fontdefinition kann zudem beschreiben, wie eine Glyphe mit einer oder mehreren anderen Glyphen mit Blick auf den Abstand zwischen zwei Glyphen, die Kombination von zwei Glyphen zu einer weiteren Glyphe und dergleichen mehr wechselwirkt. Eine Fontdefinition kann derartige Informationen für jede Glyphe, die in einer gegebenen Version des Fonts konfiguriert ist, beinhalten. Mit anderen Worten, eine Fontdefinition kann einen Font als Ganzes betreffen. Im Gegensatz hierzu bezeichnet „ein Teil einer Fontdefinition” mehrere Glyphen einer Fontdefinition, jedoch weniger als alle Glyphen, die als Teil der ursprünglichen oder vollständigen Fontdefinition beinhaltet sind. Ein Teil einer Fontdefinition ist zu einem geeigneten oder strengen Teilsatz eines Fonts analog. Ein Beispiel für einen Teil eines Fonts sind die Buchstaben G, M und Z für eine Fontdefinition für den Font „Cronos Pro”, der die 26 Buchstaben des englischen Alphabetes abdeckt. Ein Teil eines Fonts kann bei einem Fontunterteilungsszenario angefordert werden, bei dem ein neuer lokaler Font genau mit einem geeigneten Teilsatz eines Fonts anstelle einer vollständigen Fontdefinition eingerichtet wird. Das Fontunterteilungsszenario kann dafür eingesetzt werden zu vermeiden, dass sehr große Fonts heruntergeladen werden müssen. Alternativ kann ein Teil eines Fonts bei einem Fonterweiterungsszenario angefordert werden, bei dem zusätzliche Zeichen zur Erweiterung eines bestehenden lokalen Fonts verwendet werden. Ein Fonterweiterungsszenario ist dann anwendbar, wenn mehrere Zeichen unerwartet oder in Echtzeit zu einer elektronischen Datei hinzugefügt werden.
Eine „komprimierte Darstellung” (compressed representation) bezeichnet Daten, so beispielsweise eine Datenstruktur, die eine Identifizierung von mehreren einzelnen Zeichen in einem Raum, einer Größe oder einer Brandbreite beinhaltet, der/die kleiner als der gesamte Raum, die gesamte Größe oder die gesamte Bandbreite ist, der/die von den mehreren einzelnen Codepunkten, die den mehreren einzelnen Zeichen entsprechen, beansprucht werden. Eine komprimierte Darstellung für mehrere Zeichen kann dadurch erstellt werden, dass ein Kompressionsmechanismus auf mehrere Codepunkte, die den mehreren Zeichen entsprechen, angewendet wird. Ein Beispiel für eine sich ergebende Datenstruktur ist eine wahrscheinlichkeitsbasierte Datenstruktur, bei der auf Genauigkeit oder Sicherheit im Austausch gegen eine geringere Größe in gewissem Ausmaß verzichtet wird. Eine wahrscheinlichkeitsbasierte (probabilistic) Datenstruktur kann als Bloom-Filter oder durch Anwenden von einer oder mehreren Hashing-Operationen auf jeden der mehreren Codepunkte, die in einer komprimierten Darstellung codiert werden sollen, erstellt werden. Weitere Typen von wahrscheinlichkeitsbasierten Datenstrukturen können alternativ als komprimierte Darstellung verwendet werden.
Eine „Fontanforderung” (font request) bezeichnet eine Anforderung wenigstens eines Teiles einer Fontdefinition von einem Fontvorrat. Eine Fontanforderung beinhaltet eine komprimierte Darstellung von gewünschten Zeichen. Eine Fontanforderung kann zudem einen aktuellen Status eines lokalen Fonts beinhalten. Eine Endnutzervorrichtung kann eine Fontanforderung an eine Servervorrichtung, die mit einer mehrere Fontdefinitionen speichernden Fontdatenbank gekoppelt ist, senden. Die Servervorrichtung gibt eine Fontbeschreibung aus.
Eine „Fontbeschreibung” (font description) bezeichnet Glyphendaten, die ermöglichen, dass mehrere Glyphen eines Teiles eines Fonts durch eine Endnutzervorrichtung wiedergegeben werden. Eine Fontdarstellung wird durch einen Fontvorrat aus einer Fontdefinition erzeugt. Eine Fontbeschreibung kann zudem Informationen beinhalten, die an der Endnutzervorrichtung die Erzeugung eines lokalen Fonts ermöglichen, der wenigstens Glyphen, die den mehreren angeforderten Zeichen entsprechen, beinhaltet. Des Weiteren kann eine Fontbeschreibung wenigstens eine Erweiterungsanweisung, die Glyphendaten zu einem aktuellen lokalen Font hinzufügt, beinhalten.
Ein „lokaler Font” (local font) bezeichnet einen Font, der an einer Endnutzervorrichtung vorhanden ist und von der Endnutzervorrichtung zur Wiedergabe von Glyphen an einer Anzeige oder einem Drucker verwendbar ist. Ein lokaler Font kann weniger als eine ganze Fontdefinition beinhalten. Das „Erzeugen eines lokalen Fonts” bezeichnet das Erstellen eines lokalen Fonts unter Verwendung einer Fontbeschreibung, die aus einem Fontvorrat empfangen wird. Ein lokaler Font kann dadurch erstellt werden, dass ein neuer lokaler Font als Fontteilsatz (das heißt als eigentlicher oder strenger Teilsatz) einer Fontdefinition wenigstens unter Verwendung von Glyphendaten einer Fontbeschreibung eingerichtet wird. Alternativ kann ein lokaler Font durch Erweitern eines lokalen Fonts erstellt werden, indem Glyphendaten zu einem bestehenden lokalen Font wenigstens unter Verwendung von Glyphendaten und einer Erweiterungsanweisung einer Fontbeschreibung hinzugefügt werden.
Ein „Status eines lokalen Fonts” (state of a local font) bezeichnet eine Information, die angibt, über welchen Teil einer Fontdefinition eine Endnutzervorrichtung aktuell als lokaler Font an der Endnutzervorrichtung verfügt. Ein Status eines lokalen Fonts kann beispielsweise als Datenstruktur implementiert sein, die angibt, welche Glyphen einer Fontdefinition eine Endnutzervorrichtung wiedergeben kann. Wünscht eine Endnutzervorrichtung das Erweitern eines bestehenden lokalen Fonts, so kann die Endnutzervorrichtung einen Status des lokalen Fonts an einen Fontvorrat senden, um den Fontvorrat darüber zu informieren, über welche Glyphendaten sie bereits verfügt.
Eine „Erweiterungsanweisung” (augmentation instruction) bezeichnet eine Information, die erklärt, wie eine Endnutzervorrichtung neue Glyphendaten in einen bestehenden lokalen Font aufnehmen oder zu diesem hinzufügen kann, um einen neuen lokalen Font zu erzeugen, der ermöglicht, dass die Endnutzervorrichtung die vorher erworbenen Glyphen wie auch die neuerworbenen Glyphen unter Verwendung des neuen lokalen Fonts wiedergibt.
Ein „Fontinstanziierungsmodul” (font instantiation module) bezeichnet ein Modul, das fontbezogene Information ändern kann, um den Erwerb eines Teiles eines Fonts unter Verwendung eines Kompressionsmechanismus zum Auflisten von gewünschten Zeichen zu erleichtern. Ein Fontinstanziierungsmodul, das an einer Endnutzervorrichtung vorhanden ist und darauf ausgeführt wird, kann die hier beschriebenen clientseitigen Operationen durchführen. Ein Fontinstanziierungsmodul, das auf einer Servervorrichtung vorhanden ist und darauf ausgeführt wird, kann die hier beschriebenen fontvorratsseitigen Operationen durchführen.
Zudem kann, außer es ergibt sich aus dem Kontext anders, die Verwendung des Wortes „oder” als Verwendung eines „inklusiven Oders” oder als Begriff betrachtet werden, der die Einbeziehung oder Anwendung eines oder mehrerer Objekte, die durch das Wort „oder” verknüpft sind, ermöglicht (So kann beispielsweise die Aussage „A oder B” derart gedeutet werden, dass sie nur „A”, nur „B” oder sowohl „A” als auch „B” zulässt oder betrifft.
Exemplarische Umgebung
1 zeigt eine Umgebung 100 für exemplarische Ausführungsformen, die betreibbar sind, um die hier beschriebenen Techniken einzusetzen, die den Erwerb eines Fontteiles unter Verwendung eines Kompressionsmechanismus betreffen. Wie von oben nach unten dargestellt ist, beinhaltet die exemplarische Umgebung 100 wenigstens einen Dienstanbieter (Service-Provider) 118, wenigstens eine Servervorrichtung 104, wenigstens ein Netzwerk 106, wenigstens eine Endnutzervorrichtung 102 und wenigstens einen Endnutzer 108. Die Endnutzervorrichtung 102 oder die Servervorrichtung 104 können wenigstens ein Fontinstanziierungsmodul 110 beinhalten. Auf der oberen oder Serverseite der Umgebung 100 zeigt 1 auch wenigstens eine Fontdatenbank 116 und wenigstens einen Fontvorrat 120. Bei einer exemplarischen Operation beinhaltet die Umgebung 110 des Weiteren wenigstens eine Fontanforderung 112 und wenigstens eine Fontbeschreibung 114.
Bei einer oder mehreren Ausführungsformen erleichtert wenigstens ein Fontinstanziierungsmodul 110 der Endnutzervorrichtung 102 das Beziehen wenigstens eines Teiles eines Fonts aus der Fontdatenbank 116 über die Servervorrichtung 104 unter Verwendung der Fontanforderung 112 und der Fontbeschreibung 114. Damit kann das Fontinstanziierungsmodul 110 wenigstens teilweise eine oder mehrere der hier beschriebenen Techniken oder Systeme zum Erwerben eines Fontteiles unter Verwendung eines Kompressionsmechanismus implementieren. Das Fontinstanziierungsmodul 110 kann an der Endnutzervorrichtung 102, der Servervorrichtung 104, einer Kombination hieraus und dergleichen mehr befindlich sein oder dort ausgeführt werden.
Wie gezeigt ist, ist der Endnutzer 108 mit der Endnutzervorrichtung 102 gekoppelt, und es ist der Dienstanbieter 118 mit der Servervorrichtung 104 gekoppelt. Die Endnutzervorrichtung 102 kann mit der Servervorrichtung 104 über das wenigstens eine Netzwerk 106 oder umgekehrt in Kommunikation sein. Das Netzwerk 106 kann von wenigstens einem Teil eines oder mehrerer Netzwerktypen gebildet werden. Beispiele für Netzwerktypen beinhalten ein öffentliches Netzwerk, ein privates Netzwerk, das Internet, das Web, ein Ethernet, ein Intranet, ein Extranet, ein Ortsbereichsnetzwerk (LAN), ein Großbereichsnetzwerk (WAN), ein Drahtlosnetzwerk, ein verdrahtetes Netzwerk, ein zellenbasiertes Netzwerk, ein Infrastrukturnetzwerk, ein ad-hoc-Netzwerk, ein Bluetooth-Netzwerk, ein Wi-Fi-Netzwerk, ein LTE-Netzwerk (Long-Term Evolution LTE), ein öffentliches geschaltetes Telefonnetzwerk (Public-Switched Telephone Network PSTN) oder eine Kombination hieraus.
Der Endnutzer 108, so beispielsweise eine Person, die durch das Web browst, kann eine Webseite anfordern, die zur Wiedergabe durch ein Programm, so beispielsweise einen Webbrowser, unter Verwendung der Endnutzervorrichtung 102 geeignet ist. Die Endnutzervorrichtung 102 kann als beliebiger geeigneter Typ von Rechenvorrichtung implementiert oder konfiguriert sein. Beispiele für eine Endnutzervorrichtung 102 beinhalten einen Desktopcomputer, einen Laptopcomputer, eine Mobilvorrichtung (unter Annahme einer portablen Konfiguration beispielsweise ein Tablet, ein Mobiltelefon oder ein Phablet), eine Mobilvorrichtung, die mit einem gesonderten Schirm gekoppelt ist, eine Unterhaltungseinrichtung, so beispielsweise einen intelligenten Fernseher, eine Spielekonsole, eine Vorrichtung mit Konfiguration zum Empfangen einer Gebärdeneingabe, eine Vorrichtung mit Konfiguration zum Empfangen einer Sprach- oder Videoeingabe, eine Vorrichtung mit Konfiguration zur Bereitstellung einer 2D- oder 3D-Bildausgabe, eine Vorrichtung mit Konfiguration zur Bereitstellung einer Tonausgabe, eine tragbare Rechenvorrichtung, so beispielsweise eine intelligente Armbanduhr oder eine intelligente Brille, oder eine Kombination hieraus. Damit kann die Endnutzervorrichtung 102 von einer vergleichsweise große Ressourcen aufweisenden Vorrichtung mit erheblichen Speicher- und Prozessorressourcen (beispielsweise einem PC oder einer Spielkonsole) zu einer vergleichsweise geringe Ressourcen aufweisenden Vorrichtung mit begrenzten Speicher- und Verarbeitungsressourcen (beispielsweise einer tragbaren Mobilvorrichtung) reichen. An der Endnutzervorrichtung 102 kann das Fontinstanziierungsmodul 110 eine eigenständige Anwendung sein, kann als Teil einer anderen Anwendung gegeben sein, kann ein Teil einer Webbrowsinganwendung sein, kann einen nativen Code beinhalten, kann plattformunabhängig anwendbaren Code (run-anywhere code) beinhalten, kann eine heruntergeladene Anwendung oder Erweiterung sein, kann ein Teil einer Bibliothek oder kann eine beliebige Kombination hieraus und dergleichen mehr sein.
Der Dienstanbieter 118 ist mit der Servervorrichtung 104 oder dem Fontvorrat 120 gekoppelt, um für die Endnutzervorrichtung 102 wenigstens einen Teil eines Fonts aus der Fontdatenbank 116 bereitzustellen. Das in 1 dargestellte exemplarische Szenario kann als „cloudbasierte” Rechenumgebung betrachtet werden, bei der die Endnutzervorrichtung 102 Fonts aus der Servervorrichtung 104, die einen Teil der „Cloud” bildet, erwirbt. Im Allgemeinen kann der Dienstanbieter 118 eine Firma oder eine andere Entität sein, die Webressourcen, so beispielsweise verschiedene Fonts, erstellt, die über das Netzwerk 106 zur Verwendung durch den Endnutzer 108 verfügbar sind. Bei bestimmten Gegebenheiten kann ein anderer Endnutzer (nicht gezeigt), der die Entwicklung von Webseiten oder Inhalt entsprechend Webstandards wünscht, einen Dienst des Dienstanbieters 118 nutzen, der den Zugriff auf in der Fontdatenbank 116 gespeicherte verschiedene Fonts bereitstellt, und zwar zur Einbeziehung in einer Webseite, die der andere Endnutzer im Web platzieren will. Die Webseite kann sodann für einen Zugriff über eine eigenständige oder eingebettete Webbrowseanwendung, die wenigstens teilweise auf einer clientseitigen Vorrichtung, so beispielsweise der Endnutzervorrichtung 102 arbeitet, zur Verfügung gestellt werden.
Der Dienstanbieter 118 ist mit der Servervorrichtung 104 gekoppelt (er besitzt, least oder verwaltet sie beispielsweise) und veranlasst eine Ausführung des Fontinstanziierungsmoduls 110, das auf der Servervorrichtung 104 befindlich ist. Die Fontdatenbank 116 speichert mehrere Fontdefinitionen (in 1 nicht explizit gezeigt) für mehrere jeweilige Fonts. Die Servervorrichtung 104 beinhaltet die Fontdatenbank 116 oder hat auf andere Weise Zugriff hierauf. Wie gezeigt ist, beinhaltet der Fontvorrat 112 eine Servervorrichtung, die zumindest Zugriff auf mehrere Fontdefinitionen hat, und zwar beispielsweise dadurch, dass eine Kopplung mit der Fontdatenbank 116 erfolgt. Alternativ kann ein Fontvorrat 120 als Dienst, Bibliothek, Modul, Speichereinheit, Kombination hieraus und dergleichen mehr mit der Fähigkeit implementiert sein, eine Fontbeschreibung für einen Anfordernden bereitzustellen, wobei der Fontvorrat 120 lokal beim Anfordernden oder auch entfernt von diesem ist.
Die Servervorrichtung 104 ist dafür konfiguriert, wenigstens einen Teil eines Fonts über das Netzwerk 106 bereitzustellen. Beispiele für eine Servervorrichtung 104 beinhalten einen Webserver, einen Server, auf dem Open-Source-Software-läuft, einen Server mit proprietärem Design, einen eigenständigen Server, eine Serverblade, einen zugewiesenen Teil einer Serverfarm, eine Serverfunktionalität, die über wenigstens eine Datenzentrale verteilt ist, oder auch eine Kombination hieraus. Obwohl in 1 explizit nur eine einzelne Servervorrichtung 104 gezeigt ist, kann die Servervorrichtung 104 auch für eine Mehrzahl von verschiedenen Vorrichtungen oder verteilte Rechenressourcen repräsentativ sein, die interoperieren oder sich koordinieren, um Operationen als „Webdienst”, „über die Cloud” oder „in der Cloud”, wie bekannt ist, durchzuführen.
Implementiert sein kann das Fontinstanziierungsmodul 110 als Softwarepaket, Hardwarevorrichtung oder unter Verwendung einer Kombination aus Software, Hardware, Firmware, einer festen logischen Schaltung und dergleichen mehr. Implementiert sein kann das Fontinstanziierungsmodul 110 auch als eigenständige Komponente der Vorrichtung 102 oder 104, wie in 1 dargestellt ist. Konfiguriert sein kann das Fontinstanziierungsmodul 110 zusätzlich oder alternativ auch als Komponente einer weiteren Anwendung, als Komponente eines Betriebssystems (OS) einer Vorrichtung, auf der es arbeitet (beispielsweise dem Betriebssystem der Endnutzervorrichtung 102 oder der Servervorrichtung 104), als Plug-in oder Erweiterungsmodul, als eigenständiger Dienst oder mit anderen Diensten integrierter Dienst, als weitere Vorrichtungsanwendung oder Funktionalität, als für ein anderes Programm verfügbare Bibliothek, als für ein anderes Programm verfügbare Anwendungsprogrammierschnittstelle (API) oder als Kombination hieraus und dergleichen mehr.
Wie bei dem exemplarischen Betriebsszenario gezeigt ist, formuliert das Fontinstanziierungsmodul 110 der Endnutzervorrichtung 102 die Fontanforderung 112 und veranlasst, dass die Fontanforderung 112 an die Servervorrichtung 104 über das Netzwerk 106 übertragen wird. In Reaktion hierauf präpariert das Fontinstanziierungsmodul 110 der Servervorrichtung 104 die Fontbeschreibung 114 und veranlasst, dass die Fontbeschreibung 114 an die Endnutzervorrichtung 102 über das Netzwerk 106 übertragen wird. Die Erzeugung, der Inhalt und die Nutzung der Fontanforderung 112 und der Fontbeschreibung 114 werden nachstehend beschrieben.
2 zeigt ein Anzeigeszenario 200 bei einer Endnutzervorrichtung 102 mit einer exemplarischen Anwendung 202, die Zeichen in verschiedenen Fonts 210 als entsprechende Glyphen 212 wiedergibt. Wie dargestellt ist, präsentiert die Anwendung 202 ein Anwendungsfenster 204 für den Endnutzer 108 über einen Anzeigeschirm, einen Projektor oder ähnliches. Die Anwendung 202 beinhaltet ein Glyphenwiedergabemodul 206 und einen lokalen Font 208 wie auch das Fontinstanziierungsmodul 110. Das Anwendungsfenster 204 ist derart dargestellt, dass es mehrere verschiedene Fonts 210 aufweist. Sämtliche der verschiedenen Fonts 210 beinhalten Informationen darüber, wie wenigstens eine Glyphe 212 wiedergegeben werden soll. Einige der Glyphen 212 sind in 2 explizit so, wie sie in dem Anwendungsfenster 204 wiedergegeben werden, mit einem Oval und einem Bezugszeichen markiert.
Bezieht der Endnutzer 108 mit der Zeit verschiedenen textartigen Inhalt, so beispielsweise dann, wenn der Endnutzer 108 durch das Web wandert und Webseiten herunterlädt, so kann der verschiedene textartige Inhalt derart konzipiert sein, dass er verschiedenartige Fonts verwendet. Es gibt zahlreiche Sprachen auf der Welt. Einige der dargestellten exemplarischen Fonts 210 betreffen Englisch, Chinesisch (vereinfacht), Arabisch und Deutsch. Des Weiteren sind zumindest für die häufiger verwendeten Sprachen Hunderte von Fonts pro Sprache konzipiert worden. Infolgedessen werden die Fonts 210 mit der Zeit nach Bedarf erworben, wenn der Endnutzer 108 verschiedenen textartigen Inhalt, der in dem Anwendungsfenster 204 präsentiert werden soll, bezieht.
Nachdem der Font 210 bezogen und als wenigstens ein lokaler Font 208 gespeichert worden ist, kann der lokale Font 208 zur Wiedergabe von Glyphen 210 entsprechend Fontattributen oder Glyphendaten des lokalen Fonts 208 verwendet werden. Der lokale Font 208 kann beispielsweise als Datei, Datenbank oder Kombination hieraus implementiert sein. Wünscht die Anwendung 202 beispielsweise die Anzeige des Wortes „cat” („Katze”), so greift das Glyphenwiedergabemodul 206 auf den lokalen Font 208 zu und bestimmt, wie die einzelnen Buchstaben „c”, „a” und „t” wiedergegeben werden sollen (beispielsweise wie Pixel hierfür zu zeichnen oder zu aktivieren sind). Das Glyphenwiedergabemodul 206 kann zudem von dem lokalen Font 208 Information darüber beziehen, wie die verschiedenen Glyphen 212 miteinander wechselwirken. So kann beispielsweise der Buchstabe „a” gegen oder in die offene Krümmung des Buchstabens „c” geschoben werden, oder es kann die kreuzende Linie des Buchstaben „t” mit dem oberen Ende des Buchstabens „a” verbunden werden.
Das Fontinstanziierungsmodul 110, das Glyphenwiedergabemodul 206 und der lokale Font 208 sind als Teil der Anwendung 202 gezeigt. Eines oder mehrere hiervon können jedoch alternativ auch von der Anwendung 202 getrennt sein. So kann das Fontinstanziierungsmodul 110 beispielsweise eine gesonderte Anwendung sein, oder es kann der lokale Font 208 Teil eines Betriebssystems (nicht gezeigt) der Endnutzervorrichtung 102 sein.
Nachdem eine exemplarische Umgebung betrachtet worden ist, folgt nunmehr eine Diskussion einiger exemplarischer Details der Systeme oder Techniken zum Erwerben eines Fontteiles unter Verwendung eines Kompressionsmechanismus entsprechend einer oder mehreren Ausführungsformen.
Systeme und Techniken
3 zeigt ein exemplarisches Szenario 300, bei dem eine Endnutzervorrichtung 102 imstande ist, einen Teil eines Fonts aus einer Servervorrichtung 104-1 in Reaktion auf eine Fontanforderung 112 zu erwerben. 3 zeigt zwei Servervorrichtungen, nämlich die Servervorrichtung 104-1 und eine Servervorrichtung 104-2. Die Servervorrichtung 104-1 ist als Fontvorrat 120 implementiert, während die Servervorrichtung 104-2 als Webseiten anbietender Webserver implementiert ist. Wie dargestellt ist, beinhaltet das Szenario 300 zudem die Fontanforderung 112, die Fontbeschreibung 114, die Fontdatenbank 116 und einen Verweis auf den Fontvorrat 120. Die Fontdatenbank 116 speichert mehrere Fontdefinitionen 310 für mehrere Fonts.
In einer exemplarischen webbezogenen Umgebung wirkt die Servervorrichtung 104-2 als Webserver, der Information über das Web, so beispielsweise von einer Webseite 302, bereitstellen kann. Unter Verwendung einer Anwendung, so beispielsweise eines Webbrowsers, lädt die Endnutzervorrichtung 102 die Webseite 302 herunter. Die Webseite 302 beinhaltet mehrere Zeichen 316, die von der Endnutzervorrichtung 102 als Glyphen 212 (siehe beispielsweise 2) entsprechend einem oder mehreren Fonts angezeigt werden sollen. Die Webseite 302 kann ein Fontbestimmungsmodul 304 beinhalten. Das Fontbestimmungsmodul 304 bestimmt, welcher Font oder welche Fonts von der Webseite 302 verwendet werden und welche Zeichen 316 in der Webseite 302 beinhaltet sind. Das Fontbestimmungsmodul 304 kann beispielsweise als JavaScript-Code implementiert sein. Das Fontbestimmungsmodul 304 kann mit Font- und Zeicheninformation vorab geladen werden, oder es kann das Fontbestimmungsmodul 304 die textartigen Inhalte der Webseite 302 beispielsweise diesbezüglich prüfen, ob die Webseite 302 heruntergeladen wird oder wann sie angezeigt, ausgedruckt oder auf andere Weise wiedergegeben werden soll.
Das Fontinstanziierungsmodul 110 der Endnutzervorrichtung 102 kommuniziert mit dem Fontbestimmungsmodul 304, um zu bestimmen, welche Zeichen 316 in der Webseite 302 beinhaltet sind. Das Fontinstanziierungsmodul 110 kann bestimmen, ob ein spezifizierter lokaler Font 208 bereits an der Endnutzervorrichtung 102 vorhanden ist. Ist dem so, so kann das Fontinstanziierungsmodul 110 des Weiteren bestimmen, ob der spezifizierte lokale Font 208 bereits die Zeichen 316, die angezeigt werden sollen, beinhaltet. Ist dem so, so kann das Glyphenwiedergabemodul 206 (siehe 2) die entsprechenden Glyphen 212 für die bestimmten Zeichen 316 der Webseite 302 unter Verwendung des lokalen Fonts 208 wiedergeben, ohne einen Fontteil zu erwerben.
Ist der spezifizierte Font an der Endnutzervorrichtung 102 jedoch nicht vorhanden, so ist das Fontinstanziierungsmodul 110 dafür konfiguriert, einen Teilsatz des spezifizierten Fonts aus dem Fontvorrat 120 anzufordern, um einen neuen lokalen Font 208 einzurichten. Dieser Aspekt der Fontunterteilung wird nachstehend noch beschrieben. Wenn der spezifizierte Font alternativ an der Endnutzervorrichtung 102 vorhanden ist, jedoch eine oder mehrere entsprechende Glyphen, die angezeigt werden sollen, fehlen, ist das Fontinstanziierungsmodul 110 dafür konfiguriert, eine Fonterweiterung aus dem Fontvorrat 120 anzufordern, um sie zu dem bestehenden lokalen Font 208 hinzuzufügen. Der Aspekt der Fonterweiterung wird nachstehend noch insbesondere anhand 6 beschrieben. Obwohl dies in 3 nicht gezeigt ist, kann die Webseite 302 auch auf das Fontbestimmungsmodul 304 verzichten. In derartigen Fällen kann das Fontinstanziierungsmodul 110 unabhängig oder direkt die Webseite 302 oder anderen textbasierten Inhalt durchsuchen, um zu bestimmen, welche Fontdaten als Teil des lokalen Fonts 208 von Nutzen sind.
Bei einer oder mehreren Ausführungsformen erzeugt das Fontinstanziierungsmodul 110 die Fontanforderung 112. Das Fontinstanziierungsmodul 110 versieht die Fontanforderung 112 mit einer komprimierten Darstellung 308 und kann zudem einen Status des lokalen Fonts 312 beinhalten. Der Status des lokalen Fonts 312 gibt den aktuellen Status des lokalen Fonts 208 für ein Fonterweiterungsszenario, das nachstehend noch anhand 6 beschrieben wird, wieder. Die komprimierte Darstellung 308 wird in Reaktion auf die mehreren Zeichen 306, die als für die Wiedergabe der Webseite 302 relevant bestimmt worden sind, berechnet. Die komprimierte Darstellung 308 kann beispielsweise auf Grundlage von mehreren Codepunkten berechnet werden, die jeweils mehreren Zeichen 316 entsprechen. Eine exemplarische Berechnung einer komprimierten Darstellung 308 wird nachstehend anhand 4, beschrieben. Die Fontanforderung 112 kann beispielsweise als URL implementiert sein, die an einen Webserver weitergereicht wird, und kann über mehrere Proxyserver des Webs laufen. Das Fontinstanziierungsmodul 110 an der Endnutzervorrichtung 102 veranlasst, dass die Fontanforderung 112 an die Servervorrichtung 104-1 übertragen wird.
In der Servervorrichtung 104-1 empfängt das Fontinstanziierungsmodul 110 die Fontanforderung 112. Die komprimierte Darstellung 308 wird decodiert, um die mehreren Codepunkte zu identifizieren, um so wenigstens die mehreren Zeichen 316 zu ermitteln, die von dem Fontbestimmungsmodul 304 als für die Wiedergabe der Webseite 302 relevant bestimmt worden sind. Das Fontinstanziierungsmodul 110 greift auf die Fontdefinition 310 der Fontdatenbank 116 zu, um Fontattribute für mehrere Glyphen entsprechend den mehreren Zeichen 316 zu extrahieren. Das Fontinstanziierungsmodul 110 präpariert die Fontbeschreibung 114 unter Verwendung der extrahierten Fontattribute. Die Fontbeschreibung 114 wird mit Glyphendaten 314 versehen und kann wenigstens eine Erweiterungsanweisung 306 beinhalten. Die Glyphendaten 314 werden aus den Fontattributen hergeleitet und beschreiben, wie die Zeichen 316 als Glyphen 212 allein oder im Verbund mit anderen Zeichen 316 für den spezifizierten Font wiedergegeben werden sollen. Die Erweiterungsanweisung 306 gibt an, wie die Glyphendaten 314 zu einem bestehenden lokalen Font 208 hinzugefügt werden sollen, was nachstehend noch anhand 6 für ein Fonterweiterungsszenario beschrieben wird. Betrifft die Fontanforderung 112 kein Fonterweiterungsszenario, so kann der Status des lokalen Fonts 312 in der Fontanforderung 112 weggelassen werden, und es kann die Erweiterungsanweisung 306 in der Fontbeschreibung 114 weggelassen werden.
Das Fontinstanziierungsmodul 110 in der Servervorrichtung 104-1 verpackt die Glyphendaten 314 und die Erweiterungsanweisung 306 als Fontbeschreibung 114. Das Fontinstanziierungsmodul 110 veranlasst, dass die Servervorrichtung 104-1 die Fontbeschreibung 114 an die Endnutzervorrichtung 102 überträgt. Das Fontinstanziierungsmodul 110 an der Endnutzervorrichtung 102 empfängt die Fontbeschreibung 114 und verwendet die Fontbeschreibung 114 zur Erzeugung des lokalen Fonts 208. Der sich ergebende lokale Font 208 ist eine Version der Fontdefinition 310 und beinhaltet die mehreren Glyphen 212, die für die Webseite 302 mit Blick auf die bestimmten Zeichen 316 wiedergegeben werden sollen.
4 zeigt einen exemplarischen Lösungsansatz 400 zum Erzeugen einer Fontanforderung 112 durch eine Endnutzervorrichtung. Wie gezeigt ist, beinhaltet der Lösungsansatz 400 mehrere Zeichen 316, mehrere Codepunkte 406, mehrere Hashing-Operationen 410, eine wahrscheinlichkeitsbasierte Datenstruktur 408 und eine komprimierte Darstellung 308. Der Lösungsansatz 400 zeigt zudem mehrere Operationen wie eine Operation des Ermittelns einer Entsprechung 402, eine Operation des Berechnens einer Codierung 404 und eine Operation der Einbettung 412.
Bei einer oder mehreren exemplarischen Ausführungsformen ist die komprimierte Darstellung 308 als wahrscheinlichkeitsbasierte Datenstruktur 408 implementiert. Obwohl zahlreiche Zeichen 316 in einer einzigen wahrscheinlichkeitsbasierten Datenstruktur 408 codiert sein können, sind aus Gründen der Klarheit nur zwei verschiedene Zeichen 316 in 4 als codiert dargestellt. Das Zeichen 316 links wie auch der entsprechende Codepunkt 406 und mehrere zugehörige Pfeile sind mit durchgezogenen Linien gezeichnet. Das Zeichen 316 rechts wie auch der entsprechende Codepunkt 406 und mehrere zugehörige Pfeile sind mit gestrichelten Linien gezeichnet.
Jedes Zeichen 316 entspricht einem Codepunkt 406. Die Codepunkte 406 können auf eine einzige gegebene Fontdefinition 310 (siehe beispielsweise 3) angewendet werden, können mehrere Fontdefinitionen 310 betreffen, können universell eingesetzt werden (beispielsweise Unicode-Codepunkte) und dergleichen mehr. Implementiert sein kann ein Codepunkt 406 beispielsweise als mehrstelliger alphanummerischer Satz von Zeichen, so beispielsweise als vierstellige Zahl. Verwirklicht werden können die Codepunkte 406 beispielsweise mit einer Unicode-Codepunktformatierung. Bei der Operation der Ermittlung einer Entsprechung 402 werden die Codepunkte 406 ermittelt, wobei die mehreren Codepunkte 406 jeweils den mehreren Zeichen 316, die angefordert werden sollen, entsprechen. Ein Emoji-Zeichen mit lächelnden Sternenaugen kann beispielsweise dem Codepunkt „47822” entsprechen. Ein Satz von drei durch Kommata getrennten Codepunkten 406, von denen einer dem lächelnden Emoji entspricht, kann daher „78,559,47822” sein. Jeder dieser drei Codepunkte wird sodann in der wahrscheinlichkeitsbasierten Datenstruktur 408 codiert.
Die wahrscheinlichkeitsbasierte Datenstruktur 408 beinhaltet mehrere Felder, die gesetzt (beispielsweise durch Zuweisung des Wertes „1”) oder gelöscht (beispielsweise durch Zuweisung des Wertes „0”) werden können. Die wahrscheinlichkeitsbasierte Datenstruktur 408 kann unter Verwendung eines/einer oder mehrerer von zahlreichen verfügbaren Algorithmen oder Strategien erstellt werden. Beispiele beinhalten einen Bloom-Filter, einen Hyperlog, einen kinetischen Hänger (kinetic hanger), ein lokal empfindliches Hashing, einen Minihash, einen Quotientenfilter, einen Zufallsbaum (random tree), eine Streichliste (skip list) oder eine Kombination hieraus. Beispiels- und nicht beschränkungshalber wird eine Bloom-Filter-Technik auf die mehreren Codepunkte 406 für die beiden Lösungsansätze von 4 und 5 angewendet.
Für das Berechnen der Codieroperation 404 wird jedes Feld der wahrscheinlichkeitsbasierten Datenstruktur 408 zunächst gelöscht. Das Fontinstanziierungsmodul 110 der Endnutzervorrichtung 102 wendet jeden Codepunkt 406 auf mehrere Hashing-Operationen 410 an, und es wird die wahrscheinlichkeitsbasierte Datenstruktur 408 entsprechend programmiert. Wie gezeigt ist, werden drei Hashing-Operationen 410-1, 410-2 und 410-3 eingesetzt. Es können jedoch alternativ auch mehr oder weniger Hashing-Operationen 410 eingesetzt werden.
Bei einer exemplarischen Bloom-Filter-Implementierung wird jeder Codepunkt 406 dreimal gehasht, und zwar einmal von jeder Hashing-Operation 410-1, 410-2 oder 410-3. Jede Hashing-Operation 410 hasht den Codepunkt 406 auf ein Feld der wahrscheinlichkeitsbasierten Datenstruktur 408. Das Fontinstanziierungsmodul 110 setzt jedes Feld, auf das eine Hashing-Operation 410 einen gegebenen Codepunkt abbildet. Für den linken Codepunkt 406 mit den durchgezogenen Linien sind die dritten, fünften und achten Felder gesetzt. Für den rechten Codepunkt 406 mit den gestrichelten Linien sind die zweiten, fünften und achten Felder gesetzt. Bei einem Bloom-Filter können zwei oder mehr verschiedene Codepunkte 406 auf dieselbe Gruppe von Feldern in Abhängigkeit von der Anzahl oder den Typen von Hashing-Operationen 410 und der Länge oder Größe der wahrscheinlichkeitsbasierten Datenstruktur 408 abgebildet werden. Die Wahrscheinlichkeit einer derartigen duplizierenden Abbildung (duplicative mapping) kann eingedämmt, wenn nicht ganz beseitigt werden, indem die Anzahl der Hashing-Operationen 410, die Größe der wahrscheinlichkeitsbasierten Datenstruktur 408, die Typen der eingesetzten Hashing-Operationen 410, eine Kombination hieraus und dergleichen mehr angepasst werden.
Nachdem die mehreren Codepunkte 406, die den mehreren Zeichen 316 entsprechen, jeweils gehasht und zum Programmieren der wahrscheinlichkeitsbasierten Datenstruktur 408 verwendet worden sind, wird die komprimierte Darstellung 308 berechnet. Das Fontinstanziierungsmodul 110 (siehe beispielsweise 3) führt die Operation der Einbettung 412 durch, indem die komprimierte Darstellung 308 in die Fontanforderung 112 eingefügt wird. Obwohl dies explizit nicht gezeigt ist, kann das Fontinstanziierungsmodul 110 zudem einen Font spezifizieren, indem in die Fontanforderung 112 ein Verweis auf einen zur Wiedergabe geeigneten Font, so beispielsweise eine Identifizierung einer Fontdefinition 310, aufgenommen wird. Ist die Fontanforderung 112 als URL implementiert, so kann die Fontanforderung 112 zudem eine Internetadresse der betroffenen Servervorrichtung im Web beinhalten.
5 zeigt einen exemplarischen Lösungsansatz 500 zum Erzeugen einer Fontbeschreibung 114 durch eine Servervorrichtung in Entsprechung zu einer Fontanforderung 112 (beispielsweise von 3 oder 4). Wie dargestellt ist, beinhaltet der Lösungsansatz 500 mehrere Operationen, nämlich eine Decodieroperation 502, eine Ermittlungsoperation 504, eine Zugriffsoperation 506 und eine Präparationsoperation 508. Eine wahrscheinlichkeitsbasierte Datenstruktur 408 kann zum Implementieren einer komprimierten Darstellung 308 verwendet werden. Zum Decodieren einer wahrscheinlichkeitsbasierten Datenstruktur 408 wird jedes codierte Zeichen 316 eines angegebenen Fonts geprüft, um zu bestimmen, ob das Zeichen 316 angefordert wird. Bei einer gegebenen Fontdefinition entspricht jedes Zeichen 316 einem Codepunkt 406. Daher wird jeder Codepunkt 406 eines Satzes von Codepunkten 516 für eine gegebene Fontdefinition als Teil der Decodieroperation 502 decodiert.
Obwohl die Codepunkte 406 der Anzahl nach Hunderte oder Tausende oder mehr sein können, sind aus Gründen der Klarheit nur zwei Codepunkte 406 gezeigt. Der Codepunkt 406 links wie auch mehrere zugehörige Pfeile sind mit durchgezogenen Linien dargestellt. Der Codepunkt 406 rechts sowie mehrere zugehörige Pfeile sind mit gestrichelten Linien dargestellt. Ein Teil der Decodieroperation 502 kann eine Codieroperation 512 beinhalten. Bei der Codieroperation 512 wendet bei einer exemplarischen Bloom-Filter-Implementierung das Fontinstanziierungsmodul 110 (beispielsweise der Servervorrichtung 104-1 von 3) die mehreren Hashing-Operationen 410 auf jeden der Codepunkte 406 des Satzes von Codepunkten 516 zum Berechnen von mehreren Codierergebnissen 514 an (beispielsweise zum Berechnen von mehreren Hashing-Ergebnissen). Die mehreren Codierergebnisse 514 können in Reaktion auf eine empfangene Fontanforderung 112 (siehe beispielsweise 3) berechnet werden. Alternativ können die mehreren Codierergebnisse 514 für jeden Satz von Codepunkten 516 für jede Fontdefinition 310 vorab berechnet und zum anschließenden Vergleich mit einer empfangenen komprimierten Darstellung 308 vorgehalten werden.
Als Teil der Decodieroperation 502 vergleicht das Fontinstanziierungsmodul 110 die mehreren Codierergebnisse 514 mit den Feldern der wahrscheinlichkeitsbasierten Datenstruktur 408 zum Identifizieren derjenigen Codepunkte 406, die zu der komprimierten Darstellung 308 passen. Bei dem Codepunkt 406 links mit den durchgezogenen Linien bewirkt jede Hashing-Operation 410 eine Abbildung auf ein Feld, das gesetzt ist, wie durch die durchgezogenen Prüfmarken in der wahrscheinlichkeitsbasierten Datenstruktur 408 angegeben ist. Infolgedessen gilt ein Zeichen, das dem linken Codepunkt 406 entspricht, als von der Endnutzervorrichtung 102 angefordert, wie durch ein großes stilisiertes Prüfzeichen unter dem linken Codepunkt 406, der unter der wahrscheinlichkeitsbasierten Datenstruktur 408 dargestellt ist, angegeben ist. Im Gegensatz hierzu bewirken bei dem Codepunkt 406 rechts mit gestrichelten Linien zwei der Hashing-Operationen 410-1 und 410-2 eine Abbildung auf Felder, die gesetzt sind, wie durch die gestrichelten Prüfzeichen angegeben ist. Die Hashing-Operation 410-3 bewirkt jedoch eine Abbildung auf ein Feld, das nicht gesetzt ist, wie durch das gestrichelte Zeichen „x” angegeben ist. Infolgedessen gilt ein Zeichen, das dem rechten Codepunkt 406 entspricht, als nicht von der Endnutzervorrichtung 102 angefordert, wie durch das große stilisierte Zeichen „X” unter dem rechten Codepunkt 406, der unter der wahrscheinlichkeitsbasierten Datenstruktur 408 dargestellt ist, angegeben ist.
Bei der Ermittlungsoperation 504 wird jedes Zeichen 316, das einem passenden Codepunkt 406 entspricht, ermittelt. Der Codepunkt „2374” kann beispielsweise entsprechend dem Buchstaben „u” mit Umlaut (beispielsweise „ü”) ermittelt werden. Das ermittelte Zeichen 316 entspricht einer Glyphe 212. Das Fontinstanziierungsmodul 110 greift auf die Fontdefinition 310 unter Verweis auf das ermittelte Zeichen 316 zu, um wenigstens ein Fontattribut 510 zu extrahieren. Das Fontattribut 510 kann Anweisungen für die entsprechende Glyphe 206, die wiedergegeben werden soll, oder eine Erklärung darüber, wie diese wiedergegeben werden soll, beinhalten. Das Fontattribut 510 kann als vektorbasierte Darstellung der Glyphe 212 implementiert sein.
Die Ermittlungsoperation 504 und die Zugriffsoperation 506 werden für jeden Codepunkt 406 und das entsprechende Zeichen 316, von dem bestimmt wird, dass es der komprimierten Darstellung 308 entspricht, als Teil der Decodieroperation 502 wiederholt. Als Teil der Präparationsoperation 508 verpackt das Fontinstanziierungsmodul 110 die mehreren Fontattribute 510 derart, dass diese die Wiedergabeinformation in der Fontbeschreibung 114 als Glyphendaten 314 beinhalten. Die Glyphendaten 314 können einzelne Glyphen 212 oder eine Gruppierung von Glyphen 212 betreffen.
Die Lösungsansätze 400 und 500, die vorstehend anhand 4 und 5 beschrieben worden sind, sind in Situationen einsetzbar, in denen eine Fontteilmenge an der Endnutzervorrichtung 102 als neuer lokaler Font 208 neuinstanziiert wird. Diese Lösungsansätze können jedoch erwartungsgemäß auch in Situationen eingesetzt werden, in denen ein bestehender lokaler Font 208 dadurch erweitert wird, dass mehrere Glyphen 212 für mehrere entsprechende Zeichen 316 zu dem bestehenden lokalen Font 208 hinzugefügt werden. Eine exemplarische Implementierung für diese Fonterweiterung wird nachstehend anhand 6 beschrieben.
6 zeigt ein exemplarisches Szenario 600, bei dem eine Endnutzervorrichtung 102 einen Teil eines Fonts von einer Servervorrichtung 104 in einer Fonterweiterungssituation erwerben kann. Während des Webbrowsens kann eine Situation auftreten, in der ein bestehender lokaler Font 208, der einem angegebenen Font entspricht, Daten für eine Glyphe 212, die einem Zeichen 316 entspricht, dessen Wiedergabe die Anwendung wünscht, gleichwohl nicht beinhaltet. Beim Eingeben von persönlicher Information für ein Formular kann ein Endnutzer beispielsweise auf einer Webseite neue Zeichen eingeben, die in dem lokalen Font 208 nicht vorhanden sind. Das Herunterladen eines vollständig neuen Fontteiles, der auch Glyphendaten für die neuen Zeichen beinhaltet, kann zeitaufwändig oder bandbreitenintensiv sein. Demgegenüber kann das bloße Anhängen (tagging) von neuen Glyphen 212 am Ende eines lokalen Fonts 208 zu einem lokalen Font 208 führen, der groß und unhandlich oder sogar fehlerhaft ist, und zwar insbesondere dann, wenn mehr Zeichen 212 wiederholt zu dem lokalen Font 208 hinzugefügt werden.
Der lokale Font 208 kann jedoch in einer nutzbaren und kontinuierlich erweiterbaren Form erhalten bleiben, wenn die neuen Glyphen 212 sorgsam zu einem bestehenden lokalen Font 208 hinzugefügt werden. Der lokale Font 208 kann beispielsweise dafür konfiguriert sein, eine Miniaturversion der Fontdefinition 310 nachzuahmen, wenn Glyphenwiedergabedaten für jede neue Gruppe von Glyphen 212 hinzugefügt werden. Diese neue Konfigurierung des lokalen Fonts 208 kann unter Verwendung einer Erweiterungsanweisung 306 erreicht werden.
Bei einer oder mehreren Ausführungsformen analysiert das Fontinstanziierungsmodul 110 an der Endnutzervorrichtung 102 den bestehenden lokalen Font 208, um einen aktuellen Inhalt des lokalen Fonts 208 zu bestimmen. Der aktuelle Inhalt, so beispielsweise dasjenige, welche Glyphen 212 bereits vorhanden sind, stellt den Status des lokalen Fonts 312 dar. Das Fontinstanziierungsmodul 110 kann beispielsweise eine Datenstruktur erstellen, die jede Glyphe 212 angibt, die bereits in dem bestehenden lokalen Font 208 vorhanden ist. Ein Bit kann beispielsweise gesetzt (oder gelöscht) werden, um anzugeben, dass eine damit verknüpfte Glyphe 212 vorhanden (oder nicht vorhanden) ist. Alternative Datenstrukturen oder Techniken können indes ebenfalls implementiert werden, um im Status des lokalen Fonts 312 das Vorhandensein oder Nichtvorhandensein von Glyphen 212 in dem bestehenden lokalen Font 208 zu codieren.
Das Fontinstanziierungsmodul 110 beinhaltet den Status des lokalen Fonts 312 in der Fontanforderung 112 zusammen mit der komprimierten Darstellung 308. Das Fontinstanziierungsmodul 110 veranlasst zudem, dass die Endnutzervorrichtung 102 die Fontanforderung 112 an die Servervorrichtung 104 überträgt. Obwohl die komprimierte Darstellung 308 und der Status des lokalen Fonts 312 in einem Paket oder einer anderen Kommunikationseinheit, so beispielsweise einer einzigen URL, kombiniert sein können, kann jedes alternativ jedoch auch gesondert oder über zwei oder mehr Kommunikationseinheiten an die Servervorrichtung 104 kommuniziert werden. Die Servervorrichtung 104 empfängt die Fontanforderung 112 mit dem Status des lokalen Fonts 312 und stellt die Fontanforderung 112 für das Fontinstanziierungsmodul 110 an der Servervorrichtung 104 bereit.
An der Servervorrichtung 104 verwendet das Fontinstanziierungsmodul 110 die komprimierte Darstellung 308 und den Status des lokalen Fonts 312 in Verbindung mit der Fontdefinition 310, um die Erweiterungsanweisung 306 zu präparieren. Aus dem Status des lokalen Fonts 312 bestimmt das Fontinstanziierungsmodul 110, welche Glyphen 212 in dem lokalen Font 208 bereits vorhanden sind. Aus der komprimierten Darstellung 308 bestimmt das Fontinstanziierungsmodul 110, welche neuen Zeichen 316 angefordert werden. Die Erweiterungsanweisung 306 wird derart präpariert, dass sie angibt, wie Daten für die mehreren neuen Glyphen 212, die den angeforderten Zeichen 316 entsprechen, zu dem bestehenden lokalen Font 208 hinzugefügt werden sollen, vorausgesetzt, dass die betroffenen Glyphen 212 als Teil des lokalen Fonts 208 bereits vorhanden sind.
Die Erweiterungsanweisung 306 kann beispielsweise angeben, wie die neuen Glyphen 212 mit den bestehenden Glyphen 212 integriert werden sollen, indem der kombinierte Satz von Glyphen 212 in dem lokalen Font 208 umgeordnet wird. Den kombinierten und umgeordneten Glyphen 212 kann zudem eine neue lokale Ordnungszahl für den lokalen Font 208 zugewiesen werden. Die Erweiterungsanweisung 306 kann derart konfiguriert sein, dass der aktualisierte lokale Font 208 die Fontdefinition 310 in einem praktikablen Ausmaß annähert, vorausgesetzt, dass der lokale Font 208 nur ein Teil des vollständigen Fonts insgesamt ist. Wenn auf diese Weise neue Glyphen 212 zu dem lokalen Font 208 kontinuierlich hinzugefügt werden, bis jede der möglichen Glyphen 212 der Fontdefinition 310 hinzugefügt worden ist, wird der lokale Font 208 durch die Erweiterungsanweisungen 306 gegebenenfalls derart umgeordnet, dass er konfiguriert ist, als ob die Fontdefinition 312 insgesamt ursprünglich als vollständiger Satz von Glyphen 212 für den spezifizierten Font angefordert worden wäre.
Das Fontinstanziierungsmodul 110 der Servervorrichtung 104 erzeugt die Fontbeschreibung 114 derart, dass diese die Glyphendaten 314 und die Erweiterungsanweisung 306 beinhaltet. Das Fontinstanziierungsmodul 110 veranlasst, dass die Servervorrichtung 104 die Fontbeschreibung 114 an die Endnutzervorrichtung 102 überträgt. Das Fontinstanziierungsmodul 110 an der Endnutzervorrichtung 102 verwendet die Erweiterungsanweisung 306 zusammen mit den neu empfangenen Glyphendaten 314, um den bestehenden lokalen Font 208 dadurch zu erweitern, dass die mehreren Glyphen 212, die den mehreren angeforderten Zeichen 316 entsprechen, zu dem lokalen Font 208 hinzugefügt werden. Das Fontinstanziierungsmodul 110 kann die mehreren Glyphen 212 beispielsweise in den lokalen Font 208 auf Grundlage der Erweiterungsanweisung 306 aufnehmen, um eine aktualisierte Glyphenreihenfolge für den lokalen Font 208 zu erzeugen, und kann die Glyphen 212 des lokalen Fonts 208 entsprechend der aktualisierten Glyphenreihenfolge umordnen.
Nachdem exemplarische Details zu Systemen, Techniken und Schemen zum Erwerben eines Fontteiles unter Verwendung eines Kompressionsmechanismus diskutiert worden sind, werden nunmehr einige exemplarische Prozeduren zur Erläuterung von zusätzlichen Aspekten der Techniken betrachtet.
Exemplarische Prozeduren
Der vorliegende Abschnitt beschreibt anhand 7 und 8 exemplarische Prozeduren im Zusammenhang mit dem Erwerb eines Fontteiles unter Verwendung eines Kompressionsmechanismus bei einer oder mehreren Ausführungsformen. Aspekte der Prozeduren können in Hardware, Firmware oder Software oder auch einer Kombination hieraus implementiert sein. Die Prozeduren sind als Sätze von Blöcken dargestellt, die Operationen spezifizieren, die von einer oder mehreren Vorrichtungen durchgeführt werden können, wobei die Leistungsfähigkeit der Operationen jedoch nicht notwendigerweise auf die Reihenfolgen beschränkt ist, die durch die jeweiligen Blöcke gezeigt oder hier beschrieben sind, da die Operationen auch in anderen Reihenfolgen oder vollständig oder teilweise überlappend durchgeführt werden können. Bei wenigstens einigen Ausführungsformen können die Prozeduren von einer geeignet konfigurierten Vorrichtung durchgeführt werden, so beispielsweise der exemplarischen Endnutzervorrichtung 102 von 7 oder der exemplarischen Servervorrichtung 104 von 8, die sich des Fontinstanziierungsmoduls 110 bedient.
7 ist ein Flussdiagramm, das sechs Blöcke 702 bis 712 beinhaltet und eine exemplarische Prozedur 700 für eine Endnutzervorrichtung 102 darstellt, die eine Implementierung zum Erwerb eines Fontteiles unter Verwendung eines Kompressionsmechanismus entsprechend einer oder mehreren exemplarischen Ausführungsformen durchführt. Bei Operation 702 werden mehrere Zeichen, die einen Teil einer Fontdefinition bilden, bestimmt. Eine Endnutzervorrichtung 102 kann beispielsweise mehrere Zeichen 316 bestimmen, die einen Teil einer Fontdefinition 310 bilden. Zu diesem Zweck kann ein Fontinstanziierungsmodul 110 mit einem Fontbestimmungsmodul 304 kommunizieren, um zu bestimmen, welche Zeichen 316 angezeigt werden sollen, und kann auf einen lokalen Font 208 zugreifen, um zu bestimmen, welche Glyphen 212, die angezeigt werden sollen, nicht in dem lokalen Font 208 vorhanden sind. Das Fontinstanziierungsmodul 110 durchsucht eine Datei (beispielsweise ein Dokument oder Webseite), um Zeichen 316 zu erfassen. Die erfassten Zeichen 316, die keine entsprechenden Glyphen 212 in dem lokalen Font 208 aufweisen, werden hierdurch bestimmt. Die Zeichen 316 können in einer beliebigen von mehreren möglichen Darstellungen erfasst werden, so beispielsweise als Glyphenform, Identifizierungsnummer, Codepunkt, Kombination hieraus und dergleichen mehr.
Bei Operation 704 werden mehrere Codepunkte, die jeweils den mehreren Zeichen entsprechen, ermittelt. Die Endnutzervorrichtung 102 kann beispielsweise mehrere Codepunkte 406 ermitteln, die jeweils den mehreren Zeichen 316 entsprechen. Das Fontinstanziierungsmodul 110 kann beispielsweise ermitteln, welche universellen Codepunkte, so beispielsweise Unicode-Codepunktwerte, den Zeichen 316, die angefordert werden sollen, entsprechen. Werden die Zeichen 316 als Codepunkte, die zum Erstellen einer Anforderung (beispielsweise Unicode-Codepunktwerte) verwendet werden, als Teil von Operation 702 erfasst, so kann die Ermittlung von Operation 704 gemeinsam oder gleichzeitig mit der Bestimmung von Operation 702 durchgeführt werden, oder es kann die Ermittlung von Operation 704 bestätigen, dass geeignete Codepunkte bereits ermittelt sind.
Bei Operation 706 wird eine komprimierte Darstellung der wenigstens mehreren Zeichen auf Grundlage der mehreren Codepunkte berechnet. Die Endnutzervorrichtung 102 kann beispielsweise eine komprimierte Darstellung 308 der wenigstens mehreren Zeichen 316 auf Grundlage der mehreren Codepunkte 406 berechnen. Zur Bewerkstelligung der Berechnung kann das Fontinstanziierungsmodul 110 eine Bloom-Filter-Technik auf die mehreren Codepunkten 406 anwenden, um eine wahrscheinlichkeitsbasierte Datenstruktur 408 zu erstellen.
Bei Operation 708 wird eine Fontanforderung, die die komprimierte Darstellung beinhaltet, an einen Fontvorrat kommuniziert. Die Endnutzervorrichtung 102 kann an einen Fontvorrat 120 eine Fontanforderung 112, die die komprimierte Darstellung 308 beinhaltet, kommunizieren. Zu diesem Zweck kann das Fontinstanziierungsmodul 110 veranlassen, dass die Endnutzervorrichtung 102 eine Fontanforderung 112, die die wahrscheinlichkeitsbasierte Datenstruktur 408 beinhaltet, an eine Servervorrichtung 104 überträgt, die Zugriff auf eine Fontdatenbank 116 über ein Netzwerk 106 hat. Die Fontanforderung 112 kann als URL implementiert sein, die auf die Servervorrichtung 104 verweist und als Teil hiervon Felder der wahrscheinlichkeitsbasierten Datenstruktur 408 beinhaltet.
Bei Operation 710 wird eine Fontbeschreibung, die der komprimierten Darstellung entspricht, von dem Fontvorrat empfangen. Die Endnutzervorrichtung 102 kann von dem Fontvorrat 120 beispielsweise eine Fontbeschreibung 114 empfangen, die der komprimierten Darstellung 308 entspricht. Beinhalten kann die Fontbeschreibung 114 Glyphendaten 314 für wenigstens jede Glyphe 212, die einem Zeichen 316 entspricht, das in der wahrscheinlichkeitsbasierten Datenstruktur 408 codiert worden ist, um die komprimierte Darstellung 308 zu erstellen.
Bei Operation 712 wird ein lokaler Font, der mehrere Glyphen beinhaltet, die den mehreren Zeichen entsprechen, unter Verwendung der Fontbeschreibung erzeugt, wobei der lokale Font dadurch eine Version der Fontdefinition verwirklicht. Die Endnutzervorrichtung 102 kann beispielsweise einen lokalen Font 208, der die mehreren Glyphen 212 beinhaltet, die den mehreren Zeichen 316 entsprechen, unter Verwendung der Fontbeschreibung 114 erzeugen, wodurch der sich ergebende lokale Font 208 eine Version der Fontdefinition 310 darstellt. Der lokale Font 208 kann derart erstellt werden, dass die mehreren Glyphen 212, die den mehreren angeforderten Zeichen 316 entsprechen, die in dem lokalen Font 208 beinhaltet sind, wiedergegeben werden, als ob die Fontdefinition 310 als Ganzes zur Erstellung des lokalen Fonts 208 verwendet würde.
8 ist ein Flussdiagramm, das sechs Blöcke 802 bis 812 beinhaltet und eine exemplarische Prozedur 800 für eine Servervorrichtung 104 darstellt, die eine Implementierung zum Erwerb eines Fontteiles unter Verwendung eines Kompressionsmechanismus entsprechend einer oder mehreren exemplarischen Ausführungsformen durchführt. Bei Operation 802 wird eine komprimierte Darstellung, die mehreren Zeichen entspricht, die einen Teil einer Fontdefinition bilden, von einer Endnutzervorrichtung empfangen. Eine Servervorrichtung 104 kann von einer Endnutzervorrichtung 102 beispielsweise eine komprimierte Darstellung 308 empfangen, die den mehreren Zeichen 316 entspricht, die einen Teil einer Fontdefinition 310 bilden. Um den Empfang zu bewerkstelligen, kann die Servervorrichtung 104 eine URL verarbeiten und einen Teil hiervon, der eine wahrscheinlichkeitsbasierte Datenstruktur 408 bildet, in der mehrere Codepunkte 406 codiert worden sind, extrahieren. Die URL kann zudem einen speziellen Font 210 angeben.
Bei Operation 804 wird die komprimierte Darstellung decodiert, um mehrere Codepunkte zu identifizieren. Die Servervorrichtung 104 kann beispielsweise die komprimierte Darstellung 308 decodieren, um mehrere Codepunkte 406 zu identifizieren. Zu diesem Zweck kann ein Fontinstanziierungsmodul 110 die Codierergebnisse 514 unter Verwendung der Codepunkte 406 für die Glyphen 212 und entsprechende Zeichen 316 eines Satzes von Codepunkten 516 für eine Fontdefinition 310 eines angegebenen Fonts 210 erzeugen. Das Fontinstanziierungsmodul 110 kann des Weiteren die Codierergebnisse 514 mit der wahrscheinlichkeitsbasierten Datenstruktur 408 vergleichen, um zu bestimmen, welche Codepunkte 406 zu der komprimierten Darstellung 308 passen, um so die passenden Codepunkte 406 zu identifizieren.
Bei Operation 806 werden die mehreren Zeichen auf Grundlage der mehreren Codepunkte ermittelt, wobei die mehreren Zeichen jeweils den mehreren Codepunkten entsprechen. Die Servervorrichtung 104 kann beispielsweise die mehreren Zeichen 316 auf Grundlage der mehreren Codepunkte 406 ermitteln, wobei die mehreren Zeichen 316 jeweils den mehreren Codepunkten 406 entsprechen. Unter Verwendung der Fontdefinition 310 für den angegebenen Font 210 oder mittels einer allgemeinen Entsprechungstabelle für Unicode-Codepunkte wie auch die identifizierten passenden Codepunkte 406 kann das Fontinstanziierungsmodul 110 wenigstens die mehreren Zeichen 316, die von der Endnutzervorrichtung 102 angefordert worden sind, ermitteln. Das Fontinstanziierungsmodul 110 kann zusätzlich ein oder mehrere Zeichen 316 ermitteln, die unabsichtlich von der Endnutzervorrichtung 102 infolge von gegebenenfalls falschen Positiva mit der komprimierten Darstellung 308 angefordert worden sind.
Bei Operation 808 wird auf die Fontdefinition zugegriffen, um Fontattribute für mehrere Glyphen, die den mehreren Zeichen entsprechen, zu extrahieren. Die Servervorrichtung 104 kann beispielsweise auf die Fontdefinition 310 zugreifen, um Fontattribute 510 für die mehreren Glyphen 212 zu extrahieren, die den mehreren identifizierten Zeichen 316 entsprechen. Um die Extraktion zu bewerkstelligen, kann das Fontinstanziierungsmodul 110 aus der Fontdefinition 310 des angegebenen Fonts 210 diejenigen Anweisungen isolieren, die beschreiben, wie die Glyphen 212 für die wenigstens mehreren Zeichen 316, die von der Endnutzervorrichtung 102 angefordert worden sind, wiedergegeben werden sollen.
Bei Operation 810 wird eine Fontbeschreibung, die der komprimierten Darstellung entspricht, auf Grundlage der Fontattribute präpariert, wobei die Fontbeschreibung ermöglicht, dass die Endnutzervorrichtung die mehreren Glyphen als Teil eines lokalen Fonts der Endnutzervorrichtung wiedergibt. Die Servervorrichtung 104 kann beispielsweise eine Fontbeschreibung 114, die der komprimierten Darstellung 308 entspricht, auf Grundlage der Fontattribute 510 präparieren, wobei die Fontbeschreibung 114 ermöglicht, dass die Endnutzervorrichtung 102 die mehreren Glyphen 212 als Teil eines lokalen Fonts 208 der Endnutzervorrichtung 102 wiedergibt. Zu diesem Zweck kann das Fontinstanziierungsmodul 110 eine Fontbeschreibung 114 derart präparieren, dass diese Glyphendaten 314 beinhaltet, die als Anweisungen (beispielsweise als Vektordarstellung) zum Anzeigen der wenigstens mehreren Glyphen 212 dienen, die den mehreren Zeichen 316 entsprechen, die von der Endnutzervorrichtung 102 angefordert worden sind. Bei einem Szenario der Fonterweiterung kann die Fontbeschreibung 114 zusätzlich derart präpariert werden, dass sie wenigstens eine Erweiterungsanweisung 306 beinhaltet, um zu beschreiben, wie die Endnutzervorrichtung 102 die Glyphendaten 314 in einen bestehenden lokalen Font 208 aufnehmen kann.
Bei Operation 812 wird die Fontbeschreibung an die Endnutzervorrichtung übertragen. Die Servervorrichtung 104 kann die Fontbeschreibung 114 beispielsweise an die Endnutzervorrichtung 102 übertragen. Die Servervorrichtung 104, die als Fontvorrat 120 dient, kann die Fontbeschreibung 114 in eine Instanz eines Fontinstanziierungsmoduls 110 herunterladen, die an der Endnutzervorrichtung 102 betrieben wird.
Nachdem exemplarische Prozeduren entsprechend einer oder mehreren Ausführungsformen beschrieben worden sind, werden nunmehr ein exemplarisches System und eine exemplarische Vorrichtung betrachtet, die zur Implementierung der verschiedenen hier beschriebenen Schemen und Techniken verwendet werden können.
Exemplarisches System und exemplarische Vorrichtung
9 zeigt allgemein bei 900 ein exemplarisches System, das exemplarische Rechenvorrichtungen 902 beinhaltet, die für ein oder mehrere Rechensysteme oder eine oder mehrere Rechenvorrichtungen, die die verschiedenen hier beschriebenen Techniken implementieren können, repräsentativ sind. Dies erfolgt durch Einbeziehung der beiden Fontinstanziierungsmodule 110, die entweder einzeln oder zusammen gemäß vorstehender Beschreibung betrieben werden können, wie auch der Fontdatenbank 116. Beinhalten kann die Rechenvorrichtung 902 beispielsweise eine Endnutzervorrichtung (beispielsweise eine Clientvorrichtung) eines Endnutzers 108, eine Servervorrichtung eines Dienstanbieters 118, ein chipintegriertes System (on-chip ystem) oder ein System-auf-einem-Chip (system-on-a-chip SOC) oder eine beliebige andere geeignete Rechenvorrichtung oder ein solches Rechensystem. Eine exemplarische Endnutzervorrichtung 102 ist durch die Rechenvorrichtung 902-1 dargestellt, während eine exemplarische Servervorrichtung 104 durch die Rechenvorrichtung 902-2 dargestellt ist.
Die exemplarischen Rechenvorrichtungen 902 gemäß Darstellung beinhalten wenigstens ein Verarbeitungssystem 904, ein oder mehrere computerlesbare Medien 906 und ein oder mehrere I/O-Schnittstellen 908, die kommunikativ miteinander gekoppelt sein können. Obwohl dies explizit nicht dargestellt ist, kann jede Rechenvorrichtung 902 des Weiteren einen Systembus oder ein anderes Daten- und Befehlsübertragungssystem beinhalten, das die verschiedenen Komponenten miteinander koppelt. Ein Systembus kann eine Busstruktur oder eine Kombination aus verschiedenen Busstrukturen beinhalten, so beispielsweise einen Speicherbus oder einen Speichercontroller, einen Peripheriebus, einen universellen seriellen Bus oder einen Prozessor- oder lokalen Bus, der eine beliebige aus einer Vielzahl von Busarchitekturen nutzt. Eine Vielzahl von anderen Beispielen ist ebenfalls einbezogen, so beispielsweise Steuer- und Datenleitungen.
Das Verarbeitungssystem 904 bietet eine Funktionalität zur Durchführung einer oder mehrerer Operationen unter Verwendung von Hardware. Entsprechend ist das Verarbeitungssystem 904 derart dargestellt, dass es Hardwareelemente 910 beinhaltet, die als Prozessoren, funktionelle Blöcke und dergleichen mehr konfiguriert sein können. Dies kann eine Implementierung in Hardware als anwendungsspezifische integrierte Schaltung oder andere logische Schaltung, die unter Verwendung eines oder mehrerer Halbleiter gebildet ist, beinhalten. Die Hardwareelemente 910 sind nicht durch die Materialien, aus denen sie gebildet sind, oder durch die Verarbeitungsmechanismen, die dabei zum Einsatz kommen, beschränkt. So können die Prozessoren beispielsweise aus einem Halbleiter/aus Halbleitern oder Transistoren (beispielsweise elektronische integrierte Schaltungen (ICs)) gebildet sein. In diesem Zusammenhang können prozessorausführbare Anweisungen auch elektronisch ausführbare Anweisungen sein.
Die computerlesbaren Speichermedien 906 sind derart dargestellt, dass sie einen Speicher/eine Ablage 912 beinhalten. Der Speicher/die Ablage 912 bietet eine Speicher-/Ablagekapazität in Verbindung mit einem oder mehreren computerlesbaren Medien. Beinhalten kann die Speicher-/Ablagekomponente 912 flüchtige Medien (so beispielsweise einen Speicher mit wahlfreiem Zugriff (RAM)) und/oder nichtflüchtige Medien (so beispielsweise einen Nur-Lese-Speicher (ROM), einen Flash-Speicher, optische Platten, magnetische Platten und dergleichen mehr). Beinhalten kann die Speicher-/Ablagekomponente 912 zudem feste Medien (beispielsweise RAM, ROM, ein fixes Festplattenlaufwerk, das von elektromagnetischen Platten oder einem Flash-Speicher gebildet wird) wie auch entfernbare Medien (beispielsweise einen Flash-Speicher, ein entfernbares Festplattenlaufwerk oder eine optische Platte). Die computerlesbaren Medien 906 können auf eine Vielzahl von anderen Arten, wie nachstehend noch beschrieben wird, konfiguriert sein.
Die Eingabe-/Ausgabe-Schnittstelle(n) 908 bietet (bieten) eine Funktionalität, die einem Nutzer ermöglicht, Befehle oder Information in die Rechenvorrichtung 902 einzugeben, oder die ermöglicht, dem Nutzer oder anderen Komponenten oder Vorrichtungen unter Verwendung verschiedener Eingabe-/Ausgabevorrichtungen Information zu präsentieren. Beispiele für Eingabevorrichtungen beinhalten eine Tastatur, eine Cursorsteuer- bzw. Regelvorrichtung (beispielsweise eine Maus oder ein Touchpad), ein Mikrofon, einen Scanner, eine Berührungsfunktionalität (beispielsweise kapazitive, resistive oder andere Sensoren, die zum Erfassen einer physischen Berührung konfiguriert sind), eine Kamera (die beispielsweise sichtbare oder nichtsichtbare Wellenlängen, beispielsweise Infrarotfrequenzen, zum Erkennen einer Bewegung als Gesten, die keine Berührung implizieren, erkennen kann) oder auch eine Kombination hieraus. Beispiele für Ausgabevorrichtungen beinhalten eine Anzeigevorrichtung (beispielsweise einen LCD- oder LED-Schirm, einen Monitor oder einen Projektor), einen Lautsprecher, einen Drucker, eine Netzwerkkarte, eine haptische Vibrationsvorrichtung oder eine Kombination hieraus. Daher kann die Rechenvorrichtung 902 auf eine Vielzahl von Arten, wie nachstehend noch beschrieben wird, konfiguriert sein, um eine lokale oder aus der Ferne erfolgende Nutzerinteraktion zu unterstützen.
Es sind verschiedene Techniken im allgemeinen Kontext von Software, Hardwareelementen oder Programmmodulen beschrieben worden. Allgemein beinhalten derartige Module Routinen, Programme, Objekte, Elemente, Komponenten, Datenstrukturen, Kombinationen hieraus und dergleichen mehr, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Die Begriffe „Modul”, „Funktionalität” und „Komponente” bezeichnen im Sinne des Vorliegenden allgemein Software, Firmware, Hardware oder eine Kombination hieraus. Die Merkmale der hier beschriebenen Techniken sind plattformunabhängig, was bedeutet, dass die beschriebenen Techniken auf einer Vielzahl von handelsüblichen Rechenplattformen, die eine Vielzahl von Prozessoren aufweisen, implementiert sein können.
Eine Ausführungsform der beschriebenen Module und Techniken hiervon kann auf einer Form von computerlesbarem Medium gespeichert sein oder über dieses übertragen werden. Die computerlesbaren Medien können eine Vielzahl von Medien beinhalten, auf die von der Rechenvorrichtung 902 zugegriffen werden kann. Beispiels- und nicht beschränkungshalber können computerlesbare Medien „computerlesbare Speichermedien” und „computerlesbare Signalmedien” beinhalten.
„Computerlesbare Speichermedien” bezeichnen im Sinne des Vorliegenden Medien oder Vorrichtungen, die eine dauerhafte und/oder nichttemporäre Speicherung von Information ermöglichen, im Gegensatz zur bloßen Signalübertragung, Trägerwellen oder Signalen als solche. Computerlesbare Speichermedien beinhalten keine Signale als solche oder Signal tragende Medien. Die computerlesbaren Speichermedien beinhalten Hardware, so beispielsweise flüchtige und nichtflüchtige, entfernbare und nichtentfernbare Medien, oder Speichervorrichtungen, die bei einem Prozess oder einer Technologie implementiert werden, die zur Speicherung von Information geeignet ist, so beispielsweise computerlesbare Anweisungen, Datenstrukturen, Programmmodule, logische Elemente/Schaltungen oder andere Daten. Beinhalten können Beispiele für computerlesbare Speichermedien unter anderem RAM, ROM, EEPROM, einen Flash-Speicher oder eine andere Speichertechnologie, beispielsweise Solid-State, CD-ROM, DVD oder einen anderen optischen Speicher, Festplatten, magnetische Kassetten, ein Magnetband, einen Magnetplattenspeicher oder andere magnetische Speichervorrichtungen, oder eine andere Speichervorrichtung, physische Medien, ein Herstellungserzeugnis oder eine Kombination hieraus, die dafür geeignet ist, die gewünschte Information zu speichern und für einen Computer zugänglich zu sein.
„Computerlesbare Signalmedien” bezeichnen im Sinne des Vorliegenden ein Signal tragendes Medium, das dafür konfiguriert ist, Anweisungen für die Hardware der Rechenvorrichtung 902 beispielsweise über ein Netzwerk zu übertragen. Computerlesbare Signalmedien können üblicherweise computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder andere Daten in einem modulierten Datensignal, so beispielsweise Trägerwellen, Datensignale oder einen anderen Transportmechanismus, verkörpern. Computerlesbare Signalmedien können zudem ein beliebiges Informationsverteilungsmedium beinhalten. Der Begriff „moduliertes Datensignal” bezeichnet ein Signal, bei dem eine oder mehrere seiner Eigenschaften derart eingestellt oder geändert sind, dass Information in dem Signal codiert ist. Beinhalten können computerlesbare Signalmedien beispielshalber verdrahtete Medien, so beispielsweise ein verdrahtetes Netzwerk oder eine direktverdrahtete Verbindung, wie auch drahtlose Medien, so beispielsweise akustische, hochfrequenzbasierte, mikrowellenbasierte, infrarote und andere Drahtlosmedien.
Wie vorstehend beschrieben worden ist, können die Hardwareelemente 910 und die computerlesbaren Medien 906 Module, eine programmierbare Vorrichtungslogik, eine feste Vorrichtungslogik, eine Kombination hieraus und dergleichen mehr beinhalten, die in Form von Hardware implementiert sind, die bei einigen Ausführungsformen zur Implementierung wenigstens einiger Aspekte der hier beschriebenen Techniken genutzt werden kann, so beispielsweise zum Ausführen einer oder mehrerer Anweisungen oder Rechenvorgänge. Hardware kann Komponenten einer integrierten Schaltung (IC) oder eines chipinternen Systems, einer anwendungsspezifischen integrierten Schaltung (ASIC), eines feldprogrammierbaren Gate-Arrays (FPGA), einer komplexen programmierbaren logischen Vorrichtung (CPLD) oder andere Implementierungen aus Silizium oder anderer Hardware beinhalten. Wirken kann die Hardware in diesem Zusammenhang als Verarbeitungsvorrichtung, die Programmaufgaben ausführt, die durch Anweisungen definiert sind, oder als Logik, die durch die Hardware verkörpert ist, wie auch als Hardware, die zum Speichern von Anweisungen zur Ausführung genutzt wird, so beispielsweise computerlesbare Speichermedien, wie sie vorstehend beschrieben worden sind.
Kombinationen des Vorbeschriebenen können ebenfalls eingesetzt werden, um verschiedene der hier beschriebenen Techniken zu implementieren. Entsprechend können Software, Hardware oder ausführbare Module als eine oder mehrere Anweisungen oder als Logik, die in beliebiger Form von computerlesbaren Speichermedien oder einer oder mehreren Hardwareelementen 910 verkörpert ist, implementiert sein. Die Rechenvorrichtung 902 kann dafür konfiguriert sein, bestimmte Anweisungen oder Funktionen entsprechend Software oder Hardwaremodulen zu implementieren. Entsprechend kann eine als Software gegebene Implementierung eines Moduls, das durch die Rechenvorrichtung 902 ausführbar ist, auch wenigstens teilweise in Hardware verwirklicht sein, so beispielsweise unter Verwendung von computerlesbaren Speichermedien oder von Hardwareelementen 910 des Verarbeitungssystems 904. Die Anweisungen oder Funktionen können von einem oder mehreren Herstellungserzeugnissen (beispielsweise eine oder mehrere Rechenvorrichtungen 902 oder Verarbeitungssysteme 904) ausführbar/betreibbar sein, um Techniken, Module und Beispiele so, wie sie hier beschrieben sind, zu implementieren.
Die hier beschriebenen Techniken können von verschiedenen Konfigurationen der Rechenvorrichtung 902 unterstützt werden, und man ist nicht auf die hier beschriebenen exemplarischen Vorrichtungen beschränkt. Die Funktionalität kann zudem gänzlich oder in Teilen durch ein verteiltes System implementiert sein, so beispielsweise über eine „Cloud” 914 mittels einer Plattform 916, wie nachstehend noch beschrieben wird.
Die Cloud 914 beinhaltet eine Plattform 916 für Ressourcen 918 oder repräsentiert diese. Die Plattform 916 abstrahiert eine darunter liegende Funktionalität der Hardware (beispielsweise Server oder Datenzentren) und Softwareressourcen der Cloud 914. Die Ressourcen 918 können Anwendungen oder Daten beinhalten, die verwendet werden können, während eine Computerverarbeitung zumindest teilweise auf Servern ausgeführt wird, die von der Rechenvorrichtung 902 entfernt oder um diese herum verteilt sind. Die Ressourcen 918 können zudem Dienste beinhalten, die über das Internet oder über ein Teilnehmernetzwerk, so beispielsweise ein zellenbasiertes oder Wi-Fi-Netzwerk, bereitgestellt werden.
Die Plattform 916 kann Ressourcen und Funktionen zum Verbinden der Rechenvorrichtung 902 mit anderen Rechenvorrichtungen abstrahieren. Die Plattform 916 kann zudem dazu dienen, die Ressourcenskalierung zu abstrahieren, um einen entsprechenden Skalierungsgrad für einen zu erwartenden Bedarf an Ressourcen 918, die über die Plattform 916 implementiert sind, bereitzustellen. Entsprechend kann bei einer Ausführungsform mit einer vernetzten Vorrichtung eine Implementierung der hier beschriebenen Funktionalität über das System 900 oder wenigstens über die Cloud 914 zusammen mit der Rechenvorrichtung 902, so beispielsweise der Rechenvorrichtung 902-2, verteilt sein. Die Funktionalität kann beispielsweise teilweise auf einer Rechenvorrichtung 902 wie auch über die Plattform 916, die die Funktionalität der Cloud 914 abstrahiert, implementiert sein.
Schlussbemerkung
Obwohl die Erfindung in einer Sprache beschrieben worden ist, die für strukturelle Merkmale und/oder methodische Vorgehensweisen spezifisch ist, sollte einsichtig sein, dass die durch die beigefügten Ansprüche definierte Erfindung nicht notwendigerweise auf die spezifischen Merkmale oder Vorgehensweisen der Beschreibung beschränkt ist. Vielmehr sind die spezifischen Merkmale und Vorgehensweisen als exemplarische Formen der Implementierung der beanspruchten Erfindung offenbart.

Claims

Wenigstens eine Rechenvorrichtung, die in einer Digitalmediumumgebung betreibbar ist, um den Erwerb eines Schriftart- bzw. Fontteiles zu ermöglichen, der in Echtzeit unter Verwendung eines Kompressionsmechanismus spezifiziert wird, der eine verlustfreie Identifizierung von aufgelisteten Zeichen erleichtert, wobei die Rechenvorrichtung dafür konfiguriert ist, Operationen durchzuführen, die umfassen: Bestimmen von mehreren Zeichen, die einen Teil einer Fontdefinition umfassen; Ermitteln von mehreren Codepunkten, die jeweils den mehreren Zeichen entsprechen; Berechnen einer komprimierten Darstellung der wenigstens mehreren Zeichen auf Grundlage der mehreren Codepunkte; an einen Fontvorrat bzw. -speicher erfolgendes Kommunizieren einer Fontanforderung, die die komprimierte Darstellung beinhaltet; von dem Fontvorrat bzw. -speicher erfolgendes Empfangen einer Fontbeschreibung, die der komprimierten Darstellung entspricht; und Erzeugen eines lokalen Fonts, der mehrere Glyphen beinhaltet, die den mehreren Zeichen entsprechen, unter Verwendung der Fontbeschreibung, wobei der lokale Font eine Version der Fontdefinition umfasst.
Rechenvorrichtung nach Anspruch 1, wobei das Bestimmen ein Erfassen einer Nutzereingabe, die die mehreren Zeichen beinhaltet, umfasst.
Rechenvorrichtung nach Anspruch 1 oder 2, wobei die mehreren Codepunkte jeweils mehrere Unicode-Codepunktwerte umfassen.
Rechenvorrichtung nach einem der Ansprüche 1 bis 3, wobei: der Fontvorrat bzw. -speicher einen Webserver umfasst; die Fontanforderung eine einheitliche Ressourcenadresse (Uniform Resource Locator URL) umfasst; und das Kommunizieren umfasst: Einbetten der komprimierten Darstellung in der URL; und an den Webserver erfolgendes Übertragen der URL, die die komprimierte Darstellung beinhaltet.
Rechenvorrichtung nach einem der Ansprüche 1 bis 4, wobei das Erzeugen ein Einrichten des lokalen Fonts derart, dass dieser die mehreren Glyphen beinhaltet, umfasst.
Rechenvorrichtung nach einem der Ansprüche 1 bis 5, wobei das Erzeugen ein Erweitern des lokalen Fonts durch Hinzufügen der mehreren Glyphen zu dem lokalen Font umfasst.
Rechenvorrichtung nach Anspruch 6, wobei: die Rechenvorrichtung dafür konfiguriert ist, Operationen durchzuführen, die des Weiteren ein Bestimmen eines Status des lokalen Fonts vor dem Erweitern umfassen, wobei der Status für einen aktuellen Inhalt des lokalen Fonts repräsentativ ist; und das Kommunizieren ein an den Fontvorrat erfolgendes Kommunizieren des Status des lokalen Fonts umfasst.
Rechenvorrichtung nach Anspruch 7, wobei: die Fontbeschreibung eine Erweiterungsanweisung beinhaltet; und das Erweitern umfasst: Aufnehmen der mehreren Glyphen in den lokalen Font auf Grundlage der Erweiterungsanweisung zum Erzeugen einer aktualisierten Glyphenreihenfolge für den lokalen Font; und Umnummerieren der Glyphen des lokalen Fonts entsprechend der aktualisierten Glyphenreihenfolge.
Rechenvorrichtung nach einem der Ansprüche 1 bis 8, wobei die Rechenvorrichtung dafür konfiguriert ist, Operationen durchzuführen, die des Weiteren ein auf einem Anzeigeschirm erfolgendes Wiedergeben wenigstens einer Glyphe von den mehreren Glyphen unter Verwendung des lokalen Fonts umfassen.
Rechenvorrichtung nach einem der Ansprüche 1 bis 9, wobei die komprimierte Darstellung eine wahrscheinlichkeitsbasierte Datenstruktur umfasst.
Rechenvorrichtung nach Anspruch 10, wobei das Berechnen der komprimierten Darstellung ein Anwenden einer Bloom-Filtertechnik auf die mehreren Codepunkte umfasst, um die wahrscheinlichkeitsbasierte Datenstruktur, die die mehreren Zeichen darstellt, zu erzeugen.
Rechenvorrichtung nach einem der Ansprüche 1 bis 11, wobei das Berechnen der komprimierten Darstellung ein derartiges Durchführen wenigstens einer Hashing-Operation an jedem der mehreren Codepunkte umfasst, dass falsche Negativa verhindert werden, falsche Positiva jedoch zugelassen werden, wenn die komprimierte Darstellung zum Identifizieren der mehreren Codepunkte decodiert wird.
Wenigstens eine Rechenvorrichtung, die in einer Digitalmediumumgebung betreibbar ist, um den Erwerb eines Fontteiles zu ermöglichen, der in Echtzeit unter Verwendung eines Kompressionsmechanismus spezifiziert wird, der eine verlustfreie Identifizierung von aufgelisteten Zeichen erleichtert, wobei die Rechenvorrichtung dafür konfiguriert ist, Operationen durchzuführen, die umfassen: von einer Endnutzervorrichtung her erfolgendes Empfangen einer komprimierten Darstellung entsprechend mehreren Zeichen, die einen Teil einer Fontdefinition umfassen; Decodieren der komprimierten Darstellung zum Identifizieren von mehreren Codepunkten; Ermitteln der mehreren Zeichen auf Grundlage der mehreren Codepunkte, wobei die mehreren Zeichen jeweils den mehreren Codepunkten entsprechen; Zugreifen auf die Fontdefinition zum Extrahieren von Fontattributen für mehrere Glyphen, die den mehreren Zeichen entsprechen; Präparieren einer Fontbeschreibung entsprechend der komprimierten Darstellung auf Grundlage der Fontattribute, wobei die Fontbeschreibung ermöglicht, dass die Endnutzervorrichtung die mehreren Glyphen als Teil eines lokalen Fonts der Endnutzervorrichtung wiedergibt; und Übertragen der Fontbeschreibung an die Endnutzervorrichtung.
Rechenvorrichtung nach Anspruch 13, wobei das Decodieren ein Identifizieren der mehreren Codepunkte, die den mehreren Zeichen entsprechen, umfasst, wobei die mehreren Zeichen jedes Zeichen, das absichtlich von der Endnutzervorrichtung in der komprimierten Darstellung codiert worden ist, und wenigstens ein Zeichen, das unabsichtlich von der Endnutzervorrichtung in der komprimierten Darstellung codiert worden ist, beinhaltet.
Rechenvorrichtung nach Anspruch 13 oder 14, wobei das Decodieren umfasst: Durchführen wenigstens einer Codieroperation an jedem Codepunkt entsprechend jedem Zeichen, das in einem Satz von Codepunkten für die Fontdefinition beinhaltet ist, um mehrere Codierergebnisse zu erzeugen; und Vergleichen der mehreren Codierergebnisse mit der komprimierten Darstellung zum Identifizieren der mehreren Codepunkte.
Rechenvorrichtung nach einem der Ansprüche 13 bis 15, wobei das Empfangen ein von der Endnutzervorrichtung her erfolgendes Empfangen eines Status des lokalen Fonts umfasst, wobei der Status des lokalen Fonts für einen aktuellen Inhalt des lokalen Fonts an der Endnutzervorrichtung repräsentativ ist.
Rechenvorrichtung nach Anspruch 16, wobei das Präparieren ein Präparieren einer Erweiterungsanweisung auf Grundlage des Status des lokalen Fonts und der mehreren Zeichen entsprechend der komprimierten Darstellung umfasst, wobei die Erweiterungsanweisung angibt, wie die mehreren Glyphen zu dem lokalen Font hinzugefügt werden sollen.
System, das wenigstens teilweise in Hardware implementiert und in einer Digitalmediumumgebung betreibbar ist, um den Erwerb eines Fontteiles zu ermöglichen, der in Echtzeit unter Verwendung eines Kompressionsmechanismus spezifiziert wird, der eine verlustfreie Identifizierung von aufgelisteten Zeichen erleichtert, wobei das System umfasst: ein Fontinstanziierungsmodul, das konfiguriert ist zum Kommunizieren einer einheitlichen Ressourcenadresse (Uniform Resource Locator URL), die eine wahrscheinlichkeitsbasierte Datenstruktur beinhaltet, die für mehrere Zeichen repräsentativ ist, die einen Teil einer Fontdefinition umfassen, wobei die wahrscheinlichkeitsbasierte Datenstruktur mehrere Codepunkte unter Verwendung eines Kompressionsmechanismus integriert bzw. beinhaltet und die mehreren Codepunkte jeweils den mehreren Zeichen entsprechen.
System nach Anspruch 18, wobei: das System eine Endnutzervorrichtung umfasst; das Fontinstanziierungsmodul des Weiteren konfiguriert ist zum: Bestimmen der mehreren Zeichen auf Grundlage von Zeichen, die von der Endnutzervorrichtung angezeigt werden sollen; Codieren der mehreren Codepunkte in der wahrscheinlichkeitsbasierten Datenstruktur unter Verwendung wenigstens einer Hashing-Operation; Einbetten der wahrscheinlichkeitsbasierten Datenstruktur in der URL; an einen Fontvorrat bzw. -speicher erfolgenden Übertragen der URL, die die wahrscheinlichkeitsbasierte Datenstruktur beinhaltet; von dem Fontvorrat bzw. -speicher her erfolgenden Empfangen einer Fontbeschreibung, die beschreibt, wie mehrere Glyphen, die den mehreren Zeichen entsprechen, wiedergegeben werden sollen; und Erzeugen eines lokalen Fonts, der die mehreren Glyphen beinhaltet, unter Verwendung der Fontbeschreibung.
System nach Anspruch 18 oder 19, wobei: das System eine Servervorrichtung umfasst, die Zugriff auf eine Fontdatenbank hat, die eine Fontdefinition speichert; das Fontinstanziierungsmodul des Weiteren konfiguriert ist zum: von einer Endnutzervorrichtung her erfolgenden Empfangen der URL, die die wahrscheinlichkeitsbasierte Datenstruktur beinhaltet; Decodieren der wahrscheinlichkeitsbasierten Datenstruktur zum Identifizieren der mehreren Codepunkte; unter Verwendung der Fontdefinition und auf Grundlage der mehreren Codepunkte erfolgenden Präparieren einer Fontbeschreibung, die beschreibt, wie mehrere Glyphen, die den mehreren Zeichen entsprechen, wiedergegeben werden sollen; und an die Endnutzervorrichtung erfolgenden Übertragen der Fontbeschreibung.