As Oakley pointed out just after WWDC20, and as Ars Technica confirms in their Big Sur review, updating to Big Sur comes down to 2 Time Machine choices: 1) the legacy HFS+ hard link way and, 2) The APFS snapshot way. There is no way to migrate from HFS+ Time Machine to APFS Time Machine except by starting afresh. The default Big Sur Time Machine setting formats a new disk as APFS as shown in the video. Goodbye HFS+ Time Machine backups.
Oakley’s key advice is this:
I also strongly recommend that, whether using HFS+ or APFS to store your Time Machine backups in future, you start making a fresh backup set with Big Sur. You’ll have to do that if you switch to using APFS anyway, but following the problems which occurred with Catalina, you’ll be much better off if you archive your old backup set and start afresh.
To do that I plan to:
Backup macOS Catalina 10.15.7 to 2 different Time Machine hard disks: one for archive, one for migration
Turn off automatic Time Machine backups
Upgrade to macOS Big Sur 11.1, then if the upgrade is successful…
Wipe one of the Catalina Time Machine hard disks and let Big Sur Time Machine create a new APFS backup with auto backups.
I’ll let you know how it goes.
UPDATE I had my backups in order and decided not to wait for 11.1 and went ahead with Time Machine APFS migration with 11.0.1. It worked out pretty well, the upgrade from macOS Catalina was smooth and trouble free, unlike the upgrade from macOS Mojave.
Time Machine migration was equally smooth. I put away my archive Time Machine backup hard disk and reformatted the 2nd Time Machine HD for APFS (4 TB Western Digital ‘Green Label’). I then let Big Sur Time Machine do a default setup which reformatted the disk again. A completely new Time Machine backup of my MacBook Pro late 2016 1 TB SSD took about 3 hours. After the backup was complete the Time Machine HD was busy indexing for the next 8 hours. I checked Activity Monitor but could not find which process was doing the indexing.
After indexing was over Time Machine APFS snapshot backups do seem faster than the old HFS+ variety. I need more time with it, especially accessing Time Machine backups, but so far so good.
UPDATE 2 All is good and Oakley has a wonderful post that outlines how much better APFS Time Machine backups are over previous versions.
OpenType Variable Font support in focused on browsers and Adobe apps
CSS is the main focus of variable font support
Typo Labs 2018 had some interesting updates on OpenType Variable Fonts (OTVF), where they are now and roadmap directions to the future. The most interesting presentation by far was Jason Pamental’s Variable Fonts and the Future of Typography. One benefit of using variable fonts in our era of multiple digital devices is that maximum readability for any given content can be optimized across devices with optical sizing which doesn’t sound very sexy but pays big dividends.
Apple leverages this with the variable font capability in their San Francisco system font. It’s the thing that makes Dynamic Type dynamic and has existed on macOS since the QuickDraw GX era, Apple’s TrueType GX fonts provided the technology base for OTVF. Pamental stresses that there are many more important benefits to variable fonts than just optical sizing and the future of digital typography needs to incorporate them. I strongly agree with Pamental’s view but I also see problems.
The initial focus for OpenType variable fonts has been CSS web development and optical sizing support is in already in Safari and Chrome with Firefox and Edge joining any day. You can see and play with variable font examples on Axis-Praxis (ignore Arphic’s hideous AR UDJingXiHei font, it’s some Chinese designer’s idea of a Japanese font). So far, so good.
We Have Been Here Before The real problem is going to be the same problem we had before with OpenType: advanced typography feature fragmentation. I interviewed one of the top Japanese font engineers back in late 2003, Tomihisa Uchida of Iwata Corporation and he explained the problem. At that time Adobe was pushing the Japan market away from the expensive Japanese Postscript printer font model to the dynamic font download model of OpenType Japanese fonts with PDF and InDesign J. What Uchida san said in 2003 is still true today:
I work with newspaper fonts and layout. Newspaper font designs are different because the text is always vertical. Fonts need good layout to look their best.(Japanese) OpenType has fractions, third-width and quarter width glyphs, but most applications are not OpenType-feature aware so it’s a real waste. The result is pretty ugly.
Right now, the only OpenType (Japanese) layout engine out there is InDesign (J)…(this) means you have to use InDesign to access OpenType advanced typography…no matter what kind of fancy fonts you have, they look bad with poor typography.
Advanced Typography Feature Fragmentation in Action You can see and test this problem for yourself on macOS with the recently revived egword Universal 2 Japanese word processor app and Pages. Hiragino Japanese OpenType fonts bundled with macOS are chockfull of advanced typography features (both AAT and OpenType tables) mentioned by Uchida san and much more: glyph variations, vertical substitutions, extended character sets, etc. The full set is listed in the crusty old macOS Fonts >Typography palette.
Hiragino has many advanced typography features but they don’t work across apps or platforms. Some listed features such as glyph variants are completely broken. Pages accepts some of the Hiragino advanced features but does not offer vertical text layout, a basic Japanese typography requirement because the Pages team only implements the lowest common denominator typography features that work across WebKit, macOS and iOS.
egword Universal 2 has excellent Japanese vertical and horizontal text layout but ignores Typography palette advanced fonts options in favor of its own app palette which only offers a sub-set of Hiragino font features.
The only place to use the whole Hiragino feature shebang is a trip to InDesign Creative Suite J. What’s the matter with you, don’t you have one?
egword Universal 2 ignores the Hiragino font features in macOS Typography palette but deploys a limited subset in its own palette
Pages accepts some Hiragino options offered in macOS Typography palette but glyph variants are broken in macOS Mojave
Variable Fonts and What’s Missing Where do OpenType Variable Fonts fit in this scenario? What and how are features offered and how does an app present them to the poor user who might want to use them?
The answer is something I have been trying to write about from my very first blog post and revisited last week. 3 years in I think I finally understand it: the QuickDraw GX vision thing. Not the API or any of the GX technology that westerners got hung up on missing the big picture:
QuickDraw GX, the vision part not the API, was the only major text layout architecture in a major OS I know of that treated all typography from anywhere as one single thing available to all applications. The Steve Jobsian ‘it just works’ for the entire world’s advanced typography.
The critical difference was the GX vision of the world’s advanced typography and layout as one unified common fundamental thing that just works and is available everywhere seamlessly across the OS and all apps. All this advanced typography stuff doesn’t work unless it is one unified thing. To paraphrase Uchida san ‘fancy fonts look bad with poor typography’. Without vision and focus OpenType Variable fonts will turn out to be fancy fonts that look bad most of the time.
Apple is the only company in the world that owns both the software and hardware across personal computer and mobile platforms so it comes down to 2 points.
If Apple can’t come up with an advanced typography vision again, OpenType Variable Fonts will suffer the same advanced typography feature fragmentation fate that OpenType advanced typography has suffered from all along: it will live in the Adobe app ghetto which is fine for the designers who live and work there, but it never leaves that world. It will be ignored by most of the developer community because they can’t figure it out on their own when different advanced typography features are fragmented and scattered across OS platforms and frameworks (UIKit, AppKit, Core Text, WebKit). And when app developers ignore it font developers are much less inclined to support OTVF, especially Japanese and Chinese font developers who have exponentially larger development costs than Roman based font developers.
When that happens typography remains stuck at the lowest common denominator feature set but users will never know the difference, or have the opportunity to find out. The end result is that after all this time, 22 years later and counting, fancy fonts still look bad with the poor typography we end up getting. That’s sad.
Only Apple can give us world savvy advanced typography and layout as a one thing OS vision model for the rest of us. That might be too much to ask for in this era where open web standards dictate what kinds of, ahem, western centric advanced typography we get, but if Apple can’t do it, nobody can.
It’s going to be a long dry summer. Maybe it’s the lack of any new hardware but one week after WWDC18 wrapped up the Apple tech blogger crowd are already bored. Witness: as of June 14, 2018 it is 182 days since iMac Pro was last updated. Only 182 days since it was reported that Apple finally broke the hardware update jinx and here we are again. The rest of the Mac dog day lineup is here.
I have another measurement suggestion: 10,950 days. How many Mac hardware hand wringers are over that mark and how many under? It would be fun to know, I suspect the majority are over. My MacBook Pro 13″ 2016 model isn’t even close to feeling like a cool step up the hardware ladder that my MacBook Air 13″ 2011 was but it doesn’t matter much.
I use my iPad Pro 10.5″ more and more. A recent screen drop incident left me without it for a week and I realized it had become my go-to device. Going back to the laptop for everything was not fun. I’m glad it’s there but 3 years from now I think Mac hardware will matter less than ever for ever more people.
This may not be a popular opinion but until Apple dumps the Intel architecture I don’t see the Macintosh platform moving forward much.
One thing has remained constant in Apple’s long strange text layout architecture odyssey from QuickDraw GX to ATSUI to Core Text: with any big change advanced typography is the first casualty. Priorities change, this is natural, but what often happens is a reset back to the basics with advanced typography features restored over time according to new priorities.
This is especially true for the higher level text frameworks built on the underlying text architecture as Apple constantly rejiggles priorities of what advanced typography features belong at the high level vs. what stays in the deep dark scary Core Text. Developers stick with what they know instead of adding new text features, so the typography experience of most apps, regardless of platform, remains blah and ‘western centric’.
This is about to get worse as Apple figures out what bits of UIKit (TextKit calling) are going to join macOS and screw hold hands with AppKit.
Take vertical layout for example. Japan is the last major market that requires it as China, Korea and other Asian countries sold out their rich typography culture and history for western created digital typography technologies that always treated non-western typography as an outliner, never a true equal. Japanese developers had to fight to get basic vertical text support in EPUB v2 and it still sucks getting vertical text EPUB to display or print in WebKit or any web based thing for that matter. Yes, after all this time the World Wide Web is still the Roman Wide Web.
QuickDraw GX, the vision part not the API, was the only major text layout architecture in a major OS I know of that treated all typography from anywhere as one single thing available to all applications. The Steve Jobsian ‘it just works’ for the entire world’s advanced typography. Since then Apple has broken typography features into different bits assigning them to different frameworks: bidirectional layout goes up in the high level, real vertical layout remains down there in Core Text.
AppKit has some high level vertical layout features but nobody uses them, Apple included (ahem Pages), because UIKit and WebKit don’t offer the same. One veteran Japanese font engineer explained the challenges: “UIKit doesn’t support real vertical text layout, the Japanese punctuation and glyph spacing is all wrong. The easier thing for an app developer to do is bundle a display only Japanese vertical font just for displaying vertical text in the app. Go ask the programmers at Monokakido, I’m sure that’s what they have to do with their iOS Japanese dictionary apps.” And so it goes.
It’s not just text layout either. How do OpenType Variable Fonts fit into this picture? How will developers deploy them and users interact with them? The crusty old macOS advanced typography font feature palette model is so passé it’s painful to look at, let alone use. So nobody uses it, I doubt they ever did.
The GX advanced typography vision thing, or any vision thing for that matter, would be a welcome guide map. Apple had it once, let’s hope they find it again. Otherwise it will be a bumpy ride. Again.
The week after WWDC is like a small hangover, no agony or sharp pain, just the long dull ache of reality setting in after too much manufactured fun. Tech Media coverage of WWDC18 was flat and uninspired, maybe it was the lack of a new hardware announcement or a major new software initiative. The mood was captured by Japanese tech journalist Tsutsumu Ishikawa’s sour tweet, “Come to think of it there wasn’t any NFC announcement.” Come to think of it there actually was, Contactless Passes are a new thing and it will be interesting to see what developers will do with them.
The oddest thing was the reaction to the depreciation of OpenGL and OpenCL in macOS Mojave. It was all here and now hand wringing. No journalist or blogger seemed to be up to the job of putting together the bigger long term picture: that depreciation announcement plus Metal everywhere plus external GPUs, UIKit bits coming to AppKit was all just more writing on the wall that Intel CPU Macs are toast. Wouldn’t it be weird and wonderful if the new Mac Pro turns out to be the coming out party for the Apple A-Series Mac. Watching the media frenzy would be half the fun.