Web Based Production System

Atilla Korap

In my private time I am doing an MA and I'm thinking about a certain data model. One of it's advantages could be that it would be possible to make font production easier and less of a headache. I think file based production is outdated. Nobody wants to deal with files on their hard disk anymore - especially when you are working on more than one font family. But who does anyway?

So I will describe briefly and very general what I am thinking about and want to ask you to state your opinion or add ideas.

Imagine you had a web based font production system. You would log on and have access to type designs you are working on, or have worked on (version controlled). The source format at this time could only be UFO since there are enough free libraries that allow you to program web based tools that do work with UFOs. You'd be able to check out UFOs and work on them in your font editor. After that you'd check the UFO back in and you'd could start the production.
There would also be a place to store all the administrative information that is required to build different font formats with maybe even different character sets (and their according feature files) from the designs that you have in store. For instance you have designed a big character set including Latin, Latin extended, Greek and Cyrillic, but you only want to build a TrueType with a Latin 1 character set. The system would allow you to do that and subset the charset accordingly, before it produces the font. This would allow you to generate any font at any time with the click of a button.

But apart from that, what kind of production related work would you like to be able to do in this kind of environment?
How much control do you need for the naming? How much would be automated through the system? How about merging character sets to a new file? What about making a custom version of an existing design? How could the system help you to keep track of all these things? How about app compatibility? How would you like the system to handle it? Would you like to be able to see what revision of a design ended up in the font produced eventually? Should it warn you that a design has been revised but the font is still stuck on a different revision? Blablablabla...

Note that I'm not talking about a web based font editor.

Thanks for your input!

Wes Adams

I'm intrigued by the idea that nobody wants to have files on their local machines and would be interested to know what basis the statement has. As far as it goes with editors, it seems to me that we have today some really good options. Subsetting is not a bad idea, certainly. Is the point to have the files served dynamically to the user?

What are the advantages specifically of your data model? Are they performance based? Most of the ideas you have seem to suggest interface solutions. In my opinion, the drawback that existing editors share is that it is not possible to make changes to their core functionalities. The best ones are not open source. Extensions do improve matters and it would be even more exciting if there were a forkable editor. For whatever reason, that never seems to work.

Atilla Korap

The basis of the statement about files is mainly based on two things.

1. My personal experience. I'm working at Monotype and in the past 15 years have processed those 10000s of fonts many times. One of the problems that you always end up having, is that you have several source files with the same design for each font product that you are generating (at least you'll have two different source files, if you have CFF and hinted TrueTypes). Changing the design in one of those requires you to remember to apply the changes to the other files. Wouldn't it be nice, if a system would keep track of that?

2. With the WWW things have been moving away from locally based files. You have your flickr for pictures, Google Docs for your documents, GitHub for your source code, and a a content management system for your publications, etc. You can structure and group things the way you want and the system keeps track of all the files in the background, generates packages to download, thumbnails for previewing, or simply integrates a approval process to ensure you are aware of what you are doing.

Those two things made me believe that in a few years time people will find it strange to work with files when it comes to fonts. People who learned about computers in the 80s to early 2000s are somewhat used to files and it gives us the feeling of being in check. Working with hundreds and thousands of files makes it cumbersome and error-prone though. And being in control can become a very distant state.

The data model keeps information that is specific to a font product separate from the design. The advantage and idea is that you can have as many font products as you want and you can manage the information (like naming and character sets) independently. At the same time the product will be attached to one source file that again you can manage independently. The system will tell you, when you do something that distorts the relationship between the source file and the end product. Then you can either accept the difference and keep the product related to a specific revision of the source file or you can update the product with the changes or you can fork the development of the design and start a new branch with an altered design. Like you would possibly do for a customized version of a typeface.

Making a web based production system is just one application for the model. I do believe you can serve fonts dynamically, but I think UFO is not the best format in terms of performance.
So this whole idea is rather a proof of concept. It would require an incredible amount of development work to solve all the issues around it. But you have to start somewhere.

Georg Seifert

I was thinking about a similar system. We might discuss this, if you like.

Ray Larabie

Files are crap. I'm not sure the following problems could be solved by ditching files so let me know what you think.

