Bernd Raichle wrote:

Ok, I move the discussion back from sarovar to the ntg-pdftex list ...

Cool, thanks.

Thus I am still missing the rationale why a new primitive was introduced. (I didn't find anything within my backlog of this list and the list archive is missing a search functionality.)

A functional equivalent macro of \quitvmode is: \protected\def\quitvmode{\ifvmode \indent \fi } but that only works when e-TeX is enabled. In a traditional TeX, the \if test will sometiems be executed at the wrong time, or you end up with undesired side-effects like \relax tokens. So yes, the primitive is unneeded in 'pdfetex', but it was really needed when there still was a non-etex pdftex. Greetings, Taco

"TH" == Taco Hoekwater writes:

...

Thus I am still missing the rationale why a new primitive was introduced. (I didn't find anything within my backlog of this list and the list archive is missing a search functionality.) [...] TH> So yes, the primitive is unneeded in 'pdfetex', but it was really TH> needed when there still was a non-etex pdftex.

so did the need for this primitive become moot, since there will only be pdfetex from now on? the less unneeded things, the better. :) Best, v.

Martin � wrote:

On 2006-02-14 23:48:45 +0300, Vladimir Volovich wrote:

...

"TH" == Taco Hoekwater writes: TH> So yes, the primitive is unneeded in 'pdfetex', but it was really TH> needed when there still was a non-etex pdftex.

so did the need for this primitive become moot, since there will only be pdfetex from now on? the less unneeded things, the better. :)

Seems so. Does anybody really use it? We could allways emulate it in pdftex.ini... :-}

context uses it and i don't use pdftex.ini; i also (for the moment) support an non-etex mode Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Vladimir Volovich wrote:

"TH" == Taco Hoekwater writes:

...

...

Thus I am still missing the rationale why a new primitive was introduced. (I didn't find anything within my backlog of this list and the list archive is missing a search functionality.) [...] TH> So yes, the primitive is unneeded in 'pdfetex', but it was really TH> needed when there still was a non-etex pdftex.

so did the need for this primitive become moot, since there will only be pdfetex from now on? the less unneeded things, the better. :)

well, it's been around since version 1.21 so ... if we start removing features using the etex/whatever criterium, much more can be removed and we end up with broken macro packages; (and we can probably remove 75% of the whole tex tree too -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Vladimir Volovich wrote:

at least please avoid adding new unnecessary primitives in the future. :)

as said, it was neccessary at that time it depends; for instance, when we have open type font support, older pdftex specific font things can go away (like lig prevention); but we don't want to break existing macro code so ... also, the 'we have now etex' argument is not that strong: etex has been around for years now, context has provides etex overloads for quite a while now, but it's only last year that (when latex went etex) etex was seen as a kind of persistent part of tex and became the default engine; and even then, one needs to keep in mind that it will take years before you can really assume that users have an etex aware versions running. (the move from bitmap to outline fonts, dvi to pdf output, cm to lm fonts, changes in (e)fmt suffixes, changed locations of map/enc files, etc, demonstrates how stretched timelines can be) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

...

...

...

...

"Vladimir" == Vladimir Volovich writes:

at least please avoid adding new unnecessary primitives in the future. :)

The current situation is quite crappy. Plenty of new primitives are introduced each day. Most of them are useful but some of them should be discussed and tested before they go into the mainstream release. Some new primitives cannot be removed or changed because people already use them even before anything had been released. In good old days we had pdfxtex. Why can't we have it again? It was a great thing for experimental stuff. This is the current situation: Taco: "There is a new primitive." Bernd: "No need for a new primitive, a macro is sufficient." Hans: "Don't remove the primitive, Context already depends on it." (maybe I exaggerated a bit) Why can't we have pdfxtex again? Martin, I know that it's more work for you but I'm convinced that it's worth the trouble. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

On 2006-02-15 10:02:37 +0100, Taco Hoekwater wrote:

Reinhard Kotucha wrote:

...

In good old days we had pdfxtex. Why can't we have it again? It was a great thing for experimental stuff.

But nothing seems to gets noticed until it is in the mainstream application (and no longer marked experimental), so having a

Well, we could be better at advertising our new features. And it takes months before a release really hits the machines of users (e.g. many are still running teTeX 2). But I'd expect Bernd to at least follow our NEWS... Best Martin -- http://www.tm.oneiros.de

Paweł Jackowski wrote:

Taco Hoekwater napisał(a):

...

But nothing seems to gets noticed until it is in the mainstream application (and no longer marked experimental), so having a separate pdfxtex quite likely will not help. I am not against reviving pdfxtex, but I doubt there is much to be gained from it.

Agree - it wouldn't help but I'm rather against reviving xtex. I can't see anything wrong in adding new features to the mainstream *if* they remain (some kind of) a secret. Unless not mentioned in release notes or documented (afair \quitmode was not), the primitive does not exist for the end-user but for developers. Please don't make pdf*tex's again -)

indeed. also, some new features are harmless, so they quickly reach a 'stable' state while others may interfere (most noticably the font related extensions) and those are kept 'undocumented' until proven stable (may take more that a year); in the past such features even got their interfaces changed while testing; because they can be disabled (and then don't interfere) they can safely be part of the mainstream pdftex having two versions would make testing very painful Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Martin:

Yes. By carefully reading NEWS you might find out that something called quitvmode was added in 1.21a, but what it does is still a secret. :-)

Bernd:

Beta-tester can only test something which is documented

Both true. Thinking loudly; what about adding to every news file (or generating some extra 'dev-news', 'pre-manual' with) a brief description of new features; could be taken directly from patch comments... I belive those comments are enough for beta-testers, while end-users read the manual, where only stable things are described. Hans:

having two versions would make testing very painful

Ye, and having two files is much less painfull ;) -- Pawe/l Jackowski P.Jackowski@gust.org.pl

Reinhard Kotucha wrote:

Some time ago I read somewhere (maybe in a mail from Hans) that probably LuaTeX will be distributed along with pdfTeX for a while until it finally will be renamed to pdfTeX.

This is exactly what I ask for with the only exception that it should be called pdfxtex instead of LuaTeX and other experimental stuff can go there as well.

part of the problem is that we have no control over what is shipped by distributers; most program sthat i use have 'stable' versions and 'experimental' versions (take ghostscript) one of the decisions made at the informal pdftex meeting that martin, hartmut, taco and i had was that we should have stable versions (.40 to start with), maybe bug fixes t that (.41) but then instead of pdfxtex we can have just (eg) version .50 as the experimental one using two binaries (and therefore two formats etc) is simply no fun;

There is LuaTeX now and there will be Unicode-TeX and OTF-TeX in the future and they all will be renamed to pdfTeX sooner or later. So why not call all the experimental stuff pdfxtex?

.50+ .60+ .70-+

If you put experimental stuff into the mainstream release you have to be absolutely sure that it does not have any unwanted side effects. Of course, an experimental version should work, but you have more freedom for experiments because it is for evaluation only, not for production.

distributers should not put the latest pdftex (no x) in their mainstream release anyway; only stable versions; normally the 'tex live code freeze version' is the one they should use

In short: It's a matter of philosophy. You prefer to keep things secret, I prefer to involve more people.

it has nothing to do with secrecy; take thanh's font related extensions, often the few people who ask for it do the first testing, then provide feedback, and thanh changes, extends etc things; a pretty fast cycle btw and history shows that in that process functionality and control changes; so it would put a burden on documenting that in that stage; even now, i'm sure that the new \*code (char based glue) cannot be described yet, since its behaviour may change, side effects may go away of become part of the spec etc the sooner things are 'documented formally' (in the manual), the more dependencies show up since it will be used in packages; and since packages are normally uncontrolled (relative to each other) ... ; remember what fuzz there was when pdftex replaced tex in tl: many ways to test pdftexness, using old (obsolete) and new primitives, etc (in the beginning of pdftex much testing was done in version that thanh just send me (binaries) and by using it for aday or two in a production environment processing big docs, most problems could be repaired without the need for readme's, change lists, etc) anyhow, it's also a matter of convenience, speed up code writing/testing cycles etc Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Hi Taco, hi pdftex developers! Sorry, for bringing up "old" discussions and primitive. I hope you are not offended by discussing these old topics. Nonetheless I think that some (pdf)TeX changes have to be ... better discussed/discussed again/documented/revised/removed (choose the appropriate, please). I have the background of being a former member of the NTS and the e-TeX team. Within this team we had a lot of discussions about new primitives, how these primitives should behave, what are the implications, the restrictions etc. The result was that only a small part of the discussed primitives have been implemented and only a subset of the implemented primitives have found its way into the official e-TeX releases. This was and is good, because the team was sure that the extensions are as stable as TeX is. And it was and is bad, because e-TeX is "only" a small extension of TeX. On Wednesday, 15 February 2006 10:02:37 +0100, Taco Hoekwater writes:

Reinhard Kotucha wrote:

...

In good old days we had pdfxtex. Why can't we have it again? It was a great thing for experimental stuff.

But nothing seems to gets noticed until it is in the mainstream application (and no longer marked experimental), so having a separate pdfxtex quite likely will not help. I am not against reviving pdfxtex, but I doubt there is much to be gained from it.

Do not revive pdfxtex. Integrate new primitive in the mainstream application, to have them available for testing by a broader audience. No extra pdfxtex application is needed unless a change has too many (unwanted) side effects or is in a very unstable state. I propose to (a) better document the new primitive/functionality (this includes atleast a short rationale, why the current (pdf)(e-)TeX has to be extended/changed) and (b) mark all new primitive as experimental until there is enough positive/negative feedback to switch the status for experimental to stable. And probably (c) mark primitive/ functionality as deprecated if it has to be removed/replaced in the future. Knuth has completely rewritten TeX after a few years. IMHO it was a good idea to throw away TeX78 and start TeX82 (almost) from scratch. (It was a lot easier for him at this stage as it is for pdfTeX now because the number of users/macro packages/documents was very low.)

We spent the better part of yesterday talking about a primitive that has been published a year and a half ago, and whose tracker item has been closed since may 2005. That is hardly indicative of an active beta-tester base.

Beta-tester can only test something which is documented. I have just found the e-mails from July 2004 in the mailing list archive. In 2004 I was not a member of this mailing list and the pdftex development has not been moved to sarovar. During the last days I have browsed through short pieces of the pdftex code and the trackers at sarovar to understand some of the (pdf)(e-)TeX extensions integrated during the last years. Thus there will probably more questions about changes during the next days and weeks :-).

Also, \quitvmode is not superfluous except under etex. So:

"Vladimir" == Vladimir Volovich writes:

...

...

at least please avoid adding new unnecessary primitives in the future. :)

I vote for the removal of \indent since it is not needed in etex. We can patch plain.ini to contain its definition as a \protected macro. :-)

I second this proposal! ;-} ... if we are completely switching from the stable base called "TeX" to something which is no more document/macro compatible with "TeX". Regards, -bernd