Archive for May 13, 2021

Thursday, May 13, 2021

Adobe Discontinuing PostScript Type 1 Font Support

Glenn Fleishman:

Developed by Adobe way back in the early 1980s, PostScript Type 1 fonts—a way of encoding vector-based type designs into a particular file format—will lose full support in Adobe Photoshop this year, and gradually disappear from other Adobe products by 2023 as well as from other companies’ products. If you have a long history in design or using a Mac, you might find yourself unable to use some old type standbys you didn’t realize relied on outdated technology.

[…]

And, remarkably, existing PDF and EPS files that contain the older font format won’t curdle in storage. Adobe says embedded fonts will continue to display and print correctly in those file types. The only issue that will arise over time is if you wanted to open them to edit the contents after Adobe or other companies have removed Type 1 font interaction.

[…]

Adobe offered two methods of creating fonts in the mid-1980s, which were obscurely labeled after their internal specifications: Type 1 and Type 3. Adobe initially reserved Type 1 for itself, and published the Type 3 specification for general use. While Type 3 could do almost anything Type 1 could and a lot more it couldn’t, it lacked a feature calling “hinting” that allowed PostScript to render the vector curves and lines of a font effectively at lower resolutions.

[…]

You can find your Type 1 fonts in two ways in macOS: via the Finder and the Font Book app.

Update (2021-05-19): See also: Hacker News.

Update (2023-02-21): Christopher Slye (via Hacker News):

This month, Adobe is shipping several application updates which remove support for the original PostScript font format known as Type 1. Whether this change affects you or not depends quite a lot on how far back you and your work go. If some of your work dates back 20 years, some potential problems are lurking around the corner.

Previously:

Google Docs Switching From DOM to Canvas

Google (via Hacker News):

We’re updating the way Google Docs renders documents. Over the course of the next several months, we’ll be migrating the underlying technical implementation of Docs from the current HTML-based rendering approach to a canvas-based approach to improve performance and improve consistency in how content appears across different platforms.

Steve Newman:

Speaking as one of the original three authors of Google Docs (Writely), but zero involvement in this project (I left Google in 2010): I’m seeing a lot of comments asking how JavaScript-on-Canvas could possibly outperform the highly optimized native code built into the browser engines. It’s been a long time since I’ve really been involved in browser coding, but having written both Writely and, farther back, several native-app word processing engines, here are some thoughts.

Word processors have extremely specific requirements for layout, rendering, and incremental updates. I’ll name just two examples. First, to highlight a text selection in mixed left-to-right / right-to-left text, it’s necessary to obtain extremely specific information regarding text layout; information that the DOM may not be set up to provide. Second, to smoothly update as the user is typing text, it’s often desirable to “cheat” the reflow process and focus on updating just the line of text containing the insertion point. (Obviously browser engines support text selections, but they probably don’t expose the underlying primitives the way a word processor would need. Similarly, they support incremental layout + rendering, but probably not specifically optimized in the precise way a word processor would need.)

Modern browser engines are amazing feats of engineering, but the feature set they provide, while enormous, is unlikely to exactly match the exacting requirements of a WYSIWYG word processor. As soon as your requirements differ even slightly from the feature set provided, you start tipping over into complex workarounds which impact performance and are hell on developer productivity and application stability / compatibility.

iCloud Documents and Data Discontinued

Apple:

In May 2022, iCloud Documents and Data, our legacy document syncing service, will be discontinued and completely replaced by iCloud Drive. If you use iCloud Documents and Data, your account will be migrated to iCloud Drive after this date.

Via Sami Fathi:

iCloud Drive launched in 2014 as a unified, seamless way for Apple users to keep all their files, documents, and more synchronized across all their devices.

iCloud Drive was introduced with iOS 8 and OS X 10.10 Yosemite, which seems like a long time ago. However, if you have hardware that can’t update to those versions, this announcement means that syncing will stop working entirely. On Macs, at least, you can use iCloud Drive via the Web.

Previously:

Update (2021-05-18): Nick Heer:

Can Macs that run Mavericks or below access iCloud Drive via the web? I think there are some security standards that are no longer supported by Macs of around that vintage, which may be used by iCloud web.

