ugrás a tartalomhoz

Nem kalapos ő, ű használata DOMPdf-ben

gabesz666 · 2011. Ápr. 12. (K), 19.15
Sziasztok!

Nemrégiben találtam egy egészen jó PDF generáló lib-et, DOMPdf a neve. A probléma vele csupán annyi, hogy az ő és ű karakterek nem kalapos verzióját (double acute) nem tudom belegenerálni a PDF-be (vagy ? vagy a szokásos összevissza karakterek). Amivel eddig próbálkoztam, de nem segített:

  • Html entitásokra cserélni a megfelelő karaktereket
  • iconv, mb_convert, utf8_encode függvények segítségével a forrás html encode-olása
  • Windows-os font készletből Verdana átkódolása afm formátumba mind utf-8, mind iso-8859-2 encoding-al
  • (meta content-type tag megadása a forrás html-ben)


Bármilyen ötletet szívesen fogadok. Köszönöm a válaszokat!
‹ PHP rendezés a webshopra PHP kilistázás, részletesen ›
 ■
1

Senki sem gondol ránk magyarokra...

nova76 · 2011. Ápr. 14. (Cs), 09.45
Én is itt járok épp a dompdfel :-)

De már próbáltam egyéb pdf osztályokat is:

dompdf és az mpdf aránylag tűrhetően generálja le a html-t, de alapból egyik sem tüd nem kalapos ű és ő betüt. Talán az mpdf még jobb is egy fokkal.

A TCPDF freeserif font esetén tudja a karaktereinket, azonban azzal a fonttal olyan lassú, hogy használhatatlan. Ráadásul a HTML átalakítása is elég siralmas.

Az FPDF tudja az ő és ű betűket, vagy legalábbis nekem sikerült egy arial font készletet generálnom az ott leírtakkal. Csak hát a 4 közül ennek a legsiralmasabb a HTML átalakítása.

Mintha azt olvastam volna hogy az mpdfet a tcpdfből javították/fejlesztették tovább. Úgyhogy most ezen az úton fogok tovább haladni, hacsak nem előzöl be :-) De egyelőre leálltam vele, mert jó nekem az a kalapos ü és ö, amíg nincs jobb...
2

Semmi fejlemény

gabesz666 · 2011. Ápr. 14. (Cs), 11.59
Sajnos nem haladtam előre, pedig az egész kódját áttúrtam már, de túlságosan összetett. Az a gond, hogy egyenlőre azt sem tudom, hogy az afm fájl nem támogatja a megadott karaktereket vagy a php részen romlik el. Illetve amit észrevettem, hogy a CPDF classban jópár helyen utf8_decode függvényt használ.

Egyenlőre úgy tűnik, hogy lecserélem a dompdf-et fpdf-re (+tfpdf script, amivel támogatja az utf-8-at), csakhát mire újraírom az egész generálót... :S

TCPDF-et használtam egy ideig, de kegyetlenül lassú (kb. 30 másodpercig tartott neki egy egyoldalas pdf generálása).
3

Mi a tFPDF-et használjuk, ami

Hidvégi Gábor · 2011. Ápr. 14. (Cs), 13.03
Mi a tFPDF-et használjuk, ami az FPDF-re alapul, de ismeri az UTF8-at. A sima FPDF-fel nem sikerült rendes ékezeteket varázsolnom, mert az csak a Latin 1-et ismeri.

A(z) (t)FPDF kódját érdemes megnézni, kitűnő példa arra, "ahogy ne" programozzunk, rövid, semmitmondó változónevek, átláthatatlan sorok stb.
4

TCPDF + freeserif a lassú

nova76 · 2011. Ápr. 15. (P), 10.46
Csak a freeseriffel olyan lassú. De csak annál van nem kalapos ő és ű. És ami nagyon rossz a TCPDF-ben, hogy nem igazán tudsz htmlben szerkeszteni benne. Mert ami HTML-ben jól néz ki, az még megközelítőleg sem olyan PDF-ben.
5

Nincs más

gabesz666 · 2011. Ápr. 16. (Szo), 17.30
Nincs más választás, kell írni egy DOMPdf-hez hasonló lib-et, ami kezeli a html-t és az utf-8-at is rendesen :)