ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
* Re: pdfetex
@ 1998-11-20 14:07 Hans Hagen
  0 siblings, 0 replies; 3+ messages in thread
From: Hans Hagen @ 1998-11-20 14:07 UTC (permalink / raw)
  Cc: NTG-CONTEXT

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
-----------------------------------------------------------------


^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: pdfetex
@ 1998-11-20  8:21 Berend de Boer
  0 siblings, 0 replies; 3+ messages in thread
From: Berend de Boer @ 1998-11-20  8:21 UTC (permalink / raw)


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.

For me, pdf output is the greatest thing since tex. I can now use tex for 
every document.

So I'm greatly interested in the best possible pdf output. If that's etex, 
well I'm going to use that version.

> 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.

Groetjes,

Berend.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* pdfetex
@ 1998-11-19 17:36 Hans Hagen
  0 siblings, 0 replies; 3+ messages in thread
From: Hans Hagen @ 1998-11-19 17:36 UTC (permalink / raw)


Hi all, 

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.  

Short term objectives concenring etex, making context a bit faster, use
a bit less memory, and maybe a bit more robust. Long term objectives
(when etex v3 and 4 as arrive): additional typographic features,
currently beyond tex. 

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. 

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
-----------------------------------------------------------------


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1998-11-20 14:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-11-20 14:07 pdfetex Hans Hagen
  -- strict thread matches above, loose matches on Subject: below --
1998-11-20  8:21 pdfetex Berend de Boer
1998-11-19 17:36 pdfetex Hans Hagen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).