Web fonts und html-Newsletter: Verträgt sich das? Deckt das die Lizenz ab?

[[Mitglied 21bb…]]

Kunde will seine newsletter in seiner Hausschrift angezeigt sehen. Für Print und Web haben wir bei lineto die jeweiligen Lizenzen erstanden, die Web-Lizenz ist für 1 domain erteilt worden.

 

1. Deckt die Web-Lizenz den Einsatz für den newsletter ab? In der EULA hab ich nichts gefunden und lineto hat sich noch nicht dazu gemeldet
2. Macht es generell Sinn, webfonts in newslettern einzusetzen oder kann das der Großteil der Mailprogramme eh nicht oder nur falsch darstellen, wie eine kurze Recherche ergeben hat?

Über euren input freut sich der

bertel

[[Mitglied Phoi…]]

Sofern die Webfonts von der Website geladen werden, geht das mit dem Newsletter, das Verschicken der Font-Dateien wird nicht abgedeckt. 

Zum Sinn: Es gibt immer noch nicht wenige Menschen, die nur Text-Emails akzeptieren bzw. anzeigen lassen. Wenn Ihr wirklich Euer eigenes Layout versandt wissen wollt, bleibt nur der Weg über PDF.

[[Mitglied Þors…]]

Nach unserer Erfahrung hat sich in den letzten Jahren bei den Email-Programmen (bzw. -Apps) hier nichts wirklich zum Besseren gewendet. Man hätte ja erwarten können, dass die Zahl derer, die HTML-Mails mit eingebundenen externen Ressourcen – wie eben Webfonts – nicht automatisch und problemlos sehen, ständig schwinden sollte. Dem ist aber nicht so. Der Anteil der Mobilgeräte steigt weiter; die Heterogenität der Bildschirme und Betriebssysteme auch. Denk nur an Smartwatches, Spielkonsolen, Fernseher mit Internet, Internet im Auto.

 

Und dann darfst du die Leute nicht vergessen, die kein Desktop-Programm und keine Mobil-App zum Emaillesen verwenden, sondern einen von unzähligen Webmail-Clients. Dort geht der Trend auch eher dahin, externe Ressourcen aus Sicherheitsgründen nicht einzubinden (und manchmal wird das dem Nutzer nicht mal auf Nachfrage ermöglicht).

 

Der einzige Lichtblick scheint zu sein, dass Desktop-Webbrowser immer besser werden, also immer mehr in Richtung der Standards konvergieren. Mittlerweile kann sogar der aktuelle Windows-Browser Edge z.B. richtig gut CSS, inklusive aller wichtigen Opentype-Funktionen! Daher wird PDF weniger wichtig. Aber um halbwegs sicher zu gehen, dass deine Inhalte zu angezeigt werden wie beabsichtigt, musst du die Nutzer schon dazu animieren, den Newsletter mit einem Webbrowser zu betrachten.

 

Fazit: Plain-Text-Mails mit Link(s) zu einer Web-Seite und Anreißer-Text(en) sind weiterhin der beste Weg.

[[Mitglied Þors…]]

Sofern die Webfonts von der Website geladen werden, geht das mit dem Newsletter, das Verschicken der Font-Dateien wird nicht abgedeckt.

Bist du dir da sicher? Stell dir folgendes Szenarium vor: Ich habe Webfonts für eine Domain, ihrdesigner.aa, lizensiert. Dann darf ich sie für Webseiten, die auf ihrdesigner.aa gehostet werden, verwenden. Soweit so gut. Aber dürfte ich sie dann (technisch analog zu Google Webfonts) auch per externem CSS auf kundenseite.aa einbinden? Nein? Aber sie würden doch von der Domain, für die sie lizenziert wurden, geladen! HTML-Mail, die ja mit keiner zu einer Domain gehörenden Website explizit assoziiert ist, wäre da vielleicht irgendwo in einer Grauzone, würde ich befürchten.

[Ralf Herrmann]

