Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.4905); Mon, 24 Jun 2002 20:52:00 +0200 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id g5OIpVxC030776 for ; Mon, 24 Jun 2002 20:51:32 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id g5OId0T8012195; Mon, 24 Jun 2002 20:39:00 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21BB0.38BE8800" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id g5O200sK027815; Mon, 24 Jun 2002 20:40:22 +0200 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 3130 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 24 Jun 2002 20:40:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id g5OIeMaE003162 for ; Mon, 24 Jun 2002 20:40:22 +0200 Received: from moutng1.kundenserver.de (moutng1.kundenserver.de [212.227.126.171]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id g5OIcLT8012081 for ; Mon, 24 Jun 2002 20:38:21 +0200 (MET DST) Received: from [212.227.126.162] (helo=mrelayng1.schlund.de) by moutng1.kundenserver.de with esmtp (Exim 3.22 #2) id 17MYix-00009u-00; Mon, 24 Jun 2002 20:38:03 +0200 Received: from [80.129.0.165] (helo=istrati.mittelbach-online.de) by mrelayng1.schlund.de with asmtp (Exim 3.35 #1) id 17MYiw-00060J-00; Mon, 24 Jun 2002 20:38:03 +0200 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id g5OIbxn01265; Mon, 24 Jun 2002 20:37:59 +0200 In-Reply-To: <3.0.6.32.20020621144417.007b3100@mail.uark.edu> References: <3.0.6.32.20020621144417.007b3100@mail.uark.edu> Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 24 Jun 2002 18:52:00.0301 (UTC) FILETIME=[38EC75D0:01C21BB0] X-Authentication-Warning: istrati.mittelbach-online.de: frank set sender to frank@mittelbach-online.de using -f X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) Content-class: urn:content-classes:message Subject: Re: Page geometry in LaTeX Date: Mon, 24 Jun 2002 19:37:59 +0100 Message-ID: A<15639.26375.782098.164234@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Page geometry in LaTeX Thread-Index: AcIbsDkYKm0jsOGtTkyPpSb+QvjkSQ== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4204 This is a multi-part message in MIME format. ------_=_NextPart_001_01C21BB0.38BE8800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dan, > With the increasing production of electronic documents, it >is time for latex to standardize the user interface for page >geometry, much as it did graphics inclusion (with the graphics >bundle). > Since pdf output is used as much for viewing as for printing >(if not more), the variety of page layouts is not restricted by >standardized paper sizes. Moreover, the action required to >implement a particular geometry is often driver dependent, so a >common user-level interface is getting to be a must. > Standardization could also provide a consistent set of >definitions. For example, does "landscape" mean to rotate the >media or the text? Which way? This makes little difference if the >output is paper, but on screen it's a different matter. > Merely adding geomerty.sty to the "required" area of latex >would be a step forward. I spend the last month(s) in collaboration with Hideo to work on a new = release of geometry, and i agree, it might indeed be a good idea as a first step = to move the (new) geometry distribution to required. I would also think (if anybody has a bit of spare time :-( ) it would be = great if this "anybody" could do a bit work on a template based solution for = this area. > I also think that ifpdf.sty or its functionality should now also be > considered "required". again that sounds like a sensible idea (or else perhaps have it added to = the tools area, as it is so small). The problem in that area is (as i recall = that there are are numberof hacks around that actually define \pdfoutput in certain situations. Those would trip a package like this. Can't remember ofhand why one would do that, but if there are valid reasons, it seems a = good idea to provide an alternative solution. frank ps Hideo/Heiko: if you are not on latex-l you may not be able to reply sucessfully to this message without subscribing (don't fear to be = overwelmed with messages :-( --- but alternatively you can send any reply to me) ------_=_NextPart_001_01C21BB0.38BE8800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Page geometry in LaTeX

Dan,

>    With the increasing production = of electronic documents, it
>is time for latex to standardize the user = interface for page
>geometry, much as it did graphics inclusion (with = the graphics
>bundle).
>    Since pdf output is used as = much for viewing as for printing
>(if not more), the variety of page layouts is not = restricted by
>standardized paper sizes. Moreover, the action = required to
>implement a particular geometry is often driver = dependent, so a
>common user-level interface is getting to be a = must.
>    Standardization could also = provide a consistent set of
>definitions. For example, does = "landscape" mean to rotate the
>media or the text? Which way? This makes little = difference if the
>output is paper, but on screen it's a different = matter.
>    Merely adding geomerty.sty to = the "required" area of latex
>would be a step forward.

I spend the last month(s) in collaboration with Hideo = to work on a new release
of geometry, and i agree, it might indeed be a good = idea as a first step to
move the (new) geometry distribution to = required.

I would also think (if anybody has a bit of spare time = :-( ) it would be great
if this "anybody" could do a bit work on a = template based solution for this
area.

 > I also think that ifpdf.sty or its = functionality should now also be
 > considered "required".

again that sounds like a sensible idea (or else = perhaps have it added to the
tools area, as it is so small). The problem in that = area is (as i recall that
there are are numberof hacks around that actually = define  \pdfoutput in
certain situations. Those would trip a package like = this. Can't remember
ofhand why one would do that, but if there are valid = reasons, it seems a good
idea to provide an alternative solution.

frank

ps Hideo/Heiko: if you are not on latex-l you may not = be able to reply
sucessfully to this message without subscribing = (don't fear to be overwelmed
with messages :-(   --- but alternatively = you can send any reply to me)

------_=_NextPart_001_01C21BB0.38BE8800--