dvips

[Cejka Rudolf]

: Tak, a ted se mi opet zda, ze by se s dvips dalo i neco delat. Uvidim.
: Nedival se treba jeste nekdo hloubeji do dvips (dvitomp)?

Po dalsim prochazeni zdrojovek to vidim takto:

*) Dobre, uz nebudu po mpostu chtit, aby pracoval s virtualnimi fonty.
   Konstrukce "..." infont "cmr10" stejne zpusobuje jen problemy. Myslim,
   ze mpost si z tfm vytahuje jen vysku, hloubku a sirku znaku. Kerningy
   ani ligatury jsem v jeho vystupu nevidel. Navic mpost text vubec
   netransformuje a proto se treba misto mezery u cmr10 vysazi skrtatko...
   Ale pokud chceme, aby dvips pracovalo s virtualnimi fonty, pak urcite
   budeme i chtit, aby mpost zpracovaval kratke textove retezce i
   s kerningy a ligaturami (a spravne interpretovanymi mezerami).
   Tj. dokud je to mozne, pouzivejme btex ... etex s externim volanim TeXu.

*) Z uzivatelskeho hlediska je v dvips urcite chyba. Minimalne by se melo
   vypisovat "TeXovske virtualni fonty nejsou ve vkladanych PS souborech
   podporovany". Dvips je totiz postaveno na tom, ze vkladane fonty ve
   vystupu mpostu jsou ve formatu *.tfm. Podporu pro virtualni fonty by
   bylo potreba dopsat.

*) Co vsechno v dvips chybi?

     1) Nekde u volani includechars() by bylo potreba doplnit dalsi
   stavovy automat prochazejici VF znaky, aby byl dvips schopny do
   vysledneho PS souboru ulozit fyzicky tistene znaky. A kdyz si uvedomime,
   co vsechno mohou VF obsahovat (dalsi odkazy na fonty, dalsi specials pro
   vlozeni cehokoli vcetne dalsich vystupu mpostu...), tak me jima hruza.
   Je fakt, ze tento kod je jiz v dvips nekde obsazen, rozhodne by ale
   bylo nutne ho prepsat a upravit. A to nejspis nebude zadna sranda.

     2) Je potreba doplnit dalsi specialni kod, ktery bude umet tisknout
   virtualni znaky. Tj. v pripade virtualniho cmr10 by se do vystupniho PS
   klasickym zpusobem ulozil font csr10 + novy font cmr10, ktery by sve
   znaky neinterpretoval jako bitmapy, ale jako mikro-dvi definice odkazujici
   se na fyzicke znaky... A tohle se mi zda jeste hure implementovatelne,
   nez predchozi bod.

     Mozna by se mohlo zdat, ze druhy bod by slo obejit tak, ze by dvips
   prevadelo prikazy "(Text) ... fshow" na kod, ktery by cely prikaz
   rozgeneroval na sadu prikazu definovanych ve virtualnim fontu, jenze:
     a) Dvips by muselo zacit interpretovat i PS. A pokud by se zdalo, ze
        staci jen prochazet radky vystupu a hledat sekvence
        "(Text)" ... fshow", stejne bod b) od meneni vkladanych PS souboru
        odrazuje.
     b) At premyslim, jak premyslim, bod 2) se ve vystupnim souboru bude
        muset v nejake forme objevit vzdy. A ma-li nekdo pocit, ze by
        stacilo v nouzi jen prepisovat "cmr10" na "csr10", necht si precte
        nasledujici bod.
     c) Dvips by melo zcela urcite umet bud kompletni podporu VF ve
        vkladanych PS souborech, nebo nic. Kdyby se nejakym hackem do
        dvips doplnilo, aby treba "cmr10" mohlo byt virtualni s odkazem
        na "csr10", pak zase prijde nekdo, kdo bude treba chtit pouzivat
        virtualni "csr10" se slozenymi znaky odkazujicimi se na "cmr10"
        a jsme zase v troube...

Divi se stale jeste nekdo, proc autor(i) nenacitani *.vf povazuje(i) za
"feature" a nikoli za "bug"?

----------------------------------------------------------------------
                          Rudolf Cejka, VUT Brno (Fakulta Informatiky)
                  E-mail: xcejka00 at stud.fee.vutbr.cz
                     WWW: http://www.stud.fee.vutbr.cz/~xcejka00