Adobe announces end of support for “PostScript” Type 1 fonts
Comments
-
Why acquiesce? Seems like it is a point of differentiation that one could be happy about. Is it part of using some standard/default EULA on MyFonts?0
-
Nick Curtis said:I acquiesced, which is quite different from eagerly adopting. A veritable monopoly in the marketplace is not something easily bucked.I am puzzled by this statement, just as Thomas Phinney is, but I don't know if it is for the same reason.Obviously, if you are acting as a reseller of Monotype-owned fonts, you would need to do so under the license terms they specify.But if you are selling fonts of your own typeface designs, I would have thought that offering more generous license terms is just as feasible and natural as a competitive act as offering your fonts at a lower price.Of course, there is a valid point that can be made about confusion in the marketplace if every foundry has different license terms, but the ability to modify a font for one's own use would seem to be something likely to be specifically desired.1
-
FontLab just published a 10-minute video that explains how you can use TransType 4 to convert PostScript Type 1 fonts into modern OpenType fonts.
The video is also helpful in that it explains the Typographic Family vs. Styling Group issue which puzzles many users.
5 -
I don't actually think it ever had to happen. OpenType is still today basically a superset of PostScript, it's just weird to drop T1 fonts from my perspective as a software developer.Mark Simonson said:Oh, well. I guess it had to happen eventually.1 -
By “PostScript” I am assuming you mean Type 1 fonts.
I have known a LOT of software developers who have been looking forward to dropping Type 1 support for a decade or more now. I am sure that fewer than 10% of the folks who have written a font processing engine would agree with you.
Some of that extra data in OpenType, which is missing in Type 1, is incredibly important. My personal favorite would be the 'cmap' table. Just not having to worry about supporting fonts without a 'cmap' table means a ton of legacy infrastructure that can finally be abandoned.
There is a lot of redundancy and cruft in the original CFF-OpenType format, which is why Adobe has pushed the CFF2-OpenType as a replacement. CFF2-OpenType fonts are only a superset of PostScript Type 1 at a vague conceptual level, rather than having an entire Type 1 font in compressed form in a single table. All the redundancies are omitted, the data retained only in one place.
3 -
Yeah, I can imagine there is some ongoing burden re: checking for pfm files etc; but the software is already written, and every table in T1 has a direct equivalence to a present table in a current supported format. Furthermore, if they just don't like their own code for loading Type 1 fonts, they have lots of options nowadays.
It's not that it's zero work accounting for a Type 1 font loader, but as far as I can tell there's nothing in Type 1 that you don't still have to account for in other formats when you drop it.0 -
OpenType is still today basically a superset of PostScript
Although not actually containing a single line of PostScript language?
2 -
How about multiple files per font? The fact that those multiple files are platform-specific and recombine in weird ways? And that some of them can’t survive travel across certain kinds of file systems?Aaron Muir Hamilton said:
It's not that it's zero work accounting for a Type 1 font loader, but as far as I can tell there's nothing in Type 1 that you don't still have to account for in other formats when you drop it.
This all gets handled by the loader? That is an engineering mind-set. “Support” is not just an engineering concept. It is QA (testing) and tech support—as in the long-suffering and underpaid people who take calls from customers and staff company support forums.
Technically it is the end user’s responsibility to have the multiple pieces of a single Type 1 font to make it work—but your tech support needs to know about that. If you support Type 1 fonts, it is good if your tech support knows enough to be able to tell that the reason Font X does not show up in your app is because the user does not have the right platform-specific bits (“no, your AFM file won’t help on Windows. Well, actually, Windows can generate the PFM it needs if it has an AFM plus an INF, and of course the PFB is always required…”). Also, how old Mac Type 1 fonts can be corrupted if they get transferred in a way that hoses the data fork, and... I could literally write about all this for half an hour, at least.
Yeah, you could punt on that and just say “does the font work in (name of basic system app)? If not, it is not our problem.” But if you are Adobe, you are the company invented Type 1, so your staff are kind of expected to know how it works, you know?
Plus, as I already said, the biggest problem with Type 1 is what it is missing, more than what it has. That missing data has to be synthesized. Yes, the “loader” can do that. In the case of Adobe, that is their code and another thing to maintain.
Testing is also a huge deal. Anything like this needs to be tested quite regularly, or it might get broken by accident. It wasn’t so long ago that Apple had a dot release which completely broke OS level support for Type 1. So one thing you “no longer have to account for” is that you no longer need to test everything with Type 1 fonts.
Not to mention training new QA and new support staff on this increasingly obscure tech that takes a disproportionate amount of time relative to its actual importance.
As Type 1 had become more obscure and less relevant, it becomes likely that in a small company, it does not make sense for the one or two tech support people to even know all that. In a big company, there will be *some* people who know all that, but not all—so users who do have trouble need to get the right support person.
Type 1 “support” is… not trivial.
3 -
Even less trivial: the money from ending support of Type1...Thomas Phinney said:Type 1 “support” is… not trivial.1 -
Even less trivial: the money from ending support of Type1...You keep flogging this dead horse. I would be surprised if Adobe's income from selling its fonts is more than a rounding error compared to its other income.4
-
@Mark Simonson Yeah I'm sure a publicly-owned megacorporation ending support for something is mainly for the wellbeing of end-users.0
-
I didn't say that. Maybe I misunderstood you, but you seemed to be saying that Adobe is doing this to force people to repurchase their fonts in OT format (and thereby make a ton of money).
FWIW, the reasons @Thomas Phinney laid out make sense to me.
0 -
Thomas Phinney said:There is a lot of redundancy and cruft in the original CFF-OpenType format, which is why Adobe has pushed the CFF2-OpenType as a replacement. CFF2-OpenType fonts are only a superset of PostScript Type 1 at a vague conceptual level, rather than having an entire Type 1 font in compressed form in a single table. All the redundancies are omitted, the data retained only in one place.Perhaps somehow I am misunderstanding you, but this appears to mean that any benefits to software developers from an end to support for Adobe Type Manager fonts will not, in fact, be realized unless support for the original CFF-OpenType format is also dropped.As long as your support for OpenType includes full support for all OpenType fonts, including all those in the CFF-OpenType format, which means you have to support those CFF-OpenType fonts which are Adobe Type1 fonts with a little wrapper around them, you still need the code to manage without a 'cmap'.0
-
Yes, you misunderstand me. I am contradicting both your statements above. I am saying there are additional technical benefits to dropping CFF(1) OpenType support... some day, when compared to alternative formats that already exist.John Savard said:Thomas Phinney said:There is a lot of redundancy and cruft in the original CFF-OpenType format, which is why Adobe has pushed the CFF2-OpenType as a replacement. CFF2-OpenType fonts are only a superset of PostScript Type 1 at a vague conceptual level, rather than having an entire Type 1 font in compressed form in a single table. All the redundancies are omitted, the data retained only in one place.Perhaps somehow I am misunderstanding you, but this appears to mean that any benefits to software developers from an end to support for Adobe Type Manager fonts will not, in fact, be realized unless support for the original CFF-OpenType format is also dropped.As long as your support for OpenType includes full support for all OpenType fonts, including all those in the CFF-OpenType format, which means you have to support those CFF-OpenType fonts which are Adobe Type1 fonts with a little wrapper around them, you still need the code to manage without a 'cmap'.
Don’t get me wrong, if/when that happens it will be some day in the misty future, perhaps 15–30 years from now. It is just that we have at least two clear candidates already for replacement formats: either TT-OpenType or CFF2-OpenType. Those are just two possible paths for the future, though. It might be that CFF(1) does not go away at all, or something else entirely comes along to change the picture.
I will say that the end of the line for Type 1 was highly predictable, and it was just a question of when. OpenType-CFF(1) has problems and is a kluge of a format in some ways, but those problems are not nearly as compelling a story to drop support for it, compared to the problems Type 1 has/had.
Then again, cloud-based approaches to fonts, in which they are being managed remotely, may mean that for a large percentage of users of the future, this particular swap could be handled transparently and they wouldn’t even need to be aware of it.John Savard said:As long as your support for OpenType includes full support for all OpenType fonts, including all those in the CFF-OpenType format, which means you have to support those CFF-OpenType fonts which are Adobe Type1 fonts with a little wrapper around them, you still need the code to manage without a 'cmap'.
Only if “you” are dealing with reading/importing PDFs, or maybe consuming a print stream. (But print streams never really cared about cmaps one way or another, anyway—no extra work in managing without unless you mean to repurpose that print stream for some other purpose, like creating a PDF without access to the original font.)
That is not just a “little” wrapper—it contains a 'cmap' and a host of other important tables: GSUB, GPOS, os/2, etc. Notably, the kerning is not contained in the CFF table.
1 -
@Mark Simonson The only logic behind doing this is to make more money (the only reason a public-owned company exists). Which includes: saving money by no longer supporting something; not suffering a big loss in reputation because "it's very old". Adding a product/service can benefit users; removing it generally harms them.0
-
Adobe's big dilemma with Type 1 fonts is that they are not interoperable enough to work with the overall direction of Adobe's software, which is moving as quickly as possible towards a point where users can create and share documents seamlessly, regardless of device or operating system. That requires Unicode-aware fonts that can work on the web, on mobile devices, and in any operating system that runs Adobe programs. Type 1 fonts can't really function in a system like that, and it would require too vast and expensive an engineering effort to get them to work in a system like that.5
-
Yup. It's not cost-effective. Shareholders would bail. End of story.DanRhatigan said:it would require too vast and expensive an engineering effort to get them to work in a system like that.
Don't get me wrong, corporations are staffed mostly by good people. And I personally don't know any bad people working at Adobe. But in a publicly-held company the product/service is secondary to the money it can bring, and the most good people in the company can do is work under that radar until the wrong people notice. Public ownership of companies is arguably the single worst thing about Capitalism (which is saying a lot). All it does is make the very rich richer, to the detriment of Culture.0 -
Customers that need interoperability would bail. It was a long debate, but really it was just getting harder and harder to guarantee perpetual support for Type 1 when support for them was disappearing *around* the spaces Adobe could control. So the thinking was to nudge the switch before Adobe couldn't do anything about it any more. To some extent, Type 1 data needs some support for archival purposes: Acrobat will continue handle Type 1, because that's written into the ISO PDF standard, and Type 1 data inside of things like EPS files can be displayed and printed until those files are cracked open for editing.
3 -
BTW one thing that exacerbates the situation is that virtually all font EULAs now contain a no-mod clause, making things like the below largely illegal in practice.
But since I believe that Ethical > Legal, and that the no-mod clause is unethical, I strongly encourage people to convert away!1 -
Although it is true that most companies’ EULAs don’t permit modifications, Adobe’s fairly specifically permits conversion for compatibility reasons.
(This is only relevant for fonts licensed for permanent desktop use, of course. But if you are renting fonts then you can get the fonts in formats you need, anyway.)2 -
@Thomas Phinney Yes, kudos to Adobe for that!0
-
Hrant, promoting license violations is not allowed here.0
-
@James Hultquist-Todd Promoting the violation of Culture is fundamentally worse than that of Law. But I still tolerate it.
To be clear: nobody should buy a font that they know prohibits modification with the intent of modifying it; the right thing to do is boycott the font, and –publicly– encourage others to do the same. But the truth is most people don't know the clause is there (and the foundry knows well that they don't know...) and modifying something in one's possession comes naturally. This is how Culture progresses, and impeding that for personal gain is unethical... especially when one rode on the shoulders of giants to get there. BTW this is in contrast to [re]distributing the result, which to me is a clear no-no.
The right to modify a font is somewhat parallel to the "right to repair" movement:
https://en.wikipedia.org/wiki/Electronics_right_to_repair
BTW Monotype was the one who standardized the no-mod clause, but all those indie foundries that claim Monotype is unethical seem to have no qualms at all about adopting that hidden-clause tactic...3 -
For example, there is is FreeType2, a piece of software that Adobe actually pays people to help maintain (which renders text on Android/Chromebooks/other Linux and IIRC even parts of iOS), which still casually supports Type 1 fonts.
Here's the currently maintained FreeType2 API for accessing Type 1 specific tables:
https://freetype.org/freetype2/docs/reference/ft2-type1_tables.html
And here's some dood's completely free code, that anyone is entitled to use (including in commercial products), that reliably loads and transforms mac font suitcases (the way many Type 1 fonts are wrapped up still): http://fondu.sourceforge.net/#Fondu
If people who barely have any use for Type 1 fonts can manage to continue to support them, Adobe dropping it just seems kinda lazy. How much work is it really for them to support Type 1? Barely anyone uses bmp for images anymore, but PhotoShop still supports them just fine (yes I know the difference in complexity between bmp and Type 1 fonts is vast).
I'm not mad, I wouldn't pay Adobe for software unless it was built into, and paid for by, a specific contract; and I don't have a license to any rare Type 1 fonts that I actually use... but altogether it seems really unnecessary to drop the Type 1 loader in a suite of desktop software that already has a working one.
I could totally see the argument for not writing another Type 1 loader in the year 2021; but not for deleting a functioning one.1 -
Calling it a “loader” dramatically understates what is involved in supporting the Type 1 font format.
I have spent literally decades working with the people who were actually doing the programming of these pieces of software, and training the people who have to support the font formats. For quite some years, one of my main duties was acting as a liaison between a bunch of the different parts of Adobe that dealt with fonts. In that process, I got a pretty strong sense of how much work was involved.
5 -
Not to get caught in a loop on this, but it is a loader because it loads the data from the format into the datastructures of the typesetting system, those final datastructures are what actually do the layout, rasterization, etc. You can go read an implementation of this exact procedure, it is a decent chunk of code, but not that much in the grand scheme of things.Thomas Phinney said:Calling it a “loader” dramatically understates what is involved in supporting the Type 1 font format.
My main point was that that work is already thoroughly done. The thing that they are phasing out here is not the typesetting system, nor any of that great work you've witnessed in the industry, but the relatively simple component that copies information into that system.
The work involved in layout, shaping, good rasterization, autohinting, etc. is significant and ongoing, but a Type 1 font loader is not interesting or ongoing work; it is a thoroughly solved problem with a solution that literally hasn't changed for thirty years.
There is nothing diminishing about an accurate description of the piece of code they are phasing out here; it's just what it's called.
Here is the main code for the FreeType Type 1 loader: https://github.com/freetype/freetype/blob/master/src/type1/t1load.c
There is nothing magical about this. Yes, lots of work was involved when these were being written, and way more work was involved in pioneering PostScript, but the task of loading Type 1 fonts into a system that also handles OpenType is a known quantity at this point; and, this bears repeating, the code is already there.0 -
Is it allowed to promote or defend "copyfraud"?James Hultquist-Todd said:Hrant, promoting license violations is not allowed here.
DISCLAIMER: I'm not a laywer.
A person or company cannot sell licenses based on rights, which she doesn't own. Nearly all fonts for reading sizes are not creative enough to qualify for copyright in the sense of visual art. Registered design protection (DE: Musterschutz), limited AFAIK to 12 years in Europe, is the same. Arial didn't get it, because it's plagiarism of Helvetica. Is a font a program? No [1]. Is it a protectable database? No.
Only the name of the font is protectable as registered trademark, or protected as name under some constellations of competition laws.
Also an EULA is only valid, if the user explicitly agrees to it. If a user gets a font without explicit consent, the EULA is invalid. It's also invalid containing unusual or unfair restrictions.
Can someone resell a font as a product without a reselling license? No. Not in most cases.
[1] In the US some decisions are pro program.1 -
Telling end users here in this forum that they can disregard parts of an agreement they don’t like but have otherwise accepted is disrespectful to a large part of the community here, in my opinion. Let’s assume (here) that an end user has agreed to their license in good faith, because any designer or foundry here should be assumed to be a good faith licensor.
If there are problems with license agreements prohibiting conversions and modifications, I think it’s far better to argue for different terms before a business transaction. Encourage foundries to support rights that you feel are fair, and pay a fair price for them when you get them. If you don’t like it, take your business elsewhere.
Thought experiment: If you purchase a license that does not allow conversions, but you later decide that a conversion is within your rights and you do so, should you go back and pay the foundry for that, since it’s likely that the foundry priced the original license according to the rights explicitly granted?5 -
The change that Adobe will enact in early 2023 (and next year, in Photoshop's case) is fairly minor, but it addresses what is an increasingly difficult workflow problem. The code libraries that read available fonts on a user's system and report them to the active program will no longer report the presence of Type 1 fonts to the program. This is the same function that now alerts an InDesign user about the retirement plans if you open a document using Type 1, or hover over a Type 1 font in the Fonts menu. Even if a user has a Type 1 font installed for use by the OS, an Adobe program will still say the font is missing, because the program won't see it.
Like I said above, the decision is more about nudging users to finally upgrade — in whichever way makes the most sense for them, and the variety of licensing terms out there is why Adobe needs to leave it up to the user — to fonts that have Unicode data for text processing, and are more universally supported in environments other than Mac or Windows desktop OSes. Dealing with text for a greater number of languages, and making it easier for users to move documents around and collaborate on them are pretty high-level product priorities for Adobe at this point, and Type 1 fonts can't be managed in scenarios like that.4 -
The key flaw there is that individualist "like"; it's not about liking; it's a matter of social principle. In fact an unhealthy liking for money is what needs to be confronted here, because it's disrespectful of Culture, thereby of humanity.Christopher Slye said:Telling end users here in this forum that they can disregard parts of an agreement they don’t like but have otherwise accepted is disrespectful to a large part of the community here, in my opinion.
And virtually nobody who uses a font has accepted the EULA, because they have not read it. Just like people don't actually read those ten-page agreements when they download an app. Unscrupulous companies rely on people not attending to the legalese, even though that's *reasonable* human behavior. And Capitalism rewards unscrupulous individuals, to the detriment of humanity.
The negotiation mechanism you describe is simply not generally reasonable (unless it's a company with lawyers on retainer). That said, I repeat: do not buy a font if you know the EULA to be unscrupulous to you, certainly not with the intent of violating it. That would be unscrupulous like them. Also, expose its unscrupulous nature to others, which is the best way to "encourage foundries to support rights that you feel are fair".
The thought experiment: If you change your mind about the fairness of a EULA (which does assume the unlikely scenario that you actually paid attention to it) that's on you, and yes you have to stick to it. But you can –and should– still apply pressure on the foundry to change their ways.
To me all this is essentially an issue of human decency. I'm sorry that reduces profit.1
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports