One Year Later: An Interview with Louis-Rémi Babé and Yannick Mathey of Prototypo

ThomasJockin

Hey everyone!

This week, TypeThursday interviewed Louis-Rémi and Yannick of Prototypo.
You can read the interview on Medium

One point I found surprising from the interview was Prototypo's expressed interest in working with type designers to make parametric fonts, as seen in the statement:

“Prototypo won’t be successful if we can’t get type designers to help us create parametric typefaces inside the application.”

What is everyone's position on this?
Are you for or against designing such typefaces?

Bahman Eslami

I'm not against parametric typefaces but the way the idea has been implemented in the tools I've seen so far is restrictive. These tools seem too suggestive to me and creates a bias for the designer. The idea of parametric design is mostly based on constructive shapes so it might not work for every script that does not comply with roman design parameters. I suppose the restrictions in these tools comes from the fact that they are not built with collaboration of professional type designers and it merely pursues efficiency and and perhaps automation. Maybe if they look at writing and finding parameters in there (instead of type and particularly Latin type) it could lead to much more suitable design space.

James Puckett

Has anyone finished and released a typeface that began with Prototypo?

Nick Shinn

I registered at their website, but couldn’t figure out how to access the application to try it out.

attar

Frode Bo Helland said:

If one where to start with outlines, however, I can imagine all sorts of interesting possibilities.

Well, in the interview they say they want to make it easier to create/convert initial outlines (right now, outlines have to be converted to their code representation before they can be used in the app).

attar

Frode Bo Helland said:

Why translate every point in a vector drawing into code, when that is exactly what a vector drawing is?

Well afaict a vector drawing is basically a list of point coordinates, not code. If you look at the glyphs in their fonts e.g.: https://github.com/byte-foundry/john-fell.ptf/blob/master/src/glyphs/lowercases/a.coffee it's literally code, point positions are defined in function of their siblings, variables and/or math functions.
I think they simply need more explicit relationships between the various elements of a glyph such that they can change the variables to get their sliders going. e.g. I see glyphs that have a "serifWidth" variable, which must be put in use when you alter the serif's shape. Spacing, xheight etc. are all variables and appear in formulas of a point's position.

Ofir Shavit

The necessity of pairs of nodes (inner and outer outline) for parametric design is obvious, this way you can control their relation (distance, angle, handles relations etc').
But coding the initial typeface is probably harder than anything, this is where the skeleton should take place, as in Fontark, for by simply drawing the centreline/skeleton you actually program the outline's node pairs and there you have a parametric typeface, and not a "fixed" and limiting one, since you can edit the skeleton during all the design process you are almost unlimited and have the most flexible control over the outline eventually, plus a super fast and simple way to draw/build/code the initial typeface.
Fontark of course has beneath all that the SmartX system which enables a controllable and flexible sync of the glyphs, but that's another story.

Ofir Shavit

Contrast?

Miles Newlyn

I'm very open to trying parametric type design as a starting point for a new design.
I tried the free Prototypo demo using the preset 'Grotesque' which has many design problems from the outset, but found that with just the smallest change with a slider distorted the letterforms to a point that was so ugly it seemed that to correct these problems would be more work than my fairly traditional manual process.
This seemed like a very quick dismissal of Prototypo's results, I'd have liked to have seen results that enticed me to dig deeper.

Ofir Shavit

I mean that changing weight to bold is only one thing. What about changing contrast, width (without losing stroke integrity) and many other aspects.

The issue is complex and very interesting (to me at least), I see it in an evolutionary perspective, and evolution is not linear, it has leaps. One of the major changes (not to say advantages because this is a relative term) is the visible real-time modification, which is very different than "executing a command" and waiting to the result, and it has a significant impact on the design process.
Of course it is far from the traditional design process, which is great and will always be great, but, admit it or not, doesn't suits naturally to computer technology. (Drawing by hand and using besier curves has nothing in common for example). 
Take Spacing for instance, You work today with classes, that's effective in a way. But i'm a designer in nature, when I see tables with numbers I freak out. With Fontark I simply and intuitively mark the glyphs I want to space (saves them as a group by a click) and tweak it up. It is like piano playing in opposed to filling reports.

So there's the traditional process, digital technology, and in between there's mostly human creativity.

I have tried Prototypo and was disappointed too, the advantages of tweaking a fixed typeface (coded in advance) are minor, and useful in a very narrow span of modifications, provided they're done well, and since you have to code every new typeface, this is just shifting the problem to another part of the process if not creating a new one.

Fontark's approach is very different, and I think it combines better the human-machine ways of work and capabilities, so to say. Prototypo is enlarging the distance between the designer and the typeface (by limiting the control to a set of sliders), Fontark let you deep both of your hands into it, like in an open heart surgery.

Another important and interesting aspect is that both PT and FA are private and independent initiations of designers (in opposed to code developers), with very little to no support at all in our ever growing corporational world, that can evolve and grow up to be really great, but as said, community's help is fundamental to it's success.

Ofir Shavit

How much work is that defining distances?

Ofir Shavit

How is that comparable with this?:
https://youtu.be/5qMrMytabUI

* If you think we should move this discussion to another topic, that's fine with me.

Dave Crossland

Ofir Shavit said:

* If you think we should move this discussion to another topic, that's fine with me.

I'm enjoying following along

Ofir Shavit

Ofir Shavit said:

How is that comparable with this?:
https://youtu.be/5qMrMytabUI

I guess it's not.

Louis Rémi

Hi guys, sorry for the late reply, the week was rather busy : )