The ability to split a project and merge parts of it back together without breaking it would be useful. Part of my workflow often involves making dummy copies in "delete me" folders, working on them separately and copying and pasting parts of them back into the master project file and cleaning up the mess. Does the kerning come with the files I copy and paste? Only if I'm lucky. Sometimes I'll make a dummy copy, manipulate it, export the metrics or some other aspect and import that back in the master project.

Sometimes, when I want to get all experimental and such, I make a "delete me" copy of the master file. I write down that changes that I've made in order to reproduce them in the master font and then delete the experimental font file.

Manually setting all the font info and metrics for each file is a big drag. 15 years of the "auto" button not working in Fontlab has almost completely destroyed my will to live. Especially when the next/previous font button hasn't been properly debounced for half of those years so it arbitrarily skips over a font once it a while, just to keep me on my toes. If I weren't dealing with files maybe I could have some global settings for that type of thing.

Changing my mind about a kerning class and changing it in 42 files is a major bummer. Especially when I just finished fixing it and I notice another kerning class that needs changing... and then another one.

If I weren't dealing with files it might be easier to have global settings. Like a few years ago when they switched the naming for Cyrillics from afii to uni. Or like a few years ago when double encoding was deemed uncool and I had to open up several thousand font files to manually un-double them.

When I final export, I export the OTF then convert everything to TTF curves and remove hints, then export the TTFs. But I have to be careful to close all those files without saving so I don't wreck my clean OTF curves. If I screw it up, I have to revert to an older version in Dropbox. It happens when I'm tired. I don't save the TTF version because I already have several thousand master files to deal with... I don't need to double it.

If I make a variation like a stencil version of a font family. I'll make copies of all the finished files, modify them, and export. But later, if I make changes to the non-stencil family, I have to carefully make the same changes to all the files in exactly the same way or take my chances with the mask layer. It's be nice if variations were a branch of the main project so changes would be applied to both.

When I incorporated, I needed to add Inc. to my copyright message over and over across several kilofonts FOR DAYS.

A universal font submission format could be used to make life easier for designers and for distributors. Current number of zip files in my fonts folder: over 9000.

Save me, cloud!

Deleted Account

"But you have to start somewhere"

I do not talk about it much, because there are just so few power/volume users, and it is so expensive, and ultimately a doomsday machine if it gets loose from "responsible" developers. Otherwise, great idea!;).

Stuart Sandler

It's a fine idea Atilla but I guess the whole checking files in and out makes it cumbersome in my mind since I'm the only person working on it . . .

I see it as more of a Dropbox hybrid model where the File > Open dialog is hardwired to look at that folder specifically (even invisibly) to load a working UFO file that only sends the data I've changed back up to the cloud.

I couldn't or wouldn't generate my fonts from this file in the font editor but rather I'd generate all my final builds from the cloud service knowing it's combining a bunch of disparate pieces, optimizing the fonts and generating the correct formats.

You'd need to develop the cloud based featureset that'd really create the time savings. In addition to already having the naming data preferences, you'd likely want build preferences, perhaps an auto-composite feature, node checker, etc. If it's truly meant as a complement to the font editor, it should do some automated tasks so I don't have to do them in the editor.

That said, would it run python scripts on the files remotely? Could be a nifty thing to have . . . I could also see custom Automation script building like Apple offers to create batches of tasks instantaneously.

Can't wait to see how you flesh it out!

Dave Crossland

I think this is a great idea, and I'm eager to see what you cook up!

My Font Bakery project's roadmap has been to end up somewhere like this. Where its at, at the moment, is storing source files in a github repo's master branch, with a build script that calls only libre build tools; run the build using Travis on each commit; and push the output back to the repo's gh-pages branch (documented in https://github.com/googlefonts/fontbakery/#on-travis) along with diagnostic pages. And then there's a dashboard which takes a list of Github repos and shows tables with summary information from the diagnostic pages' data for the collection list.

