Font Testdriver?

Stuart Sandler

Hey Gang!

So after a ton of work on a Wordpress site for Font Diner, I was slapped in the face with the reality that Woo Commerce is an SEO turd and in turn have decided to start over using Shopify which turns out is an SEO champion!

Since Shopify is an all-in-one hosted solution it lead me to wonder about what would be the best way to do a testdrive feature for my new website. Previously I had used http://www.typeshow.net/ to render images but it adds a bit of page load and is a little pokey.

The flip side is that I can use some sort of embedded web font testdriver as well but I'm a little concerned the fonts may be vulnerable to theft from browser caches.

Any recommendations folks? Thanks in advance for your insight!

Stephen Coles

Have you looked at the tester from Typotheque’s Type Applications?

Stuart Sandler

Thanks Stephen, I'd forgotten about this one! LostType Co-Op has a nice web font based tester I saw also earlier this evening.

attar

impallari.com/testing may help.

Dave Crossland

Adrien, this isn't about testing font, but about showing potential customers a preview of the font before they purchase a license and download a licensed copy.

Kemie Guaida

I did a quick and dirty tester with a text field and javascript here:
jollygood test drive
It uses webfonts protected with fontsquirrel's "web only" obfuscation. That makes it no more and no less secure than using the font on the page itself. 

Lars Schwarz

This »obfuscation« can be removed by a 5 year old domesticated primate turning it back into a fully working desktop font within < 1 minute. If you want security, stick to image preview renderings of your web fonts (I know, this is sooooo FLIR like using Lynx)

Kemie Guaida

Yea, I know the obfuscation is hardly bulletproof, but my point is that the font is available to anyone visiting my page or any other page using the font as a Webfont anyway, so for me more security is not worth it.

Lars Schwarz

