problem v pfb verzich CSfontu?

[Petr Olsak]

On Mon, 19 Apr 2004, Petr Olsak wrote:

> Vazeni kolegove,
>
> na ftp://math.feld.cvut.cz/pub/olsak/tmp/sf.pdf jsem umistil
> PDF, ktere mi zaslal jeden kolega z Polska (jeho dopis pripojuji nize).
> Vypada to jako bugreport na pfb verze CSfontu.
>
> Pismena vzhledem k akcentum jsou zcela ulitla. PDF bylo generovano
> Adobe Distillerem 5.0.

Vazeni kolegove,

pokusim se vysvetlit technicke pozadi problemu (aby pripadne vlastnici
Adobe Distileru mohli uvazovat o reklamaci) a naznacit mozne reseni.
Omlouvam se, ze je muj e-mail ponekud delsi.

Predevsim: z Vasich odpovedi je mi jasne, proc se bugreport neobjevil
drive, kdyz uz fonty mnoho let pouzivame. Je to vlastnost az noveho
Acrobat Distileru 5.0, predchozi verze se chybne neprojevovaly.

Mam zkusenost s Acrobat Readerem, ze napr. az od verze 5.0 zacal
interpretovat ve fontu udaj BlueScale, predchozi verze si jej nevsimaly.
Ve Stormove DynaGrotesku byl tento udaj zcela ujety a ja jsem se dlouho
divil, proc az od verze AcroReaderu 5 se zacal na Dynagrotesku projevovat
naspravny hinting. Ukazalo se, ze za to mohou Stormovy fonty a ne
skutecnost, ze AcroRead od verze 5 implementuje cteni BlueScale,
zatimco ve starsich verzich si tohoto udaje nevsimal.

Je tedy potreba k problemu pristupovat velmi citlive a konzultovat to
s referencnim manualem "Adobe Type1 font format". V kazdem pripade je mi
zahadou, proc se Distiler rype ve vnitrnostech fontu a zjevne je
pregenerovava znovu (a chybne). Vzdyt to prece nema v popisu prace!
Neda se tato jeho vlastnost vypnout nejakym parametrem? Ja osobne Adobe
Distilery nepouzivam, nemam je a tudiz s nimi nemohu experimentovat.

Podivejme se nyni do vnitrnosti fontu csr10.pfb. Zamerme se napr. na znak
Zcaron (pro ostatni to je podobne). V CharString procedure je

...
-164 hmoveto % posunuti, aby akcent vysel na stred
25 callsubr  % procedura, ktera vykresli akcent
             % a vrati currentpoint do puvodni polohy
175 hmoveto  % posunuti curretpointu v vychozimu bodu kresby
476 hlineto  % zahajeni kresby pismene Z
...

Pro srovnani, samotne Z vypada takto:

...
11 hmoveto   % posunuti curretpointu v vychozimu bodu kresby
476 hlineto  % zahajeni kresby pismene Z
...

Je videt, ze skutecne vychazi -164 + 175 = 11.
Procedura 25 vypada takto:

262 822 rmoveto   % posunuti k vychozimu bodu kresby
151 -117 rlineto  % zahajeni kresby hacku
...
-140 66 rlineto   % konec kresby hacku
closepath
-274 -838 rmoveto % navrat currentpointu do vychozi pozice
return

Skutecnost, ze 262 822 neni presne to same jako -( -274 -838 )
vychazi z toho, ze Type1 closepath (na rozdil od PostScriptoveho
closepath) neposunuje s bodem kresby -- skutecne, tato zrudnost je
dokumentovana a funguje. Pri navratu do vychozi pozice je tedy zahrnut
jeste posun bodu zpet k vychozimu bodu kresby.

Kdyz se podivam, jak pismenka vypadaji ve vystupu z Distileru 5,
pak soudim, ze -274 -838 rmoveto uvnitr procedury 25 bylo totalne
ignorovano a pouzilo se az nasledujici 175 hmoveto v hlavnim programu.

V Adobe Type1 font format se na strane 31 (4.3 Conciseness) pravi, ze

> In general, find the smallest sequence of commands that accuratelly
> describe the character shape.

Prosel jsem i dalsi partie dokumentace (ale jen zbezne) a nenasel jine
misto, kde by CSfonty mohly narazit. V CSfontech ale skutecne neni pouzita
nejmensi sekvence prikazu, protoze dvakrat za sebou jdouci rmoveto (jednou
v procedure a jednou v hlavnim pogramu) by se teoreticky dalo nahradit
jedinym rmoveto. Citovanou veticku jsem vzdycky chapal jako doporuceni,
docela vagne formulovane (protoze nevime, zda pouzivani procedur z tohoto
pohledu zmensuje pocet prikazu a pokud jo, pak se da matematicky docela
obtizne najit nejmensi pocet prikazu).

Pokud tedy bude nekdo chtit reklamovat Adobe Distiler 5, mel by si pozorne
prostudovat "Adobe Type1 font format" a jit do sporu s jasnou predstavou,
kde je chyba. Ja tu predstavu osobne moc jasnou nemam.

A nyni k reseni problemu. Budeme muset nejakou chvili vydrzet s timto
problemem, dokud neudelam zasadni zmenu v CSfontech. To bude nejdrive o
prazdninach. Jedna moznost je pozadat Polaky, aby nam pregenerovali
CSfonty pomoci jejich MetaType1. Skutecne, pan Nowacki mi obratem poslal
pregenerovany csr10.pfb, ktery vypadal hodne dobre (byl dokonce mensi nez
muj original) a s nestastnym Distilerem 5 pry fungoval.

Dalsi moznosti je prejit na LM (Latin Modern) fonty, o nez se take staraji
Polaci. Po CSfontech zustaly pak jen metriky a v mapovacich soborech
bychom odkazovali na LM fonty. Puvodni Metafontove zdroje CSfontu bychom
odstehovali do muzea.

Tato moznost vyzaduje, abychom se shodli na tvaru hacku, carek a krouzku,
aby tyto akcenty vypadaly co nejpodobneji jako v puvodnich CSfontech.
Dale se musi zcela shodovat metrika pfb LM fontu (tj. sirky znaku) s tfm
metrikami csfontu. To pro vetsinu znaku neni problem, citlive jsou jen
znaky tcaron, lcaron a hlavne dcaron. Protoze tyto znaky jsou pouzivany
jen v cestine a slovenstine, nemel by byt problem uhadat metriky techto
znaku presne podle CSfontu.

Protoze LM fonty delaji Polaci, vyuziju sve cesty na jejich BachoTeX,
abych s nimi tyto problemy probral a dam vedet vysledek.

Zdravim

Petr Olsak