🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.dtp.tex
Article #16980

Re: book/memoir; wdowy sieroty; \paraskip i \lineskip problem.

#16980
From: Jarosław Sokołowski
Date: Fri, 06 May 2011 21:32
95 lines
5623 bytes
Pan Aleksander napisał:

>> Podział na strony w TeXu jest bardziej prymitywny. Funkcja kary
>> też istnieje, ale procesor widzi tylko bieżącą stronę, i jak już
>> ją wypchnie przez \output, to nie ma do niej powrotu.
>
> Czyli w zasadzie albo wszystko trzymamy w pamięci albo algorytm
> składania jest wieloprzebiegowy. Sam nie wiem co byłoby lepsze.

Pewnie lepiej by było w pamięci, zwałaszcza że jest do tego algorytm,
który można zaadaptować. Ale wieloprzebiegowością też można się
podeprzeć -- daltego wysunąłem hipotezę, że może to dać niezłe
rezultaty. Tylko czy komuś będzie się chciało ją sprawdzić?

>>>> Plus dodatkowe oddziaływanie zwrotne na \looseness. 
>>>
>>> Chyba w oddziaływaniu zwrotnym jest cały pies pogrzebany.
>>> Dlaczego akurat na \looseness? Chyba jest trochę więcej
>>> możliwości?
>>
>> Napisałem \looseness, bo akurat o tym była mowa. A teraz się nad tym
>> zastanawia i nic innego mi do głowy nie przychodzi. Algorytm podziału
>> na wiersze korzysta z pojęcia kleju poziomego -- tu dla odmiany mamy
>> klej pionowy. System kija i marchewki w obu przypadkach jest jednaki.
>> Pudełka składające się na akapit mają stałą długość, a tu *dodatkowo*
>> możemy zmienić liczbę wierszy w akapicie -- właśnie przez \looseness.
>> Innych pomysłów na wsteczną modyfikację nie mam.
>
> Teoretyzując, (bo szczegółów życia wewnętrznego TeXa nie znam)
> można zwiększyć/zmniejszyć odstępy międzywierszowe. To mogłoby
> być niedobre przy składzie dwustronnym, jeśli na kolejnych
> stronach byłyby różne ale nie powinno być globalnie tak uciążliwe.  

To przecież jest -- \baselineskip może przybierać wartości elastyczne.
Teraz do mnie dotarło, że przy dobrym algorytmie, to by mogło być
*dobre* też do składu dwustronnego. System by musiał mieć baczenie na
to, aby po obu stronach kartki składanie odbyło się wedle tego samego
registru. Wtedy to nawet Michał Jankowski z gajowym Maruchą by nie
mieli powodów do zrzędzenia.

> Można ciaśniej/luźniej składać same akapity. Tu jest ewidentna
> interakcja składu strony i linii.

No i to właśnie robi \looseness. Skraca lub wydłuża akapit o jedną
bądż kilka linijek. Przez ciaśniejszy/luźniejszy skład. I nic poza tym.

> No i duży problem z doborem mnożnika między jedną wartością kary
> i drugą.

Teraz kary poziome i pionowe funkcjonują niezależnie. Jak TeX nie
umie złożyć akapitu mieszcząc się w limicie kary, robi "overfull",
czyli wiersz wystający na margines, co jest rozpaczliwym wołaniem
"człowieku, zrób coś z tym, bo ja lepiej nie potrafię". Pionowy
rozkład jest bardziej tolerancyjny, a błędy mniej spektakularne.
Zwykle powstaje pionowy "underfull", czyli dodanie gdzieś na stronie
ekstraordynaryjnego światła o łączniej wysokości jednej czy dwóch
interlinii. Myślę, że ta rozłączność mogłaby pozostać.

> Chyba innych pomysłów nie mam...

To tak jak ja. 