I tested iCloud in the latest version of Safari for Mavericks, and the page doesn’t finish loading; it just shows a spinner. It’s possible that Chrome or Firefox would work better.

An Appreciation of Objective-C

Ken Kocienda (tweet):

Over the next fifteen years, I wrote code in ObjC just about every day. The language offered me a small collection of rules on the surface and a deep well of flexibility underneath. This combination facilitated and encouraged quick and playful experimentation. The language allowed me to wink and say, “I know what I’m doing.” ObjC winked back and became a willing participant in helping me make computers do cool stuff.

[…]

It remains one of the best languages ever for creating apps and frameworks. I’ve loved every minute I’ve spent coding in it.

I learned Objective-C around the same time and identify with what he’s saying. But I really like Swift, too, and prefer it in most cases. I think that my Swift code is more reliable and easier to read. These days it’s mostly not the Swift language that gets in my way, but the slow and unreliable tooling.

What It Was Like to Sell Apps Online in 2003

Brent Simmons (tweet):

Apple likes to claim that the App Store replaced the system of selling software in physical boxes in stores and over the mail.

But it’s not true.

My experience selling apps before the App Store was not unique or new — it’s only interesting now because people may have forgotten this history, and younger people may never have heard it.

[…]

We used a service called Kagi for the storefront and credit card processing. Kagi had been around since the ’90s, and it was well-known and trusted by the Mac community.

[…]

And it was pretty easy. Easier than dealing with the App Store!

I can’t find the link, but one of Apple’s lawyers recently argued that the reason Apple chose 30% for the App Store fee was that it wanted to do better than the prevailing alternatives at the time. And they again tried to make it sound like they invented selling software online. I’ve used at least five different e-commerce providers since 2002, and none of them charged more than 15% (most much less). All were easier to deal with than the App Store.

Peter N Lewis:

Totally the same for me - except I was Kagi’s first customer and started with them in 1995, and continue doing the same to this day (other than switching to FastSpring in 2010). It wasn’t new over a decade before the App Store was released).

Tom Harrington:

I had a very similar experience. I started selling my own apps in 2002, completely online, through a web site and in-app purchase. No boxes, no stores, no mail. Downloads, emailed serial numbers, and a third-party payment service. No Apple online store.

Marcel Weiher:

Exactly the same here, with KAGI, the license strings etc. Except that PdfCompress,BookLightning, TextLightning and PostView remained in the four figures/month. Still comfortable.

If Apple claims they somehow invented online software sales, they are lying. Egregiously.

Michael Love:

I had the same experience in the mid-90s with downloadable Mac shareware, wrote a game in middle school and sold (a dozen copies or so IIRC) via Kagi; even back then, a teenager could sell software entirely online with no retail markup or gatekeeper.

On mobile, my Palm app initially launched in 2001 through proto-app-store PalmGearHQ with a 20% commission, but in 2002 when it started to make serious money I went direct with my own merchant account + abandoned PalmGear entirely by 2005.

But neither for software in general nor for mobile specifically did Apple bring anything new to the table with the App Store; they simply imposed taxes and regulation on an existing market that was getting along perfectly fine without them.

Christopher Lloyd:

The first App Store I’m aware of appeared on NeXTStep in the early 90s

John Allsopp:

We first sold software for the Mac solely online also via Kagi in 1995

At a conference around that time an Apple exec said when I told him ‘no one will ever buy software on the internet’ :-)

Craig Hockenberry:

Kagi was responsible for the beginning of the Iconfactory’s software business. It’s been going strong for almost 25 years now.

David Sinclair:

When I started @dejal in 1991, people mailed me cash and checks — to New Zealand! — and I had to take them to the foreign exchange at my bank. Later I processed credit cards via paper forms. When I started with Kagi, it was like magic; so much easier.

Brent Simmons:

Apple itself sold software online back before the App Store — because of course they did. Everybody did.

Previously:

Update (2023-02-13): Brent Simmons:

Framed thing on the wall of my office — a thing I’m super proud of. 🐣 🐥

Copyright © 2000–2024 Michael Tsai.