SVG'den PDF'e Geçerken Ne Değişir? viewBox, Birimler ve Yazı Tipi Mantığı

SVG bir web grafiği formatıdır: esnek, ölçeklenebilir, ekrana uyum sağlayan. PDF ise bir sayfa formatıdır: sabit, fiziksel, baskıya bağlı. İkisi aynı vektör çizim modelini paylaşsa da bu felsefe farkı, dönüşümde somut sonuçlar doğurur. Bu yazıda o farkları ve neden bazı SVG'lerin PDF'e beklenmedik boyutlarda çevrildiğini açıklıyoruz.

İki farklı "sayfa" anlayışı

PDF'te sayfa fizikseldir. Her sayfa nesnesinin bir MediaBox'ı vardır ve bu, punto cinsinden sabit bir dikdörtgendir. A4 sayfa 595 × 842 puntodur, hep öyledir, her yerde öyledir. İçerik bu koordinat sistemine doğrudan yerleştirilir. "Ekrana sığdır" diye bir kavram yoktur — görüntüleyici yakınlaştırma yapar ama sayfanın kendisi değişmez.

SVG'de "sayfa" görecelidir. Bir SVG'nin doğal boyutu yoktur; içerik bir koordinat sisteminde tanımlanır ve o sistem herhangi bir görüntüleme alanına ölçeklenebilir. Aynı SVG dosyası bir yerde 100 piksel, başka bir yerde 1000 piksel genişlikte gösterilebilir ve ikisi de doğrudur.

Bu felsefe farkı, dönüşümde bir karar zorunluluğu yaratır: esnek bir grafiği sabit bir sayfaya yerleştirirken hangi ölçek kullanılacak?

viewBox: SVG'nin koordinat sistemi

viewBox özniteliği dört sayı alır:

<svg viewBox="0 0 595 842">

Bunlar sırasıyla: minX, minY, genişlik, yükseklik. Anlamı şudur: "içeriğim (0,0) noktasından başlayan 595 birim genişlik, 842 birim yükseklikteki bir alanda tanımlı."

İçerideki tüm koordinatlar bu sistemde ifade edilir. Bir dikdörtgen x="100" y="200" diyorsa, bu viewBox koordinatlarındadır.

viewBox fiziksel bir ölçü değildir. Sadece iç koordinat sistemini tanımlar. Bu sistemin gerçekte ne kadar yer kaplayacağını width ve height belirler.

width/height: görüntüleme boyutu

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

Bu dosyada içerik 595 × 842 birimlik bir koordinat sisteminde tanımlıdır ve bu sistem 210 × 297 mm'lik bir alana ölçeklenir. Yani 1 kullanıcı birimi yaklaşık 0.353 mm eder — ki bu tam olarak 1 puntodur (1/72 inç = 0.3528 mm).

Şimdi aynı içeriği farklı bir width ile düşünün:

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

İçerik aynıdır, ama yarı ölçekte gösterilir — A5 boyutunda.

Birim belirsizliği: en yaygın sorun kaynağı

Sorun, width ve height birimsiz yazıldığında başlar:

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

Bu "595 ne?" sorusunu yanıtsız bırakır. İki farklı yorum var ve aralarında yüzde 33'lük fark bulunur:

| Yorum | 1 birim | 595 birim | |---|---|---| | PDF/baskı geleneği: punto | 1/72 inç | 210 mm (A4 genişliği) | | Web/CSS geleneği: piksel | 1/96 inç | 157 mm |

Dönüştürücüler genellikle punto yorumunu kullanır ve doğru sonuç verir. Ama web ortamından gelen SVG'lerde (bir grafik kütüphanesinin ürettiği, bir tarayıcı aracının kaydettiği) piksel varsayımıyla üretilmiş değerler bulunabilir ve o zaman çıkan PDF beklenenden büyük olur.

Daha kötüsü, width/height hiç yoksa:

<svg viewBox="0 0 800 600">

Bu durumda dönüştürücü tamamen tahmin yapar. Bazıları viewBox değerlerini punto sayar, bazıları varsayılan bir sayfa boyutuna sığdırır, bazıları CSS piksel varsayar.

Çözüm basittir: SVG'yi PDF'e çevirmeden önce dosyayı bir metin editöründe açıp width ve height değerlerini fiziksel birimle yazın:

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

Bu tek düzenleme belirsizliği tamamen ortadan kaldırır.

preserveAspectRatio: oran uyuşmazlığında ne olur

viewBox oranı ile width/height oranı uyuşmazsa ne olacağını preserveAspectRatio özniteliği belirler. Varsayılan değer xMidYMid meettir: içerik oranı korunarak alana sığdırılır ve ortalanır, artan yerlerde boşluk kalır.

slice değeri ise tersini yapar: alan tamamen doldurulur, taşan kısımlar kırpılır.

PDF dönüşümünde bu, sayfada beklenmedik boş kenarlar veya kesilmiş içerik olarak görünür. Uyuşmazlık varsa viewBox ile width/height oranlarını eşitlemek en temiz çözümdür.

Yazı tipleri: temel felsefe farkı

Bu, iki format arasındaki en önemli pratik ayrımdır.

PDF yazı tiplerini gömer. Formatın varlık sebebi, belgenin her yerde aynı görünmesidir. Bunu garanti etmenin tek yolu kullanılan yazı tiplerinin çizim verilerini dosyaya koymaktır. Bir PDF açtığınızda görünen yazı tipi, dosyanın kendi içinde taşıdığı yazı tipidir.

