Roadmap

Martin Schröder

13 Dec 2005 13 Dec '05

5:52 a.m.

Hi, this weekend I've met Hans, Hartmut and Taco in Schwetzingen (we attended the christmas party of the Darmstadt TeXies with Hermann Zapf) and we discussed the status and future of pdfTeX. We came down with this "roadmap": 1.40 (200603): - all the current patches plus \primitive et.al - cleanup the code (fewer patchfiles) to have a better starting point for lua - move project to Gforge hosted by Fabrice, and setup a complete code repository there - start of "pdfTeX news" 1.50 - more bits, i.e. use more than 16 (and enough) where possible 1.60 or later - general map file handling for pdfTeX and all programs that use map files - OpenType -- this requires more bits and can be done in steps - lua -- integration can be done post 1.40, but the TeX<->Lua interface needs much testing and developement, so lua will stay experimental for quite some time sometime (i.e. whenever it's ready) - tagged pdf - merging hyperlinks in included documents Best Martin -- http://www.tm.oneiros.de

Show replies by date

Martin Schröder

13 Dec 13 Dec

7:40 a.m.

New subject: 1.40 Schedule

I propose this schedule for 1.40: - alpha, i.e. patches for the not-cleaned-up source code till 2006-01-15 (2006W02) - beta, i.e. code cleanup till 2006-02-12 (2006W06) here we are in feature freeze and can work on the manual and news - rc0 on 2006-02-20 (2006W07) bug hunting! - release on 2006-03-06 (2006W09), i.e. in time for DANTE Berlin. We should also have moved the project to Gforge hosted by Fabrice, and setup a complete code repository there till then. Comments? Best Martin -- http://www.tm.oneiros.de

Taco Hoekwater

14 Dec 14 Dec

2:05 a.m.

New subject: 1.40 Schedule

Martin Schröder wrote:

...

I propose this schedule for 1.40: - alpha, i.e. patches for the not-cleaned-up source code till 2006-01-15 (2006W02) - beta, i.e. code cleanup till 2006-02-12 (2006W06) here we are in feature freeze and can work on the manual and news - rc0 on 2006-02-20 (2006W07) bug hunting! - release on 2006-03-06 (2006W09), i.e. in time for DANTE Berlin. We should also have moved the project to Gforge hosted by Fabrice, and setup a complete code repository there till then.

Comments?

Martin, At what point do you intend to flatten the web files? My \primitive patch will be uploaded in the weekend or beginning next week (I've been sick through monday afternoon, so I am a bit behind, and now need to prepare for the NTG meeting upcoming friday). Taco

Martin Schröder

5:40 a.m.

New subject: 1.40 Schedule

On 2005-12-14 10:05:21 +0100, Taco Hoekwater wrote:

...

Martin Schröder wrote:

...
I propose this schedule for 1.40: - alpha, i.e. patches for the not-cleaned-up source code till 2006-01-15 (2006W02) - beta, i.e. code cleanup till 2006-02-12 (2006W06) here we are in feature freeze and can work on the manual and news - rc0 on 2006-02-20 (2006W07) bug hunting! - release on 2006-03-06 (2006W09), i.e. in time for DANTE Berlin. We should also have moved the project to Gforge hosted by Fabrice, and setup a complete code repository there till then.

Comments?

At what point do you intend to flatten the web files?

Starting with beta, i.e. after 2006-01-15. Best Martin -- http://www.tm.oneiros.de

Martin Schröder

22 Dec 22 Dec

6:01 a.m.

New subject: C style (was: 1.40 Schedule)

On 2005-12-14 13:40:42 +0100, Martin Schröder wrote:

...

On 2005-12-14 10:05:21 +0100, Taco Hoekwater wrote:

...
At what point do you intend to flatten the web files?

Starting with beta, i.e. after 2006-01-15.

I'd also like to unify our coding style. One easy way to do this is to use indent(1). Any opinions on options to use? The default (i.e. GNU coding standards) with --no-tabs seems OK to me. Best Martin -- http://www.tm.oneiros.de

Taco Hoekwater

6:41 a.m.

New subject: C style

Martin Schröder wrote:

...

On 2005-12-14 13:40:42 +0100, Martin Schröder wrote:

...
On 2005-12-14 10:05:21 +0100, Taco Hoekwater wrote:

...
At what point do you intend to flatten the web files?

Starting with beta, i.e. after 2006-01-15.

I'd also like to unify our coding style. One easy way to do this is to use indent(1). Any opinions on options to use? The default (i.e. GNU coding standards) with --no-tabs seems OK to me.

I've always disliked the GNU "etags-is-too-stupid-for-anything-else" function headers that break over a line, like: int main (int argv, argc**) But I'll happily run any kind of indent command after I've finished editting so ... Cheers, Taco

Martin Schröder

7:38 a.m.

New subject: C style

On 2005-12-22 14:41:58 +0100, Taco Hoekwater wrote:

...

Martin Schröder wrote:

...
I'd also like to unify our coding style. One easy way to do this is to use indent(1). Any opinions on options to use? The default (i.e. GNU coding standards) with --no-tabs seems OK to me.

I've always disliked the GNU "etags-is-too-stupid-for-anything-else" function headers that break over a line, like:

int main (int argv, argc**)

But I'll happily run any kind of indent command after I've finished editting so ...

I don't use emacs (or etags), so I've got no problems adding --dont-break-procedure-type to make you happy. :-) Best Martin -- http://www.tm.oneiros.de

Hartmut Henkel

12:28 p.m.

New subject: C style

On Thu, 22 Dec 2005, Taco Hoekwater wrote:

...

Martin Schröder wrote:

...
On 2005-12-14 13:40:42 +0100, Martin Schröder wrote:

I'd also like to unify our coding style. One easy way to do this is to use indent(1). Any opinions on options to use? The default (i.e. GNU coding standards) with --no-tabs seems OK to me.

I've always disliked the GNU "etags-is-too-stupid-for-anything-else" function headers that break over a line, like:

int main (int argv, argc**)

But I'll happily run any kind of indent command after I've finished editting so ...

i've already started to indent everything in reach, see the remark in the headers of some of pdftex's .c files: /* source code indentation by "indent -kr -nut" */ This looks quite natural: KR-mode and no tabs. Regards, Hartmut

Olaf Weber

27 Dec 27 Dec

1:27 p.m.

New subject: C style

Taco Hoekwater writes:

...

Martin Schröder wrote:

...
On 2005-12-14 13:40:42 +0100, Martin Schröder wrote:

...
On 2005-12-14 10:05:21 +0100, Taco Hoekwater wrote:

...

...
...
...
At what point do you intend to flatten the web files?

...

...
...
Starting with beta, i.e. after 2006-01-15.

...

...
I'd also like to unify our coding style. One easy way to do this is to use indent(1). Any opinions on options to use? The default (i.e. GNU coding standards) with --no-tabs seems OK to me.

...

I've always disliked the GNU "etags-is-too-stupid-for-anything-else" function headers that break over a line, like:

...

int main (int argv, argc**)

...

But I'll happily run any kind of indent command after I've finished editting so ...

That's not about etags, it's about grep, in particular the ability to do "grep ^foo *.c" and find the defn of foo(). Apart from the space (which is abominable) after the function name, I have learned to appreciate this style. -- Olaf Weber (This space left blank for technical reasons.)

Martin Schröder

6:40 p.m.

New subject: C style

On 2005-12-27 21:27:01 +0100, Olaf Weber wrote:

...

Taco Hoekwater writes:

...
I've always disliked the GNU "etags-is-too-stupid-for-anything-else" function headers that break over a line, like:

...
int main (int argv, argc**)

That's not about etags, it's about grep, in particular the ability to do "grep ^foo *.c" and find the defn of foo(). Apart from the space

Ah. Agreed.

...

(which is abominable) after the function name, I have learned to

The space is not configurable in the declaration -- only after every function call. And I prefer to have it after calls. On 2005-12-27 09:39:39 +0100, Hartmut Henkel wrote:

...

do we really want GNUish indentation? like

