Jiny zpusob visiciho rozdelovniku?

[Petr Olsak]

On Sun, 12 Dec 2004, Matous Jan Fialka wrote:

> On 11/12/04 21:22 +0100 or thereabouts, Vit Zyka wrote:
> > >Jeste jednou Vam dekuji, nastinil ste pripadnou cestu pres pdfcsplain, o
> > >ktere jsem nemel ani tuseni a zaroven ukazal, kudy cesta nevede. Dekuji Vam
> >
> > Ona asi vede, viz zadni strana obalky TST. Pochybyji, ze tam ty
> > rozdelovniky Petr Olsak zavesoval rucne ;-)
>
> Me taky prijdou trosku zavesene, ale ne o celou sirku. Kazdopadne, vite presne,
> ze je tam p. Olsak nezavesoval metodou zmeny v metrice fontu, jak popisuje v
> TBN? Mozna kdyby nam to p. Olsak prozradil? Pane Olsak? Prozradite nam to
> sladke tajemstvi? :)

Asi Vas zklamu, ale to tajemstvi neni sladke. Proste jsem pro jeden font
(vice fontu s vystrcenym rozdelovnikem jsem na zadni strane obalky
nepotreboval) provedl tftopl, poeditoval jsem jedno cislo u alternativniho
rozdelovniku a nakonec jsem provedl pltotf. Vyslednou metriku jsem nazval
jinak nez puvodni, abych ji mohl nacist pomoci \font vedle puvodni a
pouzit. Puvodni metrika csr10 je totiz ve formatu csplain jiz nactena.
Je pritom znamo, ze nelze TeX prinutit k tomu, aby pomoci \font nacetl
pozmeneny, ale stejne se jmenujici, tfm soubor znovu.

V dobe vzniku TST byl pdfTeX v pocatcich vyvoje a mozna ze primitivy na
visici interpunkci tehdy jeste ani nebyly funkcni.

Na urovni maker (s vyjimkou pouziti primitivu pdfTeXu) tento problem
rozhodne resit nelze, protoze pri vypoctu badness a demerits odstavce TeX
teprve v druhem pruchodu radkoveho zlomu pouzije metriku tohoto znaku,
ktera pak ovlivni zmineny vypocet. V dobe tohoto pruchodu neni mozne do
cinnoti TeXu zasahnout zadnym makrem, je to tam uvnitr zadratovano.
Ani pote, co druhy pruchod je ukoncen, neni jednoduche na urovni
maker pripadne jiny znak na koncich radku nahradit vystrcenym
rozdelovnikem. Troufam si rici, ze to je asi nemozne, protoze neni
k dispozici primitiv \lastchar, ktery by ten znak z hotove sazby sejmul a
bylo mozno jej nahradit jinym.

Nedavno jsem v souvisosti s timto problemem narazil na zadrhel:
alternativni hyphenchar jsem v PSovem fontu mel realizovany jen zdvojenim
slova /hyphen v encoding vektoru a upravou tfm metriky vyse popsanym
zpusobem. Ejhle: ono to nefungovalo a prznily se i spojovniky uvnitr slov
(napr. v "je-li"), protoze dvips si tu upravenou metriku sejmul, zjistil
ze na dvou pozicich je stejny znak a pouzil metriku jen podle jednoho
z tech dvou znaku. Musel jsem vyrobit pomoci t1tools duplikat fontu, ve
kterem byl znak /hyphen dvojmo.

Zdravim

Petr Olsak