Catalina introduce un nuovo carattere di sistema variabile unificato in macOS.
La sezione "system-ui" della specifica CSS Fonts Module Level 4 definisce una parola chiave per i caratteri system-ui che consente agli sviluppatori di utilizzare il carattere predefinito del sistema operativo integrato, ottimizzato per la velocità, localizzato, di altissima qualità e senza necessità di download direttamente nei loro siti e nelle loro app.
body {
font-family: system-ui;
}
Questa scelta tipografica equivale a dire "utilizza il carattere di sistema predefinito per le impostazioni internazionali correnti di questo utente".
Su macOS, il carattere system-ui è San Francisco, un carattere che un team di progettazione ha esaminato, testato e… recentemente aggiornato. Per prima cosa, esamineremo le nuove ed entusiasmanti funzionalità dei caratteri variabili in Catalina, poi vedremo un paio di bug e come sono stati risolti dagli ingegneri di Chromium.
Questo post presuppone che tu abbia già familiarità con i caratteri variabili. In caso contrario, consulta l'articolo Introduzione ai caratteri variabili sul web e il video di seguito.
Compatibilità del browser
Al momento della stesura, system-ui è supportato da Chromium (dalla versione 56), Edge (dalla versione 79), Safari (dalla versione 11) e Firefox (dalla versione 43), ma con la parola chiave -apple-system. Consulta Posso utilizzare i caratteri variabili? per gli aggiornamenti.
Nuovi poteri
Le nuove funzionalità che Catalina ha introdotto nel carattere di sistema sono ora disponibili per gli sviluppatori web a partire da Chromium 83. Il carattere system-ui ora dispone di più impostazioni variabili: dimensionamento ottico e due regolazioni uniche del peso:
h1 { font-family: system-ui; font-weight: 700; font-variation-settings: 'wght' 750 ; }
h1 { font-family: system-ui; font-weight: 700; font-variation-settings: 'wght' 750, 'opsz' 20, 'GRAD' 400, 'YAXS' 400 ; }
Su Mojave, system-ui è un carattere variabile con solo wght impostazioni. system-ui su Catalina è un carattere variabile con impostazioni wght, opsz, GRAD e YAXS.
Mi sembra che ci siano delle belle opportunità di progettazione di miglioramenti progressivi. Se vuoi, puoi approfondire le sfumature del carattere di sistema.
wght
Accetta uno spessore del carattere compreso tra 0 e 900 e viene applicato in modo uniforme a tutti i caratteri.
/* 0-900 */
font-variation-settings: 'wght' 750;
opsz
Il dimensionamento ottico è simile alla crenatura o alla spaziatura tra le lettere, ma la spaziatura viene eseguita a occhio anziché tramite calcoli matematici. Un valore pari o inferiore a 19 è destinato alla spaziatura del testo e del corpo, mentre un valore pari o superiore a 20 è destinato alla spaziatura delle intestazioni e dei titoli visualizzati.
/* 19 or 20 */
font-variation-settings: 'opsz' 20;
GRAD
Simile al peso, ma senza toccare la spaziatura orizzontale. Accetta valori compresi tra 400 e 1000.
/* 400-1000 */
font-variation-settings: 'GRAD' 500;
YAXS
Allunga il glifo verticalmente. Accetta valori compresi tra 400 e 1000.
/* 400-1000 */
font-variation-settings: 'YAXS' 500;
Combinare le opzioni
Con poche righe di CSS, possiamo modificare le impostazioni del carattere in grassetto a nostra scelta o provare altre combinazioni interessanti:
font-weight: 700;
font-weight: bold;
font-variation-settings: 'wght' 750, 'YAXS' 600, 'GRAD' 500, 'opsz' 20;
E così, gli utenti di Chromium su macOS vedono il tuo peso personalizzato aggiornato a 750 con altre divertenti modifiche 👍
macOS 10.15 ha aggiunto nuove funzionalità al suo carattere di sistema e in macOS 10.15 è stato registrato un bug system-ui nel bug tracker di Chromium. Chissà se sono imparentati.
Appendice: la regressione system-ui
Questa storia inizia con un bug diverso: #1005969. Questo problema è stato segnalato per macOS 10.15 perché la spaziatura dei caratteri system-ui sembrava stretta e compressa.
Sfondo
Hai mai notato su macOS 10.14 come i paragrafi o le intestazioni "scattano" su un carattere diverso quando la dimensione aumenta o diminuisce?
Su Mojave (macOS 10.14), il carattere system-ui cambiava tra due caratteri a seconda delle dimensioni del carattere di destinazione. Quando il testo era inferiore a 20px, macOS utilizzava "San Francisco Text". Quando il testo era 20px o superiore, macOS utilizzava "San Francisco Display". Il dimensionamento ottico è stato integrato staticamente in due caratteri separati.
Catalina (macOS 10.15) ha introdotto un nuovo carattere variabile unificato per San Francisco. Non dovrai più gestire "Testo" e "Display". Inoltre, è stata aggiunta la nuova impostazione di variazione opsz descritta in precedenza.
h1 {
font-variation-settings: 'opsz' 20;
}
Purtroppo, il valore predefinito di opsz nel nuovo carattere Catalina è 20 e gli ingegneri di Chromium non erano pronti ad applicare opsz al carattere di sistema. Di conseguenza, le dimensioni più piccole vengono visualizzate troppo strette.
Per risolvere il problema, Chromium doveva applicare correttamente opsz al carattere di sistema. Ciò ha portato alla correzione del problema n. 1005969. Vittoria! O forse no?
Non ancora completato
È qui che è diventato difficile: Chromium ha applicato opsz, ma qualcosa non sembrava ancora giusto. I caratteri di sistema su Mac hanno una tabella di caratteri aggiuntiva chiamata trak, che modifica la spaziatura orizzontale. Mentre lavoravano alla correzione, gli ingegneri di Chromium hanno notato che su macOS, quando recuperavano le metriche orizzontali da un oggetto CTFontRef, le metriche trak venivano già prese in considerazione nei risultati delle metriche. La libreria di modellazione di Chromium HarfBuzz ha bisogno di metriche in cui i valori trak non sono ancora presi in considerazione.
Internamente, Skia (la libreria grafica, non il carattere tipografico con lo stesso nome) utilizza sia la classe CGFontRef di CoreGraphics sia la classe CTFontRef di CoreText. A causa delle conversioni interne richieste tra questi oggetti (utilizzati per mantenere la compatibilità con le versioni precedenti e accedere alle API necessarie in entrambe le classi), Skia perderebbe le informazioni sul peso in determinate circostanze e i caratteri in grassetto smetterebbero di funzionare. Questo problema è stato monitorato nel problema n. 1057654.
Skia deve ancora supportare macOS 10.11 perché Chromium lo supporta ancora. Su 10.11 i caratteri "San Francisco Text" e "San Francisco Display" non erano nemmeno caratteri variabili. Ognuno era invece una famiglia di caratteri separati per ogni peso disponibile. A un certo punto, i loro ID glifo sono diventati non sincronizzati tra loro. Pertanto, se Skia eseguisse la modellazione del testo (conversione del testo in glifi che possono essere disegnati) con "San Francisco Text", il risultato sarebbe incomprensibile se disegnato con "San Francisco Display" e viceversa. Anche se Skia ha richiesto una dimensione diversa, macOS potrebbe passare all'altra. Dovrebbe essere sempre possibile utilizzare uno dei caratteri e ridimensionarlo (utilizzando una matrice per aumentarlo di dimensioni anziché richiedere una dimensione maggiore), ma CoreText ha un problema per cui non ridimensiona i glifi sbix (emoji a colori) (solo verso il basso). È un po' più complesso di così. CoreText sembra limitare l'estensione verticale dopo l'applicazione della matrice, il che sembra essere correlato al fatto che non è in grado di disegnare emoji con angoli di 45 gradi. In ogni caso, se vuoi che le emoji vengano visualizzate in grande, devi creare una copia del carattere per ottenere una versione grande.
Per creare internamente copie degli oggetti CTFont di dimensioni diverse, assicurandosi che vengano utilizzati gli stessi dati dei caratteri sottostanti, Chromium ha estratto CGFont da CTFont, quindi ha creato un nuovo CTFont da CGFont (gli oggetti CGFont sono indipendenti dalle dimensioni, il cambio magico avviene a livello di CoreText). Ha funzionato bene fino alla versione 10.154. Nella versione 10.15 questo viaggio di andata e ritorno ha comportato una perdita eccessiva di informazioni, causando il problema del peso. Flutter ha notato il problema di peso ed è stata apportata una correzione alternativa per il ridimensionamento per creare il nuovo CTFont direttamente dall'CTFont originale, controllando le dimensioni ottiche direttamente utilizzando un attributo vecchio ma non documentato in CoreText. In questo modo, tutto funziona su 10.11 e vengono risolti altri problemi (ad esempio, l'impostazione esplicita della dimensione ottica sul valore predefinito).
Tuttavia, in questo modo si preserva maggiormente la "magia" del carattere CoreText. Uno di questi sembra essere che modifichi ancora gli avanzamenti dei glifi in qualche modo diverso dalla tabella trak (la cui applicazione Chromium stava già cercando di sopprimere tramite un altro attributo non documentato).
CGFont non fa nulla di tutto questo, quindi forse Chromium potrebbe togliere CGFont da CTFont e usarlo solo per ottenere anticipi? Purtroppo, questa soluzione non funzionerebbe perché CoreText è noto per modificare i caratteri anche in altri modi. Ad esempio, rende le emoji piccole leggermente più grandi di quanto richiesto (aumentandone un po' le dimensioni). CGFont non lo sa, quindi le emoji basate su sbix finirebbero troppo vicine tra loro, perché le misureresti a una dimensione, ma CoreText le disegnerebbe più grandi di un certo importo. Chromium vuole i progressi di CTFont, ma senza tracciamento e preferibilmente senza altre modifiche.
Poiché la correzione del problema di spaziatura richiedeva una serie di correzioni interconnesse di Blink e Skia, gli ingegneri di Chromium non potevano "semplicemente ripristinare" per risolvere il problema. Gli ingegneri di Chromium hanno anche provato a utilizzare un flag di compilazione diverso per modificare un percorso di codice correlato ai caratteri in Skia, il che ha risolto il problema dei caratteri in grassetto, ma ha peggiorato il problema della spaziatura.
La correzione
Alla fine, ovviamente Chromium voleva risolvere entrambi i problemi. Chromium ora ricorre all'utilizzo delle funzioni di metrica dei caratteri OpenType integrate di HarfBuzz per recuperare le metriche orizzontali direttamente dai dati binari nelle tabelle dei caratteri del carattere di sistema. In questo modo, Chromium aggira CoreText e Skia quando il carattere ha una tabella trak (tranne quando si tratta del carattere emoji).
Nel frattempo, è ancora disponibile il problema di Skia n. 10123 per monitorare la correzione completa in Skia e tornare a utilizzare Skia per recuperare le metriche dei caratteri di sistema, anziché la correzione attuale che passa per HarfBuzz.