چگونه فونتها را در اسناد PDF جاسازی، زیرمجموعه و فونتهای مفقود را اصلاح کنیم
باز کردن یک PDF و دیدن اینکه متن به هیروگلیفهای درهم، نویسههای روی هم افتاده یا فونت پیشفرض عمومی courier تبدیل شده، یکی از آزاردهندهترین شکستها در نشر دیجیتال است. این مشکل مستقیماً از برنامههای فونت مفقود یا جاسازینشده در درخت اشیای PDF ناشی میشود. در این راهنمای فنی جامع، معماری داخلی فونتهای PDF را در چارچوب ISO 32000 کالبدشکافی میکنیم، توضیح میدهیم زیرمجموعهسازی فونت چگونه قلمهای چندمگابایتی را به بستههای بایتی سبک تبدیل میکند، جدولهای نگاشت خراب ToUnicode را عیبیابی میکنیم و نشان میدهیم چگونه فونتها را مستقیماً در مرورگر خود بدون هیچ مصالحهای در حریم خصوصی داده جاسازی و ترمیم کنید.
۱. معماری داخلی فونتهای PDF: Type 1، TrueType، OpenType و CIDFontها
یک سند PDF متن را صرفاً بهصورت تصاویر رستری عکاسی یا رشتههای ساده ASCII رندر نمیکند. در عوض، ISO 32000 محتوای متنی را از طریق عملگرهای موقعیتدهی انتزاعی بازنمایی میکند (مانند BT برای آغاز متن، ET برای پایان متن، Tf برای انتخاب فونت و Tj یا TJ برای نمایش رشتهها و آرایههای گلیف). وقتی موتور PDF با رشتهای متنی روبهرو میشود، کدهای نویسه را از جریان میخواند و آنها را به خطوط دور وکتوری فیزیکی به نام گلیف نگاشت میکند. برای رندر دقیق این خطوط دور روی صفحه کاربر یا صفحه چاپ فیزیکی، خواننده PDF باید دستورالعملهای ریاضی کاملی داشته باشد که هر خط دور، منحنی bezier، پارامتر hinting و معیار جهت را تعریف میکنند.
مشخصات PDF فونتها را به چند مدل ساختاری بنیادین دستهبندی میکند. فونتهای قدیمی Type 1 که در اصل توسط Adobe برای مفسرهای PostScript توسعه یافتند، بر اسپلاینهای bezier درجه سوم و charstringهای باینری فشرده تکیه دارند. فونتهای TrueType که Apple و Microsoft مهندسی کردند، از منحنیهای bezier درجه دوم و برنامههای hinting بایتکدی صریح استفاده میکنند که در یک ماشین مجازی ویژه درون رسترساز اجرا میشوند. فونتهای OpenType با بستهبندی منحنیهای گلیف TrueType یا داده Compact Font Format (CFF) در PostScript درون یک ساختار جدولی پوشش SFNT استاندارد، این دو دنیا را به هم پیوند میدهند. برای نظامهای نوشتاری پیچیده — شامل خطوط عربی، چینی، ژاپنی، کرهای و هندی — PDF از فونتهای مرکب Type 0 (CIDFontها) استفاده میکند که نمایههای گلیف را از کدهای نویسه جدا میکنند تا دهها هزار گونه گلیف را درون یک ظرف فونت یکپارچه پشتیبانی کنند.
در یک PDF ایدهآل، برنامه کامل باینری فونت مستقیماً در یک شیء جریان غیرمستقیم بستهبندی و واژهنامه فونت از طریق کلید /FontFile، /FontFile2 (برای TrueType) یا /FontFile3 (برای OpenType و CFF) به آن ارجاع میدهد. وقتی سندی بدون این جریانهای جاسازیشده تولید شود، فایل PDF فقط یک واژهنامه سبک /FontDescriptor دارد که فراداده پایهای مانند /FontName، /Flags، /FontBBox، /StemV، /Ascent و /Descent را ذخیره میکند. خواننده کاملاً به حال خود رها میشود تا فونت یکسانی را روی سیستمعامل میزبان پیدا کند یا یک جایگزین بصری مصنوعی بسازد.
۲. چرا فونتهای مفقود آشفتگی ایجاد میکنند: سازوکار جایگزینی فونت و جریان مجدد
وقتی کاربری PDF دارای فونتهای جاسازینشده را روی سیستمی باز میکند که همان فایلهای تایپوگرافی را ندارد، اپلیکیشن نمایش سازوکاری به نام جایگزینی فونت را فعال میکند. بیشتر خوانندهها، شامل Adobe Acrobat، Apple Preview و موتورهای PDF داخلی مرورگرهای مدرن در Chrome و Edge، فهرست پشتیبانی از فونتهای اصلی استاندارد نگه میدارند: Times New Roman (یا Times Roman)، Helvetica (یا Arial) و Courier. موتور رندر عدد صحیح /Flags در واژهنامه /FontDescriptor را بررسی میکند تا مشخص کند فونت مفقود سریفدار، بدون سریف، تکفاصله، نمادین یا ایتالیک بوده و نزدیکترین تطابق سیستمی موجود را اختصاص میدهد.
اگرچه جایگزینی فونت از از کار افتادن فاجعهبار یا صفحه کاملاً خالی جلوگیری میکند، عوارض جانبی بصری و تایپوگرافیک آن ویرانگر است. هر قلم ویژگیهای معیاری منحصربهفردی دارد: پهنای پیشروی، جفتهای کرنینگ، ارتفاع x، ارتفاع حروف بزرگ، نسبتهای بالارو و عمق پایینرو. برای مثال، اگر چیدمان اصلی با Montserrat یا Proxima Nova در ۱۱ پوینت تنظیم شده باشد، جایگزینی آن با Arial یا Helvetica پهنای پیشروی نویسهها را بر هم میزند. چون دستورهای موقعیتدهی متن در PDF اصلی فاصله واژهها و شکست سطرها را بر اساس هندسه فونت اصلی تعریف میکنند، گلیفهای جایگزینشده یا با هم برخورد میکنند، یا فاصلههای مصنوعی زشتی ایجاد میکنند یا از مرز ستونهای جدول و خانههای فاکتور فراتر میروند.
افزون بر این، در قراردادهای حقوقی، نقشههای معماری، امیدنامههای مالی و پایاننامههای دانشگاهی، جریان مجدد سطرها میتواند بندهای حیاتی را به صفحات غیرمنتظره هل دهد یا امضاها را از شرایط الزامآور جدا کند. در نشریات چندستونی، جایگزینی فونت اغلب سرعنوانها را زیر حاشیه صفحه میراند یا جدولها را به نوارهای بریده و ناخوانا تبدیل میکند. بدون جاسازی کامل فایلهای فونت، وفاداری یکسان اسناد در پلتفرمهای مختلف از نظر ریاضی ناممکن است.
۳. جاسازی کامل فونت در برابر زیرمجموعهسازی: یافتن توازن کامل حجم فایل
هنگام جاسازی فونت در PDF، نویسندگان سند با تصمیمی فنی و حیاتی روبهرو میشوند: آیا کل فایل فونت را جاسازی کنند (جاسازی کامل) یا برشی سفارشی شامل فقط گلیفهایی که واقعاً در سند استفاده شدهاند بسازند (زیرمجموعهسازی فونت)؟ درک بدهبستانهای این دو راهبرد برای ایجاد توازن میان قابلیت جابهجایی سند و وزن بایتی ضروری است.
جاسازی کامل کل جدول باینری فونت را در جریان PDF بستهبندی میکند. برای یک قلم یونیکد مدرن مانند Noto Sans، Roboto یا Arial Unicode MS، فایل کامل TTF یا OTF بهراحتی میتواند میان ۴ تا ۳۰ مگابایت باشد. اگر سندی از چهار وزن و سبک مختلف (Regular، Italic، Bold، Bold Italic) استفاده کند، جاسازی کامل فوراً ۱۵ تا ۴۰ مگابایت سربار فونت به یک یادداشت سهصفحهای که در غیر این صورت سبک بود اضافه میکند. اگرچه جاسازی کامل به کاربران بعدی امکان میدهد متن PDF را بعداً بدون نصب فونت روی رایانه خود ویرایش کنند، اسنادی متورم میسازد که کند دانلود میشوند، ارائه آنها در شبکههای موبایل گران است و اغلب توسط پیوستهای ایمیل و درگاههای آپلود دولتی رد میشوند.
زیرمجموعهسازی فونت این دوراهی را با کامپایل هوشمند باینری حل میکند. طبق ISO 32000، یک فونت زیرمجموعه هر خط دور گلیف، مدخل جدول معیار و جفت کرنینگی را که در هیچ جای جریانهای متنی سند ظاهر نشده حذف میکند. اگر سند شما فقط از ۷۸ حرف لاتین، علامت نگارشی و عدد یکتا استفاده کند، سازنده زیرمجموعه یک برنامه فونت سفارشی فوقسبک میسازد که برای هر قلم فقط ۱۲ تا ۳۵ کیلوبایت نیاز دارد. طبق استانداردهای PDF، فونتهای زیرمجموعه صراحتاً با یک پیشوند دلخواه ششحرفی بزرگ و پس از آن یک علامت بهعلاوه برچسب میخورند (برای مثال 'ABCDAA+Roboto-Bold' یا 'XYZKLM+Helvetica'). این پیشوند تضمین میکند اپلیکیشنهای نمایش هرگز زیرمجموعه سفارشی را با هیچ فونت سیستمی نصبشده عمومی اشتباه نگیرند.
۴. اصلاح متن درهم: ترمیم CMapهای خراب ToUnicode و نگاشت گلیفها
یک آسیب رایج در اسناد PDF متنی است که روی صفحه کاملاً عادی به نظر میرسد، اما هنگام کپی در کلیپبورد، استخراج با OCR یا نمایهسازی توسط خزندههای موتور جستوجو به نویسههای بیمعنا تبدیل میشود. برای مثال، کپی واژه 'Report' ممکن است بهصورت '#@%*!' یا نمادهای تصادفی غیرقابل چاپ الصاق شود. این نقص ناشی از جدول نگاشت /ToUnicode مفقود، خراب یا غیراستاندارد در واژهنامه فونت است.
طبق ISO 32000، یک فونت در PDF ممکن است کدهای نویسه داخلی دلخواهی به گلیفهای بصری مشخص اختصاص دهد. برای مثال، کد نویسه 0x01 ممکن است گلیف بصری حرف 'H' را رسم کند، در حالی که کد 0x02 حرف 'e' را رسم میکند. تا زمانی که فونت خطوط دور وکتوری را دارد، موتور رندر 'He' را درست نمایش میدهد. اما وقتی کاربر متن را کپی میکند، کلیپبورد سیستمعامل به نقاط کد استاندارد یونیکد UTF-8 یا UTF-16 نیاز دارد. CMap /ToUnicode جدول جستوجوی باینری ویژهای است که کدهای نویسه داخلی (مانند 0x01) را به مقادیر اسکالر واقعی یونیکد (مانند U+0048 LATIN CAPITAL LETTER H) ترجمه میکند.
وقتی تولیدکنندههای PDF جریان /ToUnicode را حذف کنند یا نگاشتهای نادرست CID نویسه به گلیف بسازند، استخراج متن کاملاً شکست میخورد. برای اصلاح این مشکل بدون بازسازی کل PDF، ابزارهای ترمیم مدرن سمت کاربر جدول 'cmap' زیرین TrueType جاسازیشده در جریان /FontFile2 را تحلیل، نامهای واقعی گلیف PostScript (مانند /a، /b، /hyphen) را استخراج، آنها را با Adobe Glyph List (AGL) تطبیق و یک جریان CMap /ToUnicode معتبر بازسازی میکنند. پس از ساخت و درج در واژهنامه فونت، دقت کامل کپیوالصاق، انتخاب متن و دسترسپذیری برای صفحهخوان برای همیشه بازگردانده میشود.
۵. راهنمای گامبهگام: چگونه فونتهای PDF را درون مرورگر جاسازی، زیرمجموعه و ترمیم کنیم
در گذشته، رفع خطاهای فونت جاسازینشده به نرمافزارهای گران رومیزی پیش از چاپ مانند Adobe Acrobat Pro همراه با PitStop Server یا اجرای دستورهای پیچیده ترمینال Ghostscript نیاز داشت. امروز به لطف WebAssembly، Web Workerهای مرورگر مدرن میتوانند ساختارهای باینری PDF را تجزیه، جدولهای فونت را بررسی و زیرمجموعهسازی و جاسازی باینری را کاملاً در حافظه با حریم خصوصی مطلق انجام دهند. برای ممیزی و ترمیم سند خود این گامها را دنبال کنید:
گام ۱: وضعیت فونتهای جاسازیشده را بررسی کنید. به ابزار استخراج فونتها یا مشاهده فراداده PDF ما بروید و فایل PDF خود را رها کنید. تحلیلگر واژهنامههای /Resources را در همه صفحات تجزیه و هر فونت اعلامشده را همراه با زیرنوع (TrueType، Type1، Type0)، پرچم جاسازی (جاسازیشده، زیرمجموعه یا مفقود) و قالب رمزگذاری فهرست میکند.
گام ۲: قلمهای مفقود را جاسازی کنید. اگر تحلیلگر فونتهای جاسازینشده را شناسایی کرد، ابزار جاسازی فونتها را اجرا کنید. فایل فونت TTF یا OTF منطبق را از ایستگاه کاری خود یا یک مخزن فونت متنباز (مانند Google Fonts) فراهم کنید. ابزار معیارهای گلیف را استخراج، جریانهای لازم /FontDescriptor و /FontFile2 را تولید و جدول ارجاع متقابل اشیای PDF را بهروزرسانی میکند.
گام ۳: برای کارایی بهینه وب زیرمجموعهسازی کنید. اگر PDF شما به دلیل خانوادههای فونت ۱۰ مگابایتی جاسازیشده کامل متورم است، آن را در ابزار زیرمجموعهسازی فونتها بارگذاری کنید. موتور هر جریان متنی را اسکن، مجموعه دقیق شناسههای گلیف فعال را تعیین، خطوط دور استفادهنشده را هرس، یک باینری CFF یا TrueType پاکسازیشده تولید و فونت را با پیشوند استاندارد ۶ حرفی زیرمجموعه برچسبگذاری میکند. حجم فایل بهشدت کاهش مییابد، در حالی که رندر ۱۰۰٪ واضح میماند.
گام ۴: انطباق آرشیوی بلندمدت را راستیآزمایی کنید. اگر سند شما برای پروندههای حقوقی، سوابق پزشکی یا بایگانیهای دولتی در نظر گرفته شده، فایل خروجی را از اعتبارسنج آرشیوی PDF/A ما عبور دهید تا تضمین شود همه فونتها بدون هیچ ارجاع جاسازینشده یا ممنوعی استانداردهای ISO 19005 را برآورده میکنند.
۶. الزامات آرشیوی ISO 32000 و PDF/A: چرا جاسازی فونت غیرقابل مذاکره است
سازمان بینالمللی استانداردسازی برای حفظ بلندمدت دیجیتال، مجموعه استانداردهای PDF/A (ISO 19005-1 تا ISO 19005-4) را ایجاد کرد. برخلاف فایلهای PDF عمومی که جاسازی فونت در آنها اختیاری است، انطباق با PDF/A فونتهای جاسازینشده را قاطعانه ممنوع میکند. هر گلیف رندرشده در فایل PDF/A باید خطوط دور وکتوری و توصیفگرهای معیار متناظرش را بهطور فیزیکی درون جریان سند داشته باشد.
منطق این قاعده سختگیرانه ساده است: قالبهای دیجیتال باید ۲۰، ۵۰ یا ۱۰۰ سال بعد نیز، مدتها پس از منسوخ شدن سیستمعاملهای فعلی، کارگاههای تجاری فونت و موتورهای اختصاصی رندر فونت، کاملاً خوانا بمانند. اگر قراردادی از سال ۲۰۲۶ به فونتی خارجی که روی Windows 11 نصب شده تکیه کند، باز کردن آن فایل روی یک ماشین لینوکسی در سال ۲۰۶۰ در صورت عدم وجود آن برنامه فونت، شکست میخورد یا مخدوش میشود. افزون بر این، استانداردهای PDF/A-1a، PDF/A-2a و PDF/A-4 الزام میکنند همه فونتها نگاشتهای معتبر یونیکد (/ToUnicode) داشته باشند تا صفحهخوانهای افراد کمبینا و خزندههای خودکار بایگانی بتوانند متن معنایی را بیقیدوشرط تفسیر کنند.
در چاپ تجاری و گردشکارهای پیش از چاپ (تحت ISO 15930 / PDF/X)، فونتهای مفقود باعث توقفهای پرهزینه ماشین چاپ یا خراب شدن تیراژ میشوند. پردازشگرهای تصویر رستری (RIP) با وضوح بالای Computer-to-Plate (CtP) در صورت مواجهه با فونت جاسازینشده رسترسازی را متوقف میکنند. با راستیآزمایی PDF از طریق بررسیهای خودکار پیش از چاپ و جاسازی قلمهای زیرمجموعه پیش از توزیع، وفاداری بصری دائمی را در حوزههای چاپ، وب و بایگانی حقوقی تضمین میکنید.
همین حالا این ابزارها را رایگان در مرورگر اجرا کنید
بدون آپلود فایل، استفاده نامحدود و پردازش فوری با Web Workers مدرن مرورگر.
پرسشهای متداول
تفاوت فونت جاسازیشده و فونت زیرمجموعه چیست؟▾
فونت جاسازیشده کل فایل فونت را با هزاران گلیف و جدول فراداده در بر دارد و امکان ویرایش بعدی متن را فراهم میکند، اما حجم فایل را بزرگ میکند. فونت زیرمجموعه فقط نویسههای مشخصی را که در همان سند استفاده شدهاند شامل میشود و با حفظ رندر بصری یکسان، حجم فایل را بهشدت (اغلب ۹۰٪ یا بیشتر) کاهش میدهد.
چرا متن کپیشده از PDF من شبیه نمادهای عجیب است؟▾
این به این دلیل رخ میدهد که واژهنامه فونت فاقد جدول CMap /ToUnicode معتبر است. خواننده PDF میداند اشکال وکتوری را روی صفحه چگونه رسم کند، اما کلیپبورد سیستمعامل بدون جدول ToUnicode نمیتواند شناسههای نویسه داخلی را به نویسههای استاندارد یونیکد برگرداند.
آیا از نظر قانونی میتوانم فونتهای تجاری را در فایلهای PDF عمومی جاسازی کنم؟▾
بیشتر مجوزهای فونت مدرن جاسازی در اسناد PDF را مجاز میدانند، به شرطی که فونت زیرمجموعه شده باشد (تا نرمافزار کامل فونت قابل استخراج و استفاده مجدد نباشد) و سند فقط برای چاپ و پیشنمایش تنظیم شده باشد. همیشه پرچمهای مجوز fsType در OpenType را در فایل فونت خود بررسی کنید.
آیا جاسازی فونت مانع جایگزینی فونت در رایانههای گیرنده میشود؟▾
بله. وقتی همه فونتها و معیارهای نویسههایشان درون جریان PDF جاسازی شوند، هر دستگاه نمایشی (Windows، Mac، Linux، iOS، Android) دقیقاً همان خطوط دور گلیف را رندر میکند و جریان مجدد ناشی از جایگزینی فونت کاملاً حذف میشود.
تیم مهندسی 2run
نوشتهشده توسط تیم موتور مرورگر و امنیت 2RUN OÜ (تالین، استونی). مبتنی بر معماری خصوصی سمت کاربر و بدون نگهداری داده.