Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 22:42:13 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id n0JLgBgt017623 for ; Mon, 19 Jan 2009 22:42:12 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n0JLdcdQ005903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 22:39:38 +0100 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n0JDsrJK001566; Mon, 19 Jan 2009 22:39:38 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 206695 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 19 Jan 2009 22:39:37 +0100 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n0JLdbt3022235 for ; Mon, 19 Jan 2009 22:39:37 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n0JLdXSP005838 for ; Mon, 19 Jan 2009 22:39:36 +0100 Received: from morse.mittelbach-online.de (p54A84309.dip.t-dialin.net [84.168.67.9]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1LP1qG32Yy-00027k; Mon, 19 Jan 2009 22:39:32 +0100 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id 6EA9E64605; Mon, 19 Jan 2009 22:39:29 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <308a1ed10901171859v1b6a3b8frdb782f6a05e5c6ee@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V01U2FsdGVkX1+EZT8WmBFAewegp0XrDNd5HSGSuao+zH++N10 iOU5EAu9je5ltkz6cH0dJL4nT9YQwqR7iMDv9tncSTNnWWktrp rYGw415rhA1DyuNiXsrMmyRBNan5Y3U X-Spam-Whitelist-Provider: Message-ID: <18804.62224.969079.585420@morse.mittelbach-online.de> Date: Mon, 19 Jan 2009 22:39:28 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: Persian format of LaTeX To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <308a1ed10901171859v1b6a3b8frdb782f6a05e5c6ee@mail.gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -102.464 () BAYES_00,FORGED_RCVD_HELO,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.64 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 19 Jan 2009 21:42:13.0597 (UTC) FILETIME=[CA5780D0:01C97A7E] Status: R X-Status: X-Keywords: X-UID: 5591 VAFA KHALIGHI writes: > Hi, I am building a Persian format of LaTeX and going to upload that to > CTAN, the format name is farsilatex. I just wanted first to contact you guys > to see if there is anything that I should consider? that's a difficult question you pose, especially if (as I suspect) nobody on this list really knows what the Persian typesetting needs are. As a general advice I would say that building a separate format should be the last resort taken if any other option fails, i.e., - building a babel package - building a general package to add to a document (assuming that babel is too much targeted for "latin based languages") > this format will be the modified version of latex2e format that is suitable > to meet Persian typesetting needs. what are those typesetting needs? writing a short paper on requirements and outling what isn't being managable with the current standard setup should be the first step in my opinion a) because that would enable others to point you at the right resources or possibilities (assuming some exist) b) would help to understand us what would we need to support in a future kernel to allow such support (assuming that within the current framework some things are not possible) I would also suggest to take that paper then to a wider audience than this list (for example c.t.t) > If there is no comment, then my assumption will be that there is no problem > and I continue the project. well, my main concern is that a separate format has a number of drawbacks, to name a few - maintenance is problematical, ie any fix/changes to the official version needs to be separately managed - user base will be small, ie an addon package to the standard can normally be obtained and installed by everybody (if not already part of some distribution) for a different format this is not the case normally - certain functionality as offered, for example, by babel would missing, eg the ability to easily switch between languages in a document there is nothing really stopping you from going ahead in the direction you intended (and it may turn out that it is in fact the only decent solution eventually) but I would start not with it for the reasons above. Instead document what the needs are, which of them you find/think are not doable within std LaTeX and then spawn discussion on that regards frank