From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/3779 Path: main.gmane.org!not-for-mail From: Hans Hagen Newsgroups: gmane.comp.tex.context Subject: Re: river detection Date: Thu, 11 Jan 2001 08:56:53 +0100 Sender: owner-ntg-context@let.uu.nl Message-ID: <3.0.6.32.20010111085653.0199a100@server-1> References: <3.0.6.32.20010110092703.015d1670@server-1> <3.0.6.32.20010110183813.0154c100@server-1> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: main.gmane.org 1035394496 20028 80.91.224.250 (23 Oct 2002 17:34:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2002 17:34:56 +0000 (UTC) Cc: NTG-ConTeXt mailing list Original-To: Ed L Cashin In-Reply-To: Xref: main.gmane.org gmane.comp.tex.context:3779 X-Report-Spam: http://spam.gmane.org/gmane.comp.tex.context:3779 At 01:59 PM 1/10/01 -0500, Ed L Cashin wrote: >Hans Hagen writes: > >> At 11:58 AM 1/10/01 -0500, Ed L Cashin wrote: >> >> >But you could just do a TeX macro that expands to a kind of matrix >> >like this: >> > >> > (5, 6) (11, 15) (35, 40) >> > (7, 9) (11, 15) (26, 30) >> > (2, 4) (11, 14) (24, 26) >> > >> >(there's a river at position eleven). >> >> Eh ... when tex typesets a paragraph, all input is already converted to >> lists and macro expansion is gone. So, bbox info should come from the list >> to dvi pass [or maybe from within the paragraph builder]. Keep in mind that >> f i e t s [bicycle] is not just 5 chars, but becomes fi e t s and that at >> some point the hyphenation engine pops in too. No way to hyphenate >> \hbox{f}\hbox{i}...\hbox{s}. > >I don't know what you mean by "the list to dvi pass". > >Within the paragraph builder, though, I'm thinking that there's a time >when TeX tries a certain paragraph configuration. At that time, you >have information about where the horizontal glue between hboxes begins >and ends. That's the information that I was talking about in my >example. With "I w u v fi e t s", TeX knows that there's a good >bit of horizontal glue after the "v" box and before the "fi" box. It >knows the leftmost and rightmost position of that glue, right? > >I was thinking that the river badness can be calculated at that time, >but are you saying that it can't be calculated at that time by a macro >because all the macro expansion is not going on at that time? Right. Input (either or not expanded macros) is converted into a linked list. This list is then broken into lines [actually a solution tree first]. Normally baddness is calculated by summarizing badness's of lines [kind of]. A river detector should act upon the *resulting* paragraph as a whole, since it should look 'vertical' instead of horizontal. I think that some heuristic method is needed then. I can even think of wierd ones, like: build a bitmap from the boundingboxes of the chars [no interlinespace], enlarge the bitmaps some 10%, then compress the bitmap. The smaller it is, the better the grayness [guess]. Or apply jpeg/mpeg like analysis, with those neighbouring pixel analyzation things. River detection could be done by tracing edges or something like that or a neural net. Of course one could act upon the list directlty, but i think that a more visual related method is easier, especially since we also need to take the actual dimensions of the bbox into account [even better: the real shape or composed shape]. Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com -------------------------------------------------------------------------