SVG genellikle gömmez. font-family="Roboto" yazar ve o yazı tipinin görüntüleme ortamında bulunmasını bekler. Web'de bu, CSS @font-face ile bir yazı tipi dosyası yüklenerek çözülür — ama bu bilgi SVG dosyasının kendisinde değil, sayfanın CSS'inde olabilir.

Dönüşümde ne olacağı dönüştürücünün o yazı tipine erişip erişemediğine bağlıdır:

• Erişebilirse: yazı tipi PDF'e gömülür, metin gerçek metin olarak kalır. Seçilebilir, aranabilir, erişilebilir.
• Erişemezse: benzer bir yazı tipine düşülür. Harf genişlikleri değişir, hizalama kayar, uzun satırlar taşabilir veya kısalır.

İkinci durumun sinsi yanı, sonucun yanlış ama makul görünmesidir. Bir bakışta fark etmezsiniz; ancak orijinalle yan yana koyduğunuzda hizalamaların kaydığını görürsünüz.

Kesin çözüm: SVG'yi üreten programda metinleri eğriye (outline/path) dönüştürmek. Her harf vektör şekle döner, yazı tipi bağımlılığı sıfırlanır. Bedeli metnin seçilemez ve aranamaz olmasıdır.

Renk: RGB'den çıkış yok

SVG doğal olarak RGB'dir. fill="#3366CC" veya fill="rgb(51,102,204)" yazarsınız. CMYK diye bir kavram yoktur.

PDF ise CMYK'yı, spot renkleri ve ICC renk profillerini destekler — baskı için tasarlandığı için.

SVG'den PDF'e dönüşümde renkler RGB olarak taşınır. Bu, ekran kullanımı için sorun değildir ama baskıya gidecek bir dosyada eksikliktir: matbaa CMYK ister ve RGB bir dosya aldığında dönüşümü kendisi yapar, sonuç sizin gördüğünüzden farklı olabilir. Özellikle canlı yeşiller, turuncular ve zengin siyahlar beklenmedik çıkar.

Baskı işi ciddiyse dönüşümden sonra bir tasarım programında CMYK'ya çevirmek gerekir.

Filtreler ve rasterleme

SVG'nin <filter> öğesi güçlü efektler sunar: Gaussian blur, gölge, renk matrisi, aydınlatma, türbülans.

PDF'in saydamlık ve efekt modeli farklıdır ve bu filtrelerin çoğunun doğrudan karşılığı yoktur.

Dönüştürücünün iki seçeneği vardır:

1. Yaklaşık bir karşılık kullanmak. Basit alfa saydamlığı ve bazı karışım modları için mümkündür.

2. O bölgeyi rasterlamak. Filtreli alan bir görüntüye render edilir ve PDF'e piksel olarak yerleştirilir.

İkincisi görsel olarak doğru sonucu verir ama vektör keskinliğini kaybettirir. PDF'i yakınlaştırdığınızda o bölge pikselleşir. Baskıda bu, düşük çözünürlüklü bir alan olarak görünür.

Bu yüzden baskıya gidecek SVG'lerde filtre kullanmaktan kaçınmak, gölge ve blur efektlerini vektör olarak taklit etmek daha güvenlidir.

Dinamik olan her şey sabitlenir

SVG bir web teknolojisidir ve bunun sonuçları vardır:

| SVG'de | PDF'te | |---|---| | SMIL animasyonu | İlk kare veya başlangıç durumu | | CSS animasyonu / geçiş | Sabitlenir | | :hover stilleri | Uygulanmaz, normal hâl kalır | | JavaScript ile üretilen içerik | Dönüştürücü DOM'u okuyorsa taşınır, dosyayı okuyorsa taşınmaz | | <foreignObject> (HTML gömme) | Genellikle kaybolur | | Dış CSS dosyası | Uygulanmayabilir |

Son iki madde önemli: SVG'niz dış bir CSS dosyasına veya JavaScript'e bağımlıysa, dosya tek başına eksik demektir. Dönüştürmeden önce stilleri SVG içine gömmek (inline style öznitelikleri veya <style> bloğu) gerekir.

Kazanılan şeyler

Dönüşümde sadece kaybetmezsiniz; PDF'in getirdikleri de vardır:

• Yazı tipi gömme: artık dosya kendi kendine yeter.
• Çok sayfa: birden çok SVG tek belgede toplanabilir.
• Baskı kontrolü: sayfa boyutu, yönlendirme, kenar boşlukları tanımlıdır.
• Belge özellikleri: metadata, yer imleri, dijital imza mümkün olur.
• Evrensel açılabilirlik: her cihazda beklenen şekilde davranır.

Özetle

SVG esnek ve göreceli bir koordinat sisteminde çalışır; PDF sabit ve fiziksel bir sayfa mantığına dayanır. Dönüşümdeki sorunların çoğu bu farktan doğar: width/height birimi belirtilmediğinde sayfa boyutu tahmine kalır (punto mu piksel mi ayrımı yüzde 33 fark yaratır), yazı tipleri SVG'de gömülü olmadığı için dönüştürücünün erişimine bağlıdır, renkler RGB'den çıkamaz ve karmaşık filtreler rasterlemeye yol açarak vektör keskinliğini kaybettirir. Bu sorunların hepsi önceden çözülebilir: fiziksel birim yazın, metinleri eğriye çevirin, filtre kullanmaktan kaçının ve baskıya gidecekse renk dönüşümünü ayrı bir adım olarak planlayın.