چگونه PDF را برای پخش سریع در وب و نمایش فوری خطی‌سازی کنیم

۱. خطی‌سازی PDF چیست و چرا ارائه عادی در وب شکست می‌خورد؟

یک فایل PDF استاندارد و خطی‌نشده اساساً برای دسترسی محلی و تصادفی به فایل روی دیسک ذخیره‌سازی فیزیکی طراحی شده است. در یک سند PDF استاندارد، جدول ارجاع متقابل اصلی (که در مشخصات با نام جدول xref شناخته می‌شود) و واژه‌نامه مرکزی کاتالوگ سند (/Root) به‌طور فیزیکی در انتهای جریان بایتی فایل نوشته می‌شوند. وقتی یک مرورگر وب مدرن مانند Google Chrome، ‏Mozilla Firefox یا Safari تلاش می‌کند یک PDF معمولی را از طریق درخواست استاندارد HTTP GET بارگذاری کند، با گلوگاه فنی فلج‌کننده‌ای روبه‌رو می‌شود: مرورگر بدون خواندن جدول xref نمی‌تواند درخت داخلی صفحات، واژه‌نامه‌های فونت یا جریان‌های محتوای گرافیکی را پیدا کند.

چون این نمایه حیاتی ارجاع متقابل در بایت‌های پایانی فایل قرار دارد، مرورگر فقط دو گزینه دارد: یا باید ۱۰۰٪ کل محتوای فایل را از شبکه دانلود کند تا بتواند صفحه ۱ را روی صفحه‌نمایش کاربر رسم کند، یا باید چندین درخواست رفت‌وبرگشتی شبکه بفرستد تا تریلر فایل را پیدا و بررسی کند. برای یک کاتالوگ دیجیتال محصول ۱۰۰ صفحه‌ای و ۶۰ مگابایتی یا یک مجموعه قوانین شهرداری، مجبور کردن بازدیدکنندگان به انتظار ۱۵ تا ۳۰ ثانیه‌ای فقط برای دیدن فهرست مطالب در صفحه ۱، نرخ پرش عظیمی ایجاد می‌کند و پهنای باند زیادی از سرور وب مصرف می‌کند.

خطی‌سازی PDF این محدودیت معماری را برای همیشه حل می‌کند. خطی‌سازی که در ISO 32000-1 Annex F تعریف شده، چیدمان فیزیکی اشیا درون فایل PDF را بازسازی می‌کند. همه اشیای غیرمستقیم، برنامه‌های فونت، تصاویر جاسازی‌شده و مسیرهای وکتوری لازم برای رندر نخستین صفحه را استخراج و آن‌ها را به‌طور پیوسته درست در ابتدای جریان فایل گرد می‌آورد. همراه با درخواست‌های HTTP Range ‏(تعریف‌شده در IETF RFC 7233)، مرورگرهای وب می‌توانند صفحه ۱ را در کمتر از ۲۵۰ میلی‌ثانیه نمایش دهند و هم‌زمان صفحات باقی‌مانده را بی‌صدا در پس‌زمینه پخش کنند.

۲. کالبدشناسی Fast Web View: سازوکار داخلی آن (ISO 32000 Annex F)

برای درک اینکه Fast Web View چگونه صفحات را فوراً تحویل می‌دهد، باید کالبدشناسی باینری فیزیکی جریان بایتی یک PDF خطی‌شده را بررسی کرد. طبق رهنمودهای ISO 32000 Annex F، سند خطی‌شده به‌جای مجموعه‌ای پراکنده از اشیای غیرمستقیم، به بخش‌های متوالی متمایز تقسیم می‌شود:

۱. بخش ۱ — واژه‌نامه پارامترهای خطی‌سازی: این واژه‌نامه ویژه که در ۱۰۲۴ بایت نخست فایل فیزیکی قرار می‌گیرد، با کلید /Linearized شناخته می‌شود. این واژه‌نامه پارامترهای فراداده حیاتی را در بر دارد: /L ‏(طول دقیق بایتی کل فایل)، /O ‏(شماره شیء واژه‌نامه /Page صفحه نخست)، /E ‏(آفست بایتی پایان صفحه نخست)، /N ‏(تعداد کل صفحات سند)، /T ‏(آفست بایتی جدول ارجاع متقابل صفحه نخست) و /H ‏(آرایه‌ای که آفست‌ها و طول‌های بایتی جریان راهنمای اصلی را نشان می‌دهد).

۲. بخش ۲ — جدول ارجاع متقابل و اشیای صفحه نخست: بلافاصله پس از واژه‌نامه پارامترها، PDF یک جدول ارجاع متقابل محلی فراهم می‌کند که منحصراً به نمایه‌سازی اشیای لازم برای صفحه ۱ اختصاص دارد. پس از این جدول، گروه اشیای صفحه نخست می‌آید که جریان محتوای صفحه، توصیف‌گرهای فونت و XObjectهای تصویر را در خود جای داده است.

