BUG in CSfonts: uppercase acute depends on resolution

[Petr Olsak]

On Thu, 1 Dec 2005, Karel Piska wrote:

>   Nicmene, vratme se k CSfontum.
>
>     BUG REPORT  1 Dec 2005
>   V METAFONTove verzi CSfontu neni dobre carka pro velka
> pismena (jeden ze zakladnich akcentu). Tvar techto carek
> totiz zalezi na zarizeni (mode) a jeho rozliseni,
> jak napr. ukazuji obrazky pro \'A ve fontech csr10 a csbx10.

Dekuji za upozorneni na chybu. Prosel jsem ty MF zdrojaky a zjistil jsem,
ze ackoli chyba vypada na prvni pohled hruzostrasne, font pri beznych
rozlisenich pracuje spravne. Podrobne to vysvetlim nize. Na zaklade teto
skutecnosti jsem se rozhodl nezverejnovat okamzite verzi MF zdrojaku
CSfontu s opravou, ale pockat na pripadne dalsi namety a zverejnit novou
verzi (opravujici chyby)  na zacatku pristiho roku.

Zjistil jsem, ze ve zdrojacich je v tom citlivem miste v pripade
obracene carky (grave) nad verzalkou oprava provedena s poznamkou:
"Corrected by P.O, 6.97", tj. uz jsem to opravoval v roce 1997.
Nejak jsem se v te dobe nepodival, ze tentyz kostlivec, jaky byl
u obracene carky, ceka na svou prilezitost i u normalni carky :-(.

Technicky rozbor chyby:

Skutecne, v miste, kde ma byt uveden rozmer zavisly na rozliseni je misto
toho podil dvou promennych zavislych na rozliseni, cimz vznika vysledek
nezavisly na rozliseni, takze to nakonec cele na rozliseni zavisle je
(kdo nezna filosofii MF, mozna trochu nechape:-). Podrobneji, pracuje se
s promennymi stem a stem_corr, ktere jsou v jednotkach pixelu a v miste,
kde se ma pero posunovat v jednotkach pixelu je uveden jejich podil. Jeste
presneji, je tam uveden magicky vzorec (nevim, ktery chytrak takovou
silenost vymyslel):

stem / max(1, 3/4 stem_corr)

Kdyz je tedy (v jednotkach pixelu) stem_corr < 4/3, deli se na danem miste
jednickou a vysledek je roven stem, tj. hodnota je (spravne) v jednotkach
pixelu. Pritom stem_corr je v csr* fontech roven 1/36pt, takze az po
rozliseni 2600dpi vychazi tento podil jako stem a to je spravne. Pro vyssi
rozliseni nez 2600dpi vychazi ale stem_corr > 4/3, takze se pracuje
s podilem 4/3 stem / stem_corr, coz jednak s sebou skubne (je tam
nespojitost) a druhak dostavame vyraz nezavisly na rozliseni, coz je
spatne. V pripade fontu csbx12 a csbx10 navic je stem_corr = 2/36pt, takze
to citlive rozhrani je uz pri rozliseni 1300dpi. Shrnuti:

pro csr17, 12, 10, 9, 8 je  stem_corr = 1/36pt, tj.:
          pri rozliseni do 2600 to funguje, pro vyssi rozliseni ne
pro csbx12, 10, csb10, csbxsl10 je stem_corr = 2/36pt, tj.:
          pri rozliseni do 1300 to funguje, pak uz ne.
pro ostatni fonty typu csr* je stem_corr mirne mensi nez 1/36pt
a pro ostatni fonty csbx* je stem_corr mirne mensi nez 2/36pt, takze si
kazdy muze za domaci cviceni pro tyto fonty spocitat, az po ktere
rozliseni to bude fungovat.

Zaver: protoze se bezne pouzivaji rozliseni 600 dpi a 1200 dpi, chyba neni
fatalni. Na druhe strane je to chyba docela zaludna a hloupa. Kdo
potrebuje generovat fonty s vyssim rozlisenim hned, muze si sam opravit
chybu v souboru csaccent.mf, kde na radku 234 je treba vyraz
stem/max(1,3/4stem_corr) nahradit vyrazem stem.

V pristim roce zverejnim opravenou verzi.

Zdravim

Petr Olsak