Most graphic designers will be happy to simply use a well designed parametric typeface, as it already represents a significant improvement in terms of creation over using an existing font. But they need many distinctive and well designed parametric typefaces to be able to create a font that suits their needs.

So one of the main challenges for projects such as Metapolator, FontArk and Prototypo is to get type designers to create those parametric typefaces. And the easier we make this process, the more typefaces we'll get. The problem is that, "making creation easier" is almost always synonym with "limiting the creative possibilities". This is the case with the skeleton approach, and with Hobby Splines: you give up some control on the resulting outline, but make it way easier to produce coherent shapes and alphabets.

In Prototypo we started using an outline approach but soon had to admit that it didn't scale. This is why we later switched to a hybrid approach where we combine skeletons for stems and outlines for expressive serifs.

Our next challenge is to develop a visual tool to create parametric typefaces. We're getting there, but the KickStarter campaign clearly wasn't sufficient to cover the development of such a tool ; )

Bahman Eslami

In Prototypo we started using an outline approach but soon had to admit that it didn't scale. This is why we later switched to a hybrid approach where we combine skeletons for stems and outlines for expressive serifs.

I apologize if I sound blunt but You see this is where it goes downward for me. Why do we need a parameter called Serif for crying out loud?! Serif is an idea, you're putting ideas in designer's heads! I wouldn't use a tool that tells me okay this is the parameters like horizontal stem and vertical stem. I wouldn't even use a tool that would tell me these are type of pen that you have and these are parameters according to Vox classification, because those parameters are very specific and they are the tools for the inventor of those terms to describe the phenomena that we call typeface styles. If I want to design a typeface it's because I want to describe my own feelings with letters and this doesn't happen by playing with these parameters simply because they are not mine and I want to think in my own specific way. Does it make any sense?

Louis Rémi

@Frode Bo Helland «a significant improvement in terms of creation». Type design is the last frontiere in graphic design, that's why graphic designers are receptive to tools that make it approchable.

@Bahman Eslami Then we can agree that Prototypo is not intended for you  We've long accepted we cannot please everyone.

James Puckett

@louisremi To me the name Prototypo implies that the system is intended for creating a prototype to build on, similar to what Frank Blokland is doing with Letter Modeler. But you seem to be saying that it’s a tool for graphic designers to “design” fonts by adjusting parameters and downloading out a file. How do you intend for Prototypo to be used?

Adam Twardoch

Solutions such as Prototypo approach realistic scenarios from the wrong end.

Parametrize the teriary glyphs first — make parametrized mathematical operators, technical symbols, maybe combining diacritics, and the rest of the bulk of the Unicode long tail. Let people use these.

For a-z, you still want a real designer. It’s like with music: many musicians will happily employ synth drums and bass, but they want to play their guitar solo themselves. 

Ofir Shavit

@louisremi ; I believe that the way  to attract type designers to Prototypo is by letting them sell typefaces/templates in PT so GD could buy them and work with them in your app. For that you should provide a decent creation/integration tools, great manipulation algorithms that ends up with worthy results for amateurs, and proof commercial potential (demand). This way you will serve both ends.

In Fontark we have an excellent visual tool to create the initial typeface, the designer draws the skeleton and FA's engine extracts a workable outline of pairs of nodes of it in real time (we put a lot of efforts in developing this engine, not trivial at all with besier curves, and we still have a lot of work to perfect it) and caps which can vary and wear serifs etc', the skeleton is editable all the way up to the end of the design process, plus you draw the skeleton over what we call the Matrix, and SX system, which is a sophisticated grid of anchors, that syncs the skeletons across the typeface, all very simple and intuitive, but quite a challenge to market.
Basically, FA is not designed for amateurs, it is aimed and built for design work, as professional prototyping and for skilled graphic designers that can create typefaces if they have time/the right tool for it.
We also plan a templates market and fonts market, but all of these demands a lot of resources. 

@Adam Twardoch ; I think that practice will show that Unicode have many short tails instead of one long one, and you'll need a designer for each one.

 

Ray Larabie

Exactly, Adam. I feel like there's a lot of effort going into automating all the parts of type design that type designers don't want. Some of the following annoyances might not be the types of things that parametric tools can address. I use FontLab, the old version (Windows) so perhaps some of these problems have already been solved in other applications.