Bist du dir da sicher? Stell dir folgendes Szenarium vor: Ich habe Webfonts für eine Domain, ihrdesigner.aa, lizensiert. Dann darf ich sie für Webseiten, die auf ihrdesigner.aa gehostet werden, verwenden. Soweit so gut. Aber dürfte ich sie dann (technisch analog zu Google Webfonts) auch per externem CSS auf kundenseite.aa einbinden? Nein? Aber sie würden doch von der Domain, für die sie lizenziert wurden, geladen! HTML-Mail, die ja mit keiner zu einer Domain gehörenden Website explizit assoziiert ist, wäre da vielleicht irgendwo in einer Grauzone, würde ich befürchten.

 

Das Gedankenbeispiel ist berechtigt, gilt aber natürlich nur für den Fall, dass die Webfonts überhaupt an Domains gebunden sind und nicht zum Beispiel an Pageviews für beliebige Webinhalte. 

[[Mitglied Þors…]]

Klar. Wobei man dann aber eben auch genau nachlesen müsste, was im Email-Kontext eine Pageview ausmacht. (Und eine HTML-formatierte Email ist, streng genommen, auch kein Webinhalt.)

[[Mitglied 21bb…]]

Die Lizenz sagt:

 

[[Mitglied Þors…]]

Wär’s mein Kunde, würde ich die diesbezügliche Unsicherheit einfach als Argumentationshilfe benutzen, um ihn in Richtung Plain-Text-Email mit Webseitenverweis (oder, bei sehr kritischem Layout, auch PDF-Download) zu steuern.

 

Hätte ich keinerlei technische Bedenken, würde ich mich bei diesen Lizenzbedingungen als hauptsächlich auf dem US-Markt aktive US-Firma erst mal keine größeren Sorgen machen – solange der Newsletter von der lizenzierten Domain verschickt wird und die Zahl der monatlichen Newsletter halt im Bereich der erlaubten Page Views liegt. Aber US-Rechtsprechung funktioniert ganz anders als in Deutschland (und der Schweiz?): solange ein Beklagter plausibel darlegen kann, dass ein durchschnittlicher Lizenznehmer die Lizenz vernünftig (in seinem Sinn) interpretiert, hat er exzellente Chancen, damit durchzukommen. Eine der deutschen Abmahnmafia vergleichbare Abmahnindustrie gibt es bei uns auch nicht.

 

Ob das in DE und oder CH wegen irgendwelcher Spitzfindigkeiten u.U. doch teuer werden könnte, wage ich nicht zu beurteilen.

[[Mitglied Muec…]]

Sofern die Webfonts von der Website geladen werden, geht das

... nur, wenn man beim Lesen der E-Mail auch noch online ist.

Eigentlich war das System E-Mail mal so konzipiert, dass man sich einen Schwung Mails runterlädt und die dann offline lesen kann,

Es wird immer noch Leute gehen, die das genau so machen .... Nicht wie unsereiner mit Webmail ...

Zum Sinn: Es gibt immer noch nicht wenige Menschen, die nur Text-Emails akzeptieren bzw. anzeigen lassen.

Das ist auch mein liebstes Mail-Format. Verschicken tue ich nur sowas. Beim Empfang kann man es sich nicht immer aussuchen ... Leider ...

Das automatische Anzeigen von Bildern habe ich meinem Webmailer aber bspw. abgewöhnt ...

Nach unserer Erfahrung hat sich in den letzten Jahren bei den Email-Programmen (bzw. -Apps) hier nichts wirklich zum Besseren gewendet. Man hätte ja erwarten können, dass die Zahl derer, die HTML-Mails mit eingebundenen externen Ressourcen – wie eben Webfonts – nicht automatisch und problemlos sehen, ständig schwinden sollte. Dem ist aber nicht so. Der Anteil der Mobilgeräte steigt weiter; die Heterogenität der Bildschirme und Betriebssysteme auch. Denk nur an Smartwatches, Spielkonsolen, Fernseher mit Internet, Internet im Auto.

Eben!

Ist bei dem Hintergrund der Tipp ...

Wenn Ihr wirklich Euer eigenes Layout versandt wissen wollt, bleibt nur der Weg über PDF.

... überhaupt tauglich?

Und dann darfst du die Leute nicht vergessen, die kein Desktop-Programm und keine Mobil-App zum Emaillesen verwenden, sondern einen von unzähligen Webmail-Clients. Dort geht der Trend auch eher dahin, externe Ressourcen aus Sicherheitsgründen nicht einzubinden (und manchmal wird das dem Nutzer nicht mal auf Nachfrage ermöglicht).

Eben!

Fazit: Plain-Text-Mails mit Link(s) zu einer Web-Seite und Anreißer-Text(en) sind weiterhin der beste Weg.

Das ist auch mein Favorit als Leser. Wenn ich mal Newsletter lese ... Die meisten dümpeln eh ungelesen im Postfach ... Ein guter Betreff ist jedenfalls wichtig!

Bei Der Variante mit Webfont in Mail einbinden, wenn das überhaupt geht, ist noch die Datenmenge zu beachten, die jedes Mal das Postfach füllt ...

[[Mitglied 21bb…]]

 

Bei Der Variante mit Webfont in Mail einbinden, wenn das überhaupt geht, ist noch die Datenmenge zu beachten, die jedes Mal das Postfach füllt ...

Ist das denn so? Ich dachte die Webfonts werden temporär geladen um die Schrift anzuzeigen und werden eben nicht runtergeladen und auf dem Zielrechner gesichert … 

[Ralf Herrmann]

… um ihn in Richtung Plain-Text-Email mit Webseitenverweis (oder, bei sehr kritischem Layout, auch PDF-Download) zu steuern.

 

Auch wenn ich die Gründe dazu nachvollziehen kann, möchte ich doch mal einwerfen, dass dies natürlich nicht der Normalfall und im Zweifel auch nicht im Sinne des konkreten Kunden ist. Dass hier bei mir Newsletter als PDF ankämen ist die absolute Ausnahme und wenn, nervt es mich eher. Gerade bei der Flut von E-Mails will man so schnell wie möglich sehen, wie relevant die Inhalte für einen sind – da stört jeder zusätzliche Klick sowie das Warten auf das Öffnen des PDF-Programms und die Chance ist groß, dass ich den Newsletter letztlich wieder abbestelle.

Den Verweis auf eine Webversion kenne ich überhaupt nur als einführender Link für HTML-Mails, die eventuell bei der Anzeige Probleme machen könnten. Ansonsten ist natürlich die Frage, was der Newsletter will. Reden wir von einer Behörde oder einem kommerziellen Unternehmen? Bei letzterem scheint mir doch der schicke, durchgestaltete HTML-Newsletter als eine Art Anzeige die nachvollziehbare Standardvariante. Der Nutzen (also am Ende finanzieller Ertrag) dieser Form überwiegt dann gegebenenfalls, dass einige Nutzer den Newsletter nicht perfekt angezeigt bekommen. 

Fallback-Lösungen bezüglich externer Ressourcen sind natürlich sinnvoll. Es schadet nicht, wenn das Layout auch erstmal ohne Bilder sinnvoll und wiedererkennbar aussieht, weil viele Nutzer Bilder standardmäßig blockieren. Für Webfonts würde man logischerweise einen Font Stack definieren, der dann notfalls auf passende Systemfonts zurückgreift. 

 

Bei obiger, domaingebundener Lizenz müsste man aber bei der Foundry wegen Newsletter-Nutzung noch einmal nachfragen/nachverhandeln. 

[[Mitglied Þors…]]

Gerade bei der Flut von E-Mails will man so schnell wie möglich sehen, wie relevant die Inhalte für einen sind – da stört jeder zusätzliche Klick sowie das Warten auf das Öffnen des PDF-Programms und die Chance ist groß, dass ich den Newsletter letztlich wieder abbestelle.

Ich meine tatsächlich keine Anzeigen (die so tun, als sein sie »echte« Newsletter und nur nicht abbestellt werden, weil das [a] vom Versender bewusst erschwert wird, die Inhalte vielleicht mal marginal interessieren könnten, [c] mit gelegentlichen Gutscheinen geködert wird oder [d] der Empfänger zu faul/abgelenkt ist, die Abbestellprozedur durchzuziehen). Was diese des »Newsletter« angehst, hast du natürlich völlig recht.

 

Es sind aber nicht nur Behörden, die »echte« Newsletter verschicken – also solche, die bewusst (und nicht als Nebeneffekt) abonniert werden und bei denen die Empfänger die Newsletter regelmäßig nicht nur einmal überfliegen. Zu den Organisationen, die solche Newsletter verschicken, gehören Non-Profits aller Art, nicht formal organisierte Interessengruppen, aber auch Unternehmen in der internen Kommunikation oder für eng begrenzte »High Affinity«-Nutzergruppen.

 

Abgesehen vielleicht von der internen Unternehmenskommunikation (und auch da wird es schwieriger, da »use your own device« immer populärer wird) kann man aber auch den loyalsten Anhängern nicht wirklich vorschreiben, welche Geräte sie benutzen sollen (na gut, es sei denn, man ist Apple). Und die sind dann eben besonders verstört, wenn der erwartete Rundbrief von »ihrer« Organisation nur zerschossen ankommt. 

 

Was PDFs angeht, hören wir von loyalen Nutzergruppen immer wieder, dass sie sich die Dinger ausdrucken und (privat) an den Kühlschrank bzw. (im Büro) neben den Monitor pinnen wollen. Und Webseiten auszudrucken sieht halt immer noch doof aus.

[[Mitglied Vitr…]]

Ist das denn so? Ich dachte die Webfonts werden temporär geladen um die Schrift anzuzeigen und werden eben nicht runtergeladen und auf dem Zielrechner gesichert … 

 

Üblicherweise ist dies so. Die Schriften liegen dann entweder auf dem eigenen Netzspeicherplatz oder auch auf speziell dafür vorgesehenen Servern z.B. bei den Diensten Google-Fonts oder Typekit. Ruft man nun eine Netzseite auf bei der Webfonts verwendet werden, werden die Schriften von dort zwar heruntergeladen, aber nicht wie normale Desktop-Schrifen installiert, sondern wie andere Netzinhalte in den Zwischenspeicher des Browsers befördert um sie zum Anzeigen des Seite zu benutzen.

Allerdings ist es auch möglich HTML-Seiten gar nicht ins Netz zu stellen sondern sie lokal, auf dem eigenen Rechner zu lagern (ggf. um sie später hochzuladen). Hier können dann die Webfonts auch auf dem eigenen Rechner liegen ohne installiert zu sein. Sie werden dann zum Anzeigen eben nicht aus dem Netz geladen sondern von der eigenen Festplatte.

 

So wie man bei einer HTML-Mail auch Bilder mitsenden kann die dann angezeigt werden, so ginge dies dann eben auch mit Webfonts. Praktisch habe ich dies aber noch nicht versucht und ob alle Mailprogramme mit Webfonts zurechtkommen weiß ich nicht.

[[Mitglied catf…]]

Und was passiert in diesem Fall, wenn der Empfänger diese Mail, um sie z.B. auf einem anderen Gerät zu nutzen dann über Datei - Speichern auf seinem Gerät abspeichert. Wenn ich so zur lokalen Nutzung eine Webseite speichere, wird ja zu der HTML-Datei ein Ordner mit den Resourcen dieser Seite gespeichert, und die Verlinkung in der HTML-Datei auf dieses Verzeichnis umgestellt.

Landet dann der Webfont auch in diesen Recourcen, und könnte der Empfänger, offnet er dieses Verzeichnis so eventuell diese Fontdatei missbräuchlich nutzen, wodurch dann ja ebentuell ein Lizenzproblem durch die Übertagung des Fonts zum Empfänger der Mail entstehen könnte?

[[Mitglied Vitr…]]

Würde die Schrift in eine Mail eingebettet wäre sie auch als Anhang separat abspeicherbar. Im Woff-Format aber nicht ohne konvertieren als Desktopschrift nutzbar.

Speichert man eine Netzseite ab so finden sich, zumindest im Firefox, keine Schriftdateien im Ressourcenordner. Man könnte aber versuchen die Netzadresse der Schrift herausfinden und sie dann einfach herunterladen oder sie aus dem Zwischenspeicher entnehmen. Wie dies genau funktioniert erkläre ich hier aber nicht, sonst gibt es bestimmt einen Rüffel.

Manche Woff-Dateien sind aber trickreich bearbeitet um ein konvertieren zu erschweren, leider erschweren diese Maßnahmen auch die Feststellung der Schriftart.