The Next Font Format?

2

Comments

  • Could the T-period problem be more simply solved by a clever shaping of the regular collision shape? Seems to me if the period's collision shape, rather than being an equidistant halo around the period, was more like a bottle extending up above the dot, it would tuck properly because the "neck of the bottle" would hit the T's collision shape and stop it from moving too close at the bottom. 

    But I do think a workable system would have to be more complex than moving enveloped glyphs together until they hit. The envelopes that would work with WE would probably be less satisfactory for WY. For WY, you'd probably want to be forgiving of the collision at the top given the gap below. In other words, overlapping collision shapes in one area should be permissible given greater distances-to-collision elsewhere. Perhaps one could invent a formula to optimize the ratio of area of overlap of collision shapes to area of space between collision shapes. 

    Maybe this should be its own thread. I'd be very interested in hearing more from those of you who have already been thinking this through for years.
  • While not as sexy or purposeful as slick design features, why not a meaningful DRM built into the font for both mobile and desktop use?

    I'd love to see fonts assigned to organizations or single human users just like iTunes MP3s are locked to accounts, no reason fonts can't be locked to user accounts assuming the new spec provides for some OS level kernel/check than enforces this.
  • Maybe relevant: recently the W3C started a community group in ‘an attempt to find ways of using stroke fonts in design workflows’: https://www.w3.org/community/stroke-fonts/
  • "While not as sexy or purposeful as slick design features, why not a meaningful DRM built into the font for both mobile and desktop use?"

    OT's owners can do that, build in DRM for their platforms, and they have. For the public, font meta data containing that kind of information was a once in a lifetime possibility that is now gone by.

    "They recommended first stepping back and discussing what the problems we setting out to solve really are."

    The world is understaffed when it comes to composing good typography, much less functional, platform-independent typography, from the piles of glyphs in piles of styles from the many 10's of thousands of families of fonts.

  • Dave CrosslandDave Crossland Posts: 1,042
    why not a meaningful DRM

    Because its technically impossible unless libre software is banned, and most web browsers are libre. 

    The music industry has moved on from DRM to streaming; web font services are font streaming services. TypeKit et al require users to keep their accounts paid up.  

    You don't want meaningful DRM, you want equitable distribution agreements with streaming distributors. FontStand and WebType seem to be leading the way there.
  • Thomas PhinneyThomas Phinney Posts: 1,510
    Or AAT for that matter.
  • James PuckettJames Puckett Posts: 1,627
    edited July 2015
    While not as sexy or purposeful as slick design features, why not a meaningful DRM built into the font for both mobile and desktop use?

    Doing that at this point seems likely to be a business disaster IMHO. Digital design culture is very open-source centric, and those people don’t like having to pay for anything. Adding DRM to fonts would lead to thousands of designers swearing off commercial fonts entirely.
  • "The music industry has moved on from DRM to streaming;"

    True, but when Donald Trump wants to use Neil's song for his personnel own profit, his people have to call Neil's. Not all music rights are the same.

    "Adding DRM to fonts would lead to thousands of designers swearing off commercial fonts entirely."

    Thousands would be an improvement. You are perhaps unaware that DR restriction, aka lack of DRM, is causing Hundreds of Thousands of Google and Adobe advertisers and publishers to lose their type identities. Both Google and Adobe have said as much publicly. 

    I am not talking about DRM that effects a user at a browser.  I am talking about at web authoring, and so are many others.
  • Richard FinkRichard Fink Posts: 165
    The guy on the right - me - will most likely be dead before any of these ideas get implemented. The guy on the left - Crossland - and some others here might live to see them.

    However, with advances in medical science happening all the time, what the heck, maybe I'll make it! So here's my take. Excuse the drama.

    +1 to Roel Neiskins desire for any new format to be capable of being saved as a multifont file like ttc.  (Frankly, it seems like this could be worked out, like Roel suggests, as a WOFF3 feature. But whenever and wherever it gets done, there is no denying the benefits.)  Making a single http call is almost always faster and less costly than multiple calls of even very small files. There's a clear benefit, now, today.

    -1 To Stu and David - discussing DRM for fonts at this stage of the game is a complete waste of time IMHO. (Don't shoot I'm just the messenger!) The ship has sailed and it's sailing towards "open" seas.
    For example, I noticed that the new Microsoft Edge browser has dropped checking for a CORS header and/or an "installable" flag in the font file, as Internet Explorer now does, when the font is a raw, unwrapped, TTF or OTF file.
    Building a more interoperable Web with Microsoft Edge

  • Yes Rich, sfnt is open. But the only ships sailing in Google seas are free, and the only ships sailing in Adobe seas are bundled, and the only ships sailing in Apple seas are Apple's. That ain't open, for business. 
  • Dave CrosslandDave Crossland Posts: 1,042
  • Dave CrosslandDave Crossland Posts: 1,042
    edited July 2015
    David,
    You are perhaps unaware that DR restriction, aka lack of DRM, is causing Hundreds of Thousands of Google and Adobe advertisers and publishers to lose their type identities. Both Google and Adobe have said as much publicly. 

    You're not talking about a lack of DRM though, are you: You're talking about Adobe having their own font streaming infrastructure, and the lack of a business relationship between you and them, because you don't want to submit your type library to TypeKit.

    That is the problem with per-font distributors like FontStand and Cloud.Typography and WebType: They go after a small, exclusive, discerning market (editorial) while the library distributors go after the mass market (advertising.)
     That ain't open, for business. 

    I think the TypeKit Library Manager's office has been open for business since web fonts started?

    If you want to take on paid contracts for making libre fonts, email me. 

    Craig & Ray: I think DecoType's ACE does a lot of what you are describing. The manual is online, https://www.google.com/search?q=tasmeem+manual

  • Yes, I am talking about a lack of DRM. So the rest of your speculative is moot. This is not to say that DRM would be mandatory. But the fact that so many people are so against, even optional standardization of DRM for fonts, is absolutely positive. ;)

    So, E.G. If a table contained assurance to poor vulnerable Google that the font being used in an ad on their service, was absolutely licensed, what would happen!?;)

  • Dave CrosslandDave Crossland Posts: 1,042
    edited July 2015
    (Before posting this, I did stop to think, is this on topic? And indeed I think it is: The Next Format could indeed offer an opportunity to include an EPAR, and its the same R that is in DRM, so, off to the races we go :)

    I'll leave Google out of this because they, as you say, seems to be open for business with libre fonts.
    If a table contained assurance to poor vulnerable [Adobe] that the font being used in an ad on their service, was absolutely licensed, what would happen!?;)
    Why on earth would that information be in a table inside the font?

    Maybe you are implicitly proposing that ad customers would upload fonts to Adobe?

    I can't imagine that Adobe would allow that, with all the complications that could follow. Adobe seems pretty clear; if type designers want to make their fonts available to Adobe's customers, they should submit them for inclusion in TypeKit's library.

    It seems highly unlikely to me that Adobe wants to be bothering its customers with the decision costs of managing their own type libraries. 

    It was recognized by Adobe and Monotype's sales teams that today's customers want single-ticket big-buffet libraries so they can stop thinking about font licensing minutia, and get on with their real jobs: composing good typography from the piles of glyphs in piles of styles from the many 10's of thousands of families of fonts. 

    All the micro-transactions in FontStand and WebType's "subscribe to each family" model have a cost, and those costs adds up to the point that most customers don't want to carry them, which is why those services remain niche products for the small market of discriminating high end editorial typographers. 

    And you and Stuart's plan for mass market adoption is to add more transaction costs to using fonts? :) 

    In the past you and I have discussed your epar proposal. I continue to think that a solution like musicbrainz.org makes more sense, and typedia.com seems like a good place to add such machine readable metadata too; but if Font Bureau's sponsorship of fontsinuse.com included the pro bono detailing of some of xierpa sherpa special forces, that could be the home for it; and with Stephen Coles now blogging at identifont.com perhaps that might turn out to be it. All 3 have the same aim in mind, I think, but so far (afaik) have limited themselves to human readable information. 

    The problem with font tables containing licensing information is that the answer to who has a paid up license today will have a different answer tomorrow.

    I hope someone can remind me, why did Microsoft reject EEULAA?
  • Ray LarabieRay Larabie Posts: 882
    Just to tie a knot in my collision shape thing: now that I've thought about it some more, it would probably be better to simply do this sort of thing in font software and have it spit out some concise, super efficient kerning and class tables. Never mind. (in Roseanne Roseannadanna voice)

    But I'm still serious about the transparent gradients: we absolutely need that in the next format.
  • Mark SimonsonMark Simonson Posts: 1,121
    edited July 2015
    I've thought about it as a dev tool, too, and did some preliminary Python code to test the concept (e.g., generating AFM data), but never got any further with it (yet). (I would show it here, but it might be too off-topic.) Having it part of a font format would be better and allow things that would be impossible otherwise (e.g., automatic kerning between different fonts, styles, or sizes.). Having it as a development tool might well make kerning easier.

  • John HudsonJohn Hudson Posts: 1,627
    edited July 2015
    Just to tie a knot in my collision shape thing: now that I've thought about it some more, it would probably be better to simply do this sort of thing in font software and have it spit out some concise, super efficient kerning and class tables.

    That presumes that the spacing in question is something that can be expressed in kerning and class tables. Microsoft's MATH table uses cut-in shape kerning precisely because the spacing involved between dynamically scaled and vertically offset glyphs cannot be expressed in regular pair/class kerning data formats. Likewise, cascading Arabic involves relationships of rise and run that cannot be easily predicted and are too complex even for OpenType's contextual kerning lookup data formats.

  • Richard FinkRichard Fink Posts: 165
    I thought of one other wish-list item.
    I'd like to see, rather than a point centric measuring system, a pixel centric measuring system. (Or a toggle between the two.)
    Something that ties the CSS properties that can be applied to fonts - like letter-space and word-space.
    ( For example, word space seems to currently be adjusted by a re-calculation of the advance width of the last letter of each word, or at least that's the way it seemed in my tests a few years ago.)
    There should be a way to predict (at least within a range) what will happen visually when the default "neutral" setting is changed to some other value. (In other words, what mathematical formulas are at play and how uniform are they from platform to platform, user agent to user agent.)
    I'm going to be adding some adjustment features to my test suite - a la Typetester - in the coming months, and I'm interested in seeing how fonts with different metrics behave as adjustments are applied in different user agents.

    BTW - @ David Berlow - you seem to be bitching that a few companies have positioned themselves more competitively than an independent foundry like FB can.  I'm a little uncertain exactly what your complaint is. Is it that a company like Adobe can piggy-back fonts along with their other graphic design products? Or what? 

    Lastly, I seem to remember being called a crank some years ago on another forum when, on the basis of a lot of research and a lot of evidence, I pointed out that, contrary to common belief, fonts are NOT protected by copyright as computer software even though the belief that they are is buttressed by the fact that the copyright office will (in error) issue a certificate upon submission of a TTX representation of the "code" of the font.
    At this juncture, I think it's fair to say that anyone who continues to call for a font format with DRM deserves to also be deemed a crank. Crossland obligingly debated the thing once again. But I'm a crank - so, fellow cranks, stop wasting my time with talk of fonts with DRM. 
  • Dave CrosslandDave Crossland Posts: 1,042
    a pixel centric measuring system

    You mean, "reference pixel centric", right?
  • Dave: "I'll leave Google out of this because they, as you say, seems to be open for business with libre fonts."

    ...but then, you become infinitely less important. You will change back into your Google clothes soon, I'm guessing. Open for business is not open to business. 

    Rick: "I'm a little uncertain exactly what your complaint is."

    ... It is certainly not my complaint little one. And we are definitely not trying to bother anyone. Why... we wouldn't hurt a fly. This  licensing issue cluster fuck was brought up to us by Google and then by Adobe. My response is as you see. We are In The business of fonts, not helping developers spread use of their authoring tools via free use of our fonts.;) 

    Someone else btw, is likely to suggest fixing this "licensing non-issue" outside of the format, and we are not going along, but you'll figure dat out later. :)


  • Dave CrosslandDave Crossland Posts: 1,042
    Dave: "I'll leave Google out of this because they, as you say, seems to be open for business with libre fonts." ...but then, you become infinitely less important. You will change back into your Google clothes soon, I'm guessing. Open for business is not open to business.

    I don't have Google clothes, and I have studious tried to avoid appearing to have any.

    Libre fonts is not as tied to Google as you make out; Adobe also host them, as does Font Squirrel.
    This  licensing issue cluster fuck was brought up to us by Google and then by Adobe
    I don't understand how you could attribute the lack of EPAR to Google or Adobe. 
  • Thomas PhinneyThomas Phinney Posts: 1,510
    Well, Adobe certainly had no interest in EPAR in its early versions, back in the day, because their lawyers advised that they couldn't use electronic bits to summarize license terms in that way. With Adobe as one of the two partners in OpenType, that certainly didn't help.

    These days, Open Font Format / OpenType is genuinely open. If folks are still interested in EPAR they should push it again. Who knows, maybe enough time has passed that Adobe legal would take a different view as well?

  • "I don't understand how you could attribute the lack of EPAR to Google or Adobe."

    Getting better understanding Is Hard, and reading is libre, but why write about clothes or fashion, to naked people.

    "These days, Open Font Format / OpenType is genuinely open."

    Genuinely Open Type is good! Got GOT? it is then. GOT interpreters!? must be next.



  • After 11 years as "typography consultant" at a newspaper (Santa Barbara Independent), I developed quite a wish list … here's one of the simpler items, for a start: One of our local communities was Isla Vista (where UCSB is), frequently abbreviated to "I.V." We would inevitably get into kerning trouble when that was used as a possessive, e.g. "I.V.'s parking deficit." The kerning table would tuck the second period back under the V, as you would normally expect; but the second autokern would be between the period and the apostrophe, and that would make the apostrophe crash into the V! So what I'm proposing is the facility for a kerning table to accommodate character triples—because just doing pairs oversimplifies the real-world need.
         You may think our problem was just "local." My response would be another wish-list item: Bring to InDesign, and its ilk, what I remember from early Quark Xpress: The user's ability to customize/modify/extend a font's kerning table, in-house. (We would have made frequent use of that, with place names like Santa Ynez, San Ysidro, and San Ygnacio.) 
  • The kerning exceptions can be handled through an OpenType Feature and hopefully the app one is using will support it. There is also at least one plugin for InDesign that will do exactly what you wish for in changing kerning.
  • James PuckettJames Puckett Posts: 1,627
    Opentype allows for triple kerns, but they're much more work to implement than kerning pairs. There's also a great deal of language research required, and most type designs don't have the budget to implement triple kerns for the 120+ languages commonly supported in typefaces today.
  • While it's currently not hard to check the version number of a font in Windows. There are other operating systems where the installed font version number is hard to track down. I guess. I mean, I managed to do it in Android but it was a hassle.

    I don't think there's anything you can change with the format itself to fix this since those fields are already included. Maybe it's a matter of, adding to the spec, a requirement/recommendation that font properties be made visible inside apps.

    Currently, when a customer has a problem, I can ask them to check the properties in Windows to verify the version number. But who knows what fonts will be installed on in the future? Nail clippers? How will my customers check the version number of a font that they've installed on their nail clippers?

    In Windows 10, the font viewer shows the version number but doesn't show copyright or trademark messages. If you check properties/details, it only shows the first ~32 characters of each field. I think an in-app, bare minimum properties display should be required or at least recommended. If the customer could get some in-app information about language support as well, that would be helpful.

    What about a "check for update" option? We could add an URL that points to a plain text file with a version number. If the version number doesn't match the one in the font, display a message to "contact your vendor for the latest version" and include an URL for that as well.


  • How about security issues, encryption & co? In light of the new Fontstand model, for example, where you can rent a font by temporarily having it activated on your computer. But the font format itself does not support actual self-destruction. So it is easy to extract the font files, while they are activated on your computer, and have them forever. This seems like an obvious format-related issue, that could be solved by inventing a different format.
  • What about a "check for update" option? We could add an URL that points to a plain text file with a version number. If the version number doesn't match the one in the font, display a message to "contact your vendor for the latest version" and include an URL for that as well.
    Like https://musicbrainz.org for fonts?
Sign In or Register to comment.