Önce hosting firmasının sunucusundaki PHP yorumlayıcısında PDF eklentisinin olmadığını öğrendim. Bu nedenle hosting firması değiştirmem gerekeceğini düşünmeye başladım. Ancak biraz daha araştırınca sadece PHP ile geliştirilmiş ve herhangi bir C PDF kütüphanesi ihtiyacı duymadan PDF formatında çıktı üretebilen bir PHP projesi ile tanıştım: FPDF.

FPDF basit yazabilen bir PHP sınıfından ibaret bir proje. Bu sınıfı genişleterek kendi projenize uygun PDF çıktısı üretecek yeni bir sınıf yazarak kullanmanız gerekiyor. Böylece PDF dökümanının dinamik bir şekilde yazılması sürecinin tamamına (mesela yeni sayfaya geçilmesinde yapılacak işlemlere) müdahale edebiliyorsunuz.

<?php

require('fpdf.php');

class PDF extends FPDF

{


function Header()
{
    // her yeni sayfanın üst kısmına yazılacak
    $this->SetFont('Arial','B',16);
    $this->SetTextColor(255,192,203);
    $this->MultiCell(0,5,"sample header text",0,'L');
}
}


$pdf=new PDF();
$pdf->AddPage();
$pdf->SetFont('Arial','',12);
$txt="FPDF is a PHP class which allows to generate PDF files with pure PHP, that is to say ".
    "without using the PDFlib library. F from FPDF stands for Free: you may use it for any ".
    "kind of usage and modify it to suit your needs.\n\n";
for($i=0;$i<25;$i++)
    $pdf->MultiCell(0,5,iconv('utf-8', 'iso-8859-9', $txt),0,'J');
$pdf->Output();

?>

Türkçe True Type fontları da FPDF’in kullanabileceği formata dönüştürerek sorunsuz Türkçe karakter yazdırmanız mümkün oluyor. Üretilen PDF’lere bu fontlar da gömülüyor ve her PDF gösterebilen ortamda sorunsuz bir şekilde Türkçe karakterleri gösterebiliyor. Tek dezavantajı UTF-8′den anlamıyor. Türkçe yazdırmanız gereken herşeyi iso-8859-9 formatında yazdırmanız gerekiyor. Normalde UTF-8 kodlaması kullandığım için bu durum benim için büyük bir problem olarak karşıma çıktı. Ancak iconv() işlevi yardımıma koştu. Veritabanından okuttuğum tüm UTF-8 içeriğini iconv() ile iso-8859-9′a dönüştürerek FPDF yardımı ile PDF’e yazdırdım.

Basit PDF yazdırma dışında ihtiyacım olan gelişmiş özellikler için ise yine www.fpdf.org‘daki scriptler yardımıma koştu. Her birisinin ayrı ayrı yetenekleri olan onlarca script FPDF’in özelliklerini ve yeteneklerini genişletmektedir. Örneğin çapraz yazı yazmak için Rotation script’i kullanılabilir. Benim amacım çapraz silik yazı yazarak watermark oluşturmak olduğu için Watermark script’i işimi gördü. Bunun yanında PieChart türünde bazı grafikler çizme ihtiyacım olduğu için Sector script’ini de kullandım. Öğretmenlerin sadece çıktı alabilmeleri için PDF Security de uygulama ihtiyacım vardı. Bu nedenle Protection script’ini de projeye dahil ettim.

Üretilen sınav sayfasında her bir sorunun resmi/resimleri ile beraber cevap şıkları da dahil olarak ne kadar yer kaplayacağı önceden bilinemiyor. Bu nedenle oluşturduğum PDF üreteci sınıfın geçici bir instance’ı ile PDF sayfası hazırlıyor ve artan boşluğu hesaplıyorum. Böylece yeni yazılacak olan sorunun ne kadar yer kaplayacağını önceden hesaplamış oluyorum. Buna göre de sayfa yapısında sorular arasında eşit miktara boşluk bırakarak soruların dengeli ve düzenli bir şekilde yerleştirilmesini sağlıyorum. Bu hesaplama bana iki kez PDF oluşturma maliyeti getiriyor. Ancak bu durum bu güne kadar bir performans sorununa neden olmadı.