if (strcmp (fp->tfm_name, nontfm) != 0) { p = (fm_entry *) avl_find (tfm_tree, fp); if (p != NULL) { if (mode == FM_DUPIGNORE)

i would prefer K&R (--k-and-r-style):

if (strcmp(fp->tfm_name, nontfm) != 0) { p = (fm_entry *) avl_find(tfm_tree, fp); if (p != NULL) { if (mode == FM_DUPIGNORE) {

I suggest a tamed k&r: --k-and-r-style --blank-lines-after-procedures --line-length 80 --procnames-start-lines --space-after-procedure-calls --no-tabs /* this does not work in indent 2.2.6 :-( */ --preprocessor-indentation 2 /* this is new in indent 2.2.9 */ this gives if (strcmp (fp->tfm_name, nontfm) != 0) { p = (fm_entry *) avl_find (tfm_tree, fp); if (p != NULL) { if (mode == FM_DUPIGNORE) { Best Martin -- http://www.tm.oneiros.de

Taco Hoekwater

28 Dec 28 Dec

1:20 a.m.

New subject: C style

Martin Schröder wrote:

...

On 2005-12-27 21:27:01 +0100, Olaf Weber wrote:

...
Taco Hoekwater writes:

...
I've always disliked the GNU "etags-is-too-stupid-for-anything-else" function headers that break over a line, like:

...
int main (int argv, argc**)

That's not about etags, it's about grep, in particular the ability to do "grep ^foo *.c" and find the defn of foo(). Apart from the space

Ah. Agreed.

I use "grep ^\\w *.c", and also find static and global identifiers. But like I said, I don't really care as long as there is a 'run this command' statement somewhere. Taco

Martin Schröder

15 Jan 15 Jan

6:43 p.m.

New subject: Flattening the web files (was: 1.40 Schedule)

On 2005-12-14 13:40:42 +0100, Martin Schröder wrote:

...

On 2005-12-14 10:05:21 +0100, Taco Hoekwater wrote:

...
At what point do you intend to flatten the web files?

Starting with beta, i.e. after 2006-01-15.

I've started this by merging the change files and want to end up with pdftex1.ch (applied to tex.web) and pdftex2.ch (merged with all the web2c-changes). extra.ch will have to stay, but will be renamed to pdfetex.ch4. Best Martin -- http://www.tm.oneiros.de

Hans Hagen

16 Jan 16 Jan

4:15 a.m.

New subject: Flattening the web files

Martin � wrote:

...

On 2005-12-14 13:40:42 +0100, Martin Schr�der wrote:

...
On 2005-12-14 10:05:21 +0100, Taco Hoekwater wrote:

...
At what point do you intend to flatten the web files?

Starting with beta, i.e. after 2006-01-15.

I've started this by merging the change files and want to end up with pdftex1.ch (applied to tex.web) and pdftex2.ch (merged with all the web2c-changes). extra.ch will have to stay, but will be renamed to pdfetex.ch4.

why no go for a pdftex.web (no tex.web any longer); seems better to me if we go 32 bit Hans

Taco Hoekwater

4:34 a.m.

New subject: Flattening the web files

Hans Hagen wrote:

...

why no go for a pdftex.web (no tex.web any longer); seems better to me if we go 32 bit

I agree, that would be easier. The number of fixes to tex.web is near-zero anyway. Taco

Martin Schröder

9:30 a.m.

New subject: Flattening the web files

On 2006-01-16 12:34:59 +0100, Taco Hoekwater wrote:

...

Hans Hagen wrote:

...
why no go for a pdftex.web (no tex.web any longer); seems better to me if we go 32 bit

I agree, that would be easier. The number of fixes to tex.web is near-zero anyway.

What about eTeX? Currently I have pdfetex_web_srcs = $(srcdir)/tex.web \ $(srcdir)/etexdir/etex.ch \ $(srcdir)/etexdir/etex.fix \ $(srcdir)/pdfetexdir/pdfetex.ch1 \ $(srcdir)/pdftexdir/pdftex.ch \ $(srcdir)/pdfetexdir/pdfetex.ch2 and pdftex_web_srcs = $(srcdir)/tex.web \ $(srcdir)/pdftexdir/pdftex.ch So pdftex.web _or_ pdfetex.web would be easy, but having one file for both would be difficult. Shall we simply drop pdftex.web and go for an integrated pdfetex.web? Both TeX and eTeX are very stable. Best Martin -- http://www.tm.oneiros.de

Hans Hagen

9:56 a.m.

New subject: Flattening the web files

Martin � wrote:

...

On 2006-01-16 12:34:59 +0100, Taco Hoekwater wrote:

...
Hans Hagen wrote:

...
why no go for a pdftex.web (no tex.web any longer); seems better to me if we go 32 bit

I agree, that would be easier. The number of fixes to tex.web is near-zero anyway.

What about eTeX? Currently I have

pdfetex_web_srcs = $(srcdir)/tex.web \ $(srcdir)/etexdir/etex.ch \ $(srcdir)/etexdir/etex.fix \ $(srcdir)/pdfetexdir/pdfetex.ch1 \ $(srcdir)/pdftexdir/pdftex.ch \ $(srcdir)/pdfetexdir/pdfetex.ch2

and

pdftex_web_srcs = $(srcdir)/tex.web \ $(srcdir)/pdftexdir/pdftex.ch

So pdftex.web _or_ pdfetex.web would be easy, but having one file for both would be difficult. Shall we simply drop pdftex.web and go for an integrated pdfetex.web? Both TeX and eTeX are very stable.

drop also, let's define pdfetex as an abbreviation for pdfe(xtended)tex i suppose that you merge the etex code into the flattened file? Hans

Taco Hoekwater

10:03 a.m.

New subject: Flattening the web files

Hans Hagen wrote:

...

...
So pdftex.web _or_ pdfetex.web would be easy, but having one file for both would be difficult. Shall we simply drop pdftex.web and go for an integrated pdfetex.web? Both TeX and eTeX are very stable.

drop

drop

...

i suppose that you merge the etex code into the flattened file?

yes, please. We probably want/have to modify the etex stuff for opentype/wide characters support. Cheers, Taco

Martin Schröder

11:13 a.m.

New subject: Flattening the web files

On 2006-01-16 18:03:35 +0100, Taco Hoekwater wrote:

...

Hans Hagen wrote:

...
drop

drop

O.K.

...

...
i suppose that you merge the etex code into the flattened file?

yes, please. We probably want/have to modify the etex stuff for opentype/wide characters support.

I will use tie, i.e. the pdfetex.web generated by the Makefile, and copy the comments manually. Best Martin -- http://www.tm.oneiros.de

Martin Schröder

17 Jan 17 Jan

8:38 a.m.

New subject: Flattening the web files

On 2006-01-16 19:13:57 +0100, Martin Schröder wrote:

...

...
yes, please. We probably want/have to modify the etex stuff for opentype/wide characters support.

I will use tie, i.e. the pdfetex.web generated by the Makefile, and copy the comments manually.

pdftex and pdftexdir are gone. :-) Best Martin -- http://www.tm.oneiros.de

Hans Hagen

9:27 a.m.

New subject: Flattening the web files

Martin � wrote:

...

On 2006-01-16 19:13:57 +0100, Martin Schr�der wrote:

...
...
yes, please. We probably want/have to modify the etex stuff for opentype/wide characters support.

I will use tie, i.e. the pdfetex.web generated by the Makefile, and copy the comments manually.

pdftex and pdftexdir are gone. :-)

congratulations Hans

Martin Schröder

9:38 a.m.

New subject: Flattening the web files

On 2006-01-17 17:27:39 +0100, Hans Hagen wrote:

...

Martin ??? wrote:

...
pdftex and pdftexdir are gone. :-)

congratulations

But the name of the project will still be pdfTeX (not pdfeTeX), right? Best Martin -- http://www.tm.oneiros.de

Heiko Oberdiek

11:08 a.m.

New subject: Flattening the web files

On Tue, Jan 17, 2006 at 05:38:48PM +0100, Martin Schröder wrote:

...

On 2006-01-17 17:27:39 +0100, Hans Hagen wrote:

...
Martin ??? wrote:

...
pdftex and pdftexdir are gone. :-)

congratulations

But the name of the project will still be pdfTeX (not pdfeTeX), right?

Thus the directory "pdftexdir" would be shorter than pdfetexdir ;-) Or will we have a directory "pdfluaetexdir"? Yours sincerely Heiko --

Hans Hagen

3:52 p.m.

New subject: Flattening the web files

Martin � wrote:

...

On 2006-01-17 17:27:39 +0100, Hans Hagen wrote:

...
Martin ??? wrote:

...
pdftex and pdftexdir are gone. :-)

congratulations

But the name of the project will still be pdfTeX (not pdfeTeX), right?

indeed, let's stay with the historic name (of course it's up to thanh to make the final decission on that); for a while i wondered if calling the binary pdftex would make sense, but then we need to adapt too many manuals, tools, etc; Hans

Staszek Wawrykiewicz

4:48 p.m.

New subject: Flattening the web files

On Tue, 17 Jan 2006, Hans Hagen wrote:

...

...
But the name of the project will still be pdfTeX (not pdfeTeX), right?

Good decission.

...

indeed, let's stay with the historic name (of course it's up to thanh to make the final decission on that);

Sure. Thanh, would you please say the final agreement that pdftex means from now "pdftex with all etex extensions"? (no more pdfetex)

...

for a while i wondered if calling the binary pdftex would make sense, but then we need to adapt too many manuals, tools, etc;

Hans, thanks for pointing that. It just means that we have to change at least fmtutil.cnf and make some cosmetic changes is some documentation. I vote for doing that. It is much more easy to explain (especially for the newbees) that pdftex is just an extension which incorporates also all etex things. -- Staszek Wawrykiewicz StaW@gust.org.pl

Hans Hagen

18 Jan 18 Jan

4:22 a.m.

New subject: Flattening the web files

Staszek Wawrykiewicz wrote:

...

Hans, thanks for pointing that. It just means that we have to change at least fmtutil.cnf and make some cosmetic changes is some documentation. I vote for doing that. It is much more easy to explain (especially for the newbees) that pdftex is just an extension which incorporates also all etex things.

indeed, as well as other extensions (not part of etex) Hans

Martin Schröder

4:41 a.m.

New subject: Flattening the web files

On 2006-01-18 00:48:26 +0100, Staszek Wawrykiewicz wrote:

...

On Tue, 17 Jan 2006, Hans Hagen wrote:

