Font Testdriver?

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!

«1

Comments

  • Stephen Coles
    Stephen Coles Posts: 1,006
    edited January 2015
    Have you looked at the tester from Typotheque’s Type Applications?
  • 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
    attar Posts: 209
    impallari.com/testing may help.
  • 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.
  • 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
    Lars Schwarz Posts: 114
    edited January 2015
    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)
  • 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
    Lars Schwarz Posts: 114
    edited January 2015
    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.
  • 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, 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.
  • 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.
  • 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?
  • 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.

  • 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.
  • "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.
  • IMHO there are only a handful of people that care about investing time and effort to prevent bad actors from eventually pirating their work. 
  • 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.
  • @Lars Schwarz  Do you mean CORS?
  • Lars Schwarz
    Lars Schwarz Posts: 114
    edited January 2020
    @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.
  • @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.
  • @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).
  • @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.
  • @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).
  • 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.
  • @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.
  • 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.
  • 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.
  • 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. 

    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.

    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.


  • 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.