Received: via tmail-4.1(11) (invoked by user schoepf) for schoepf; Sun, 12 Mar 2000 03:08:20 +0100 (MET) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id DAA19274 for ; Sun, 12 Mar 2000 03:08:20 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8BC7.D6504200" Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id DAA20749 for ; Sun, 12 Mar 2000 03:08:19 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <8.7FC8B26E@mail.listserv.gmd.de>; Sun, 12 Mar 2000 3:07:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 452046 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sun, 12 Mar 2000 03:05:27 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id DAA18522 for ; Sun, 12 Mar 2000 03:05:26 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id DAA15964 for ; Sun, 12 Mar 2000 03:08:14 +0100 Received: from kammer.uni-hannover.de (zaphod.kammer.uni-hannover.de [130.75.139.53]) by relay.uni-heidelberg.de (8.9.3+Sun/8.9.3) with ESMTP id DAA08186 for ; Sun, 12 Mar 2000 03:05:27 +0100 (MET) Received: from zarniwoop.kammer.uni-hannover.de.kammer.uni-hannover.de (reinhard@zarniwoop.kammer.uni-hannover.de [130.75.139.54]) by kammer.uni-hannover.de (8.9.3/8.8.7) with ESMTP id DAA02407 for ; Sun, 12 Mar 2000 03:08:13 +0100 In-Reply-To: <200003081323.NAA23620@nag.co.uk> References: <200003081323.NAA23620@nag.co.uk> Return-Path: X-Mailer: VM 6.37 under Emacs 20.2.1 x-vm-v5-data: ([nil nil nil nil nil nil nil nil nil]["1749" "Sun" "12" "March" "2000" "03:08:13" "+0100" "Reinhard Kotucha" "reinhard@KAMMER.UNI-HANNOVER.DE" nil "44" "Re: float position rules" "^Date:" nil nil "3" nil nil nil nil nil]nil) Content-class: urn:content-classes:message Subject: Re: float position rules Date: Sun, 12 Mar 2000 03:08:13 +0100 Message-ID: <200003120208.DAA02407@kammer.uni-hannover.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Reinhard Kotucha" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3569 This is a multi-part message in MIME format. ------_=_NextPart_001_01BF8BC7.D6504200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>>>> "David" =3D=3D David Carlisle writes: >> usually 10% to 60% of \textheight. > ie too large to go in top, too small to make a float page on > their own, ideal material for taking to the end of the document, > given the default latex parameter settings! It certainly would help a little bit if the output routine would be more verbose. FMi now worked on the output routine and told us at the DANTE meeting that the float placing algorithm works much better than people think. But in fact it is a black box. It is hard to find out why a float is not placed. It doesn't provide any information *why* a float is deferred, and which variable I have to change. On the other hand, the output routine provides useful information. When I have a text that contains several verbatim environments and I get the message Overfull \hbox (1.39494pt too wide) in paragraph at lines 39--43 I can increase \textwidth by 1.39494pt and everything is well. Something like this is impossible with floats because I don't get any information. In the current LaTeX2e, float placement is black magic. BTW., writing such information to the log file could encourage people to read log files. I hope. I'm not sure they do. Regards, Reinhard -- -------------------------------------------------------------------------= --- Reinhard Kotucha Phone: = +49-511-751355 Berggartenstr. 9 D-30419 Hannover = mailto:reinhard@kammer.uni-hannover.de -------------------------------------------------------------------------= --- Microsoft isn't the answer. Microsoft is the question, and the answer is = NO. -------------------------------------------------------------------------= --- ------_=_NextPart_001_01BF8BC7.D6504200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: float position rules

>>>>> "David" =3D=3D David = Carlisle <davidc@NAG.CO.UK> writes:

    >> usually 10% to 60% of = \textheight.

    > ie too large to go in top, too = small to make a float page on
    > their own, ideal material for = taking to the end of the document,
    > given the default latex = parameter settings!

It certainly would help a little bit if the output = routine would be
more verbose.  FMi now worked on the output = routine and told us at the
DANTE meeting that the float placing algorithm works = much better than
people think.

But in fact it is a black box.  It is hard to = find out why a float is
not placed.  It doesn't provide any information = *why* a float is
deferred, and which variable I have to change.

On the other hand, the output routine provides useful = information.

When I have a text that contains several verbatim = environments and I
get the message

 Overfull \hbox (1.39494pt too wide) in paragraph = at lines 39--43

I can increase \textwidth by 1.39494pt and everything = is well.
Something like this is impossible with floats because = I don't get any
information.

In the current LaTeX2e, float placement is black = magic.

BTW., writing such information to the log file could = encourage people
to read log files.  I hope.  I'm not sure = they do.

Regards,
  Reinhard

--
----------------------------------------------------------------= ------------
Reinhard = Kotucha           =             &= nbsp;           &n= bsp;   Phone: +49-511-751355
Berggartenstr. 9
D-30419 = Hannover           = ;           mailto:reinhard@kammer.un= i-hannover.de
----------------------------------------------------------------= ------------
Microsoft isn't the answer. Microsoft is the = question, and the answer is NO.
----------------------------------------------------------------= ------------

------_=_NextPart_001_01BF8BC7.D6504200--