Portál AbcLinuxu, 26. července 2025 14:45
% obdelnicek n 7290 2880 m 9180 2880 l gs col0 s gr % text /Helvetica ff 240.00 scf sf 2340 2790 m gs 1 -1 sc (Ahoj svete) col0 sh grProblém je ten, pokud je v obrázku takto čeština musíš mít k dispozici kódový vektor a písmo, které znaky umí. Potom to tedy vypadá nějak následovně:
/isovec [ 8#055 /minus 8#200 /grave 8#201 /acute 8#202 /circumflex 8#203 /tilde ... ] def /Helvetica /Helvetica-iso isovec ReEncode /Helvetica-iso ff 240.00 scf sf 2340 2790 m gs 1 -1 sc (Ahoj sv\xxxte) col0 sh grTo je pravděpodobně náš případ. Zde je problém ten, že pokud to prohlédneš v AR tak ten se podívá na dokument, z vektoru podle čísla xxx zjistí, že má použít znak ecaron, vezme si font Helvetica, zjisí že v něm požadovaný znak není, zobrazí .notdef znak což je v Type1 nic. AR7 si nevezme Helveticu ale Myriad Pro, který už znak ě obsahuje a zobrazí ho. Pokud chceš zobrazit všechno korektně i v AR5, musíš do epska vložit písmo, které obsahuje české znaky a patřičně psko upravit. Tedy v našem příkladě nějak:
... /FontName /NimbusSanL-Regu def % definice pisma (z .pfa) ... FontName currentdict end definefont pop /NimbusSanL-Regu /NimbusSanL-Regu-iso isovec ReEncode /NimbuSanL-Regu-iso ff 240.00 scf sf 2340 2790 m gs 1 -1 sc (Ahoj sv\xxxte) col0 sh grPak už to zobrazí korektně i AR5, který se podívá, zjistí z vektoru že má použít znak ecaron, podívá se do písma které je vhozené přímo v obrázku, tam ho najde a zobrazí ě. Jednoduché, ne?
epstopdf
a každému se chová jinak. Pro srovnání, mně to robí automaticky. Jediné co mě napadá je rozdílná verze nebo konfigurace GhostScriptu. Jen tak pro jistotu, ke GhostScriptu máš instalována i česká písma (např. /usr/share/ghostscript/fonts/n019003l.*
)? A pokud se podíváš do zmíněného souboru .afm uvidíš tam něco jako:StartFontMetrics 3.0 Comment Copyright (URW)++,Copyright 1999 by (URW)++ Design & Development Comment Creation Date: 12/22/1999 Comment See the file COPYING (GNU General Public License) for license conditions . FontName NimbusSanL-Regu FullName Nimbus Sans L Regular FamilyName Nimbus Sans L ... C -1 ; WX 500 ; N ccaron ; B 31 -23 477 741 ; ...nebo ne? Jinak se ted divám, že to lze ovlivnit volbama v ghostscriptu, teoreticky pokud bys měl optimalizaci pro sazbu či tisk tak to subsetuje, pokud pro obrazovku tak je nesubsetuje. Zkus epstopdf pustit s volbou -d a uvidíš co pouští za příkaz. Ale opravdu je divné, že různé verze ghostscriptu se chovají jinak.
* Input filename: dig_popis_dat.eps
* BoundingBox comment: %%BoundingBox:
* Output filename: dig_popis_dat.pdf
* Ghostscript command: gs
* Compression: on
* Ghostscript pipe: gs -q -sDEVICE=pdfwrite -dAutoRotatePages=/None "-sOutputFile=dig_popis_dat.pdf" - -c quit
* Scanning header for BoundingBox
* Old BoundingBox: 0 0 648 288
* New BoundingBox: 0 0 648 288
* Offset: 0 0
* Ready.
Mrknu se na gs, jeste jednou dik. Martin
pfb2pfa pismo.pfb
což bys pustil na NimbusL-Regu a NimbusL-Bold z gs. Tím bys získal soubory .pfa, které pak můžeš v klidu vložit např. před část % begin encoding
a změnil bys jim v jejich hlavičce jména z NimbusSanL-Regu a NimbusSanL-Bold na Helvetica a Helvetica-Bold a pak by ti to fungovalo také. Možná by ten výsledný pdf soubor byl zbytečně velký, ale co už.epstopdf -d -nogs vstup.eps | gs -q -sDEVICE=pdfwrite \ -dCompatibility=1.3 -dPDFSETTINGS=/prepress \ -sOutputFile=vystup.pdf -c -a pak by se snad všechny verze GhostScriptu měly chovat správně tak jak mají, přestože písma vkládá jak printer a prepress tak i default (alespoň jsem tak zvyklý ze sedmičky)...
-dCompatibility=1.3 -dPDFSETTINGS=/prepress
tento problem resi... (alespon pro dvipdf, nikoliv pro dvips->ps2pdf)
Martin
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.