Howdy, Stranger!
Categories
- All Categories
- 39 Introductions
- 3.6K Typeface Design
- 765 Font Technology
- 1K Technique and Theory
- 590 Type Business
- 435 Type Design Critiques
- 527 Type Design Software
- 30 Punchcutting
- 132 Lettering and Calligraphy
- 79 Technique and Theory
- 53 Lettering Critiques
- 462 Typography
- 289 History of Typography
- 111 Education
- 62 Resources
- 480 Announcements
- 74 Events
- 104 Job Postings
- 147 Type Releases
- 154 Miscellaneous News
- 259 About TypeDrawers
- 52 TypeDrawers Announcements
- 109 Suggestions and Bug Reports
Options
We need a tutorial on how to create a font tester in HTML / CSS / JS
Igor Petrovic
Posts: 263
Just an idea, I think it would be great if some of the code-savvy folks here would be willing to make a tutorial on this. As I see it, it's the main component that is highly specific to font sites, and I guess it would make life easier for independent type designers and foundries.
Or is there already one that I overlooked?
Or is there already one that I overlooked?
0
Comments
I'm not going to write a complete tutorial because although it is quite specific to font sites, like all programming it's just a matter of thinking through the different steps of what you need to get done and how you're going to do it, and much of that is specific to the kind of site you're making.
Do you mean "font tester" from the point of view of the type designer or the potential purchaser? The answer's going to be different, but there'll be some overlap. Assuming the first:
- You need a way for the user to drop/upload the font onto the web site, and for you to then display text in it. I chose to use fontdrag.js from Ryan Seddon in Galvanized Jets, because that takes care of the main steps: decoding the font from the File object into a data: URI object; adding the URI to a CSS font-face rule; calling a callback to register the font with the rest of your testing app. But in other cases (like Crowbar and Fontpainter) I've done this by hand, using React Dropzone components as a base.
- You need to be able to inspect the font and see what it can do (variable axes, glyphs available, etc). I've done this in different ways in the past; Galvanized Jets used a variable-aware fork of opentype.js, but these days I'd probably use fontkit. If I were doing very custom stuff I might use harfbuzzjs.
- You need to provide an interface to variation sliders, and alter the CSS properties of your text based on user input. varfont.ts in Galvanized Jets is a good example of how to do that.
And those really are pretty much all the font-specific parts; other than that it's just all plain programming, and it depends on what other features you want to add.If you have any more specific questions I'd be happy to answer.
The idea is to help independent type designers to have their website (which I find very important given the situation on the market). For those of us who don't code it might be a big pain point that leaves us to the mercy of ~Corporations~ or direct us to the (in my opinion) expensive subsription solutions.
For example, at the moment I am able to do full HTML/CSS, but still don't know JS part. I am not sure I am in situation to dive into learning JS, but it would be really helpful for me to see a tutorial with JS part executed and commented (explaining the purpose of each step). Then I could have a general overview and insert the "JS module" into my existing site (and maybe even tweak JS here and there).
Nowadays there are solutions on the web to make your own website relatively easily, but still not for selling fonts. If we could manage to have this minimal type tester (for customer) as a clean copyable HTML/CSS/JS module that might be a bridge to those other "realtively easy" solutions.
Thanks John, I was hoping that it would be in the form of a code snippet like many HTML/CSS/JS tutorials on the web. Does it still need a license?
<html> <section class="try-me" contenteditable>Try me</section> <style class="my-css-rules" contenteditable>.my-css-rules { display: block; } .try-me { font-size: 150px; }</style> </html>Want to change the font? Specify the font-family.
Want to change it to one of your fonts? Use the @font-face rule to tell it where your font is.
Want to clean up your code so that the only CSS you see is what applies to the font tester? Add another style element at the top and move the other CSS rules there.
Later as you add Javascript to the page to listen for things like sliders or drop-down menus changing, you will learn how to automate the process of adding, changing, and removing CSS rules.
EDIT: Now I understand the principle, this is the perfect level of complexity/simplicity. If one knows where to find more resources like this short example, I would appreciate it
We’ll start with another simple HTML structure. Note that instead of using a style element like last time I’m using an inline style style="font-size: 100px;" since it’s a little easier to understand what’s happening when we change it dynamically. Then we’ll add a script tag with some Javascript to connect these two elements.
<html> <section id="demo" class="try-me" style="font-size: 100px;" contenteditable>Try me</section> <input type="range" name="size" id="slider" min="10" max="200" value="100" step="1"> <script> var demo = document.getElementById("demo"); var slider = document.getElementById("slider"); slider.addEventListener("input", function() { demo.style.fontSize = slider.value + "px"});</script> </html>After declaring our two variables, one representing the “Try me” demo element, and the other representing the slider, we now have a way of referring to each of these in our code.In line 3 we add something called an event listener to the slider so our code can respond whenever the slider receives an "input" event (whenever someone’s dragging around our slider). Try changing "input" to "change" to see the difference between these two kinds of events.
Line 4 of our Javascript is the function that is executed each time our event listener “hears something.” It says the demo element’s inline style should be replaced by a new value (the slider’s value). The + "px" is concatenated; this means we’re literally tacking on the px unit to the end of the value. For example if the value of the slider is 144, then the new inline style for the demo element will be font-size: 144px;
– Font size (slider) – you can add notches, for example, on 16, 24, 48 pt, or wherever you want.
– Leading (slider).
– Tracking (slider).
– Variable font axes (sliders) – very easy to add new axes with their ranges.
– Dark mode inversion.
– Font family styles choosing (drop down menu).
– Text snippets (I use it for testing different languages, figures, kerning, so on) – you can add your own easily.
– OpenType Features, Stylistic Sets, Kerning and so on (buttons for turning on/off) – most of them are already there, but very easy to add new features.
The produced code is terse as possible, while still taking into account some of the browser quirks and bugs, which would be a great starting point to learn how the JavaScript, font and HTML interact. (Alternatively, you can take a look at the main JavaScript that has all the good bits).
And how well
And that vs, or as well as, big families
However, if my customers later use font files on their websites, that's also the leak point, right? But that also makes thieves work harder, to chase fonts in the wild instead of harvest all the library in one place.
I got a rough estimation that making the described backend rendering could be a day of work or so for the PHP guy.
What are your thoughts on all of this?
the advice I've seen on typedrawers from people who sell a lot of fonts is that anti-piracy measures aren't worth the trouble; even if you lock down your own website, the retail fonts will make their way to shady forums, etc.
with that said there is more you can do on your own site, if you want (set a cross-origin policy, split the fonts into multiple files and use them in a CSS fallback chain, base64 encode them, etc)
Regarding the frontend rendering, I know the platforms and foundries that provide the font testing using direct browser rendering, and it works well for them. In the same time, the backend rendering is not so difficult to implement using some PHP library, but the rendering time is a bit longer and the people will experience some delay when typing.
If it is of any help, as a graphic designer that licenses a handful of fonts personally every year, and primarily works in branding—thus helping determine which fonts are licensed/used in projects—I won’t even consider a font from a foundry that does not include live font files on their site.
Seeing how the fonts actually render on screen is extremely important to my work. A png, jpg, or even SVG rendering does not suffice in my opinion.
My philosophy is, if you are too scared to host your own fonts, then why the hell do you even sell web fonts?
Basically, you prefer a raw frontend font rendering so you can evaluate the result?