Arapça يوضح ملف PDF ifadesini TextOut çağrısına verin ve sonucu açın. Harfler ters yönde ilerler ve her biri, sanki biri İngilizceyi tersten yazıp her karakterin arasına boşluk koymuş gibi, sonrakiyle arasında görünür bir boşlukla yalıtılmış biçiminde durur. Hiçbir istisna oluşmadı. Hiçbir uyarı basılmadı. Çıktı basitçe yanlıştır ve yanlıştır çünkü Arapçanın bağlı olduğu iki ayrı dönüşüm hiç gerçekleşmemiştir. Bu iki dönüşümün ne olduğunu ve hangi çağrının onları yaptığını bilmek, karmaşık yazı sistemli PDF çıktısının neredeyse tamamıdır
HotPDF, Delphi ve C++Builder için yerel bir VCL PDF bileşenidir ve sağdan sola işini ayrı bir çağrı üzerinden sizin yerinize yapar. Ayrıca bir yerel ayara bağlanmadan önce bilmek isteyeceğiniz birkaç belirli noktada da durur; bu yüzden bu yazı kavramları ve dürüst sınırları haritalar, çağrının kendisine dair uygulamalı kurulum ise RtLTextOut başvuru yazısında yer alır
Doğru bir dize neden hâlâ yanlış basılır
Unicode metni mantıksal sırada, yani yazdığınız ve sesli okuduğunuz sırada tutar. Bir işleyici ise glifleri görsel sırada yerleştirmek zorundadır. Soldan sağa yazı sistemlerinde bu iki sıra çakışır ve kimse bunu düşünmez. Arapça ve İbranice için çakışmaz; tek bir satır yönleri karıştırdığında, örneğin "PDF" Latin belirtecini ya da rakamlarla yazılmış bir fiyatı taşıyan bir Arapça cümlede, Unicode Çift Yönlü Algoritması (UAX #9) soldan sağa parçaların sağdan sola satırın içine tam olarak nasıl yerleşeceğine karar verir. Birinci dönüşüm budur, yani yeniden sıralama, ve satırı ters çeviren şey bunun atlanmasıdır
İkincisi bağlamsal şekillendirmedir. Bir Arap harfi, sözcük içinde nereye düştüğüne göre farklı çizilir: başta, ortada, sonda ya da tek başına. Kod noktası boyunca aynı kalır; yalnızca glif değişir. Her kod noktasını doğrudan varsayılan glifine veren bir işlem hattı, tam olarak giriş paragrafındaki kopuk, yalıtılmış biçimli çıktıyı üretir. İbranice bu adımı atlar, çünkü harfleri bitişmez, ama yine de yeniden sıralamaya ihtiyaç duyar. Arapça ikisini de ister ve test ettiğiniz dizenin İbranice değil Arapça olmasının nedeni budur
Masaüstünde bunların hiçbiri sizin sorununuz değildir. Bir VCL formu bir TEdit içine Arapça boyadığında, işletim sisteminin metin yığını onu sessizce yeniden sıralar ve şekillendirir; ekranda kusursuz görünen dizenin naif bir PDF içinde bozuk çıkmasının nedeni tam olarak budur. Bir içerik akışı düzenlenebilir metin saklamaz. Konumlandırılmış glifler saklar, dolayısıyla akışı kim üretiyorsa eskiden işletim sisteminin üstlendiği şekillendirme işini devralır. RtLTextOut, o işi geri alan çağrıdır
RtLTextOut sizin için neyi şekillendirir
HotPDF, Latin yolunu ve karmaşık yazı sistemi yolunu iki ayrı yöntem olarak tutar. TextOut, ona verdiğinizi verdiğiniz sırayla basar. RtLTextOut ise önce her iki dönüşümü de uygular — satırın tamamında çift yönlü yeniden sıralama, bitişen yazı sistemleri için bağlamsal çözümleme — ve sonra basar. Hangi yazı sisteminin kurallarının geçerli olacağı çağrının kendisiyle değil, fontun karakter kümesiyle içeri taşınır; böylece yön, karakterlerden yapılan bir tahmin yerine her çağrı noktasında açık bir tercihtir. Parametre parametre kurulum, karakter kümesi değerleri, font kaydı adımları ve derlenebilir eksiksiz bir örnek RtLTextOut başvuru yazısında bulunur; bu yazı dönüşümlerin ne anlama geldiğinde, nerede durduklarında ve işe yaradıklarının nasıl kanıtlanacağında kalır
Bu yükseklikte bile önemli olan tek bir kullanım kuralı vardır: girdi mantıksal sırada olmalıdır, çünkü ters çevirmeyi RtLTextOut kendisi yapar ve elinizle önceden çevirdiğiniz bir dize iki kez ters çevrilmiş olarak çıkar — başvuru yazısı bu tuzağı ve temizliğini adım adım anlatır. Tuzağın burada anılmayı hak etmesinin nedeni, testten sağ çıkmasıdır. İki kez ters çevrilmiş saf Arapça bir dize kusursuz görünebilir ve ancak satır bir Latin sözcük ya da sayı taşıdığında dağılır, çünkü o gömülü kesimler artık UAX #9 kuralına göre yerleşmez. Hata işlemede değildir; algoritmaya zaten yarı işlenmiş metin verilmesindedir
Aynı karışık yön davranışı, kodu tökezlettiğinden çok gözden geçirenleri tökezletir. Sağdan sola bir satırın içinde rakamlar ve gömülü Latin sözcükler yine soldan sağa okunur. Çift yönlü düzenle çalışmamış biri, işlenmiş bir faturaya bakar, hesap numarasının çevresindeki Arapçaya göre "yanlış" yönde okunduğunu görür ve bunu bir hata olarak yazar. Oysa bu, belirtime uygun sonuçtur. Kabul ölçütlerinize, ana dili konuşan ilk gözden geçirmeden önce yazılmış kısa bir not koymak size bu gidiş gelişi kazandırır
Yeniden sıralama ile bitişmenin yettiği ve yetmediği yerler
Arapça ve İbranice akan metin için — raporlar, faturalar, sözleşmeler, mektuplar — yeniden sıralama artı bağlamsal bitişme işin tamamıdır ve RtLTextOut bunu tek başına taşır. Sınır, tipografi bitişmeden fazlasını istediğinde belirir. HotPDF'in Arapça tarafındaki yanıtı, isteğe bağlı olarak açılan üretici tarafı bir şekillendiricidir: AutoShapeArabic := True ayarlayın; bileşen mantıksal sıradaki kesimi çift yönlü geçişten önce Unicode Sunum Biçimlerine yeniden yazar, böylece bitişme biçimleri mantıksal komşulara göre hesaplanır ve bitişik harf katlamaları, bir görüntüleyicinin çözmesine bırakılmak yerine PDF dosyasının gerçekten taşıdığı kod noktalarına gömülür. Anahtar varsayılan olarak kapalıdır ve kapalı kaldığı sürece çıktı bayt düzeyinde kararlıdır; dolayısıyla onu açmak genel bir yükseltme değil, belge işlem hattı başına bilinçli bir karardır. Aynı isteğe bağlı model, HotPDF'in şekillendirdiği diğer bitişen sağdan sola yazı sistemlerine de uzanır: Süryanice, N'Ko, Adlam ve Hanifi Rohingya yazılarının her birinin, Arapça olanı yansıtan kendi otomatik şekillendirme bayrağı vardır
İsteğe bağlı OpenType özellikleri ise yine başka bir mekanizmadır. İsteğe bağlı bitişik harfler ve benzeri tekli değiştirme özellikleri, tek seferde bir değiştirme çözen — önce girdi glif kimliği, sonra özellik etiketi — ve özellik geçerli olmadığında girdi glifini değiştirmeden döndüren GetSingleSubstituteGlyph(GID, 'liga') üzerinden geçer. Bu, kendi tuttuğunuz bilinen ve sonlu bir bitişik harf listesini sürmeye yeter. Tam bir GSUB motoru değildir ve iddialı yerel ayar planlarının yanlışa saptığı yer tam olarak bu farktır: Arapçayı kusursuz işleyen bir şekillendirme hattı yeniden sıralama ile bitişmeyi kanıtlamıştır, fazlasını değil
Yazı sistemleri arasında kapsam
Arapça her iki dönüşümü de çalıştırır; test edilecek dizenin o olmasının ve bir Arapça geçişinin işlem hattının çalıştığına dair en güçlü tek kanıt olmasının nedeni budur. İbranice yeniden sıralamaya ihtiyaç duyar ama bitişmeye duymaz, çünkü harfleri tek başına durur; İbranice doğru işlenirken Arapça kopuk çıkıyorsa çift yönlü yarı sağlamdır ve bağlamsal yarı hiç çalışmamıştır. Farsça ve Urduca Arap yazısını kullanır ve davranışını devralır; ancak Urducanın Nastaliq biçemine olan eğilimi, okunabilirlik sonuçlarını ana dili konuşan birinin değerlendirmesi gereken bir font kararıdır
Tayca ise sınırın tümüyle öbür tarafında durur. Soldan sağa akar, dolayısıyla çift yönlü işe ihtiyaç duymaz ve harfleri bitişmez, dolayısıyla bağlamsal çözümlemeye de ihtiyaç duymaz; Tayca dizeler Latin gibi sıradan TextOut yolundan geçer. Taycanın sahip olduğu şey üst üste binen işaretlerdir — temel ünsüzün üstündeki ve altındaki ünlüler ve ton işaretleri — ve bunların doğru oturup oturmaması, fontun birleşen işaretlerini şekillendirme motorunun yardımı olmadan yığılacak biçimde kurmasına bağlıdır. Taycaya adanmış fontların çoğu bunu yapar. Benzerini değil, gömeceğiniz fontun tam olarak kendisiyle test edin
Devanagari ve Hint ailesinin geri kalanı dürüst bir tam durak noktasıdır. Ünlü işaretleri ünsüz kümelerinin çevresinde yeniden sıralanır ve birleşik harfleri bağlama bağlı değiştirme zincirleriyle oluşur; bu, yeniden sıralama ve bitişmenin ötesinde, tam GSUB alanıdır. Yol haritasında bir Hint yerel ayarı varsa, söz vermeden önce gerçek müşteri dizeleriyle gerçek bir pilot çalıştırın — Arapçanın çalışması Devanagari için kanıt değildir. CJK dizeleri, üst üste binen aksanlarıyla Vietnamca ve karışık Avrupa metni sıradan yoldan, çift yönlü çözümleme olmadan geçer; iki yolu rapor kodunda fiziksel olarak ayrı tutmak da işe yarar: RTL kesimler için bir yordam, geri kalan her şey için bir başkası; böylece yerel ayar mantığı, birinin ayarlamayı unuttuğu bir bayrağın arkasında gizlenmek yerine çağrı noktasında görünür olur
Glif kapsamı, şekillendirme daha çalışmadan belirlenir
Şekillendirme glifleri bir fonttan seçer. Font onları taşımıyorsa seçilecek bir şey yoktur; klasik dağıtım başarısızlığının — geliştiricinin makinesinde kusursuz, sessiz bir font ikamesinin ardından müşterinin sunucusunda boş kutular — bir şekillendirme sorunu değil, bir kapsam sorunu olmasının nedeni budur. Pratik çare, bir makinede kurulu olana güvenmek yerine kendi gönderdiğiniz bir fontu kaydetmektir ve bu, başvuru yazısında adım adım anlatılır. Kavramsal nokta şudur: herhangi bir şekillendirme sorusu anlam kazanmadan önce kapsamın kurulmuş olması gerekir ve bu, çıktıya gözle bakarak değil, programlı olarak kurulabilir
// RegisterUnicodeTTF sonrasında verinizin gerçekten kullandığı
// kod noktaları için kapsamı denetleyin
GID := Pdf.GetUnicodeGlyphForCodepoint($0628); // U+0628 ARABIC LETTER BEH
LogGlyphAudit($0628, GID);Kaydın kendisi iki kısıt taşır — gömülü Unicode işleme için PDF 1.5 alt sınırı ve fontun gömme izni bitleri — ve ikisi de kurulum adımlarıyla birlikte RtLTextOut başvuru yazısında ele alınır. Buraya ait olan, denetim alışkanlığıdır: GetUnicodeGlyphForCodepoint sizin erken uyarı sisteminizdir. Hizmet başlarken verinizin gerçekten kullandığı kod noktası aralıklarını dolaşın ve hangi glif kimliklerinin döndüğünü günlüğe yazın. Böylece bir kapsam boşluğu, müşteriye çoktan ulaşmış bir faturadaki eksik karakterler olarak değil, yayılım sırasında bir başlatma günlüğündeki satır olarak ortaya çıkar
Okuma sırası gliflere değil belgeye aittir
Her glifi doğru elde etmek yine de bir şeyi eksik bırakır. ISO 32000-1 §12.2, belgenin genel okuma sırasını bildiren /Direction adlı bir görüntüleyici tercihi tanımlar. Hiçbir glife dokunmaz. Yaptığı şey, bir görüntüleyiciye ikili yayılımları nasıl dizeceğini, karşılıklı sayfa düzeninin hangi taraftan başlaması gerektiğini ve okuma arayüzünün hangi yöne yaslanacağını söylemektir. Bunların hiçbiri tek bir sayfada görünmez; unutulmasının nedeni de tam olarak budur
// Belge düzeyinde sağdan sola okuma sırasını bildirin
Pdf.Direction := RightToLeft; // ViewerPreferences içine vpDirection eklerDirection ayarlamak işin tamamıdır: özellik ayarlayıcısı belgenin ViewerPreferences yapısına vpDirection ekler, böylece tek satır tercihi dosyaya taşır. Metin RtLTextOut üzerinden çıkıyorsa bunu bedavaya elde edersiniz, çünkü çağrı yan etki olarak belge yönünü çevirir — karışık bir belgenin bunu geri almasının gerektiği durumu başvuru yazısı ele alır. Bunu kendiniz ayarlamanız gereken durum, başka herhangi bir yolla üretilmiş sağdan sola bir belgedir; örneğin akışın yukarısında önceden şekillendirdiğiniz ve sıradan yoldan çizdiğiniz bir girdi. Onu dışarıda bırakırsanız baktığınız tek sayfalık kanıt her iki durumda da aynı görünür; sonra biri çift taraflı bir kitapçık basar, yayılımlar aynalanmış çıkar ve nedeni haftalar öncesinden eksik kalmış tek satırdır
Şekillendirilmiş çıktıyı doğrulama
Uçtan uca doğrulayın, çünkü bir sayfa doğru görünüp aşağı akıştaki her şey için yine de kullanışsız olabilir. Üç denetim sorunların çoğunu bulur. Metni Acrobat içinden geri kopyalayın ve kod noktalarını kaynak dizenizle karşılaştırın. Sayfada gördüğünüz bir sözcük için görüntüleyicinin belge içi aramasını çalıştırın. Ve çıktıyı, geliştirme fontlarınızın bulunmadığı, ikameyi açığa çıkarma olasılığı en yüksek makinede açın. Bunların hiçbiri, hiçbir yapay derlemin yakalayamayacağı şeyleri yakalayan, gerçek bir belgeye bakan ana dili konuşan bir okuyucunun yerini tutmaz. Biçim yayına çıkmadan önce o incelemeyi takvime koyun
Test dizelerini, geçen yıl bir çevirmenin gönderdiği ne varsa onu yeniden kullanmak yerine bilinçli olarak seçin. Yerel ayar başına işe yarar bir asgari: saf yazı sistemiyle bir cümle, gömülü Latin marka adları içeren bir cümle, rakam ve para birimi taşıyan bir satır ve aksanlı ya da birleşen işaretli adlar. Gerçek müşteri adları, doldurma metninin dokunmadan bıraktığı varsayımları kırar; bu yüzden bir destek kaydı daha önce görmediğiniz bir örüntüyü ortaya çıkardığında regresyon kümesinin bir dize büyümesine izin verin
Font kaydı, alt kümeleme ve gündelik metin çizme API bilgisi HotPDF ile rapor çıktısı, fontlar ve görüntüler üzerine yazıda ele alınmaktadır. Aynı belgelerin erişilebilirlik profillerini de karşılaması gerektiğinde, PDF/A ve PDF/UA doğrulama yazısındaki dil etiketleme ve yapı kuralları buradaki şekillendirme işinin üzerine oturur
Yukarıda anlatılan sağdan sola ve Unicode font API bileşenleri, Delphi ve C++Builder için HotPDF Delphi Bileşeni ile birlikte gelir; ürün sayfası tam metin çıktısı başvurusuna bağlantı verir