While you say this isn't about a web based font editor, it seems to me such a system would naturally end up with one - Glyphr, perhaps I can see how the bakery diagnostic pages could evolve into a 'wiki' like system that is entirely web based. This is the kind of integration that I think desktop font editors could be weak at... A long time ago George Williams added a feature to FontForge that would pull down fonts from the Open Font Library, and also push edited versions back up. It was a bit rough, and the OFL developers changed their API so it broke soon after... But it is true that anything that can be done by a web based app can be done by a desktop app. I'd love to see working with fonts homed on Github made easier in all editors

Behdad suggested to me that http://noflojs.org could be used to make a finer UI for a web based production system as you describe; however I'm wary of a fully home-grown system because, as David Berlow says, it becomes expensive. Your 'Blablablabla' questions seem to me better dealt with using command line tools, and cookbook-recipe/snippets documentation to swipe from.

Luke Prowse

This is really interesting. I like the idea of multiple people working simultaneously on a single project/file - obviously with controls in place. Splitting tasks up and remerging can be laborious but more importantly things can slip through the cracks. Often we'll make mini-adjustments outside of the big to-do's and simply managing all that between even two designers working at the same time can be... how do I phrase this delicately? ...a ball ache.

Jack Jennings

Assuming that you have to build some part of this system first—that it won't emerge fully realized—what does the the most stripped down version do? That is to say, what part of your imagined system is the most important aspect?

I think that there's multiple ideas that aren't necessarily codependent:

* Version control (specialized for vectors)
* Manageable variations of a master source file
* Reproducible generation of assets from source file
* Automatic generation when source files change
* Web-based platform (hiding direct file interaction)

All of these things would be really nice to have, and from what I know of there's not an accessible, standard solution in the type world. I started on a system for just doing reproducible/automatic builds (actually this ended up being pretty close to the philosophy of noflo, @Dave Crossland), but didn't get very far; it's a ton work even if you break down each chunk.

From my perspective doing it all on the web is a component of the idea and not necessarily a prerequisite. I'm curious if you'd agree if you could only pick one to two aspects of this to build.

Wes Adams

Nice to see Jack chime in here. A couple years back he really dug into this stuff and probably knows the technical aspects better than most.

Ray's points make a lot of sense. It seems like the editors are designed with the idea of giving you control over each aspect, which in turn means they must all be defined. The idea of using a production compiler is not one we explored. Its a good one. 

As for the web aspect, the browser is really convenient for display and managing assets. 

Very keen on this, would like to stay updated.

Atilla Korap

Thanks for the replies so far and sorry for the late response.

My thinking actually comes top-down:
Here are a number of things that I have to deal with manually when I design and produce fonts and I want to change them.

Then I thought about what was required and all of Jack's mentions are basically the prerequisites to be able to build a web based platform. But it is not necessarily web based. It could also be a Robofont plugin that allows you to access your designs and work on them. Or to pull all information required from the system and produce a font.

So Version control and data consistency on any level is the core of this kind of system.

Atilla Korap

Stuart Sandler said:

It's a fine idea Atilla but I guess the whole checking files in and out makes it cumbersome in my mind since I'm the only person working on it . . .

I think it would be useful even then.

That said, would it run python scripts on the files remotely? Could be a nifty thing to have . . . I could also see custom Automation script building like Apple offers to create batches of tasks instantaneously.

Oh, wow! That is sort of, the next level!

Can't wait to see how you flesh it out!

Guess who else can't wait...

Dan Reynolds

> I think it would be useful even then.

I agree! Especially if there was some sort of record of what changes had been made to the file between the time it was checked-out and then checked back-in.

Stuart Sandler

Some other thoughts occurred to me as I read Wes' comment . . .

1) I guess I was responding to the task of manually checking things and and out (did this a long time ago and found it dreadful) - That said, instead of manually checking in and out characters, if the system could determine what glyph was being worked on based on if it was opened locally and if the data is being 'tweaked' or had recently been tweaked, then it would 'auto-lock' it from being editably by another party unless you threw up an alert that asks you if you want another party to take over in which case it would then allow you to 'see' the glyph but lock all the edit tools that may allow modifications.

2) I LOVE the idea that the browser becomes a panel of palettes you can toggle as you're working on the font. More like a hybrid editor where you're doing the glyph work locally using a desktop tool but also as part of your build environment are working with remote browser based tool panels.

Great stuff here!