I don't need any parametric help drawing the Latin alphabet. There are very few situations in alphabet design where parametric tools would improve the process, other than keeping sidebearings consistent. I've seen a lot of parametric tools and they all seem to focus on modifying the alphabet. Interesting for you; useless for me. Defining and adjusting the bowls and humps (like bh) wouldn't save me time. Bowls are reused 3 times at the most (bpþ,dq) Humps (nhηm) Not worth the trouble of setting up. Maybe nice for doing obliques? It's really not important to me.

The ability to adjust the x-height, ascenders and descenders is useless to me. When I make an ultra-light from heavy or vice versa, I adjust the x-height by scaling the lowercase vertically. This messes up the ascenders and descenders which takes me about 4 minutes to fix, maybe a couple more minutes if there's Greek. The distortion in the stem thickness when scaling doesn't matter because I only scale x-height when I'm designing a different weight. If I'm scaling my boldest weight to use as a template to create my lightest weight, the change in stroke thickness is of no concern. I just can't imagine any other reason for adjusting the x-height. The ability to adjust the height of diacriticals after they've been applied would be a time saver. For example, if I change the x-height for a lighter weight, I need the lowercase diacritics to shift vertically while leaving the capital diacritics alone.

Smart sidebearings would be helpful. Right now, at least in FontLab, you have to copy/paste, memorize or scribble on scraps of paper. Sometimes I want to tweak a letter after I've filled out the diacriticals. It's especially painful after generating 80 instances but I've done it. One time, it took me 2 solid days to adjust the sidebearing on one letter because I noticed it after generating instances/cleanup.

Here are some examples of characters that would benefit from automation. Currently, I make these using disposable component glyphs which, after interpolation, are decomposed. Then the welding begins. Removing overlaps, building connections, checking sidebearings. It's especially messy for italics. These characters alone can add 2-3 days of work to a large family.

ƁɓƇƈƊɗƘƙƝɲƳƴҐґҒғҖҗҚқҢңҰұҲҳҶҷӃӄɌɍŒœæƠơƯư.

Flippies: my own term. These are glyphs made with components which use 180° rotations (xy scale -100%)  )}]>≥›¿¡әҺһƎ  At the end of production, these are decomposed. During production, they're annoying because they move in the opposite direction of parental sidebearing shifts. They're not just used for the sake of laziness. When you're interpolating something like ?, you want the ¿ to interpolate identically.

Glyphs made of components which are really parents. If I make ƠơƯư using OoUu ̛ , I can't use them as parents for ỚớỜờỞởỠỡỢợỨứỪừỬửỮữỰự. I don't know if there's a parametric solution for that one but it's sure is a drag.

Serif assistance seems pointless to me. Serifs are not just caps, stuck on the ends of lines. They're the letter itself. I don't understand how adjusting serif parameters would be useful. If you need different serifs, you need a whole new font. If I make a Clarendon serif and change it to a slab, I need to rethink my K, my O, ball terminals, the g...basically make a new font. It's exciting for stage presentations to get the audience cheering but not something a type designer would have a use for.

Ofir Shavit

Ray Larabie said:

Exactly, Adam.

There's a contradiction here, because the problems described by Ray are mostly not parametric issues, and could have been automated and solved in traditional type design tools 20 years ago (why didn't they?), but Adam suggests parametric tools should do it.

To make things clearer I will divide the type design process to 3 stages as follows...

Stage A - The DNA, the design work, The A-Z art.
Stage B - Tuning. Mainly dealing with proportions - Thickness, contrast, relations, spacing, slant, etc'.
Stage C - The tail. The extraction, compositing, welding, OT features, etc'. (And there should be a D stage for pure technical issues such as naming, hinting, etc' but these are out of this disscussion).

You say that there's no problem with stage A with traditional tools, B is practically part of A, and C is the pain in the ass (hope this word is aloud here).

Prototypo (at the moment at least) is focused on stage B.

In my opinion A and C are related and dependant, the method you perform A is influencing, limiting and binding C (and One big reason why all the C problems hasn't yet been dealt with efficiently), and I say that there's a lot to improve in A tools and methods (crazy guy), improvements that makes (B and) C much easier to deal with, but I'll start a new discussion for that later on.

Kent Lew

I use FontLab, the old version (Windows) so perhaps some of these problems have already been solved in other applications.

Yes, Ray, many of these are solved (or solvable) in current [non-parametric] apps.

Dave Crossland

Ofir Shavit said: could have been automated and solved in traditional type design tools 20 years ago (why didn't they?), but Adam suggests parametric tools should do it.

In fact there were several independent efforts about 20 years ago, including Sampo Kaasila's "Incubator Pro," Ares' "Font Chameleon," and ElseWare "FontWorks."

http://luc.devroye.org/fonts-33674.html

https://www.myfonts.com/foundry/Elseware/

http://www.truetype-typography.com/ttparam.htm

Ofir Shavit

These looks like stage B parametric tools that didn't deal with stage C's technical issues of compositing characters of existing parts.