Technically speaking this is not obfuscating. Obfuscating means scrambling the source and make it unreadable. The »web only« flag is more like breaking things but keep them usable (like removing the packaging from a Snickers, wrap it in white paper and pretending you can't eat it anymore).

»Web only« probably helps if you want to prevent desktop usage, but I does not prevent anyone from taking the web font and use it as web font on another domain.

Kemie Guaida

Yes I know. But my point is, if you are allowing self-hosted webfont usage, this is a known risk. And if you're willing to take that risk (I am, others may not), then you can just as well use a webfont preview as a font tester.

Thierry Blancpain

Several questions worth asking yourself in this regard:
– Are your typefaces already available to people interested in pirating it? 
– Who do you optimize your business for? Pirates or actual customers?
– Will you lose or gain from making your typefaces easier to try, test, show to friends?

For me it is absolutely clear that trying to fight font piracy on the back of your paying customers is a losing proposition. I’m repeating myself on Typedrawers when it comes to this topic, but I couldn’t be more convinced by this: my time is best used by making our customers happier. It definitely isn’t well spent (or making me happy, for that matter) by trying to make font pirates’ life a tiny bit harder.

Just make a web font tester and be done with it. At this point, everything else is a useless waste of time.

Dave Crossland

Thierry, I think trying to hinder unlicensed use is an own-goal for foundries, since the biggest paychecks in the industry come from private settlements or public lawsuit damages over (unapologetic) unlicensed usage. (http://www.quora.com/Do-companies-get-sued-for-using-fonts-illegally)

Dalton Maag not only have a web font tester but encourage downloading and sharing their retail fonts for non-commerical usage. It will be interesting to see if any enforcement actions become public in the next few years.

Stuart Sandler

Just an update on this thread, MyFonts is now using an image testdrive solution instead of just rendering a WOFF font which I applaud and feel it will reduce the type of rampant piracy we've been seeing since they introduced the web font test-drive.

Revisiting this topic, are there any capable WordPress font test-drive systems that output images these days? I've already reached out to Johannes about his Fontsampler to see if outputting images is an option.

Lars Schwarz

Stuart Sandler said:

Just an update on this thread, MyFonts is now using an image testdrive solution instead of just rendering a WOFF font which I applaud and feel it will reduce the type of rampant piracy we've been seeing since they introduced the web font test-drive.

Revisiting this topic, are there any capable WordPress font test-drive systems that output images these days? I've already reached out to Johannes about his Fontsampler to see if outputting images is an option.

I might be wrong, but afaik MF never had a woff based, non-image based, preview unless you refer to Typecast which had been sunset 2 years ago?

Johannes Neumeier

From a technical point of view a Wordpress plugin just is nowhere near the right place for implementing any kind of text to image rendering; PHP libraries for rendering text are too rudimentary (like, font size and line height, and happy to understand unicode), and even as such cannot be relied on to be available on the myriad of hosting setups Wordpress sites find themselves on. I do get these requests from time to time, but I wholeheartedly agree with Thierry - time is spent better elsewhere. Heck, time would even be spent better improving the webfont base approach in my Wordpress plugin - time I cannot seem to find.

Devil's advocate: You'd have to create a server side rendering stack, say an python app based on harfbuzz, cairo - or could one use drawbot more conveniently for this? - host the fonts there, too, create an API for requesting images with size, font and sample text options, you'd probably want some smart caching of the rendered images (and a lot of storage for it), too, and your server infra need to be speedy in rendering, returning and transferring those images. And at the end of the day (or weeks of dev) you are still just returning images to a user, probably even only after they press a button each update because updating and rendering on keystroke/slider change is waaay to resource expensive. So, I don't see it. Not from a business point of view, not from a UX point of view; declining such a work even as commission would probably be stupid, but as I see it also the ethical thing to do as developer.

Johannes Neumeier

For fear of sounding a bit too harsh I want to add that I am sympathetic of course to the original problem of not wanting your fonts pirated, and neither do I want this happen to my fonts. If appealing to your customers and winning them over by making their purchasing decision as easy as possible is not enough and you want actual tangible protection, the best and most easiest way is to limit exposure. Subsetting the characters and features included in the preview webfonts is fairly easy to do with pyftsubset (part of the fontTools python package) and is the only real way of limiting what someone ripping your fonts will actually get in their ripped font.

Lars Schwarz

"is waaay to resource expensive"? It's 2020, using APIs/3rd party services to rending simple images like that isn't really an issue at all.

Lars Schwarz

IMHO there are only a handful of people that care about investing time and effort to prevent bad actors from eventually pirating their work. 

Lars Schwarz

On a side note there are other ways to protect web fonts (other than simple obfuscation) from being downloaded and pirated, or at least to make that process way harder than it's currently being implement on most sites.

JoyceKetterer

@Lars Schwarz  Do you mean CORS?

Lars Schwarz

@JoyceKetterer No, default browser security features should be used anyways, but this won't prevent people from simply grabbing/caching/proxying the woff file when transferred. I was referring to a completely different mechanism to load and display web fonts in general. Can't share any details here since this forum is kinda publicly available to everyone incl bad actors, but the solution I refer to works the same as current web font "live" previews from the end user perspective, but different when it comes to loading the respective font file.

Stuart Sandler

@Lars Schwarz @Johannes Neumeier I appreciate your insight and thoughts and in fact believe much of this already exists in the form of TypeShow which is now open sourced on Git - https://github.com/raureif/typeshow

In fact I had a conversation with the creator of the code who indicated he's not interested in supporting it any further but I believe he would be open to having the code updated and even made into a Wordpress plug-in.

I'm happy to put up some funds to commission this work if there is interest by other folks.

Lars Schwarz

@Stuart Sandler A service/API for that would be more useful, especially when taking into account that not everyone uses Wordpress (or its underlying tech-stack/programming language). This however would require hosting/uploading copyrighted material to some 3rd party which then involves some terms/contracts and stuff, which makes it somewhat complicated, internationally/legal-wise (even though still do-able of course).

Lars Schwarz

@Stuart Sandler @Johannes Neumeier On a side note: I did something very similar (a HarfBuzz based API for rendering preview) already, but I'm not into Wordpress Plugins dev. So if someone (Johannes?) wants to do that part I could easily provide an API for the rendering itself. However I would be focusing on something I have on mind that would allow using real web font previews, but without the "easy to download/cache/proxy" drawback.

Johannes Neumeier

@Lars Schwarz If you cannot post it publicly, because it can be reverse engineered, it, too, is a more or less simple obfuscation. Can you link us a site that uses such an approach, or if you feel that would paint someone a target, send such a link or explanation of what you refer to via PM — I am officially curious

For what it's worth, the Typeshow implementation centers, at its very core, around writing a rendered font to an image with this method, which supports just about picking a font, size and color (despite using FreeType under the hood).

Lars Schwarz

There is no site using this method yet, because for now it's only a proof-of-concept thing I suggested to 5, 6 people/foundries I thought they would be interested in.

Stuart Sandler

@Lars Schwarz @Johannes Neumeier the offer stands if you both want to tag team on an update to Typeshow. Also the reason I suggested creating it as a WP plug-in was for all the reasons you mentioned Lars. Better if this can be contained ideally but I think it could become part of a platform of Font Rendering as a Service if there is interest.

Helmut Wollmersdorfer

TypeShow renders an image at the backend. This needs an image processing library installed at the server. In this case PHP-GD compiled with FreeType (and maybe HarfBuzz). ImageMagick is also an option, compiled with FreeType or Pango.

On a cheap webspace supporting the popular CMSs WordPress or Typo3 PHP-GD will be installed, as many popular plug-ins or extensions need GD. I usually install it per default on servers for shared hosting. But I doubt that PHP-GD-freetype is installed on cheap webspaces. Never had such a demand from a customer. Others like PDF rendering is demanded sometimes.

It's questionable if a plugin for WP is a good way. WP is a big security hole itself. A provider will want extra money for special needs like FreeType or HarfBuzz, and maybe for additional ressources to provide performance. Would need a try how fast it is to render a few letters. Not so bad I guess. 

The code of TypeShow looks well structured and modern, but isn't maintained since 2013 years. It's so small, that it can be ported to any other language. An API would be a better option, just a few parameters via AJAX and get an image back.

It's also questionable if FreeType or HarfBuzz is needed. For my application of font identification it's not essential. This just needs some metrics of each glyph and a rendered image of each character (or a subset), which can be done in batch once for each font and store a special fingerprint in a database. This wouldn't even need a font, because it also works with images from a scanned book page or a specimen catalog. Or grab the image from a font shop.

Helmut Wollmersdorfer

Lars Schwarz said:

There is no site using this method yet, because for now it's only a proof-of-concept thing I suggested to 5, 6 people/foundries I thought they would be interested in.

If the font is sent to the client (browser), then it can be made usable. It's possible to make it harder by uglifying JavaScript, i. e. renaming all variables and functions with nonsense. Also the font itself can be obfuscated e. g. by changing codepoints (needs JS to convert them from user input to the special encoding of the font. You can also encrypt the code and the font. But somewhere you need the key and the decryption code. And this will be very slow with good encryption. If the renderer of the browser is used, then the font exists in the browser. Otherwise you need a renderer written JavaScript.

This doesn't avoid that somebody, which didn't sign an EULA directly, grabs the font from a website or extracts it from PDF. If it's a trivial creation then it's not protected by copyright. Nearly all text fonts are considered trivial creations (handycraft and not art) by jurisdictions in most countries.

Lars Schwarz

Helmut Wollmersdorfer said:

Lars Schwarz said:

There is no site using this method yet, because for now it's only a proof-of-concept thing I suggested to 5, 6 people/foundries I thought they would be interested in.

If the font is sent to the client (browser), then it can be made usable. 

Yes, but my approach is different. 

Helmut Wollmersdorfer said:

But I doubt that PHP-GD-freetype is installed on cheap webspaces.
...
It's questionable if a plugin for WP is a good way. WP is a big security hole itself. A provider will want extra money for special needs like FreeType or HarfBuzz, and ...

That's why I suggested to use a simple API/service instead.

Helmut Wollmersdorfer said:

It's also questionable if FreeType or HarfBuzz is needed. For my application of font identification it's not essential. 

Font identification is actually something different. Showing font previews based on image based data sounds like a bad idea.

Helmut Wollmersdorfer

Lars Schwarz said:

That's why I suggested to use a simple API/service instead.

An API hosted on an external server adds complexity. This server will need a GUI for the users (=fontmakers) to upload, user handling, maintain the fonts and provide additional metadata. A WP-Plugin will need the same, but only for one customer.

Of course a small widget in any frontend (WP, Typo3, others) using an API is more flexible. This can be pure JS + CSS. If this is convenient, depends on the number of different fonts to display.

In summary the development costs of API + customisable widget are a little  bit higher, but the result is more reusable and flexible. For the API-Backend anything can be used. And the widget needs only HTML around it.