...
for a while i wondered if calling the binary pdftex would make sense, but then we need to adapt too many manuals, tools, etc;

Hans, thanks for pointing that. It just means that we have to change at least fmtutil.cnf and make some cosmetic changes is some documentation. I vote for doing that. It is much more easy to explain (especially for the newbees) that pdftex is just an extension which incorporates also all etex things.

So the project is pdfTeX. And the binary is pdftex (current beta has pdfetex)? Changing the name of the binary back to pdftex will cause confusion, as now (teTeX 3/TL2005) the binary used is pdfetex (pdfTeX is just a symlink to pdfetex, changing the binary back to pdfTeX would need the reversed link). Best Martin -- http://www.tm.oneiros.de

Hans Hagen

9:06 a.m.

New subject: Flattening the web files

Martin � wrote:

...

On 2006-01-18 00:48:26 +0100, Staszek Wawrykiewicz wrote:

...
On Tue, 17 Jan 2006, Hans Hagen wrote:

...
for a while i wondered if calling the binary pdftex would make sense, but then we need to adapt too many manuals, tools, etc;

Hans, thanks for pointing that. It just means that we have to change at least fmtutil.cnf and make some cosmetic changes is some documentation. I vote for doing that. It is much more easy to explain (especially for the newbees) that pdftex is just an extension which incorporates also all etex things.

So the project is pdfTeX.

And the binary is pdftex (current beta has pdfetex)? Changing the name of the binary back to pdftex will cause confusion, as now (teTeX 3/TL2005) the binary used is pdfetex (pdfTeX is just a symlink to pdfetex, changing the binary back to pdfTeX would need the reversed link).

for one or two years we can ship two binaries, pdftex and pdfetex which are just copies, otherwise we get problems on platforms without symlinks, so - compile pdftex - copy it to pdfetex Hans

Martin Schröder

20 Jan 20 Jan

7:06 p.m.

New subject: Flattening the web files

On 2006-01-18 17:06:30 +0100, Hans Hagen wrote:

...

Martin ??? wrote:

...
So the project is pdfTeX.

And the binary is pdftex (current beta has pdfetex)? Changing the name of the binary back to pdftex will cause confusion, as now (teTeX 3/TL2005) the binary used is pdfetex (pdfTeX is just a symlink to pdfetex, changing the binary back to pdfTeX would need the reversed link).

for one or two years we can ship two binaries, pdftex and pdfetex which are just copies, otherwise we get problems on platforms without symlinks, so

- compile pdftex - copy it to pdfetex

Yes. And I want to keep pdftexdir and drop pdfetexdir. pdftex is what we say it is (even when it will really be pdfealephluatex). Best Martin -- http://www.tm.oneiros.de

Hans Hagen

14 Dec 14 Dec

2:35 a.m.

New subject: 1.40 Schedule

Martin � wrote:

...

I propose this schedule for 1.40: - alpha, i.e. patches for the not-cleaned-up source code till 2006-01-15 (2006W02) - beta, i.e. code cleanup till 2006-02-12 (2006W06) here we are in feature freeze and can work on the manual and news - rc0 on 2006-02-20 (2006W07) bug hunting! - release on 2006-03-06 (2006W09), i.e. in time for DANTE Berlin. We should also have moved the project to Gforge hosted by Fabrice, and setup a complete code repository there till then.

this includes the flattening i suppose Hans

Martin Schröder

12 Feb 12 Feb

5:30 p.m.

New subject: 1.40 Schedule

On 2005-12-13 15:40:23 +0100, Martin Schröder wrote:

...

- beta, i.e. code cleanup till 2006-02-12 (2006W06) here we are in feature freeze and can work on the manual and news

A reminder: - the manual is still mostly 1.30 Hartmut? Pawel? - we have no news I still like something like ltnews; unless someone (Hans?) provides something better, I propose simply using them as a template. - patch 473 is the last one I will accept for 1.40 Oh yes:

...

- rc0 on 2006-02-20 (2006W07) bug hunting! That's only one week away...

Best Martin -- http://www.tm.oneiros.de

Taco Hoekwater

13 Feb 13 Feb

3:08 a.m.

New subject: 1.40 Schedule

Martin Schröder wrote:

...

- patch 473 is the last one I will accept for 1.40

thanks

...

...
- rc0 on 2006-02-20 (2006W07) bug hunting!

That's only one week away...

i've been using the beta for a production job a few weeks now and have not seen anything weird yet. :-) Taco

Paweł Jackowski

7:59 a.m.

New subject: 1.40 Schedule

...

A reminder: - the manual is still mostly 1.30 Hartmut? Pawel?

Ooops the entire week I'm in Finland with poor possibilities to update anything. Will try however. What's the status of \pdfstrcmp and regexp stuff; still left experimental? And... Even if they are, meybe it is better to document those features to let people use and test the embryo?.. Best, -- Pawe/l Jackowski P.Jackowski@gust.org.pl

Martin Schröder

9:11 a.m.

New subject: 1.40 Schedule

On 2006-02-13 15:59:18 +0100, Pawel Jackowski wrote:

...

Ooops the entire week I'm in Finland with poor possibilities to update anything. Will try however. What's the status of \pdfstrcmp and regexp stuff; still left experimental? And... Even if they are, meybe it is better to document those features to let people use and test the embryo?..

Yes. Yes. Have fun Martin -- http://www.tm.oneiros.de

Hans Hagen

9:26 a.m.

New subject: 1.40 Schedule

Paweł Jackowski wrote:

...

...
A reminder: - the manual is still mostly 1.30 Hartmut? Pawel?

Ooops the entire week I'm in Finland with poor possibilities to update anything. Will try however. What's the status of \pdfstrcmp and regexp stuff; still left experimental? And... Even if they are, meybe it is better to document those features to let people use and test the embryo?..

experimental, may even dissappear in favor of lua stuff (taco will start working on that soon) 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 -----------------------------------------------------------------

Paweł Jackowski

5:22 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

Pawel: [...]>What's the status of \pdfstrcmp and regexp

...

...
stuff; still left experimental? And... Even if they are, meybe it is better to document those features to let people use and test the embryo?..

Hans:

...

experimental, may even dissappear in favor of lua stuff (taco will start working on that soon)