۳. بخش ۳ — جریان راهنمای اصلی: جریان راهنما جدول‌های جست‌وجوی باینری (جدول راهنمای آفست صفحات و جدول راهنمای اشیای مشترک) را در بر دارد. این جدول‌ها به موتور رندر مرورگر وب امکان می‌دهند آفست‌ها و طول‌های بایتی دقیق هر صفحه بعدی را بدون تجزیه کل درخت سند محاسبه کند.

۴. بخش‌های ۴ و ۵ — کاتالوگ سند و صفحات باقی‌مانده: کاتالوگ مرکزی سند (/Root)، طرح‌کلی‌ها، نشانک‌ها و واژه‌نامه‌های رشته پس از آن می‌آیند. سپس صفحات باقی‌مانده سند (صفحه ۲ تا صفحه N) به ترتیب عددی دقیق چیده می‌شوند و با یک جدول ارجاع متقابل اصلی ثانویه که اشیای غیر صفحه نخست را نمایه می‌کند پایان می‌یابند.

۳. دست‌دهی کلاینت و سرور: HTTP 206 Partial Content در عمل

جادوی Fast Web View به همکاری فعال میان نمایشگر PDF مرورگر و سرور وب میزبان نیاز دارد. وقتی کاربر به نشانی یک PDF خطی‌شده می‌رود، مرورگر یک درخواست اولیه HTTP GET با سرآیند HTTP Range می‌فرستد که ۳۲ یا ۶۴ کیلوبایت نخست سند را درخواست می‌کند (برای مثال 'Range: bytes=0-32767').

اگر سرور وب میزبان از ارائه بازه بایتی پشتیبانی کند، با کد وضعیت HTTP 206 ‏(Partial Content) همراه با سرآیند 'Content-Range: bytes 0-32767/62914560' پاسخ می‌دهد. مرورگر بی‌درنگ واژه‌نامه /Linearized و جریان راهنمای اصلی را از این تکه اولیه می‌خواند. چون کل گروه اشیای صفحه نخست در همین محموله اولیه قرار دارد، مرورگر فونت‌ها و جریان‌های وکتوری را تجزیه و صفحه ۱ را فوراً روی صفحه‌نمایش رندر می‌کند.

اگر کاربر سپس روی پیوندی کلیک کند که به صفحه ۷۸ می‌رود یا نوار پیمایش تصاویر کوچک را مستقیماً به میانه سند بکشد، مرورگر صفحات ۲ تا ۷۷ را دانلود نمی‌کند. در عوض، به جدول راهنمای اصلی در حافظه رجوع می‌کند، محاسبه می‌کند که صفحه ۷۸ از آفست بایتی ۳۴٬۱۲۰٬۵۰۰ آغاز می‌شود و ۴۲۰٬۱۰۰ بایت طول دارد، و بی‌درنگ درخواستی هدفمند می‌فرستد: 'Range: bytes=34120500-34540599'. سرور فقط همان بایت‌های درخواستی را ارائه می‌دهد، صفحه مقصد را در کسری از ثانیه رندر می‌کند و مصرف کلی پهنای باند سرور را برای کاربرانی که فقط فصل‌های منتخب را بررسی می‌کنند تا ۹۰٪ کاهش می‌دهد.

۴. پیکربندی سرور وب برای ارائه بازه بایتی

حتی یک PDF کاملاً خطی‌شده نیز اگر سرور وب زیرین یا شبکه تحویل محتوا (CDN) از درخواست‌های بازه بایتی HTTP پشتیبانی نکند یا آن‌ها را فعالانه حذف کند، پخش نخواهد شد. خوشبختانه سرورهای وب مدرن به‌طور پیش‌فرض از بازه‌های بایتی RFC 7233 پشتیبانی می‌کنند، اما پیکربندی‌های خاص کش یا فشرده‌سازی ممکن است تصادفاً آن را غیرفعال کنند.

در Nginx مطمئن شوید که دستور 'max_ranges' روی 0 تنظیم نشده باشد. اگر از کش پراکسی معکوس استفاده می‌کنید، با بررسی اینکه دستور 'proxy_cache_key' بازه‌ها را در نظر می‌گیرد، پشتیبانی از بازه بایتی را لحاظ کنید یا کش را برای جریان‌های PDF چندمگابایتی دور بزنید. در Apache HTTP Server تأیید کنید که 'mod_headers' سرآیند پاسخ 'Accept-Ranges' را حذف نمی‌کند. یک استقرار استاندارد Apache سرآیند 'Accept-Ranges: bytes' را خودکار ارسال می‌کند.

برای فضای ذخیره‌سازی ابری و پلتفرم‌های لبه مانند Amazon S3، ‏Google Cloud Storage، ‏Microsoft Azure Blob Storage و Cloudflare CDN، درخواست‌های بازه بایتی از ابتدا فعال‌اند. اما مراقب میان‌افزارهای فشرده‌سازی پویای gzip یا Brotli روی سرورهای وب باشید: اگر یک پراکسی معکوس تلاش کند کل جریان PDF را به‌طور پویا و درجا فشرده کند، سرآیند 'Content-Length' را حذف و بازه‌های بایتی را غیرفعال می‌کند و توانایی مرورگر برای ارسال درخواست‌های HTTP 206 را از بین می‌برد. PDFها از قبل به‌صورت داخلی با FlateDecode فشرده شده‌اند؛ فشرده‌سازی gzip سمت سرور عملاً هیچ فشرده‌سازی اضافه‌ای فراهم نمی‌کند و در عین حال خطی‌سازی را می‌شکند.

۵. گام‌به‌گام: خطی‌سازی PDFها در سمت کاربر بدون خطرات حریم خصوصی ابری

در گذشته، اجرای خطی‌سازی به نصب ابزارهای سنگین خط فرمان رومیزی مانند QPDF، ‏Ghostscript یا خرید مجوزهای گران سازمانی Adobe Acrobat نیاز داشت. افزون بر این، بسیاری از سرویس‌های آنلاین PDF ادعا می‌کنند فایل‌ها را خطی‌سازی می‌کنند، اما آپلود کل اسناد چندمگابایتی به سرورهای ابری دوردست را الزامی می‌کنند — و صورت‌های مالی محرمانه شرکت‌ها، بسته‌های مدارک حقوقی و پرونده‌های بیماران را در معرض رهگیری داده توسط اشخاص ثالث قرار می‌دهند.

ابزار بومی مرورگر خطی‌سازی / نمایش سریع وب ما با استفاده از WebAssembly کامپایل‌شده ۱۰۰٪ به‌صورت محلی درون مرورگر وب شما اجرا می‌شود. روش بهینه‌سازی نشریات خود در چند ثانیه این است:

گام ۱: ابزار خطی‌سازی را باز کنید و سند هدف خود را به ناحیه رها کردن بکشید. فایل از طریق HTML5 File API مستقیماً در حافظه مرورگر دستگاه شما (RAM) خوانده می‌شود؛ هیچ بایتی به ابر آپلود نمی‌شود.

گام ۲: موتور WebAssembly گراف اشیای داخلی PDF را تحلیل، همه منابعی را که صفحه ۱ به آن‌ها ارجاع می‌دهد شناسایی، جدول‌های راهنمای اصلی را ترکیب و جریان‌های اشیا را در چیدمان باینری سازگار با ISO 32000 Annex F بازچینی می‌کند.

گام ۳: روی دکمه دانلود PDF خطی‌شده کلیک کنید. پیش از استقرار فایل، در صورت تمایل می‌توانید آن را از ابزار فشرده‌سازی فایل PDF ما عبور دهید تا وضوح تصاویر فشرده‌نشده کاهش یابد، یا سرآیند حاصل را در بازرس فراداده PDF بررسی کنید تا تأیید شود 'Fast Web View: Yes' ثبت شده است.

۶. چگونه وضعیت Fast Web View را بررسی و مشکلات را عیب‌یابی کنیم

پس از پردازش سند، ضروری است بررسی کنید که خطی‌سازی با موفقیت اعمال شده و محیط میزبانی وب شما آن را به‌درستی ارائه می‌کند. سه روش ساده برای ممیزی فایل‌ها وجود دارد:

۱. بازرسی رومیزی: PDF را در Adobe Acrobat Reader یا هر نمایشگر حرفه‌ای باز کنید. به File > Properties بروید (یا Ctrl+D / Cmd+D را فشار دهید). در زبانه Description، فیلدی با عنوان 'Fast Web View' را پیدا کنید. اگر فایل به‌درستی خطی شده باشد، 'Yes' نشان می‌دهد. اگر 'No' نشان دهد، فایل به‌صورت غیرخطی ذخیره شده است.

۲. بازرسی سرآیند شانزده‌شانزدهی: می‌توانید چند سطر نخست فایل را با یک نمایشگر ترمینالی مانند 'head -n 20 document.pdf' بررسی کنید. در ۱۰۲۴ بایت نخست، باید به‌وضوح واژه‌نامه‌ای حاوی '/Linearized 1.0' را همراه با پارامترهای /L، /H، /O و /E ببینید.

۳. آزمودن دست‌دهی زنده HTTP 206 با cURL: برای تأیید اینکه سرور وب عملیاتی شما بازه‌های بایتی را به‌درستی ارائه می‌کند، این را اجرا کنید: 'curl -I -r 0-1023 https://yourdomain.com/catalog.pdf'. پاسخ سرور باید 'HTTP/1.1 206 Partial Content' ‏(یا HTTP/2 206) را برگرداند و 'Content-Range: bytes 0-1023/total_size' را شامل شود. اگر به‌جای 206 پاسخ HTTP 200 OK دریافت کنید، سرور وب یا CDN شما سرآیند Range را نادیده می‌گیرد.