Font Testdriver?

Lars Schwarz

Why so pessimistic? Sorry to say, but it sounds like you either don't want something like that for whatever reason or I'm missing your actual point? 

Building something new requires some effort, no big news here. 

Helmut Wollmersdorfer

Does it sound pessimistic?

I just want to estimate it realistically, if I should do it.

It's not new. Half of the work (prototype, proof of concept) is done. For the WP plug-in I would need 40 hours to be on the secure side, because I have never developed one and PHP is not me favorite language. Somebody experienced in developing WP plug-ins, e. g. a gallery (technically similar in many internals) will need half the time or be faster.

An API with a small frontend for user registration is easier for me, because done often.

How large is the demand? How many font designers are willing to pay how much for a backend service?

Lars Schwarz

Most likely nobody would pay for it, but maybe donate to it or support it in other ways.

IMHO MyFonts still using image based previews is as old school as it can get, seems they forgot about variable fonts, even though I do remember seeing them publishing some blog post/newsletter that advertised them as "cool trending stuff" recently. 

However for independent designers/foundries that don't want to use their original files due to concerns regarding illegal usage/piracy and that don't have time/money/devs for developing a custom type tester a 3rd party service that offers multiple CMS integrations would be "handy", handy in terms of useful. 

Some don't bother with illegal usage, some do. Some of those that do think that limiting/preventing illegal downloads and distribution of those fonts has a direct effect on sales and ... others don't. 

In other words, developing something like that shouldn't be about money at all even though donations/support helps/is welcome.

Johannes Neumeier

Good to have some discussion on this. I think any image based solutions are approaching the problem backwards and are an unfortunate compromise.

@Stuart Sandler I installed the TypeShow locally yesterday to test and if you have your own PHP webhosting you could try just install the code from the repo there and test if you can run the "demo.html" from your server. If so, you can configure it to use your fonts and run the app just for your own pleasure and use.

@Helmut Wollmersdorfer Regarding demand for such a thing. My woff-based Wordpress Fontsampler plugin has approximately 500 active installs — from support requests I gather maybe about half of users are some kinds of service providers that, for lack of anything better suited, use it to render previews of engraving/printing/customisation fonts for some other product of theirs, the other half are made up of the so-called "target audience" of designers, studios and indeed type foundries. I've seen it in use ranging form portfolio presentations to simple testers to fairly integrated into web shops. I'd say there are probably ~25 indie type foundries that use the plugin. How much of those users would a) translate to other platforms / an API service and b) a image based solution I dare not guess.

@Lars Schwarz Maybe you can describe the general gist of how your solution would approach the problem, without giving away any commercial interest you might have? If you render a true webfont at any point, I cannot see how an attacker could not grab the data in between, either when it goes over the wire, or when it goes into the fontface constructor. The pitching floor is yours, lots of potential customers also reading here

But let me circle back to my initial suggestion of subsetting and something that has been on my mind for a while (mostly because I receive these inquiries about protecting webfonts ever so often). Especially with all this talk about making this an API based service. I once hacked together a wrapper around pyftsubset for a flask application that can be used to dynamically subset webfonts to cover exactly the string requested from a user e.g. in the tester (I can put it online as a crude demo, if people are curious). The subsetting is fast enough for this to be near instantaneous even when performed on every keystroke (~15ms for the subset, plus caching rendered subsets, 1~15kb of woff2 to transfer for a moderate charset). This could be combined with an per-instance limit of unique characters (based on what and how the tester should work), so you could prevent downloading an overly big subset of the font ever in one go. Even when ripping one partial range after another within the limit, the kerning and feature code will still be subset to the specific range within the limit, so it would be fairly troublesome to reconstruct a good ripped replica of the original font. Or a foundry could choose not to have such a limit — it would still require someone to figure out to "type out" all unicode points in the font to ever be served a "full" copy of the woff.

In my Wordpress plugin this really is out of the question, because it requires the python setup and server side processing, but I think this is thinkable as an API based service. It could be as simple as loading an API javascript file on your foundry site and instantiating any "dynamic" webfont with a simple constructor that reloads from the API as the user types. The foundry can use whatever existing webfont based tester they want to or implement their own, and the webfont is served protected simply by being sent as tailored piecemeal to the user's browser. Does something like this sound at all feasible in the real world?

Roel Nieskens

Even when ripping one partial range after another within the limit, the kerning and feature code will still be subset to the specific range within the limit, so it would be fairly troublesome to reconstruct a good ripped replica of the original font.

After learning how brutal font rippers will go to work (like yanking outlined text from specimen PDFs and dumping them to a font) I doubt imperfect kerning will deter them.

Obscure hacks might give some peace of mind to the one offering the fonts, and an interesting puzzle for any pirate with 20 minutes of free time. But to fundamentally address this problem, you should look to browser makers, and the only option there would be a DRM-like construction. If you really, really don't want your fonts pirated, make noise for that.

(Of course, as long as the font will somehow show up on your screen, poor rips are going to continue to be possible)

Stuart Sandler

I think it's important to address the perception of the tone in this thread that rendering via images vs WOFF fonts is related to some sort of personal paranoia related to piracy.

In part, it is understood that no matter what precautions are taken, fonts inevitably over time will be pirated.

Offering customers a test drive of the font greatly helps them decide if they wish to purchase the font. If the test drive system uses images, only a rasterized image is downloaded to the user's browser locally and is only useful for the purpose of evaluation.

If the test drive system is WOFF/CSS based using a web font, we know it's simply a TTF file in a wrapper and even if we apply misdirection, subsetting or some combination of trickery, we're literally delivering the vector outlines and/or an installable font with very little conversion effort to return it to a mostly typeable font.

My position is simply if I can accomplish the task of offering a test drive to help the user decide if they wish to purchase my fonts, there is no harm delivering rasterized images. If I deliver WOFF files, I become the seed to my potential own piracy.

It's not a matter of paranoia, it's a matter of common sense.

Lars Schwarz

@Johannes Neumeier I prefer not to share any details here, but instead I'll continue working on the prototype of mine, so I can share an example once ready. 

Having a plugin that supports all options (images, subsets or complete web fonts) would be nice. I'd myself would prefer something that is more open (not in terms of open source) to all kind of integrations, that's why I would prefer an API/service for the rendering part and giving other devs the option to develop their own modules/plugins/extensions for whatever CMS/frontend they'd like to use it with.

Jasper de Waard

Personally, I have a preference for image-based testdrivers, but not because of pirating concerns. I simply think it makes most fonts look more like themselves. An image will look the same on any device and any browser, so a potential customer's opinion is not dependent on the software they use. Furthermore, hinting, in spite of all its practical benefits, has the tendency to make fonts look just a little different as one goes from one size to another. When I'm judging the aesthetical quality of a typeface, I don't like that. When the typeface is used on some website, it makes perfect sense. Of course, it makes sense to also see how a font performs as webfont, but that is a different matter.

Georg Seifert

Rasterized images might not look good on Retina or scaled viewports.