FPDF’in PDF yazma performansı oldukça yüksek. 5 sayfalık bir PDF’i günümüz için orta güçte olan bir bilgisayarda 0.5 saniyede yazabilmekte. PDF security uygulandığında ise aynı PDF yaklaşık 7 saniyede üretilebilmekte.

FPDF’in oldukça iyi bir dökümantasyonu var. İngilizce sıkıntısı yaşayanlar için dökümantasyonun Türkçe tercümesi Çağlar Ülküderner tarafından yapılmış.

FPDF’i iş başında görmek ve ürettiği sonucu yakından incelemek için sınav üretme demo’sunu http://www.successtosbs.com‘dan gerçekleştirebilirsiniz. Öğretmen Girişi sayfasından Demo Girişi bağına tıklamanız demo kullanıcısı ile oturum açmanız için yeterlidir.

PHP’den PDF üretme ihtiyacı olanlara FPDF’i şiddetle öneririm.

Türkçe karakter sorunlarımız saklama, gösterim, sıralama, büyük – küçük harf dönüşümü gibi kategorilere ayrılabilir. UTF serisi kodlama standartları ile beraber saklama ve gösterim sorunları büyük ölçüde çözülmüştür ve sistemler arası uyumlu hale gelmiştir. UTF standardının yardımı ile eskisi kadar çok Türkçe karakter sorunu ile karşılaşmaz olduk.

Ancak ı ve İ harflerimiz ile ilgili öyle bir sorunumuz var ki, ne yazık ki çözülmesi ile ilgili umudumu kaybetmiş durumdayım. İngiliz i harfinin büyük hali I olmaktayken, Türkçe i harfi’nin büyük hali ise İ olmaktadır. Ancak her iki i harfinin de her kodlama standardındaki sayısal değeri aynıdır. Aslında karakteristik olarak benzer karakterler olsalar da bu özellikleri nedeni ile birbirinden oldukça ayrı karakterlerdir.

Kullandığımız alfabenin Latin ailesinden geliyor olması nedeni ile ne yazık ki tüm yabancı isimler orijinal hali ile yazılarak kullanılmaktadır. Örneğin Linux ismi, Linüks değil de Linux olarak yazılmaktadır. Bu metni Türkçe olarak büyütürsek LİNUX, İngilizce olarak büyütürsek LINUX olarak yazılmaktadır. Ancak orijinalini yazma eğilimimiz olduğu için LINUX olanını kullanırız. Bu durum tüm kuralları alt üst etmektedir. Bu, bizim dilimizde bir metnin bir bütün olarak Türkçe olması söz konusu olamayacağı anlamına gelmektedir. Örneğin bu cümle Türkçe olarak yazıldı, ama içindeki Linux özel ismi Türkçe değildir ve büyük hali de LINUX‘tur.

Bu durum nedeni ile özellikle ana dili Türkçe olmayan geliştiriciler tarafından geliştirilmiş olan (tüm yabancı menşeyli yazılımlar bu kategoridedir) yazılımlarda Türkçe karakter sorunu bulunmaktadır.

Örneğin; PostgreSQL’in Türkçe sıralama ve harf küçültüp büyütme yapabilmesi için dil seçimi ile ilgili tüm çevre değişkenlerinin tr_TR olarak kurulu olması ihtiyacı bulunmakta. Ancak aynı PostgreSQL’in sunucu süreçleri İngilizce dili olarak kurulmuş olan çevre değişkenli bir ortamdan başlatılmaktadır. SQL cümleciklerinin özel kelimelerinin tamamı standart tanım gereği İngiliz dili ile ifade edilen kelimeler (INSERT, INTO, INDEX, …) olması ve küçük büyük harf ayrımı yapılmaması gerektiği belirtilmiş durumda. PostgreSQL küçük büyük harf ayrımını yapmamak için hepsini küçük harfe dönüştürerek bir yapıda tutmakta ve kullanıcının girdiği SQL cümleciklerinin SQL özel kelimelerini de küçülterek bunlarla karşılaştırmakta. Ancak kendi içinde tuttuğu yapı insert, into, index iken kullanıcının girdisi ınsert, ınto, ındex’e dönüştürülmekte. Bu nedenle büyük harflerle yazılmış SQL sorguları işletilememekteydi. Yıllar önce bu sorunu fark edip PostgreSQL geliştiricileri ile paylaştım. Yerel ayarlardan etkilenen bir küçültme işevi olan tolower()’ı kullanmamalarını, özellikle İngilizce küçültme yapan ayrı bir işlev kullanmalarını rica ettim. Beni kırmayıp, sorunu güzelce anlayıp 3-4 günde çözüm getirdiler ve bir sonraki sürümde bu yamanın dahil olacağını ilettiler.

Aynı sorun PHP’de de var. Tamamiyle İngilizce harflerden oluşabilen PHP fonksiyon isimleri ne yazık ki aynı hataya düşülerek yerel dil duyarlı bir işlevle küçültülmeye çalışılmaktadır. Sonuç PostgreSQL ile aynı olmaktadır. PHP geliştiricilerine de hata raporu ilettim. Ancak bu durumu 2003 yılından beri biliyoruz deyip gene çözüm sağlamamayı yeğlediler. Ben her defasında hazırlamış olduğum bu yamayı kullanarak yeniden PHP derlemek zorunda kalıyorum.

Aynı sorun ne yazık ki Java’da da var. Ingilizce olması gereken ifadeler Türkçe yerel dil ayarlı ortamda bambaşka bir hal almakta. Özellikle içinde i ya da I harfleri bulunuyorsa. Karşılaştırmalar çalışmamakta, Bean’lerin setter veya getter methodları bulunamamakta.

Önceleri UNIX’in libc kütüphanesini tasarlayanları suçladım. Yerel duyarlı tolower() / toupper() işlevini geliştiren zihniyet, sadece İngilizce olabilecek olan ifadelerin küçük büyük harf ayrımı yapılmaksızın her yerel dil ayarı altında karşılaştırılabilmeleri için tolower_english() ve toupper_english() sürümlerini hazırlamaz mı hiç? Ancak işin ayrıntılarına inince bu da çözüm sağlamıyor. Lütfen okumaya devam ediniz.

Bu savaşı devam ettirdik ve Türkçe bilmeyen geliştiricileri yola getirdik diyelim. Bu sefer de hem Türkçe hem İngilizce olabilecek olan veri türleri ile ilgili sorunlarımız var. Örneğin bir kullanıcı doğrulama sürecinde ad ve soyad bilgilerini kullandığımızı düşünelim. Küçük ve büyük harf ayrımı da yapmadığımızı düşünelim.

ismail -> İSMAİL (Türkçe bir isim olan İsmail’in doğal dilinde büyütülmesi)
michael -> MICHAEL (Yabancı bir isim olan Michael’in doğal dilinde büyütülmesi)

Uygulamanızı kullanan hem Türk hem de yabancı kullanıcılar olduğunu düşünün. Türk olan kullanıcı ismail, İsmail, İSMAİL gibi verileri girecektir. Ancak yabancı olan kullanıcı Michael, MICHAEL olarak girecektir. Buna göre siz hangi dilde küçültme veya büyütme yaparak karşılaştırmaya sokacaksınız? Ülkemizin köklü bankalarından İş Bankası bu sorunu i ve ı’yı aynı harf kategorisine koyarak çözmüş. “sezai, SEZAİ, sezaı, SEZAI” bu girdilerin hepsi de Türkçe olan Sezai ismini doğrulamaktadır. Benzer şekilde “michael, MİCHAEL, MICHAEL, mıchael” girdilerinin hepsi de yabancı olan Michael ismini doğrulamaktadır. Bu yaklaşım sistemi çalışır duruma getiriyor, günü kurtarıyor olsa da kesinlike doğru çözüm değildir. Yanlış ifadeler doğru gibi kabul edilmektedir.

Ben bu ı ve İ sorunundan bıkmış durumdayım. Ama ne yazık ki çözüm yolu yok. Türkçe i harfini kodlama standardında İngiliz i harfinden ayrı tutsak bu sefer şekil olarak aynı oldukları için karışacaklar. Sırf bu sorunu çözmek için alfabemizi de değiştiremeyeceğimize göre bu sorunla yaşamaya devam edeceğiz. Yanlış da olsa İş Bankası’nın uyguladığı yöntem, sistemi çalışır tutan tek yöntem gibi göründüğü için ben olsam hiç beğenmesem de aynı yöntemi uygulardım.