ما الذي يتغير عند الانتقال من SVG إلى PDF؟ viewBox والوحدات ومنطق الخطوط

SVG صيغة رسوم ويب: مرنة، وقابلة للتحجيم، ومتكيفة مع الشاشة. أما PDF فصيغة صفحات: ثابتة، وفيزيائية، ومرتبطة بالطباعة. ورغم أن الاثنتين تتشاركان نموذج الرسم المتجهي نفسه، فإن هذا الاختلاف الفلسفي يولّد نتائج ملموسة في التحويل. نشرح في هذا المقال تلك الفروق ولماذا تُحوَّل بعض ملفات SVG إلى PDF بمقاسات غير متوقعة.

فهمان مختلفان لـ«الصفحة»

الصفحة في PDF فيزيائية. فلكل كائن صفحة MediaBox وهو مستطيل ثابت بوحدة النقطة. وصفحة A4 هي 595 × 842 نقطة، دائماً وفي كل مكان. ويوضَع المحتوى في نظام الإحداثيات هذا مباشرة. ولا وجود لمفهوم «لائم مع الشاشة» — فالعارض يكبّر لكن الصفحة نفسها لا تتغير.

و«الصفحة» في SVG نسبية. فليس لملف SVG مقاس طبيعي؛ بل يُعرَّف المحتوى في نظام إحداثيات ويمكن تحجيم ذلك النظام إلى أي منطقة عرض. فقد يُعرَض ملف SVG نفسه بعرض 100 بكسل في موضع وبعرض 1000 بكسل في آخر وكلاهما صحيح.

وهذا الاختلاف الفلسفي يفرض قراراً في التحويل: أي مقياس يُستخدَم عند وضع رسم مرن في صفحة ثابتة؟

viewBox: نظام إحداثيات SVG

تأخذ الخاصية viewBox أربعة أعداد:

<svg viewBox="0 0 595 842">

وهي بالترتيب: minX، وminY، والعرض، والارتفاع. ومعناها: «محتواي معرَّف في منطقة تبدأ من النقطة (0,0) بعرض 595 وحدة وارتفاع 842 وحدة».

وتُعبَّر كل الإحداثيات في الداخل بهذا النظام. فإن قال مستطيل x="100" y="200" فذلك بإحداثيات viewBox.

وviewBox ليس مقياساً فيزيائياً. بل يعرّف نظام الإحداثيات الداخلي فقط. وما تحدده width وheight هو كم يشغل هذا النظام من مساحة فعلية.

width/height: مقاس العرض

<svg width="210mm" height="297mm" viewBox="0 0 595 842">

فالمحتوى في هذا الملف معرَّف في نظام إحداثيات من 595 × 842 وحدة، ويُحجَّم هذا النظام إلى مساحة 210 × 297 مم. أي أن وحدة المستخدم الواحدة تساوي نحو 0.353 مم — وهي النقطة الواحدة بالضبط (1/72 بوصة = 0.3528 مم).

والآن تخيّل المحتوى نفسه بـ width مختلف:

<svg width="105mm" height="148.5mm" viewBox="0 0 595 842">

المحتوى واحد، لكنه يُعرَض بنصف المقياس — بمقاس A5.

التباس الوحدات: أشيع مصدر للمشكلات

تبدأ المشكلة حين تُكتَب width وheight بلا وحدة:

<svg width="595" height="842" viewBox="0 0 595 842">

فيبقى سؤال «595 ماذا؟» بلا جواب. وثمة تفسيران بينهما فارق 33%:

| التفسير | الوحدة الواحدة | 595 وحدة | |---|---|---| | عرف PDF/الطباعة: نقطة | 1/72 بوصة | 210 مم (عرض A4) | | عرف الويب/CSS: بكسل | 1/96 بوصة | 157 مم |

وتستخدم المحوّلات تفسير النقطة عادةً وتعطي نتيجة صحيحة. لكن في ملفات SVG الآتية من بيئة الويب (المنتَجة من مكتبة رسوم بيانية، أو المحفوظة بأداة متصفح) قد توجد قيم أُنتجت بافتراض البكسل وعندئذ يخرج ملف PDF أكبر مما هو متوقع.

والأسوأ ألا توجد width/height إطلاقاً:

<svg viewBox="0 0 800 600">

ففي هذه الحالة يخمّن المحوّل تخميناً كاملاً. فبعضها يعدّ قيم viewBox نقاطاً، وبعضها يلائمها مع مقاس صفحة افتراضي، وبعضها يفترض بكسل CSS.

والحل بسيط: افتح الملف في محرر نصوص قبل تحويل SVG إلى PDF واكتب قيمتَي width وheight بوحدة فيزيائية:

<svg width="210mm" height="297mm" viewBox="0 0 595 842">

فهذا التعديل الواحد يزيل الالتباس تماماً.

preserveAspectRatio: ماذا يحدث عند عدم تطابق النسب

إن لم تتطابق نسبة viewBox مع نسبة width/height، حددت الخاصية preserveAspectRatio ما سيحدث. والقيمة الافتراضية xMidYMid meet: أي يُلاءم المحتوى مع المنطقة مع صون نسبته ويُوسَّط، ويبقى فراغ في المساحة الزائدة.

أما القيمة slice فتفعل العكس: تُملأ المساحة كاملة وتُقتطع الأجزاء الفائضة.

ويظهر ذلك في التحويل إلى PDF على شكل حواف فارغة غير متوقعة في الصفحة أو محتوى مقتطع. وإن وُجد عدم تطابق فأنظف حل هو مساواة نسبتَي viewBox وwidth/height.

الخطوط: فرق فلسفي جوهري

وهذا أهم تمييز عملي بين الصيغتين.

PDF يضمّن الخطوط. فسبب وجود الصيغة هو ظهور المستند على الصورة نفسها في كل مكان. والسبيل الوحيد لضمان ذلك وضع بيانات رسم الخطوط المستخدمة في الملف. فالخط الذي تراه حين تفتح ملف PDF هو الخط الذي يحمله الملف في داخله.

وSVG لا تضمّن عادةً. فتكتب font-family="Roboto" وتتوقع وجود ذلك الخط في بيئة العرض. ويُحلّ ذلك في الويب بتحميل ملف خط عبر @font-face في CSS — لكن هذه المعلومات قد تكون في CSS الصفحة لا في ملف SVG نفسه.

وما يحدث في التحويل متوقف على قدرة المحوّل على الوصول إلى ذلك الخط:

• إن استطاع الوصول: ضُمِّن الخط في PDF وبقي النص نصاً حقيقياً. فيكون قابلاً للتحديد والبحث ومتاحاً.
• وإن لم يستطع: جرى التراجع إلى خط مشابه. فتتغير عروض الحروف وتنزاح المحاذاة وقد تفيض الأسطر الطويلة أو تقصر.

والجانب الماكر في الحالة الثانية أن النتيجة تبدو خاطئة لكن معقولة. فلا تلاحظها بنظرة واحدة؛ لكنك ترى انزياح المحاذاة حين تضعها إلى جانب الأصل.

والحل القاطع: تحويل النصوص إلى منحنيات (outline/path) في البرنامج الذي ينتج SVG. فيتحول كل حرف إلى شكل متجهي وتُصفَّر التبعية للخطوط. وثمنه أن النص لا يعود قابلاً للتحديد ولا للبحث.

اللون: لا مخرج من RGB

SVG بطبيعتها RGB. فتكتب fill="#3366CC" أو fill="rgb(51,102,204)". ولا وجود لمفهوم CMYK.

أما PDF فيدعم CMYK والألوان الموضعية وملفات ألوان ICC — لأنه مصمم للطباعة.

