The Next Font Format?
I started a wiki page collecting ideas:
https://meta.wikimedia.org/wiki/Future_Global_Font_Format_Requirements
Comments
-
You have made a good start!0
-
I don't know know how to propose this, formally into something that would work on a wiki page but here's what I'd like to see.
I think an important capability currently missing in the OpenType format is that lack of transparency control. Currently, the only way to simulate transparency is using dots, hatching, grain and other highly detailed tricks. These detailed fonts can end up being very heavy and render unpredictably. Gradient effects, the kind already supported by PostScript could accomplish these effects more reliably and with higher fidelity.
With current font technology, there's no elegant way to accurately simulate pencil, watercolor or calligraphy with semi-transparent ink. Transparent gradients would also allow experimental techniques reduce the need for pinching near intersections. Currently, we can only use stroke width to reduce weight. If we had transparency at our disposal, we could use new techniques involving less stroke width reduction or none at all. Here's a example of how transparency could be used to reduce an intersection's weight.
Here's a crude example, I drew with my mouse showing a pen effect that can currently only be done with multiple layers. Try to imagine how this would look in pencil, with transparency indicating pencil pressure variation as well. Currently, there's no way to make convincing pencil writing.
You can't really simulate a typewriter with current font technology. If you compare the best typewriter font with real typewriter print, there's no comparison. That rich range of grays is currently unavailable except using dots.
We've all seen beautiful calligraphy using transparent inks. Some of those effects could be simulated using transparent gradients. Gradients have been a part of PostScript for decades so perhaps it could be tacked onto the existing PostScript format but set up in a way that it would be backwards compatible with the current system.
4 -
Great idea! However, isn't this possible with the MS and Adobe-Mozilla color font formats?0
-
Thanks. I don't think those formats can do transparent gradients.0
-
The Adobe-Mozilla color font format most certainly can do transparent gradients and can do these things. The Microsoft one cannot, at least not in its current version.0
-
For the MS format, maybe not transparent, but if you assume your type is set black on white, and your gradient is white to black, who can tell?
Still, I agree that supporting truly transparent alpha colors in color formats is good, and something a future font format should support.0 -
The ms Color Tablets are RGBA. I made some tests and transparency is actually supported only the fonts from MS don't use it.1
-
Thanks for checking! That's what I assumed0
-
But transparency is on my wish list for a while now, too. And the proper way to integrate (pixel) images. Then you have the resolution problem but so much more possibilities. All that is supported by the adobe/Firefox proposel but I don't know if SVG is the right way to go.0
-
I would just like <calt> effects to not fail when tracking is applied.
Better yet, CS should support <rand>.0 -
It would be cool to animate glyphs, comparable to animated gifs that cycle continuously.
This would enable, for instance, buzzing neon, swaying fronds, swirling flourishes, letters that emerge through drawing, and all manner of skittery effects.
0 -
I wish there were a format that would take the browser and app out of the equation so type would work the same everywhere every time.6
-
I would like to see a new spacing paradigm. The current one, in which each glyph is contained in a rectangle and each rectangle butts up against the next, is unnecessarily simplistic. To work around it, we have pair kerning, which only works within a single font.
It seems to me that it would be simpler and more flexible if side bearings could have contours other than straight and vertical. They could be slanted, for instance, or follow the contour of the glyph in some useful way. Maybe we could even do without kerning tables.18 -
John Hudson has talked about sidebearings having shapes in the past. I think it’s a fabulous idea. That and (good) end-user software support for combining diacritical marks could free up a great deal of production and QA time that would better be spent on things like drawing or supporting more scripts.
On the subject of 3D fonts, it’s a cool idea, but impractical. Rigging up 3D animation is an art usually practiced by specialists. It’s not something many type designers would have time to learn on top of their other work. And the amount of human hours it would take to rig up an entire font so that the letters are well animated and don’t unrealistically collide would make the cost incredibly high. Outside of Hollywood tentpole films and AAA video games nobody would have the budget, which makes it unlikely anyone would develop the software to create such a font.0 -
Maybe that spacing paradigm could involve a geometry layer, a bit like collision meshes in video games. In a game, if you have a complex mesh and you need to check it for the purpose of the real-time calculation of collision physics, the visible, detailed geometry can be too taxing to calculate in real-time. For example, if you were to roll a ball down a detailed, bumpy path, there's a lot of heavy physics to calculate on-the-fly. Game designers create (manually or automatically) a simplified, hidden collision mesh for the purpose of being able to calculate collisions more quickly.
If we were able to create a simple, invisible shape layer to each glyph, it could help guide a real-time optical kerning system.
Another useful feature of a collision mesh is make sure the physics engine ignores certain, unwanted polygons. Going back to the hill example: if you have hill with a few blades of grass on it, you don't want a rolling ball to be affected by the grass. In the collision mesh, you'd leave out the blades of grass so you ball can roll right through.
If you use Adobe optical kerning on distressed fonts, you can see how specks and spots end up messing up the spacing. You can also feel the CPU struggle with the complex shapes of distressed fonts. With a simplified collision layer for each glyph, we could define which shapes matter for spacing and which should be ignored... just like those blades of video game grass.
At the very least, such a system could reduce the calculations required for optical kerning. I think it would also be very useful in preventing accent collisions, especially in composites where kerning can't even help. For example, a T colliding with a composite accented lowercase i.
3 -
Maybe we could even do without kerning tables
I am quite sure that the fancy stuff required for Arabic that OpenType doesn't do will find a lot of use in other scripts including Latin0 -
I recall John Hudson writing about it and one of the ideas I'm thinking is very much along the same lines.
It's an old idea, though. I don't claim to have originated it. Back in the early eighties there was a Compugraphic typesetter that had a system like this. Each glyph had more than one set of sidebearings, arranged vertically into zones. There were at least three: one above the x-height, one at the x-height, and one below the x-height. Or something like that. Glyphs were spaced by, in effect, sliding the glyphs together until one of the zones touched. It's not unlike the old technique used with wood or metal type where two pieces of type, say an L and a T, are notched and fit together to allow closer spacing.
I've played around with the idea and the math is quite simple.3 -
Let's fix scaling, sizing, rendering, positioning and substitution, Unicode, and the web.0
-
OpenType MATH has spacing cut-ins already. This is core to high-quality rendering of mathematics.2
-
All that is supported by the adobe/Firefox proposel but I don't know if SVG is the right way to go.
Why wouldn't it be? SVG is very versatile and prominent on the web, and seems like it could do all those animations [1], gradients, transparency, bitmaps.
As a front-end developer, I wish multiple weights and styles could be served up in one font file. Maybe that should become a feature of WOFF3, though, as it's probably only interesting for web use. (And there'd be arguments against it: maybe four separate requests for small files is better than one for a big file.) Edit: TrueType Collections can do this, but have no web support, that's why I fish for a naive work-around. Interesting responses and better ideas:
Live font interpolation [2] could be useful to address this issue. Something similar was proposed to W3C recently [3].
[1] Since JavaScript is disabled in OpenType SVG fonts, and SMIL seems to be dying a slow death, the only thing left is CSS animations which are relatively simple in what the can accomplish.
[2] http://alistapart.com/article/live-font-interpolation-on-the-web
[3] https://www.w3.org/community/stroke-fonts/0 -
Frode, Adobe had a proposal to do something of that in the early days of OT. Of course, the font can't actually see the text block, but the line layout services can, so the idea was that the app would insert specific invisible, non-spacing glyphs at key locations — beginnings and ends of lines, beginnings of paragraphs, etc. — and these could be addressed in OTL contextual lookups. So you could, for example, have swash features that would use different swash glyphs in different locations automatically.
Elsewhere in OTL we already have the layout engine identifying aspects of text and discretely applying individual features on character glyphs. That's how Arabic joining behaviour is implemented, for example, so that would be another mechanism by which text block topography could be addressed. It wouldn't be as flexible as the Adobe idea, but it wouldn't require glyph insertion, just keeping track of what characters are where and a set of new features to describe the topography.1 -
Polygonal spacing remains a tantalising idea. The difficulty is coming up with the right polygons to achieve correct spacing between different glyphs: it's not really solving the problem if one uses polygons instead of rectangles but still needs kerning pair exceptions for some combinations. I've tried defining an ideal shape around an uppercase T that would result in correct spacing relative to both other caps and lowercase, and it's harder than one would think.
Yes, the MATH table uses 'cut-in' kerning, but that's because we need to be able to space scaled elements in superscript and subscript positions where we can't always be sure exactly how large or how high/low they will be (because of the number of factors affecting equation layout). Actually defining the cut-ins is far from easy, and considerably more difficult than traditional dx kerning. This is, in part, a tool issue, though, and any serious attempt at polygonal spacing would need to involve a new spacing editing paradigm.
[On the latter, I've thought for a long time that an iterative auto-spacer would be a great tool to have. The trouble with most auto-spacing/kerning, is that it doesn't accept the right kind of instructions from the designer. What I want is an heuristic spacer, that I can provide with some key spacing that will then determine the outcomes for other glyphs, and which I can run iteratively, each time adding more key data to modify outcomes from previous iterations until I am satisfied with the result. So, for example, one might begin by saying 'This is the spacing of HH, OO, HO and OH. Don't change any of these values, and calculate other spacing relative to these.' Then on the next pass you might say 'You spaced AV and VA too tightly, I want them like this...'. Such a system could even remember things about the way you like to space, and apply them to future projects.]
Top of my list on the spacing front is being able to space/kern tyepform objects, rather than just individual glyphs. Consider: when a combining mark glyph is positioned on a base glyph using an anchor attachment, it forms a unit that should be spaced relative to other units (individual glyphs, or other combinations) as such. At present, the only way to do this is to contextually adjust the spacing of the bases taking into account the presence of the mark. Being able to define combinations of bases and marks as typeform objects, then preview and space them in a glyph-like way would be great. [This could either be a format extension, i.e. the typeforms could be defined within the font data, or a tool expression, i.e. the typeform spacing would be translated into contextual kerning during font generation.]
4 -
The ATypI programme has just been announced, with the last 2 sessions of the 1st day on "OpenType 2.0":
http://www.atypi.org/conferences/sao-paulo-2015/programme-1
"OpenType Open Mike: What do you want to see in OpenType 2.0? Lucky Tech Day participants will get up to five minutes to pitch their ideas around their OpenType 2.0 wish list. Pitches will be need to be pre-registered to avoid repetition and supporting material and slides will need to be provided ahead of time for collation into a single slide deck."
- http://www.atypi.org/conferences/sao-paulo-2015/programme-1/programme/activity?a=511"OpenType 2.0 Panel: Nadine Chahine Moderated by Nadine Chahine with industry panelists who will be responsible for drafting and implementing the OpenType 2.0 standard across apps, operating systems, tools as well as the fonts themselves."
- http://www.atypi.org/conferences/sao-paulo-2015/programme-1/programme/activity?a=513
1 -
I'm staring to see 3 main groups:
1) Corporate concerns:
- Better Compression for faster load times
- Better World Scripts support for easier internationalization
2) Typography concerns:
- Optical and multi-axis support
- Better Rendering
- Better Spacing/Kerning methods
3) Creativity concerns:
- Transparency
- Randomization
- Colors, FX, Layers, etc...
But of course, all the 3 groups are interrelated.
3 -
I'll say what I've said before: let's forget about the distinction between a “font” as a set of complex data tables and a “layout engine” as a software program that takes a text, a font and a few formatting attributes and returns a “line of type”.
Instead, define an API (programming interface) that allows a standardized way of inputting:
1. A piece of text
2. A 2D area to fill
3. A minimal set of mandatory formatting attributes
4. An optional set of arbitrary attributes
and allows outputting:
1. An arrangement of positioned visual shapes drawn in a specific technique
2. A linearized “map” of text pieces that correspond to the visual shapes and allows searching, text selection and editing.
Then, allow arbitrary software programs (real “font software”) to work behind that API.
Some of these fonts can make use of shared libraries that do simple-script single-line layout and just provide a static set of images and metrics. Other fonts can fill the requested space with dynamically drawn handwriting simulation, yet others with a sheet of musical notation or a chemical formula or a math equation, or a chessboard.
In essence: allow to bundle the layout engine with the font, or the font with the layout engine.
Something like HTML Canvas but with a “text layer”. So the font can return an area filled with things that you see and information what it is that you see (in detail).
OpenType, AAT, ACE, MATH, Multiple Master etc. can all be such shared libraries behind the API, and as a designer, you can just draw 700 static glyphs that use one of these libs, or you can draw 675 static glyphs but program 25 special dynamic glyphs that “draw themselves” using your custom program.
We have recorded music that we can play and we have a way to have a software program generate music on the fly. We have moving pictures that come from a camera recording and those that are generated by computer code on the fly (like in computer games). We can draw diagrams or write software that draws them dynamically.
We should finally also have a way to compose a “paragraph of text” by both methods.
And then, we’ll be able to write your own “kinetic kerning engine” along with your “responsive glyphs” ourselves. We won't *have to* “export our font as a GIF” (pardon me, OTF) before it can be “used”. We'll still be able to, because LegacyOpenTypeLineSetter will be one of those shared libs that our software font will be able to call. Like an MPEG-1 decoder that's needed to play some video.5 -
Building the layout engine into the font would be nice. Because then I wouldn’t have spent my morning getting four different Devanagari layout results in different applications.0
-
More engine programming into the font is essentially what SIL Graphite is about, afaik.0
-
Is ACE a layout engine or a font format?I agree; someone I spoke to privately said that one can't talk about a new format separate from a new line - paragraph! - layout engine, and talking about a new layout engine and consequent text handling pipeline is a large proposition. They recommended first stepping back and discussing what the problems we setting out to solve really are.
Thus I began drafting that wiki page, starting each section with "Users suffer ..." and then enumerating "prior art"1 -
Adam, your idea seems to have some prior art
"Computer Typography Without Fonts"0 -
Going back to Mark's spacing paradigm and what John said about the difficulty of coming up with the right shapes. I think what's required for this real-time, non-optical kerning to work are three collision shape types.
A collision shape is layer that defines what the optical kerning program sees. The actual glyph shape will be ignored by the real-time kerning program.
Think about when you're kerning and how you deal with the following situations: T/A vs. T/period
A T/A kern should be easy to calculate using a basic collision shape. The T/period kern is trickier because you don't want the period to tuck all the way to the T stem. To be able to control this, you might need three layers of collision shapes.
Shape 1: the regular collision shape
For the T and A, this would be the shape which defines the tightest kern allowed. For the T, you'd set it at the minimum distance you'd want something to tuck into it. For a T, this might look like a fat T. For the A, it might look like a triangle.
Shape 2: the soft collision shape
How close to you want a period, hyphen or other "untuckables" to get? In the case of a T, where do you want the period kerning limit to be? Where do you want the hyphen to stop? For the A, where do you want the quotation marks to stop? For the T it might look like a T with a very fat stem. For the A, it might look like a trapezoid, the top of the trapezoid would represent the place where you'd want a quotation mark to stop.
Shape 3: the hard collision shape
Not all glyphs require these. This defines what will conform to the soft receiving shape. A period, quotation mark or hyphen would include a hard collision shape. That way, next to a U, the period will kern normally. Next to a T, the period will stop at the T's soft collision shape. If you want you J to tuck all the way into a T, then don't include a hard collision shape. If you want the J to stop where the period would stop, add a hard collision shape. If you want the J to tuck into the T a bit further than a period, but not all the way, adjust the J's hard collision shape accordingly to allow some overlap when it encounters a soft collision shape.
I think these collision shapes should be actual shapes, not just fancy sidebearings. They could also be useful for dealing with vertical collisions such a g colliding with an accent on the line below. They should be made of straight lines and not curves to help with the speed of calculations. There should be No limits on the complexity, but more complex shapes will increase kerning calculation time.
1
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 803 Font Technology
- 1K Technique and Theory
- 622 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 485 Typography
- 303 History of Typography
- 114 Education
- 68 Resources
- 499 Announcements
- 80 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 270 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports