From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/262 Path: main.gmane.org!not-for-mail From: Hans Hagen Newsgroups: gmane.comp.tex.context Subject: Re: pdfetex Date: Fri, 20 Nov 1998 15:07:18 +0100 Sender: owner-ntg-context@let.uu.nl Message-ID: <36557796.DCCA74D3@wxs.nl> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1035391127 22518 80.91.224.250 (23 Oct 2002 16:38:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2002 16:38:47 +0000 (UTC) Cc: NTG-CONTEXT Original-To: Berend de Boer Xref: main.gmane.org gmane.comp.tex.context:262 X-Report-Spam: http://spam.gmane.org/gmane.comp.tex.context:262 Berend de Boer wrote: > > On Thursday, November 19, 1998 6:36 PM, Hans Hagen [SMTP:pragma@wxs.nl] > wrote: > > > I'm currently making context a bit more etex aware (etex is the > > successor to tex). Now etex and pdftex are merged, I foresee that > > pdfetex will be *the* tex to use: tex/etex functionality as well as > > dvi/pdf output. > > For me, .pdf output is the only option in a world of Microsoft Word users. > dvi output means that users need to have access to .pk/.tfm/... files > before they can read my documents. Right, but dvi has the advantage of speed, and some ntg people are working on extended dvi with embedded font (info). > So I'm greatly interested in the best possible pdf output. If that's etex, > well I'm going to use that version. The additional etex functionality is never that visible for users. An example: context supports color, grid snapping, multiple haders etc. All those are implemented using a multiple mark mechanism programmed in tex, using the one mark official mark. Etex has natural support for multiple marks and context will use that when available. As a consequence, documents with lots of page-border dependant stuff (color, headings, etc) process faster. (I had a rather complicated file that ran over 40 % faster). > > I'm still not sure to what extend I must support etex's right-left > > typesetting, not only typesetting, but also hyper features, color etc. > > Any input on this is welcome. > > I think you must free context as is, only do some bug fixes and in the > newer releases only support etex. Supporting both is error prone (for tex > users) and I think you will not be able to use all etex features as best as > possible. Normally functionallity in context is quite frozen and extensions seldom have consequence for exiting things. I recently extended the font mechanism (more on that later); upward compatible but definitions far more comfortable. This has nothing to do with etex, although etex provides some powerfull low level primitives that again speed up things. Unless I'm going to use etex 3/4 feautures (which are more typographically oriented) users will only notice performance improvements. Concerning Right/Left typesetting, that will always be an additional mode, and therefore not conflict with existing stuff. (Freezing is dubious. If I'd frozen context half a year ago, there would be no field / javascript / and more to you still unknown -) features. Don't worry, etex will not harm existing things.) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | mail: pragma@wxs.nl -----------------------------------------------------------------