Aaa, so if luaTeX might *replace* anything, i belive it makes no sense to write even a word. After tracking all the patches some more doubts: 1. '-etex' cmdline switch is already mentioned in 'pdftex --help' but I couldn't force it to work; the option is 'not recognized' during format creation (pdftex-beta, 1.40.0, 13.02.2006 compiled under Cygwin). 2. \ifabsnum, \ifabsdim; eTeX manual or pdfTeX manual? 3. \primitive, \ifprimitive; to be documented or to be replaced with namespaces? 4. \pdfinsertht, experiments with snapping and kerning (patch #415)? BR, -- Pawe/l Jackowski P.Jackowski@gust.org.pl

Taco Hoekwater

14 Feb 14 Feb

12:48 a.m.

New subject: 1.40 Manual (was 1.40 Schedule)

Paweł Jackowski wrote:

...

2. \ifabsnum, \ifabsdim; eTeX manual or pdfTeX manual?

The pdfTeX manual is the right (only) place.

...

3. \primitive, \ifprimitive; to be documented or to be replaced with namespaces?

My idea is: flag as experimental, \primitive may change its behaviour still (depending the outcome of the discussion on sarovar). I do not really expect a namespace solution coming soon. That is to say: i certainly do not have the time to write a functional specification for such an extension. If someone else feels up to that, than I will happily (attempt to) write an implementation, but it would still be too late for 1.40. Cheers, Taco

Paweł Jackowski

3:55 a.m.

New subject: 1.40 Manual (was 1.40 Schedule)

...

...
2. \ifabsnum, \ifabsdim; eTeX manual or pdfTeX manual? The pdfTeX manual is the right (only) place.

Done. I doubted since in the patch note you say its etex change AND it seems to be enabled iff etex is enabled. No other pdftex primitives described in the manual behave like that.

...

...
3. \primitive, \ifprimitive; to be documented or to be replaced with namespaces? My idea is: flag as experimental, \primitive may change its behaviour still (depending the outcome of the discussion on sarovar).

I do not really expect a namespace solution coming soon. That is to say: i certainly do not have the time to write a functional specification for such an extension. If someone else feels up to that, than I will happily (attempt to) write an implementation, but it would still be too late for 1.40.

Got that. Left undocumented, as snapping and kerning yet. Other things; \pdfobjcompresslevel, \pdflastlink, \pdfsavepos (DVI), \ifabsnum, \ifabsdim are done. Something missed? Check welcome. BeSt, -- Pawe/l Jackowski P.Jackowski@gust.org.pl

Hartmut Henkel

12:42 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

On Tue, 14 Feb 2006, [UTF-8] Pawe? Jackowski wrote:

...

...
...
2. \ifabsnum, \ifabsdim; eTeX manual or pdfTeX manual? The pdfTeX manual is the right (only) place.

Done.

newest CVS manual with newest cont-tmf.zip stops compiling here with subsubject : - Expandable commands [16.14]) ! Incomplete \ifx; all text was ignored after line 2034. It's caused by \Tex {\ifabsnum} How to do this? Regards, Hartmut

Martin Schröder

1:17 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

On 2006-02-14 20:42:40 +0100, Hartmut Henkel wrote:

...

On Tue, 14 Feb 2006, [UTF-8] Pawe? Jackowski wrote:

...
...
...
2. \ifabsnum, \ifabsdim; eTeX manual or pdfTeX manual? The pdfTeX manual is the right (only) place.

Done.

newest CVS manual with newest cont-tmf.zip stops compiling here with

subsubject : - Expandable commands [16.14]) ! Incomplete \ifx; all text was ignored after line 2034.

It's caused by \Tex {\ifabsnum}

How to do this?

It seems \type doesn't handle \iffoo ... Hans? Best Martin -- http://www.tm.oneiros.de

Hartmut Henkel

1:24 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

On Tue, 14 Feb 2006, Martin Schröder wrote:

...

On 2006-02-14 20:42:40 +0100, Hartmut Henkel wrote:

...
On Tue, 14 Feb 2006, [UTF-8] Pawe? Jackowski wrote:

...
...
...
2. \ifabsnum, \ifabsdim; eTeX manual or pdfTeX manual? The pdfTeX manual is the right (only) place.

Done.

newest CVS manual with newest cont-tmf.zip stops compiling here with

subsubject : - Expandable commands [16.14]) ! Incomplete \ifx; all text was ignored after line 2034.

It's caused by \Tex {\ifabsnum}

How to do this?

It seems \type doesn't handle \iffoo ...

yes, this works \starttext \def\foo#1{\type{#1}} {\catcode`\i=12 \foo {\ifabsnum} } {\def\ifabsnum{\relax} \foo {\ifabsnum} } \stoptext but it's ugly.

...

Hans?

Hans? Regards, Hartmut

Hans Hagen

2:05 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

Hartmut Henkel wrote:

...

On Tue, 14 Feb 2006, Martin Schr�der wrote:

...
On 2006-02-14 20:42:40 +0100, Hartmut Henkel wrote:

...
On Tue, 14 Feb 2006, [UTF-8] Pawe? Jackowski wrote:

...
...
...
2. \ifabsnum, \ifabsdim; eTeX manual or pdfTeX manual?

The pdfTeX manual is the right (only) place.

Done.

newest CVS manual with newest cont-tmf.zip stops compiling here with

subsubject : - Expandable commands [16.14]) ! Incomplete \ifx; all text was ignored after line 2034.

It's caused by \Tex {\ifabsnum}

How to do this?

It seems \type doesn't handle \iffoo ...

yes, this works

\starttext \def\foo#1{\type{#1}}

