The Next Font Format?

Dave Crossland
Dave Crossland Posts: 1,429
in Type Design Software
Does anyone here have ideas for what they wish was in OpenType that isn't?

I started a wiki page collecting ideas:

https://meta.wikimedia.org/wiki/Future_Global_Font_Format_Requirements
«13

Comments

  • Chris Lozos
    Chris Lozos Posts: 1,458
    You have made a good start!
  • Ray Larabie
    Ray Larabie Posts: 1,431
    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.
  • Dave Crossland
    Dave Crossland Posts: 1,429
    Great idea! However, isn't this possible with the MS and Adobe-Mozilla color font formats?
  • Ray Larabie
    Ray Larabie Posts: 1,431
    Thanks. I don't think those formats can do transparent gradients.
  • Thomas Phinney
    Thomas Phinney Posts: 2,883
    edited June 2015
    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.
  • Dave Crossland
    Dave Crossland Posts: 1,429
    edited June 2015
    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.
  • Georg Seifert
    Georg Seifert Posts: 674
    The ms Color Tablets are RGBA. I made some tests and transparency is actually supported only the fonts from MS don't use it.
  • Dave Crossland
    Dave Crossland Posts: 1,429
    Thanks for checking! That's what I assumed :)
  • Georg Seifert
    Georg Seifert Posts: 674
    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.
  • Nick Shinn
    Nick Shinn Posts: 2,207
    I would just like <calt> effects to not fail when tracking is applied.

    Better yet, CS should support <rand>.
  • Nick Shinn
    Nick Shinn Posts: 2,207
    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.

  • James Puckett
    James Puckett Posts: 1,992
    edited June 2015
    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.
  • Ray Larabie
    Ray Larabie Posts: 1,431
    edited June 2015
    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.
  • Dave Crossland
    Dave Crossland Posts: 1,429
    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 Latin :)
  • Mark Simonson
    Mark Simonson Posts: 1,734
    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.
  • Deleted Account
    Deleted Account Posts: 739
    Let's fix scaling, sizing, rendering, positioning and substitution, Unicode, and the web.
  • attar
    attar Posts: 209
    OpenType MATH has spacing cut-ins already. This is core to high-quality rendering of mathematics.
  • Roel Nieskens
    Roel Nieskens Posts: 188
    edited June 2015
    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/

  • John Hudson
    John Hudson Posts: 3,186
    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.
  • John Hudson
    John Hudson Posts: 3,186
    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.]
  • Dave Crossland
    Dave Crossland Posts: 1,429
    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
  • PabloImpallari
    PabloImpallari Posts: 806
    edited July 2015
    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.

  • James Puckett
    James Puckett Posts: 1,992
    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.
  • attar
    attar Posts: 209
    More engine programming into the font is essentially what SIL Graphite is about, afaik.
  • Dave Crossland
    Dave Crossland Posts: 1,429
    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" :)
  • Dave Crossland
    Dave Crossland Posts: 1,429
    Adam, your idea seems to have some prior art ;)

    "Computer Typography Without Fonts"
  • Ray Larabie
    Ray Larabie Posts: 1,431
    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.


Categories