X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6203" "Thu" "10" "April" "1997" "22:19:19" "+0200" "Frank Mittelbach" "Frank.Mittelbach@UNI-MAINZ.DE" nil "132" "Re: math fonts (and all those glyphs)" "^Date:" nil nil "4" nil nil nil nil nil] nil) Received: from listserv.gmd.de (listserv.gmd.de [192.88.97.1]) by mail.Uni-Mainz.DE (8.8.5/8.8.4) with ESMTP id WAA17729 for ; Thu, 10 Apr 1997 22:50:22 +0200 (MET DST) Received: from listserv.gmd.de by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <10.087B7433@listserv.gmd.de>; Thu, 10 Apr 1997 22:50:21 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 123335 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 10 Apr 1997 22:50:18 +0200 Received: from kralle.zdv.Uni-Mainz.DE (kralle.zdv.Uni-Mainz.DE [134.93.8.158]) by relay.urz.uni-heidelberg.de (8.7.6/8.7.4) with ESMTP id WAA29695 for ; Thu, 10 Apr 1997 22:50:01 +0200 (MET DST) Received: from frank.zdv.uni-mainz.de (Ufrank@localhost) by kralle.zdv.Uni-Mainz.DE (8.8.5/8.8.5) with UUCP id WAA21767 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 10 Apr 1997 22:40:23 +0200 (MET DST) X-Authentication-Warning: kralle.zdv.Uni-Mainz.DE: Ufrank set sender to frank.zdv.uni-mainz.de!latex3 using -f Received: (from latex3@localhost) by frank.zdv.uni-mainz.de (8.6.9/8.6.9) id WAA02681; Thu, 10 Apr 1997 22:19:19 +0200 References: <9704101205.AA08054@sgibulirsch6.mathematik.tu-muenchen.de> Message-ID: <199704102019.WAA02681@frank.zdv.uni-mainz.de> Reply-To: Mailing list for the LaTeX3 project In-Reply-To: <9704101205.AA08054@sgibulirsch6.mathematik.tu-muenchen.de> Date: Thu, 10 Apr 1997 22:19:19 +0200 From: Frank Mittelbach Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: math fonts (and all those glyphs) Status: R X-Status: X-Keywords: X-UID: 1919 Although I'm very welcoming discussions I'M S O R R Y TO SAY % (that's a properly kerned upper case % with letter spacing as additional emphasis :-) that I think this discussion right now is totally going into the wrong direction. I know that Johannes and perhaps others think that there are several shortcomings in Justin's work (or perhaps better say in the combined effort of many people back then) and that there are many symbols out there that should find a place in that encoding ... and yes there are shortcoming and there might be glyphs missing and and and BUT let me assure you that there have been design goals and a lot of reasoning that went into that final proposal and that it was not a "committee" result. let me give you a view of the major goals (from the top of my head, a better explanation can probably be found in Justin's epos although I do admit that sometimes the pearls are difficult to find therein --- this is not a criticism of Justin's work, it is simply an observation and it is due to the fact that we spend 90% of his stay in Mainz on working on the actual content and so there wasn't enough time to actually polish the result) ... back to the goals: - 100% glyph compatibility with existing font usage: that means kerning needs to be preserved if existing to make it possible to, say, reproduce a paper written with CM math fonts or cm+AMS exactly as before if passed through LaTeX or AmSTeX (or plain TeX) but now using the new fonts - keep within kerning limitations of TeX: that means you have to combine those characters in a single font that are likely to be kerned --- an impossible task with TeX (as we are not in Omega) as in principle one might want to kern any symbol with any (other) symbol. Nevertheless there are important basics that one better does not violate - low usage of font families as that is a major restriction of TeX - on the other hand keep characters with similar design within a single font to make exchange of individual fonts (or font groups) possible, eg try to put geometric symbols together as well as putting similar textual characters together - finally: don't go overboard with finding all kind of new characters and symbols that one might want but which will result in the encoding set as a whole becoming yet another TeX only encoding All or most of all the above and probably other stuff I forgot have been achieved quite well with the final proposal perhaps with the exception of the "finally" item. In other words if there is something that one might to think of is taking stuff OUT not IN. Why that? very simple: because I hope that this encoding will be able to serve the TeX community well and that means that we do get not only a CM-based implementation of it but also an Euler implementation and a Lucida math and a Mathtime and hopefully perhaps even more. If we clutter that encoding with additional symbols that are not to be found in professional fonts at all or very likely you can forget about this aspect and this aspect on the long run is in my opinion the more important one (otherwise we can live with what we do have right now why change? and accept that if we try to use any other math fonts then either we don't find any or it doesn't come in a compatible encoding or ...) [as an aside: this is also my major concern about the current evolvement of the TS encoding that while it contains a lot of interesting characters and gets more and more of them doesn't live up to its promise as it again divides the world into TeX and the rest only that the rest is a huge number of professional typefaces (and their expert versions) so i think it would be much better to separate TS into something that can be expected to be implemented by most available fonts and a bigger encoding which would not and i'm intending to go that path ... if anybody like to reply to that aside please change the subject line to "TS encoding issues" ] So no. I'm against taking the proposal apart before it is implemented and implementing means not only producing a basic virtual font implementation (don't get me wrong I'm really impressed of seeing Matthias work and i'm very grateful for it) but it also means - implementing the kerning and the additional kerning stuff of the proposal (eg integral kerning etc etc) - implementing the needed macros - and unfortunately also somehow the missing glyphs Open issues like how to arrange the symbols within one (!) encoding (as this is not specified) clearly needs some decisions but I agree with Matthias that some arbitrary solution in the first go would do. Nevertheless applying certain principles here does no harm and all those comments were well-taken. However, once that is done and we are already quite close to that point I think, we should get of the next hill and that is: take the euler math fonts and implement them as well why? because only if we really are able to switch fonts on demonstration (and apply the proposal to a different font family) we can actually see how well it works. (in fact applying it to mathtime and/or lucida would be also very helpful but in contrast to euler less people would be able to actually play with it then so i think euler is a better second solution and the commercial fonts only thereafter or in addition) THEN AND ONLY THEN i would return and open up the discussion and has started right now. in fact a lot of those comments and suggestions today did came up during the development of the proposal not only on the discussion list but also in all those long nights here in Aston and elsewhere. So I think I can safely claim that it is very likely that most of them have been considered and for some reason or other have been rejected not that i want this being understood as: "we don't care we know better" it is only that I don't have much faith in wading through the same discussions again without actually having something real to look at and play with it and (get the arguments substantiated) and for this i think it needs an implementation NOW and one for two sets of math fonts as explained above. best frank