{\catcode`\i=12 \foo {\ifabsnum} }

{\def\ifabsnum{\relax} \foo {\ifabsnum} }

\stoptext

but it's ugly.

hm, this works here, \def\xx#1{\type{#1}} \starttext \xx {\ifabsnum} \stoptext so, how old is your context? (there has been a bug in the code for a while due to a faulty fix that dealt with verbatim and tables) (in case f real trouble one can configure a few things using \recodeverbatimmode; the problem with verbatim mode is that it also supports syntax highlighting and such and there is no real robust way to cover all situations at the same time) 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 Schröder

2:10 p.m.

New subject: 1.40 Manual

On 2006-02-14 22:05:28 +0100, Hans Hagen wrote:

...

so, how old is your context? (there has been a bug in the code for a while due to a faulty fix that dealt with verbatim and tables)

teTeX 3.0 ConTeXt ver: 2005.01.31 I want a TeX package manager... :-(( Best Martin -- http://www.tm.oneiros.de

Hans Hagen

3:24 p.m.

New subject: 1.40 Manual

Martin � wrote:

...

On 2006-02-14 22:05:28 +0100, Hans Hagen wrote:

...
so, how old is your context? (there has been a bug in the code for a while due to a faulty fix that dealt with verbatim and tables)

teTeX 3.0 ConTeXt ver: 2005.01.31

I want a TeX package manager... :-((

aka miktex -) 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 -----------------------------------------------------------------

Hartmut Henkel

2:20 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

On Tue, 14 Feb 2006, Hans Hagen wrote:

...

hm, this works here,

\def\xx#1{\type{#1}}

\starttext

\xx {\ifabsnum}

\stoptext

so, how old is your context? (there has been a bug in the code for a while due to a faulty fix that dealt with verbatim and tables)

it's ConTeXt ver: 2006.02.03 21:03 fmt: 2006.2.14 int: english mes: english Just downloaded it today. Regards, Hartmut

Taco Hoekwater

2:47 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

Hartmut Henkel wrote:

...

On Tue, 14 Feb 2006, Hans Hagen wrote:

...
hm, this works here,

\def\xx#1{\type{#1}}

\starttext \xx {\ifabsnum} \stoptext

Sure, but that is because your \ifabsnum is an undefined control sequence, since you are still using 1.30.5 :-) Here is a bit of equivalent plain TeX code that crashes in the same fashion: \def\xx#1{\type{#1}} \starttext \xx {\iffalse} \stoptext The simplest solution (for now) is to start pdftex-t.tex with : \let\ifabsnum\relax \let\ifabsdim\relax Cheers, Taco

Hartmut Henkel

2:31 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

On Tue, 14 Feb 2006, Hans Hagen wrote:

...

hm, this works here,

\def\xx#1{\type{#1}}

\starttext

\xx {\ifabsnum}

Hans, does your pdftex version already know about \ifabsnum?

...

\stoptext

Regards, Hartmut

Hans Hagen

2:40 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

Hartmut Henkel wrote:

...

On Tue, 14 Feb 2006, Hans Hagen wrote:

...
hm, this works here,

\def\xx#1{\type{#1}}

\starttext

\xx {\ifabsnum}

Hans, does your pdftex version already know about \ifabsnum?

no, i'm on windows and will only ask fabrice to make new binaries when i have the impression that there is something stable; as long as the codebase is not really multi platform i don't want to bother him with messy merges 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 -----------------------------------------------------------------

Hans Hagen

2:41 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

Hartmut Henkel wrote:

...

On Tue, 14 Feb 2006, Hans Hagen wrote:

...
hm, this works here,

\def\xx#1{\type{#1}}

\starttext

\xx {\ifabsnum}

Hans, does your pdftex version already know about \ifabsnum?

you can try \chardef\recodeverbatimmode\plusone (grouped since we don't want to affect other verbatim code) 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 Schröder

2:46 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

On 2006-02-14 22:31:13 +0100, Hartmut Henkel wrote:

...

Hans, does your pdftex version already know about \ifabsnum?

Doesn't matter: \iftrue on line 2033 will also fail. Best Martin -- http://www.tm.oneiros.de

Hans Hagen

3:04 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

Martin � wrote:

...

On 2006-02-14 22:31:13 +0100, Hartmut Henkel wrote:

...
Hans, does your pdftex version already know about \ifabsnum?

Doesn't matter: \iftrue on line 2033 will also fail.

i have an idea for a workaroud but it needs some testing, 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 -----------------------------------------------------------------

Hans Hagen

1:57 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

Martin � wrote:

...

It seems \type doesn't handle \iffoo ...

Hans?

hm, it does here in a test file, but depending on arg passing verbatim is always a bit tricky (tex doing tex -) 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 -----------------------------------------------------------------

Hartmut Henkel

4:29 p.m.

New subject: 1.40 Manual (was 1.40 Schedule)

There are quite a few places in the manual where pdftex and pdfetex are mentioned. Should we remove the pdfetex references (leaving one remark at the beginning about history)? And it's now that pdftex includes all pdfetex functionality, and the extended format writing can still be enabled by the asterisk *, right? Regards, Hartmut

Martin Schröder

4:46 p.m.

New subject: 1.40 Manual

On 2006-02-15 00:29:07 +0100, Hartmut Henkel wrote:

...

There are quite a few places in the manual where pdftex and pdfetex are mentioned. Should we remove the pdfetex references (leaving one remark at the beginning about history)? And it's now that pdftex includes all

Yes.

...

pdfetex functionality, and the extended format writing can still be enabled by the asterisk *, right?

Yes. And -etex :-) Best Martin -- http://www.tm.oneiros.de

Hartmut Henkel

15 Feb 15 Feb

11:50 a.m.

New subject: 1.40 Manual

On Wed, 15 Feb 2006, Martin Schröder wrote:

...

...
pdfetex functionality, and the extended format writing can still be enabled by the asterisk *, right?

Yes. And -etex :-)

Does this work with your system? I just tried in fmtutil.cnf: pdfetex pdftex - -translate-file=cp227.tcx -etex pdftex.ini does _not_ switch to etex mode here. But pdfetex pdftex - -translate-file=cp227.tcx *pdftex.ini does it ok. Regards, Hartmut

Hartmut Henkel

11:58 a.m.

New subject: 1.40 Manual

On Wed, 15 Feb 2006, Hartmut Henkel wrote:

...

pdfetex pdftex - -translate-file=cp227.tcx -etex pdftex.ini

actually it says: hahepc1:/home/hahe# pdftex -ini -etex -jobname=pdfetex -progname=pdfetex -translate-file=cp227.tcx pdftex.ini pdftex: unrecognized option `-etex' This is pdfTeXk, Version 3.141592-1.40.0-beta-20060213 (Web2C 7.5.5) (INITEX) Regards, Hartmut

Hartmut Henkel

12:05 p.m.

New subject: 1.40 Manual

On Wed, 15 Feb 2006, Hartmut Henkel wrote:

...

On Wed, 15 Feb 2006, Hartmut Henkel wrote:

...
pdfetex pdftex - -translate-file=cp227.tcx -etex pdftex.ini

actually it says:

hahepc1:/home/hahe# pdftex -ini -etex -jobname=pdfetex -progname=pdfetex -translate-file=cp227.tcx pdftex.ini pdftex: unrecognized option `-etex' This is pdfTeXk, Version 3.141592-1.40.0-beta-20060213 (Web2C 7.5.5) (INITEX)

ah, Akira's patch (after 20060213) should solve this. Sorry for the noise. Regards, Hartmut

Paweł Jackowski

12:23 a.m.

New subject: 1.40 Manual (was 1.40 Schedule)

Hi,

...

! Incomplete \ifx; all text was ignored after line 2034.

Seems I had the same problem with ConTeXt taken from last TL; as Taco advised, I upgraded (to 2006.02.03) and now it works fine.

...

There are quite a few places in the manual where pdftex and pdfetex are mentioned. Should we remove the pdfetex references (leaving one remark at the beginning about history)? And it's now that pdftex includes all pdfetex functionality, and the extended format writing can still be enabled by the asterisk *, right?

Ye, I didn't touch this part since I still can't force -etex option to work. Akira says however, that his binary works ok so og ahead. Regards, -- Pawe/l Jackowski P.Jackowski@gust.org.pl

Hans Hagen

1:53 a.m.

New subject: 1.40 Manual (was 1.40 Schedule)

Hartmut Henkel wrote:

...

There are quite a few places in the manual where pdftex and pdfetex are mentioned. Should we remove the pdfetex references (leaving one remark at the beginning about history)? And it's now that pdftex includes all pdfetex functionality, and the extended format writing can still be enabled by the asterisk *, right?

makes sense indeed 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 -----------------------------------------------------------------

Hans Hagen

14 Dec 14 Dec

6:29 a.m.

Martin � wrote:

...

Hi, this weekend I've met Hans, Hartmut and Taco in Schwetzingen (we attended the christmas party of the Darmstadt TeXies with Hermann Zapf) and we discussed the status and future of pdfTeX.

We came down with this "roadmap":

1.40 (200603): - all the current patches plus \primitive et.al - cleanup the code (fewer patchfiles) to have a better starting point for lua - move project to Gforge hosted by Fabrice, and setup a complete code repository there - start of "pdfTeX news"

maybe also add hz support for ttf fonts (currently limited to type1; why?) Hans

Reinhard Kotucha

10:04 p.m.

...

...
...
...
...
"Hans" == Hans Hagen writes:

...

maybe also add hz support for ttf fonts

...

(currently limited to type1; why?)

The hz algorithm changes the FontMatrix of the font. The FontMatrix is a property of a Type1 font. If you want to do it in a more general way you have to change the PDF text matrix. But though this had been done in dvipdfm, it's not easy. BTW., for the same reason ExtendFont and SlantFont do not work with TTF. Changing the text matrix would be better because currently a font is included more than once if font expansion is used. There is another nasty thing: CFF fonts can have a single font with different font matrices, but there is a restriction in the PDF spec which allows only one FontMatrix for a particular CFF font. Changing the text matrix would have a few advantages: * The file size will be significantly smaller. This did not matter in the past because very few people used font expansion, but with the advent of \autoexpand and microtype.sty it will affect many files now. * ExtendFont and SlantFont will work with TTF fonts as well. * If dvi output is required, pdftex can insert a \special which changes PostScript's matrix in a similar way as it does it for pdf output. This will not work for TTF in dvips, though. Hans, you are the second one who asked (I asked Thanh a few years ago), so I think that the priority is not very high. I think that it should be put on a TODO list. I also recommend to look into Mark Wick's sources. He already solved this problem. What is needed to make dvips able to process TTF? If no subsetting is required, will dvips be able to deal with Type42? Type42 can be created from TTF on-the-fly. Is it difficult to insert the pdftex TTF subsetting code into dvips? It is useful to care about dvi output and dvips because many people ask how to use psfrag and using dvips -E and epstopdf is a simple solution. 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. ----------------------------------------------------------------------------

Hans Hagen

15 Dec 15 Dec

8:44 a.m.

Reinhard Kotucha wrote:

...

Hans, you are the second one who asked (I asked Thanh a few years ago), so I think that the priority is not very high.

well, how about deciding now that it has a high priority; we need to go that direction anyway because soon open type will take over also, as you say, now that pdftex generates the instances itself, hz has become feasible also, when you and i want it, it becomes hard for thanh to ignore it -) since thanh is 'on leave' maybe hartmut sees it as a challenge ... btw, thanks for the explanation Hans