وتُنقَل الألوان في التحويل من SVG إلى PDF بنظام RGB. وهذا ليس مشكلة للاستخدام على الشاشة لكنه نقص في ملف ذاهب إلى الطباعة: فالمطبعة تطلب CMYK وحين تتسلم ملفاً بنظام RGB تُجري التحويل بنفسها وقد تختلف النتيجة عما رأيته. وتخرج الخضراوات الزاهية والبرتقاليات والأسود الغني على نحو غير متوقع خصوصاً.

فإن كان عمل الطباعة جاداً فينبغي التحويل إلى CMYK في برنامج تصميم بعد التحويل.

المرشّحات والتصيير النقطي

يقدم عنصر <filter> في SVG مؤثرات قوية: الطمس الغاوسي، والظل، ومصفوفة الألوان، والإضاءة، والاضطراب.

ونموذج الشفافية والمؤثرات في PDF مختلف ولا مقابل مباشر لمعظم هذه المرشّحات.

وأمام المحوّل خياران:

1. استخدام مقابل تقريبي. وهذا ممكن لشفافية ألفا البسيطة وبعض أنماط المزج.

2. تصيير تلك المنطقة نقطياً. فتُصيَّر المنطقة ذات المرشّح إلى صورة وتُوضَع في PDF كبكسلات.

والثاني يعطي نتيجة صحيحة بصرياً لكنه يُفقد حدّة المتجه. فحين تكبّر ملف PDF تتبكسل تلك المنطقة. وتظهر في الطباعة كمنطقة منخفضة الدقة.

ولذلك من الأأمن تجنّب استخدام المرشّحات في ملفات SVG الذاهبة إلى الطباعة، ومحاكاة مؤثرات الظل والطمس بالمتجهات.

كل ما هو ديناميكي يُثبَّت

SVG تقنية ويب ولذلك نتائج:

| في SVG | في PDF | |---|---| | حركة SMIL | الإطار الأول أو حالة البداية | | حركة/انتقال CSS | تُثبَّت | | أنماط :hover | لا تُطبَّق، وتبقى الحالة العادية | | محتوى مولَّد بجافاسكربت | يُنقَل إن كان المحوّل يقرأ DOM، ولا يُنقَل إن كان يقرأ الملف | | <foreignObject> (تضمين HTML) | يضيع عادةً | | ملف CSS خارجي | قد لا يُطبَّق |

والبندان الأخيران مهمان: فإن كان ملف SVG لديك معتمداً على ملف CSS خارجي أو على جافاسكربت، فالملف ناقص بمفرده. وينبغي تضمين الأنماط داخل SVG قبل التحويل (بخصائص style سطرية أو بكتلة <style>).

ما يُكتسَب

لا تخسر في التحويل فحسب؛ فثمة ما يجلبه PDF أيضاً:

• تضمين الخطوط: فيصير الملف مكتفياً بذاته.
• تعدد الصفحات: فيمكن جمع عدة ملفات SVG في مستند واحد.
• التحكم في الطباعة: فمقاس الصفحة والاتجاه والهوامش معرَّفة.
• خصائص المستند: فتصير البيانات الوصفية والإشارات المرجعية والتوقيع الرقمي ممكنة.
• إمكان الفتح في كل مكان: فيتصرف كما يُتوقَّع على كل جهاز.

الخلاصة

تعمل SVG في نظام إحداثيات مرن ونسبي؛ ويقوم PDF على منطق صفحة ثابتة وفيزيائية. ومعظم مشكلات التحويل نابعة من هذا الفرق: فحين لا تُحدَّد وحدة width/height يبقى مقاس الصفحة رهن التخمين (والتمييز بين النقطة والبكسل يُحدث فارق 33%)، والخطوط غير مضمّنة في SVG فتتوقف على وصول المحوّل إليها، والألوان لا تخرج من RGB، والمرشّحات المعقدة تفضي إلى تصيير نقطي يُفقد حدّة المتجه. وكل هذه المشكلات يمكن حلها سلفاً: اكتب وحدة فيزيائية، وحوّل النصوص إلى منحنيات، وتجنّب استخدام المرشّحات، وخطّط لتحويل الألوان كخطوة منفصلة إن كان الملف ذاهباً إلى الطباعة.