>>>> Na to jednak jest już za późno.
>>>
>>> Dlaczego?
>>
>> To wynika z warunku zbieżności funkcji monotonicznej. Funkcja opisująca
>> numer wersji programu musi być niemalejąca (w czasie). Wiadomo też, że
>> wersja TeXa jest zbieżna do $\pi$. Jej aktualna wartość, to 3.141592,
>> oznaczmy ją jako $V_t$. Rozpatrzmy $\epsilon = \pi - V_t$. Wartość
>> $\epsilon$ rzędu 0.000000653589 nie jest wystarczająca do przeprowadzenia
>> tak rewolucyjnej zmiany.
>
> No, to już kwestia czysto TeXniczna. System nie musi (a nawet nie
> mógłby) się nazywać TeX. Na razie nie bardzo jestem sobie w
> stanie wyobrazić algorytm łamania stron.

Taki jak łamanie akapitu -- bierzemy tekst od jednego sztywnego podziału
na strony do drugiego, a następnie za pomocą kija i marchewki znajdujemy
najlepsze podziały pomiędzy nimi.

> A do tego trzeba by najpierw sprawdzić, że jest lepszy niż to, co w tej
> chwili jest w TeXu.

Można w ten sposób rozwiązać problem (1) wakatów na końcach rozdziałów,
(2) wdów i sierot, (3) registru, (4) nagłówków podrozdziałów, (5) bloków
powiązanych logicznie, które nie powinny (choć czasem mogą) być podzielone
na strony (6) innych rzeczy, o których w tej chwili nie pamiętam.

> Pozdrawiam serdecznie 

Ja również

-- 
Jarek
Technical Details
Message-ID: <slrnis8q7l.cpo.jaros@falcon.lasek.waw.pl>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!.POSTED!not-for-mail
References: <83bbd898-1142-477e-a936-91a2abd55153@p19g2000yqh.googlegroups.com> <slrnis56ac.dd1.jaros@falcon.lasek.waw.pl> <35b293d4-9e54-4752-930a-2f0d54bf89f4@j31g2000yqe.googlegroups.com> <ipuljk$3ee$1@speranza.aioe.org> <slrnis666p.ind.jaros@falcon.lasek.waw.pl> <kjzhb98fc3s.fsf@ccfs1.fuw.edu.pl> <slrnis85o2.s5m.jaros@falcon.lasek.waw.pl> <slrnis8heb.fql.r-znk@amber.within.nat> <slrnis8lij.694.jaros@falcon.lasek.waw.pl> <slrnis8n7v.i1g.r-znk@amber.within.nat>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!.POSTED!not-for-mail
From: Jarosław Sokołowski <jaros@lasek.waw.pl>
Newsgroups: pl.comp.dtp.tex
Subject: Re: book/memoir; wdowy sieroty; \paraskip i \lineskip problem.
Date: Fri, 6 May 2011 21:32:37 +0000 (UTC)
Organization: : : :
Lines: 95
Message-ID: <slrnis8q7l.cpo.jaros@falcon.lasek.waw.pl>
References: <83bbd898-1142-477e-a936-91a2abd55153@p19g2000yqh.googlegroups.com> <slrnis56ac.dd1.jaros@falcon.lasek.waw.pl> <35b293d4-9e54-4752-930a-2f0d54bf89f4@j31g2000yqe.googlegroups.com> <ipuljk$3ee$1@speranza.aioe.org> <slrnis666p.ind.jaros@falcon.lasek.waw.pl> <kjzhb98fc3s.fsf@ccfs1.fuw.edu.pl> <slrnis85o2.s5m.jaros@falcon.lasek.waw.pl> <slrnis8heb.fql.r-znk@amber.within.nat> <slrnis8lij.694.jaros@falcon.lasek.waw.pl> <slrnis8n7v.i1g.r-znk@amber.within.nat>
NNTP-Posting-Host: 213-238-72-224.adsl.inetia.pl
Mime-Version: 1.0
X-Trace: news.onet.pl 1304717557 6886 213.238.72.224 (6 May 2011 21:32:37 GMT)
X-Complaints-To: niusy@onet.pl
NNTP-Posting-Date: Fri, 6 May 2011 21:32:37 +0000 (UTC)
User-Agent: slrn/0.9.8.1 (Linux)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit