Hello people, I'd like to inform you on the current status and short-term forecast for e-Omega. The current official release is versioned 3.14159--1.15--2.1 (RC1) and is based on Omega 1.15 and e-TeX 2.1; even though it is just considered a Release Candidate, it's stable enough for production use. In fact, it has already been successfully used to publish in mixed-direction context. There will likely be at least one more release candidate, to solve a couple of direction-related bug, and probably two (the second featuring probably mostly a code clean-up). The e-Omega task force has decided for a name change for the project. From the first stable release onwards, the project (and the resulting program) will be called Aleph ($\Aleph$ in TeX notation). For those who missed the previous announcements, e-Omega (soon Aleph) is a user initiative, effectively started in November 2002, to merge two of the most important TeX extensions (Omega and e-TeX) to ensure that the wonderful enhancements in each would be readily available to users that need both of them. In its present state it was presented at the TUG2003 conference in Hawai`i this july. The focus of Aleph development is and will be: * providing a stable and reasonably fast extension to TeX containing most of the Omega enhancements (support for large fonts, multiple directions and character coding manipulations (OTPs/OCPs); the only unavailable feature is the support for SGML/XML) and many of the e-TeX enhancements (except for the bidirectional ones, surpassed by the more powerful multidirectional capabilities of Omega); * providing a development environment for middle-level users which would not grow obsolete in the short term, henceforth ensuring continued support for already-developed OTPs and similar companion tools; * providing a development environment for modern format developers (ConTeXt, and hopefully in the near future a new LaTeX as well) to support multidirectional typesetting in an easier-to-handle and more powerful programming environment. Both in the right-to-left world and in the CJK world work is already in progress to make sure these points are fully exploited. Thanks also to the excellent (independently developed) dvipdfmx DVI-to-PDF converter, support for the extended features of Omega and e-Omega/Aleph will not come at the cost of losing the option of easy PDF production (yes, we all would like to have PDF production directly integrated like in pdf-TeX, but don't expect that any time soon.) A note about the new name. Among the many reasons for the choice of the name there are: * the origins and purpose of the project: whereas Omega seeks to eventually offer the definitive answer to virtually all the problems of multilingual typesetting, Aleph has a more modest goal: to provide an immediately available and usable step in that direction. Since Aleph is the first letter of both the Arabic and the Hebrew alphabet (both of which need the multidirectional features offered by e-Omega), and as the project was started thanks to the initiative of Idris S. Hamid and Alan Hoenig (who are working on Arabic and Hebrew), choosing such a common name which connotes both "immediate" and "multilingual" was considered an appropriate choice. * also, Aleph is used in mathematics to denote transfinite numbers. This will allow "perverted" autoreferential tricks, like having a countable first stable release of Aleph ($\Aleph_0$); following major releases will be subsequent transfinite numbers ($\Aleph_1$, $\Aleph_2$, etc) and minor improvements/bugfixes will be cardinals ($\Aleph_0+1$, $\Aleph_0+2$, etc) A mailing list, graciously hosted by NTG, the Dutch TeX User Group, is available; its address is aleph at ntg dot nl. Since it is moderated, please subscribe before sending emails to it. Instructions on how to subscribe to the list are available at http://www.ntg.nl/mailman/listinfo/aleph On behalf of the e-Omega/Aleph task force, I would like to thank Donald Ervin Knuth for giving us TeX; John Plaice, Yannis Haralambous and the rest of the Omega folks for their amazing achievements which gave us such a powerful base on which to build; Peter Breitenlohner and the NTS team for giving us the excellent e-TeX; all the distributions' maintainers for providing easy, integrated, interoperable and up-to-date systems; and everybody in the TeX community, for making it the wonderful environment that it is. My very personal thanks also go to Hans Hagen, Idris Hamid and Alan Hoenig, for convincing me to put my hands in the project, and to the distributions' maintainers, in particular Christian Schenk and Fabrice Popineau, for their essential help and neverending patience in bearing with a 'programmer' victim of his background as a mathematician which takes him to submit patches without testing them "because in theory they should work", and Olaf Weber and Thomas Esser, for making e-Omega/Aleph available under Linux as well. [Copies of this message have been posted to the comp.text.tex newsgroup and the ConTeXt and Omega mailing lists] -- Giuseppe "Oblomov" Bilotta
On Mon, 8 Sep 2003 16:43:26 +0200
Giuseppe Bilotta
I'd like to inform you on the current status and short-term forecast for e-Omega.
Could you give some brief comments for we (me, I mean) who haven't been following Omega progress? Please point to web documents if such exist: * If I'm a pdftex/Context user, what does it take become an Aleph/Context user? * Are there special considerations for "fonts in Aleph"? It's a entirely new setup, isn't it? * Could you compare and contrast the quality and capabilities of dvipdfmx with pdf generation in pdftex? * If my work is entirely in English, is there any benfit of Aleph for me? Regards, -Bill -- Sattre Press Curiosities of the Sky http://sattre-press.com/ by Garrett Serviss info@sattre-press.com http://csky.sattre-press.com/
Monday, September 8, 2003 Bill McClain wrote:
On Mon, 8 Sep 2003 16:43:26 +0200 Giuseppe Bilotta
wrote:
I'd like to inform you on the current status and short-term forecast for e-Omega.
Could you give some brief comments for we (me, I mean) who haven't been following Omega progress? Please point to web documents if such exist:
* If I'm a pdftex/Context user, what does it take become an Aleph/Context user?
For casual stuff, dump the format with texexec -tex=eomega --make en and then compile with texexec -tex=eomega filename For "permanent" use of e-Omega/Aleph as ConTeXt engine change the appropriate lines in texexec.ini.
* Are there special considerations for "fonts in Aleph"? It's a entirely new setup, isn't it?
No, you can keep using your old stuff.
* Could you compare and contrast the quality and capabilities of dvipdfmx with pdf generation in pdftex?
I'll leave this to Hans, since I have not used dvipdfmx myself (MiKTeX does not yet carry it).
* If my work is entirely in English, is there any benfit of Aleph for me?
Uh ... not really, unless you need it for some very special stuff. The only "general" advancement in Omega (and thus Aleph) which is of "general" interest is the presence of more than 15 math families, which can greatly reduce the programmer's onus in supporting multiple symbol sets. This is not something for the general user, though, unless some low-level programming for this takes place first. (Hi there, Hans! ;>) Omega features like multidirectional typesetting or OCPs might turn useful for special purposes. For example, there is a book by Martin Gardner where some text is typeset mirrored; with some work, you can achieve this by exploiting the TeX/MetaPost link provided by ConTeXt; or you can do it with Omega. Another example, at one time I needed a way to code the text (think for example of ROT13): even though the coding is easy and could be implemented with a preprocessor or something, OCPs allow to do it "internally". But, as I said, these are very special requirements. Normal day-to-day left-to-right text does not need any of the advanced features in Omega, -- Giuseppe "Oblomov" Bilotta
On Mon, Sep 08, 2003 at 06:08:12PM +0200, Giuseppe Bilotta wrote:
Monday, September 8, 2003 Bill McClain wrote:
On Mon, 8 Sep 2003 16:43:26 +0200 Giuseppe Bilotta
wrote: I'd like to inform you on the current status and short-term forecast for e-Omega.
Thanks to the e-Omega group for your work. I think this is a great step forward.
Uh ... not really, unless you need it for some very special stuff.
The only "general" advancement in Omega (and thus Aleph) which is of "general" interest is the presence of more than 15 math families, which can greatly reduce the programmer's onus in supporting multiple symbol sets. This is not something for the general user, though, unless some low-level programming for this takes place first. (Hi there, Hans! ;>)
In your announcement you mentioned:
containing most of the Omega enhancements (support for large fonts, multiple directions and character coding manipulations (OTPs/OCPs); the only unavailable feature is the support for
I hope this brings TeX from the ASCII world into the Unicode world. Does this imply internal support for the various input encodings, such as utf-8? Regards, Simon -- Simon Pepping email: spepping@scaprea.hobby.nl home page: scaprea.hobby.nl
Monday, September 8, 2003 Simon Pepping wrote:
On Mon, Sep 08, 2003 at 06:08:12PM +0200, Giuseppe Bilotta wrote:
Uh ... not really, unless you need it for some very special stuff.
The only "general" advancement in Omega (and thus Aleph) which is of "general" interest is the presence of more than 15 math families, which can greatly reduce the programmer's onus in supporting multiple symbol sets. This is not something for the general user, though, unless some low-level programming for this takes place first. (Hi there, Hans! ;>)
In your announcement you mentioned:
containing most of the Omega enhancements (support for large fonts, multiple directions and character coding manipulations (OTPs/OCPs); the only unavailable feature is the support for
I hope this brings TeX from the ASCII world into the Unicode world. Does this imply internal support for the various input encodings, such as utf-8?
Yes in general (management of various input encodings is one of the strong points of Omega) and no in particular. UTF is not internally supported by Omega 1.15 (it is by Omega 1.23, at least for what I can see in the sources), and since the current release of e-Omega is 1.15-based, it has no internal support for UTF. -- Giuseppe "Oblomov" Bilotta
* If my work is entirely in English, is there any benfit of Aleph for me?
Sure. Consider, for example, the problem of transliteration. You may want to define a series of character mappings using otps to avoid using a lot of control sequences for accents and the like. Let's say u have an accent "\.d" that u use often for transliterating some sound. With an otp u can define the character sequence ".d" so that it always gives you \.d in the output. You can group your otp's so that they only take effect when delimited in some predefined way, e.g. "<.d>" Suppose you want a character to behave as a control sequence but don't want to make that character active. You can define a character in an otp so that whenever you type it you get a particular control sequence. I'm sure there are other creative examples as well. Best wishes Idris
At 09:45 09/09/2003 -0600, you wrote:
* If my work is entirely in English, is there any benfit of Aleph for me?
Sure. Consider, for example, the problem of transliteration. You may want to define a series of character mappings using otps to avoid using a lot of control sequences for accents and the like. Let's say u have an accent "\.d" that u use often for transliterating some sound. With an otp u can define the character sequence ".d" so that it always gives you \.d in the output. You can group your otp's so that they only take effect when delimited in some predefined way, e.g. "<.d>"
Suppose you want a character to behave as a control sequence but don't want to make that character active. You can define a character in an otp so that whenever you type it you get a particular control sequence.
I'm sure there are other creative examples as well.
i suggest that later this year idris/gb/me try to cook up a manual for that kind of thingies 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 ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Tuesday, September 9, 2003 Hans Hagen wrote:
At 09:45 09/09/2003 -0600, you wrote:
* If my work is entirely in English, is there any benfit of Aleph for me?
Sure. Consider, for example, the problem of transliteration. You may want to define a series of character mappings using otps to avoid using a lot of control sequences for accents and the like. Let's say u have an accent "\.d" that u use often for transliterating some sound. With an otp u can define the character sequence ".d" so that it always gives you \.d in the output. You can group your otp's so that they only take effect when delimited in some predefined way, e.g. "<.d>"
Suppose you want a character to behave as a control sequence but don't want to make that character active. You can define a character in an otp so that whenever you type it you get a particular control sequence.
I'm sure there are other creative examples as well.
i suggest that later this year idris/gb/me try to cook up a manual for that kind of thingies
The two ideas presented by Idris surprised me because I had never thought about (ab)using OCPs these ways :) I'll see what I can think of :) -- Giuseppe "Oblomov" Bilotta
On Tue, 09 Sep 2003 09:45:32 -0600
Idris S Hamid
With an otp u can define the character sequence ".d" so that it always gives you \.d in the output.
I know I could look this up, but briefly: (1) What's an otp? (2) Given a set of pfb and afm files (or a set of ttf files) how do I define such things for Aleph? -Bill -- Sattre Press Tales of War http://sattre-press.com/ by Lord Dunsany info@sattre-press.com http://tow.sattre-press.com/
Bill McClain wrote:
On Tue, 09 Sep 2003 09:45:32 -0600 Idris S Hamid
wrote: With an otp u can define the character sequence ".d" so that it always gives you \.d in the output.
I know I could look this up, but briefly:
(1) What's an otp?
Here r the best sources on otp's: http://omega.cse.unsw.edu.au:8080/roadmap/doc-1.12.ps http://omega.cse.unsw.edu.au:8080/papers/tsukuba-arabic97.pdf The second one especially has examples, many of them language-neutral.
(2) Given a set of pfb and afm files (or a set of ttf files) how do I define such things for Aleph?
Not sure I understand this, but there is a way to prepare huge (i.e., >256-glyphs) fonts for use by Omega starting from the afm files. I actually documented this in detail some time ago; I have to search and find it... ...Ahh! I found it;-) http://www.dtek.chalmers.se/~d97ost/omega-example.html There is also a test file using Arabic script for those who wanted to try doing Arabic-script in ConTeXt/Gamma. Originally made for Omega1.15, it will work with eOmega/Aleph. Best wishes Idris
Idris S Hamid wrote:
...Ahh! I found it;-)
More to the point: http://www.dtek.chalmers.se/~d97ost/omega/font-instructions.txt Best Idris
At 14:59 09/09/2003 -0600, you wrote:
(1) What's an otp?
fyi, filt-ini.tex and filt-bas.tex provide a higher level layer around (loading) otp's 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 ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
participants (5)
-
Bill McClain
-
Giuseppe Bilotta
-
Hans Hagen
-
Idris S Hamid
-
Simon Pepping