Axure RP – Wie man wirklich jede Schriftart in einen Prototypen einbindet. Ein altes Problem (hoffentlich) ein für alle Mal gelöst.

Bild auf dem steht: "Welcome, nice to meet you!"

Axure RP bietet uns einen enormen Umfang an Möglichkeiten, um fast alles, was sich irgendwie als Webseite oder App darstellen lassen kann, umzusetzen. Durch den Einsatz von konditioneller Logik, Variablen, mathematischen Operatoren, dynamischer Inhalte etc. bleiben kaum Wünsche offen – bis auf einen: Schriftarten reibungslos und fehlerfrei auf allen Plattformen anzeigen.

Das Schriftarten-Problem ist nicht neu und die Axure-Entwickler haben bereits einige Möglichkeiten integriert, um die Arbeit mit ausgefalleneren Fonts zu erleichtern. So können wir in den „Publish“-Einstellungen mittels Link oder @font-face auf externe Schriftarten verlinken. Und seit Axure RP 9 brauchen wir, um die beliebten Google-Fonts einzubinden, diese nicht einmal mehr hier hinterlegen. Das geschieht automatisch, sodass wir unseren Prototypen einfach nur veröffentlichen und teilen müssen. So sparen wir Zeit und Mühe.

Wer Nicht-Systemschriften (also alles außer Arial, Time New Roman, Verdana, Georgia etc.) in Axure RP einbinden wollte, hat sicher schon einmal die offizielle Support-Seite hierzu aufgerufen. Sie kann aber in bestimmten Fällen nicht helfen:

Wenn wir den Axure-Prototypen vor Ort im User Lab testen, gibt es keine Probleme, solange die gewünschte Schriftart lokal auf dem Rechner installiert ist. Doch was ist, wenn wir unseren Prototypen unterwegs oder an Orten mit unzuverlässiger Internetverbindung testen wollen, aber dabei auf Fonts zugreifen müssen, die auf einem Server liegen? Z. B. einen speziellen Corporate Font. Oder wenn wir einen Remote Usability Test planen? Die Probanden haben keinen Zugriff auf lokal gespeicherte Fonts. Nicht immer lässt sich die gewünschte Schriftart auf einen Server hochladen (aus diversen Gründen).

Andere Prototyping-Tools, wie z. B. Adobe XD, haben dieses Problem nicht. Jede Schriftart wird online richtig angezeigt. Dafür haben XD-Prototypen aber auch längere Ladezeiten, was in manchen Fällen (z. B. Remote Usability Testing) andere Probleme mit sich bringt – abgesehen davon, dass Adobe XD mit seinem begrenzten Funktionsumfang Axure RP in Sachen Prototyping nicht das Wasser reichen kann. (Okay, die Sprachsteuerung ist interessant.)

Wie lösen wir dieses Problem? Müssen wir es wie in den Anfangszeiten des Internets machen und unsere Überschriften und Texte nun als Bild hinterlegen?

Mit CSS und Base64 Schriftarten einbetten

Nein. Die Lösung liegt in Base64. Dies ist ein Verfahren, mit dem 8Bit-Binärdaten (z. B. Bilder oder eben Fonts) in eine codierte Zeichenfolge umgewandelt werden. Damit können Anwendungen fehlerfrei Inhalte austauschen, auch zwischen solchen, die nicht für die Übertragung von z. B. Bildern gedacht sind. Im Web findet Base64 aber auch an anderen Stellen Verwendung. Z. B. codieren einige Webseiten ihre Inhalte in diesem Format, um diese vor einer ungewollten Verbreitung zu schützen.

Wie binden wir unsere Schrift nun in Axure RP ein? Dazu eine Step-by-Step-Anleitung:

Nehmen wir an, wir wollen eine Landingpage erstellen, die mit einer ausgefalleneren Schriftart ausgestattet ist. Ich habe mich daher für einen kostenlosen Display-Font entschieden: die charakterstarke Hyrbo, von Dom Rowland.

In Axure RP sieht der Font korrekt aus:

