Adobe announces end of support for “PostScript” Type 1 fonts

13»

Comments

  • edited April 13
    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.
    Losing access to your fonts is never an upgrade, especially if you are “upgrading” to the exact same font just in an OpenType container with a cmap table instead of one of the standard encodings or CID, and the Type 1 outlines translated to Type 2 outlines (CFF); or maybe a CID-keyed OpenType font.

    Could you clarify what you mean by “have unicode data for text processing”? If the glyphs are there in the Type 1, and the loader knows how to map Unicode codepoints to them (it does), then what exactly is missing from a conventional face that already worked? Every MacRoman codepoint has an equivalent Unicode codepoint, including a registered PUA codepoint for the Apple logo; every PostScript Standard Encoding codepoint also has a Unicode equivalent; and all other known PostScript character sets have direct translations to Unicode (I'm also pretty sure CID-keyed fonts are matched up with Unicode by Type 1 loaders these days as well) that are currently supported by Type 1 loaders.

    As a software developer, and a software publisher, I get that it is not zero effort to maintain things, and that there are pressures to get people to “upgrade”, but I feel like if Adobe has a good reason for this particular move, it has not been well explained.

    Your point about “moving documents around” would seem to only apply to cases where custom fonts are embedded in the document, but if they support doing that anyway (far as I'm aware, they do) then Type 1 wasn't getting in the way of that to begin with. Furthermore, embedding Type 1 fonts in documents is a permanent part of PDF, which Adobe will continue to support.

    Adobe CS has its own font loaders and typesetting code, separate from the operating system; their Type 1 loader is part of the application already, so I don't think this affects platform support either.

    In sum, I can see that there are arguments for this, and some of them would be convincing in some context; but none of the arguments I've seen are convincing in the full context.
  • John SavardJohn Savard Posts: 803
    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.

    The point is that countries should have had consumer protection laws which would have modified this scenario.
    Once a consumer has paid good money for a font, the consumer should be able to use that font forever.
    So if Adobe wishes to end support for Adobe Type I fonts, first it must ensure that every typefounder that made and distributed Type I fonts changes its license terms, so that the owners of these fonts can legally convert them to OpenType without incurring additional charges. After these negotiations are completed, then support for Type I fonts can be dropped, and not before.
    The same thing should apply to software. 16-bit Windows programs will not run on 64-bit versions of Windows. This is due to a technical limitation of how x86 processors work in 64-bit mode; they can handle 64-bit software and 32-bit software, but not 16-bit software, while in 32-bit mode they can handle 32-bit software and 16-bit software - and switching from 64-bit mode to 32-bit mode requires rebooting.
    The government should have told AMD and Intel that repeating the mistake of the 80286 was not an option; that the CPUs would have to be designed so that Windows could be designed as it would have to be designed: 100% upwards compatibility so that every Windows program just runs perfectly on every later version of Windows.
  • Thomas PhinneyThomas Phinney Posts: 2,031
    @John Savard

    I understand the desire for backwards compatibility. And I like being able to run old software! I really do.

    But I also think that your position, as given here, is utter madness.
  • edited April 13
    John Savard said:
    ...
    The same thing should apply to software. 16-bit Windows programs will not run on 64-bit versions of Windows. This is due to a technical limitation of how x86 processors work in 64-bit mode; they can handle 64-bit software and 32-bit software, but not 16-bit software, while in 32-bit mode they can handle 32-bit software and 16-bit software - and switching from 64-bit mode to 32-bit mode requires rebooting.
    The government should have told AMD and Intel that repeating the mistake of the 80286 was not an option; that the CPUs would have to be designed so that Windows could be designed as it would have to be designed: 100% upwards compatibility so that every Windows program just runs perfectly on every later version of Windows.
    These are extreme measures, and they would have a marked negative effect on the quality of software and the performance of hardware. In the case of Type 1, Adobe may have an ethical obligation to not unduly burden their customers (especially given that their software will continue to use Type 1 internally for some things, essentially forever) without offering some clear benefit with the change; but in the long term you should just buy software (or support open source developers) from people who don't screw you over instead of trying to police Adobe.

    Attempting to control these things through regulation is a fool's errand, especially given that so few people even understand the technical details that you'd be regulating; it seems like even you, coming to this with some specialized knowledge, don't understand these things quite well enough to regulate them either.

    Even if you could write those rules, they would tend to simply shift innovation, and the use of innovative tools, out of the U.S. to a more forgiving jurisdiction.

    P.S. As dastardly as Intel, AMD, and Microsoft are with some things; they make a very genuine attempt to maintain backward compatibility, and they have mostly succeeded at this! You can continue to run 16-bit DOS and Windows programs on current CPUs through emulators, and those emulators on modern chips are still several times faster than the fastest 16-bit intel chips ever were. Microsoft also makes available free virtualization software that lets you run incompatible programs in older environments, and you can also use third party virtualization software (much of which is also free) to accomplish the same, if you ever had a license to the version of Windows that your program originated on.
  • John SavardJohn Savard Posts: 803
    But I also think that your position, as given here, is utter madness.

    In the case of fonts, there is an alternative: the government could simply invalidate the no-modification clauses in contracts insofar as they prevent people from converting fonts to a form they can continue to use.
    In the case of software, yes, over a sufficiently long span of time, a burden of legacy support can become onerous. And government intervention in the free market, because it is in principle dangerous, should be reserved for cases where it is necessary.
    In the case of Microsoft Windows, it is not terribly infeasible technically for x86-64 to have been extended so that it would have been easy to support 16-bit Windows 3.1 applications in 64-bit Windows. But if the government passed the kind of law I advocate, it would also apply to the Macintosh.
    Expecting an M1 processor to run not only programs written for the x86 architecture, but also programs written for the PowerPC - under both OS X and System 9 - and programs written for the 68000... I can see how a term like "utter madness" might be considered to be applicable.
    And Apple didn't have a choice about abandoning the 68000: Motorola abandoned it. IBM didn't offer PowerPC chips that were suitable for laptops, in Apple's estimation, which certainly seemed accurate at the time.
    Apple did choose not to offer 68000 emulation software on new purchases of PowerPC Macintosh computers, and that was something they didn't have to do; but things like "reasonably technically feasible" are hard to define in law.
  • edited April 13
    In the case of fonts, there is an alternative: the government could simply invalidate the no-modification clauses in contracts insofar as they prevent people from converting fonts to a form they can continue to use.

    By the way, there is some of this already in U.S. copyright law; for Americans with Disabilities, there is protection against license agreements, and against claims of DRM circumvention, when copying and modifying works for compatibility purposes (subject to limitations blah blah, I'm not your lawyer, and this is not legal advice).

    In general I think that converting works for compatibility/accessibility should be a protected activity for people with licenses to those works.

    Given the way that these formats actually work, it's hard to say whether loading a Type 1 font into OpenType-compatible tables at runtime (the way most Type 1 fonts are loaded these days) is meaningfully different from loading a Type 1 font into OpenType tables on disk; and harder still to argue that this is any different, on a computer that supports hibernation, which will save those converted OpenType tables to disk when you close the lid.

    Arguably every time a MacBook lid is closed for more than a few seconds, converted Type 1 fonts are saved to disk. :+ )
  • You guys know how Adobe treats users of older versions of InDesign, right?
Sign In or Register to comment.