Reinhard Kotucha

17 Dec 17 Dec

8:50 p.m.

...

...
...
...
...
"Hans" == Hans Hagen writes:

...

Reinhard Kotucha wrote:

...
Hans, you are the second one who asked (I asked Thanh a few years ago), so I think that the priority is not very high.

well, how about deciding now that it has a high priority; we need to go that direction anyway because soon open type will take over

...

also, as you say, now that pdftex generates the instances itself, hz has become feasible

...

also, when you and i want it, it becomes hard for thanh to ignore it -)

Thanh didn't ignore it, I asked at a time (spring 2002) when he had absolutely no time to work on pdftex. But I remember that we also spoke about problems like rounding errors, especially when fonts with different transformation matrices are nested. 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. ----------------------------------------------------------------------------

Martin Schröder

22 Dec 22 Dec

4:55 a.m.

New subject: dvipdfmx (was: Roadmap)

On 2005-12-13 13:52:30 +0100, Martin Schröder wrote:

...

1.40 (200603): - all the current patches plus \primitive et.al - cleanup the code (fewer patchfiles) to have a better starting point for lua - move project to Gforge hosted by Fabrice, and setup a complete code repository there - start of "pdfTeX news"

1.50 - more bits, i.e. use more than 16 (and enough) where possible

1.60 or later - general map file handling for pdfTeX and all programs that use map files - OpenType -- this requires more bits and can be done in steps - lua -- integration can be done post 1.40, but the TeX<->Lua interface needs much testing and developement, so lua will stay experimental for quite some time

sometime (i.e. whenever it's ready) - tagged pdf - merging hyperlinks in included documents

Btw: We talked about dvipdfmx. When will pdftex have all of it's features? I vaguely remember that we are not missing very much. Best Martin -- http://www.tm.oneiros.de

Hans Hagen

7:50 a.m.

New subject: dvipdfmx

Martin � wrote:

...

On 2005-12-13 13:52:30 +0100, Martin Schr�der wrote:

...
1.40 (200603): - all the current patches plus \primitive et.al - cleanup the code (fewer patchfiles) to have a better starting point for lua - move project to Gforge hosted by Fabrice, and setup a complete code repository there - start of "pdfTeX news"

1.50 - more bits, i.e. use more than 16 (and enough) where possible

1.60 or later - general map file handling for pdfTeX and all programs that use map files - OpenType -- this requires more bits and can be done in steps - lua -- integration can be done post 1.40, but the TeX<->Lua interface needs much testing and developement, so lua will stay experimental for quite some time

1.70

- take relevant bit and pieces of aleph, esp r-l typesetting so that pdftex+lua can replace aleph - additional font features (beyond open type) - lua input preprocessing (replacement for otp's)

...

...
sometime (i.e. whenever it's ready) - tagged pdf - merging hyperlinks in included documents

Btw: We talked about dvipdfmx. When will pdftex have all of it's features? I vaguely remember that we are not missing very much.

there is this cid stuff (thanh wanted to add those unicode vectors automatically) Hans

Vladimir Volovich

12:48 p.m.

New subject: dvipdfmx

"HH" == Hans Hagen writes: HH> 1.70 HH> - take relevant bit and pieces of aleph, esp r-l typesetting so HH> that pdftex+lua can replace aleph also very essential part of omega/aleph are the 16-bit fonts (or even 32-bit?). HH> - additional font features (beyond open type) - lua input HH> preprocessing (replacement for otp's) will lua provide input processing as powerful as OTPs? Best, v.

Hans Hagen

2:01 p.m.

New subject: dvipdfmx

Vladimir Volovich wrote:

...

"HH" == Hans Hagen writes:

HH> 1.70

HH> - take relevant bit and pieces of aleph, esp r-l typesetting so HH> that pdftex+lua can replace aleph

also very essential part of omega/aleph are the 16-bit fonts (or even 32-bit?).

that's where open type comes in

...

HH> - additional font features (beyond open type) - lua input HH> preprocessing (replacement for otp's)

will lua provide input processing as powerful as OTPs?

i dunno, but it will definitely be easier (and documented) Hans

Vladimir Volovich

2:38 p.m.

New subject: dvipdfmx

"HH" == Hans Hagen writes: HH> - take relevant bit and pieces of aleph, esp r-l typesetting so HH> that pdftex+lua can replace aleph

...

...
also very essential part of omega/aleph are the 16-bit fonts (or even 32-bit?). HH> that's where open type comes in

in my understanding it is essential to have "font 16-bitness" on the abstract level of TeX (i.e. metric features; specific glyph representation is very much secondary), not connected to any specific font format like Opentype. TeX has always been independent of physical font formats, and that is it's strength... [and omega's 16-bit fonts are no exception] HH> - additional font features (beyond open type) - lua input HH> preprocessing (replacement for otp's)

...

...
will lua provide input processing as powerful as OTPs? HH> i dunno, but it will definitely be easier (and documented)

are there any preliminary considerations or descriptions of how it will work (of course not detailed - just to understand the proposed idea of such a replacement of OTPs)? Best, v.

Hans Hagen

3:02 p.m.

New subject: dvipdfmx

Vladimir Volovich wrote:

...

"HH" == Hans Hagen writes:

HH> - take relevant bit and pieces of aleph, esp r-l typesetting so HH> that pdftex+lua can replace aleph

...
...
also very essential part of omega/aleph are the 16-bit fonts (or even 32-bit?). HH> that's where open type comes in

in my understanding it is essential to have "font 16-bitness" on the abstract level of TeX (i.e. metric features; specific glyph representation is very much secondary), not connected to any specific font format like Opentype.

well, if you only want metric info then \wdcode, \htcode, \dpcode,\iccode, \whatevercode can also be a solution (pdftex already has many \*codes associated with characters)

...

TeX has always been independent of physical font formats, and that is it's strength... [and omega's 16-bit fonts are no exception]

but -since many fonts don't demand much control- it's also a weakness that tex cannot handle for instance afm files directly. since tfm compatibility will remain, some kind of 32 bit native tex format will probably show up (in the past there has been discussions about reading property lists which are extendible instead of tfm files); now that pdftex offers many font related features, it may as well make sense to control such things at the macro level on top of regular fonts and not using a dedicated font format; so, whatever will happen, there will be much control over fonts and how they are used, but a more native and direct support will also be provided.

...

HH> - additional font features (beyond open type) - lua input HH> preprocessing (replacement for otp's)

...
...
will lua provide input processing as powerful as OTPs? HH> i dunno, but it will definitely be easier (and documented)

are there any preliminary considerations or descriptions of how it will work (of course not detailed - just to understand the proposed idea of such a replacement of OTPs)?

no, and it's currently also not under discussion, just under consideration; also, overloading and plugins is part of the game (btw i never could find a clear description / explanation of otp's which makes it a mechanism for a happy few while in fact we need mechanisms for the many) Hans

Reinhard Kotucha

4:26 p.m.

New subject: dvipdfmx

...

...
...
...
...
"Vladimir" == Vladimir Volovich writes:

...

also very essential part of omega/aleph are the 16-bit fonts (or even 32-bit?).

It's certainly better to start with 32 bit rather than to look for volunteers in a few years. 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. ----------------------------------------------------------------------------

6726

Age (days ago)

6790

Last active (days ago)

List overview

Download

68 comments

10 participants

participants (10)

Hans Hagen
Hartmut Henkel
Heiko Oberdiek
Martin Schröder
Olaf Weber
Paweł Jackowski
Reinhard Kotucha
Staszek Wawrykiewicz
Taco Hoekwater
Vladimir Volovich