So sieht meine Landingpage in Axure RP aus. Alles prima. Und so, wenn ich meinen Prototypen lokal veröffentliche.
Auch schön.

Veröffentliche ich den Prototypen nun jedoch online und rufe den Link mit einem anderen Gerät auf, nimmt der Ärger seinen Lauf:

Dieses Bild hat ein leeres Alt-Attribut. Der Dateiname ist 03-616x456.png
Das hat mit dem bisherigen Design nicht mehr viel zu tun.

Nun kommen CSS und Base64 ins Spiel. Hierzu öffne ich die entsprechenden Einstellungen in Axure RP und gehe auf den Reiter „Fonts“:

Unter „Publish“ auf „Publish to Axure Cloud“ klicken
(oder auf „Generate HTML Files“, wenn der Prototyp
lokal aufgerufen werden soll).
Dort auf den Reiter „Fonts“ klicken.

Dort klicken wir auf „Font Mapping“ und mappen unsere gewünschte Schriftart mit der lokal installierten Font (Das scheint zunächst keinen Sinn zu ergeben, ist für eine Online-Veröffentlichung aber wichtig. Soll der Prototyp ausschließlich offline verwendet werden, können wir hier den Namen einer installierten Schrift angeben, die durch die gewünschte Schrift ersetzt werden soll). Anschließend müssen wir wieder in die vorherige Einstellung und klicken dort auf „+ Add Font“, geben hier denselben Namen erneut ein und klicken auf den Reiter „@font-face“:

Unter „Font Mapping“ können wir unsere
gewünschte Schriftart durch den installierten
Font „ersetzen“.
Zurückgehen, auf „+ Add Font“ und dort auf „@font-face“ klicken.
Name des Fonts eingeben.

Hier wird es spannend. Denn in das Feld gehören nun die entsprechenden CSS-Angaben sowie die Base64-Codefolge. Um den Base64-Code zu erhalten, suchen wir im Web nach einem der zahlreichen Online Encoder, der den verschlüsselten Zeichensatz unserer Schriftart erstellen muss. Beispielhaft können wir diesen hier nehmen.

Was passiert hier mit unserer Schriftart? Die Tools enkodieren die Zeichen der Font in eine sehr lange Zeichenfolge. Diese können wir per CSS direkt in den Prototypen einbinden, ohne sie dafür auf einem anderen Server zugänglich zu machen. Bei manchen Online-Konvertern können wir auch exakt angeben, welche Zeichen der Schriftart wir in Base64 verschlüsseln wollen. Dies ist vor allem sinnvoll, wenn wir mehrere Schriftarten gleichzeitig einbinden wollen, nicht alle Zeichen benötigen oder die Ladegeschwindigkeit jedoch nicht zu sehr belasten möchten.

Nun benötigen wir den folgenden CSS-Schnipsel und fügen dort den Namen (font-family) unserer Schriftart sowie den scheinbar endlos langen Base64-Code ein:

font-family: HIER_DEN_NAMEN_EINGEBEN; src: url(data:application/font-ttf;charset=utf-8;base64,HIER_DIE_BASE64-ZEICHENFOLGE-EINFÜGEN) format(‚truetype‘);

Das sieht dann ungefähr so aus:


In das freie Feld muss die entsprechende Zeile CSS sowie unser Base64-Code eingefügt werden.

Fertig! Wenn wir nun den Prototypen lokal oder online veröffentlichen, werden wir unsere Landingpage im gewünschten Design vorfinden.

Mit dieser Methode lassen sich auch Icon-Fonts umwandeln.

(Anmerkung: Einen Fehler konnte ich persönlich trotz dieser Methode finden: Wenn die enkodierte Schriftart in mehreren verschachtelten Gruppen gemeinsam mit SVG-Grafiken verortet ist, kommt es bei manchen Browsern seltsamerweise vereinzelt zu Darstellungsfehlern. Hier kann es helfen, die betroffenen Gruppen aufzulösen.)

Portraitfoto: Robin Nagel

Robin Nagel

Senior User Experience Consultant

eresult GmbH

Bisher veröffentlichte Beiträge: 10

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert