Catalina นำแบบอักษรระบบที่ใช้ตัวแปรใหม่มาใช้กับ macOS
ส่วน "system-ui" ของข้อกำหนดโมดูล CSS Fonts Module ระดับ 4 กำหนดคีย์เวิร์ด system-ui
ตัวอักษรที่ช่วยให้นักพัฒนาซอฟต์แวร์สามารถใช้แบบอักษรเริ่มต้นในตัว ที่ได้รับการเพิ่มประสิทธิภาพติดเทอร์โบ มีการแปล คุณภาพสูงมาก ไม่จำเป็นต้องดาวน์โหลดในเว็บไซต์และแอปของตนโดยตรง
body {
font-family: system-ui;
}
ตัวเลือกแบบอักษรนี้จะคล้ายกับการพูดว่า "ใช้แบบอักษรระบบเริ่มต้นสำหรับภาษาปัจจุบันของผู้ใช้รายนี้"
ใน macOS แบบอักษร system-ui
คือ San Francisco ซึ่งเป็นแบบอักษรที่ทีมออกแบบได้คัดกรอง ทดสอบ และเพิ่งอัปเกรด ก่อนอื่นเราจะพูดถึงฟีเจอร์แบบอักษรใหม่ๆ ที่น่าสนใจสำหรับ Catalina จากนั้นเราจะพูดถึงข้อบกพร่อง 2-3 รายการและวิธีที่วิศวกร Chromium แก้ปัญหา
โพสต์นี้จะถือว่าคุณคุ้นเคยกับแบบอักษรตัวแปรอยู่แล้ว หากไม่มี โปรดดูข้อมูลเบื้องต้นเกี่ยวกับแบบอักษรตัวแปรบนเว็บ และวิดีโอด้านล่าง
ความเข้ากันได้กับเบราว์เซอร์
ในขณะที่เขียน system-ui
ได้รับการสนับสนุนจาก Chromium (ตั้งแต่ 56), Edge (ตั้งแต่ 79), Safari (ตั้งแต่ 11 เป็นต้นไป) และจาก Firefox (ตั้งแต่ 43) แต่ใช้คีย์เวิร์ด -apple-system
ดูข้อมูลอัปเดตได้ที่ฉันจะใช้แบบอักษรตัวแปรได้ไหม
พลังใหม่
ความสามารถใหม่ที่ Catalina นำมาใช้กับแบบอักษรของระบบจะเปิดให้บริการแก่นักพัฒนาเว็บตั้งแต่ Chromium 83 เป็นต้นไป แบบอักษร system-ui
มีการตั้งค่าตัวแปรเพิ่มขึ้น ได้แก่ การปรับขนาดออปติคัลและการปรับน้ำหนักแบบไม่ซ้ำกัน 2 แบบ ดังนี้
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 ; }
ใน Mojave ระบบจะใช้ system-ui
เป็นแบบอักษรตัวแปรที่มีการตั้งค่า wght
เท่านั้น ส่วน system-ui
ใน Catalina เป็นแบบอักษรตัวแปรที่มีการตั้งค่า wght
, opsz
, GRAD
และ YAXS
ดูเหมือนเราจะมีโอกาสได้ออกแบบการปรับปรุงที่ก้าวหน้าไปเรื่อยๆ นะ คุณสามารถเจาะลึกรายละเอียดปลีกย่อยของแบบอักษรของระบบได้ตามต้องการ
wght
ยอมรับน้ำหนักแบบอักษรระหว่าง 0
ถึง 900
และใช้กับอักขระทั้งหมดเท่าๆ กัน
/* 0-900 */
font-variation-settings: 'wght' 750;
opsz
การปรับขนาดออปติคัลคล้ายกับการเว้นช่องไฟหรือระยะห่างตัวอักษร แต่ระยะห่างนั้นดำเนินการโดยสายตามนุษย์แทนที่จะเป็นทางคณิตศาสตร์ ค่า 19
หรือต่ำกว่าเป็นค่าสำหรับการเว้นระยะห่างระหว่างข้อความและเนื้อหา ส่วน 20
หรือมากกว่าเป็นค่าสำหรับการเว้นวรรคส่วนหัวและชื่อเรื่องที่แสดงเว้นวรรค
/* 19 or 20 */
font-variation-settings: 'opsz' 20;
GRAD
คล้ายกับน้ำหนัก แต่ไม่มีการสัมผัสกับระยะห่างในแนวนอน ยอมรับค่าระหว่าง 400
ถึง 1000
/* 400-1000 */
font-variation-settings: 'GRAD' 500;
YAXS
ขยายรูปอักขระในแนวตั้ง ยอมรับค่าระหว่าง 400
ถึง 1000
/* 400-1000 */
font-variation-settings: 'YAXS' 500;
การรวมตัวเลือก
เราสามารถปรับแต่งการตั้งค่าแบบอักษรให้เป็นตัวหนาตามตัวเลือกของเรา หรือลองใช้ชุดค่าผสมอื่นๆ ที่น่าสนใจได้โดยใช้ CSS เพียงไม่กี่บรรทัด ดังนี้
font-weight: 700;
font-weight: bold;
font-variation-settings: 'wght' 750, 'YAXS' 600, 'GRAD' 500, 'opsz' 20;
และเช่นเดียวกัน ผู้ใช้ Chromium ใน macOS จะเห็นน้ำหนัก 750 ที่กำหนดเองและการปรับแต่งอื่นๆ สนุกๆ ของคุณ 👍
สนามเด็กเล่น
คลิกรีมิกซ์เพื่อแก้ไขในภาพแตกด้านล่างเพื่อรับสำเนาของ Glitch ที่แก้ไขได้ จากนั้นแก้ไขตัวเลือก font-variation-settings
ใหม่เพื่อดูผลกระทบต่อแบบอักษร โปรดทราบว่ากลิทช์นี้จะทำงานเฉพาะในกรณีที่คุณใช้อุปกรณ์ macOS Catalina
macOS 10.15 เพิ่มฟีเจอร์ใหม่ในแบบอักษรของระบบและใน macOS 10.15 ระบบได้บันทึกข้อบกพร่องที่ยุ่งยากของ system-ui
ไว้ในเครื่องมือติดตามข้อบกพร่องของ Chromium สงสัยว่าเกี่ยวข้องกันหรือเปล่า
ภาคผนวก: การถดถอยของ system-ui
เรื่องราวนี้เริ่มต้นด้วยข้อบกพร่องอื่น ซึ่งก็คือ #1005969 กรณีนี้เกิดขึ้นกับ macOS 10.15 เนื่องจากระยะห่างของแบบอักษร system-ui
ดูแคบและอัดแน่น
ที่มา
ใน macOS 10.14 คุณสังเกตเห็นหรือไม่ว่าย่อหน้าหรือส่วนหัว "สแนป" เป็นแบบอักษรที่มีรูปลักษณ์ต่างกันอย่างไรเมื่อปรับขนาดขึ้นหรือลง
ใน Mojave (macOS 10.14) แบบอักษร system-ui
จะสลับระหว่างแบบอักษร 2 แบบตามขนาดแบบอักษรเป้าหมาย macOS ใช้ "San Francisco Text" เมื่อข้อความอยู่ภายใต้ 20px
เมื่อข้อความมีขนาด 20px
ขึ้นไป macOS จะใช้ "San Francisco Display" การปรับขนาดออปติคัลสร้างขึ้นจากแบบคงที่โดยแบ่งเป็นแบบอักษร 2 แบบ
Catalina (macOS 10.15) ได้จัดส่งแบบอักษรร่วมแบบใหม่สำหรับซานฟรานซิสโก ไม่ต้องจัดการ "ข้อความ" และ "ดิสเพลย์" อีกต่อไป และยังได้รับการตั้งค่ารูปแบบใหม่ opsz
ตามที่อธิบายไว้ก่อนหน้านี้ด้วย
h1 {
font-variation-settings: 'opsz' 20;
}
ขออภัย ค่าเริ่มต้น opsz
ในแบบอักษร Catalina ใหม่คือ 20
และวิศวกรของ Chromium ไม่ได้เตรียมพร้อมที่จะใช้ opsz
กับแบบอักษรของระบบ ซึ่งส่งผลให้ขนาดเล็กแสดงผลที่แคบเกินไป
ในการแก้ไขปัญหานี้ Chromium ต้องใช้ opsz
กับแบบอักษรของระบบอย่างถูกต้อง ซึ่งส่งผลให้ปัญหา #1005969 ได้รับการแก้ไข ชนะเลิศ! หรือว่าคือ...
ยังไม่เสร็จ
ปัญหาอาจเกิดขึ้นเมื่อ Chromium ใช้ opsz
แต่มีบางอย่างทำงานผิดปกติ แบบอักษรของระบบใน Mac มีตารางแบบอักษรเพิ่มเติมชื่อว่า trak
ซึ่งจะปรับแต่งระยะห่างในแนวนอน ระหว่างการแก้ไข วิศวกร Chromium พบว่าใน macOS เมื่อดึงข้อมูลเมตริกแนวนอนจากออบเจ็กต์ CTFontRef
เมตริก trak
ได้นําไปพิจารณาในผลลัพธ์ของเมตริกแล้ว ไลบรารีการกำหนดรูปแบบ HarfBuzz
ของ Chromium ต้องการเมตริกที่ค่า trak
ยังไม่ได้เป็นปัจจัยพิจารณา
สำหรับภายใน Skia (ไลบรารีกราฟิก ไม่ใช่แบบอักษรที่มีชื่อเดียวกัน) จะใช้ทั้งคลาส CGFontRef
จาก CoreGraphics
และคลาส CTFontRef
จาก CoreText
เนื่องจากออบเจ็กต์เหล่านั้นต้องมี Conversion ภายใน (ใช้เพื่อการรักษาความเข้ากันได้แบบย้อนหลังและเข้าถึง API ที่จำเป็นของทั้ง 2 คลาส) Skia จะลดข้อมูลน้ำหนักในบางสถานการณ์ และแบบอักษรตัวหนาจะหยุดทำงาน ซึ่งติดตามได้ในปัญหา #1057654
Skia ยังต้องรองรับ macOS 10.11 อยู่เนื่องจาก Chromium ยังคงรองรับอยู่ ในวันที่ 10.11 แบบอักษร "San Francisco Text" และ "San Francisco Display" ไม่มีแม้แต่แบบอักษรที่เปลี่ยนแปลงได้ แต่แต่ละแบบจะมีแบบอักษรแยกกันสำหรับทุกๆ น้ำหนักที่มี ก่อนหน้านี้รหัสรูปอักขระทั้ง 2 รหัสไม่ตรงกัน ดังนั้น ถ้า Skia จัดรูปแบบข้อความ (แปลงข้อความเป็นรูปอักขระที่สามารถวาดได้) ด้วย "San Francisco Text" ข้อความนี้จะเป็นคำที่ไม่มีความหมายหากวาดด้วย "San Francisco Display" และในทางกลับกัน และแม้ว่า Skia เพิ่งจะขอขนาด macOS อื่นก็อาจเปลี่ยนไปใช้เครื่องอื่นด้วย เป็นไปได้ที่จะใช้แบบอักษรอันใดอันหนึ่งและเพียงแค่ปรับขนาด (ใช้เมทริกซ์เพื่อปรับขนาดแทนการขอขนาดใหญ่) แต่ CoreText
มีปัญหาเรื่องที่ไม่ปรับขนาดรูปอักขระ sbix (อีโมจิสี) ขึ้น (ลดลงเท่านั้น) มันซับซ้อนมากกว่านั้น ดูเหมือนว่า CoreText
จะจำกัดขอบเขตในแนวตั้งหลังจากแอปพลิเคชันเมทริกซ์ ซึ่งดูเหมือนว่าจะเกี่ยวข้องกับการวาดอีโมจิในมุม 45 องศาไม่ได้ ไม่ว่าในกรณีใดก็ตาม หากต้องการให้อีโมจิแสดงขนาดใหญ่ คุณต้องทำสำเนาแบบอักษรเพื่อรับเวอร์ชันขนาดใหญ่
ดังนั้น เพื่อสร้างสำเนาของออบเจ็กต์ CTFont
ขนาดต่างๆ ภายในขณะที่มีการใช้ข้อมูลแบบอักษรพื้นฐานเดียวกัน Chromium จะดึง CGFont
ออกจาก CTFont
และสร้าง CTFont
ใหม่จาก CGFont
(ออบเจ็กต์ CGFont
มีขนาดไม่ขึ้นอยู่กับขนาด การสลับแบบวิเศษจะเกิดขึ้นที่ระดับ CoreText
) ทั้งหมดนี้ใช้งานได้ดีจนถึงวันที่ 10.154 ในเวลา 10:15 น. - การเดินทางไป-กลับนี้สูญเสียข้อมูลมากเกินไป ซึ่งส่งผลให้เกิดปัญหาเรื่องน้ำหนัก Flutter พบปัญหาเรื่องน้ำหนักและมีการแก้ไขทางเลือกสำหรับการปรับขนาดเพื่อสร้าง CTFont
ใหม่จาก CTFont
เดิมโดยตรง ในขณะที่ควบคุมขนาดออปติคัลโดยตรงโดยใช้แอตทริบิวต์เก่าแต่ไม่มีข้อมูลใน CoreText
การทำงานนี้ทำให้ทุกอย่างทำงานได้ในเวอร์ชัน 10.11 และแก้ไขปัญหาอื่นๆ (เช่น การตั้งค่าขนาดออปติคัลเป็นค่าเริ่มต้นอย่างชัดเจน)
แต่วิธีนี้จะรักษา "เวทมนตร์" ของ CoreText
ไว้ในแบบอักษรได้มากกว่า ดูเหมือนว่าหนึ่งในนั้นยังคงปรับเปลี่ยนความก้าวหน้าของรูปอักขระด้วยวิธีอื่นที่ไม่ใช่เพียงตาราง trak
(แอปพลิเคชันที่ Chromium ได้พยายามระงับแอตทริบิวต์อีกรายการที่ไม่ได้ระบุไว้อยู่แล้ว)
CGFont
ไม่ได้ทำอะไรกับ "เวทมนตร์" นี้เลย บางที Chromium อาจได้ CGFont
สำหรับCTFont
แล้วใช้เพื่อรับความก้าวหน้าไหม ต้องขออภัยด้วยที่จะไม่สามารถใช้งานได้ เพราะ CoreText
มีการล้อเลียนกับแบบอักษรในลักษณะอื่นเช่นกัน เช่น ทำให้อีโมจิขนาดเล็กใหญ่กว่าที่คุณขอไว้จริงเล็กน้อย (ระบบจะเพิ่มขนาดอีกเล็กน้อย) CGFont
ไม่ทราบเรื่องนี้ คุณจึงลงเอยด้วยอีโมจิที่ใช้รูปแบบ sbix ของคุณอยู่ใกล้กันเกินไปเนื่องจากคุณต้องวัดที่ขนาดเดียว แต่ CoreText
จะวาดให้ใหญ่ขึ้นในระดับหนึ่ง Chromium ต้องการความก้าวหน้าของ CTFont
แต่ก็ต้องการสิ่งที่ไม่ต้องติดตาม และไม่ควรติดตามอื่นใด
เนื่องจากการแก้ไขปัญหาเรื่องระยะห่างจำเป็นต้องใช้ชุดการแก้ไข Blink และ Skia ที่เชื่อมต่อถึงกัน วิศวกร Chromium จึง "แค่เปลี่ยนกลับ" เพื่อแก้ปัญหานี้ไม่ได้ วิศวกร Chromium ยังได้ลองใช้แฟล็กเวอร์ชันอื่นสำหรับการเปลี่ยน Codepath ที่เกี่ยวข้องกับแบบอักษรใน Skia ซึ่งแก้ปัญหาแบบอักษรตัวหนา แต่ปัญหาเรื่องระยะห่างกลับลดลง
การแก้ไข
สุดท้ายแล้ว Chromium ต้องการแก้ไขทั้ง 2 อย่าง ขณะนี้ Chromium หันไปใช้ฟังก์ชันเมตริกแบบอักษร OpenType แบบอักษรในตัวของ HarfBuzz เพื่อดึงเมตริกแนวนอนจากข้อมูลไบนารีในตารางแบบอักษรของระบบโดยตรง เมื่อใช้ตัวเลือกนี้ Chromium จะเลี่ยง CoreText
และ Skia เมื่อแบบอักษรมีตาราง trak
(ยกเว้นเมื่อเป็นแบบอักษรอีโมจิ)
ในระหว่างนี้ คุณยังคงมีปัญหาสกี #10123 เพื่อติดตามการแก้ปัญหานี้อย่างเต็มรูปแบบใน Skia และกลับไปใช้ Skia เพื่อเรียกข้อมูลเมตริกแบบอักษรระบบจากที่นั่น แทนการแก้ไขปัจจุบันที่ดำเนินการผ่าน HarfBuzz