Hi,

how diffcult could it possibly be to fully integrate TeX

(and, for that matter, pdftex) as a subset of ruby?

Essentially, TeX is just some trivial arithmetic.

Maybe pdftex is a bit more complex.

Regards,

Piero

Hi,

how diffcult could it possibly be to fully integrate TeX

(and, for that matter, pdftex) as a subset of ruby?

What do you mean by that ? Do you want to produce Pdf files formatted

by Tex from within ruby ? Or do you want to be able to make a LaTeX

document using Ruby to write macros, like PerlTex ?

http://www.tug.org/tex-archive/help/Catalogue/entries/perltex.html

In either case, I don’t believe it’s less than a few month

more-than-fulltime work.

Essentially, TeX is just some trivial arithmetic.

Maybe it is trivial, but I don’t believe it to be small, and I have a

strong feeling that the author was not writing code for nothing…

```
Vince
```

Well, perltex basically extends TeX: you work

inside TeX, then at some point you go out, do

someting in perl, then go back in TeX. In some

sense this is already present in the original

implementation of TeX (via write18 stuff etc).

What I mean is: would it be possible to completely

dispense with TeX? I mean, to produce a dvi file from

inside ruby, using a syntax as close as possible

to TeX’s. Or to produce a pdf output via commands

close to pdftex’s. Of course I can easily write some

ruby code which outputs a .tex file and then asks TeX

to compile it, but that would be pointless.

Why I am asking: TeX’s algorithms (paragraph

formatting, hyphenation, math formatting etc) are

close to optimal, and having them at hand would

be much more useful that leaving them buried inside

the TeX program (or pdftex). One simple application

could be to insert beautifully formatted formulas

into any document; or, one might play with the

basics of TeX and produce a superTeX with more

bells and whistles. In any case, every ruby programmer

could play wiih TeX and expand or simply use its

algorithms.

Just dreaming,

Piero

[email protected] wrote:

Why I am asking: TeX’s algorithms (paragraph

formatting, hyphenation, math formatting etc) are

close to optimal, and having them at hand would

be much more useful that leaving them buried inside

the TeX program (or pdftex).

Yes, unless the effort required to recreate the TeX algorithms is unduly

onerous, and unless no sane person would be willing to undertake the

task

of converting the code.

One simple application

could be to insert beautifully formatted formulas

into any document; or, one might play with the

basics of TeX and produce a superTeX with more

bells and whistles. In any case, every ruby programmer

could play wiih TeX and expand or simply use its

algorithms.

In principle, yes, all you say is true – one could recreate all TeX

processing in plain Ruby code. But it would probably be very slow, and

it

would be a case of reinventing the wheel.

Just dreaming,

Fair enough. Have you considered reducing your idea to practice, by

recreating the TeX engine in Ruby? It’s one think to speculate about

such a

thing, it’s quite another to write and test the code.

On Sun, Dec 10, 2006 at 03:00:05AM +0900, Paul L. wrote:

of converting the code.

I think you misunderstood what he was saying. I think he wants ruby

bindings to TeX at the level below the TeX syntax (IOW instead of

producing TeX and piping it thru pdftex, link to libtex (I don’t think

there is such a thing)). He doesn’t want to reimplement TeX in ruby.

would be a case of reinventing the wheel.

*reiterates what I said above*

Just dreaming,

Fair enough. Have you considered reducing your idea to practice, by

recreating the TeX engine in Ruby? It’s one think to speculate about such a

thing, it’s quite another to write and test the code.

Again, I don’t think this is what he’s going for.

On Dec 9, 9:50 am, [email protected] wrote:

Hi,

how diffcult could it possibly be to fully integrate TeX

(and, for that matter, pdftex) as a subset of ruby?

Essentially, TeX is just some trivial arithmetic.

Maybe pdftex is a bit more complex.

Regards,

Piero

Actually the luaTeX project is the result of similar concerns and

needs. It’s being developed by fans of Ruby but lua was chosen for

embedding in the TeX engine itself for a number of reasons (much

smaller for one thing, and also that lua was designed for just this

sort of thing).

Check out

https://foundry.supelec.fr/frs/?group_id=10

There is a manual in there as well.

At the macropackage level (eg ConTeXt) Ruby plays a much more important

role.

luaTeX is the most important development (at the engine level) in TeX

in years so check it out!

Take care

Idris

Hi,

On Dec 9, 9:50 am, [email protected] wrote:

Essentially, TeX is just some trivial arithmetic.

Not so, designing/implementing its algorithms provided more than one

gradaate student with his doctorate

Look up the collection Digital Typography by Knuth to see just how

non-trivial TeX is…

Best

Idris

Hi Piero,

On Dec 9, 9:50 am, [email protected] wrote:

Essentially, TeX is just some trivial arithmetic.

Not so, designing/implementing its algorithms provided more than one

gradaate student with his doctorate

Look up the collection Digital Typography by Knuth to see just how

non-trivial TeX’s arithmetic is…

Best

Idris

Hi,

On Dec 9, 9:50 am, [email protected] wrote:

Essentially, TeX is just some trivial arithmetic.

Not so, designing/implementing its algorithms provided more than one

gradaate student with his doctorate

Look up the collection Digital Typography by Knuth to see just how

non-trivial TeX is…

Best

Idris

“ishamid” [email protected] writes:

smaller for one thing, and also that lua was designed for just this

luaTeX is the most important development (at the engine level) in

TeX in years so check it out!

Does that mean that you have given up on Omega?

ishamid wrote:

Hi,

On Dec 9, 9:50 am, [email protected] wrote:

Essentially, TeX is just some trivial arithmetic.

gradaate student with his doctorate

Hey, I did not want to sound dismissive. I read

the TeXbook quite thoroughly (if you have heard

of pdfsync.sty, I wrote the first iteration of it

and consider TeX and the work behind it one

of the gems around here. That said, after all

this work, TeX’s algorithms are now a bunch

of trivial arithmetic, and they should be easy

to replicate in any language…

Thank you for the pointer to luatex. I would have

liked so much something inside ruby but I guess

they also gave a thought to it and decided for

the better

Piero

David K. wrote:

Well, I don’t want to sound dismissive either. I read TeX, the

Program, quite thoroughly, and I contributed the last iteration of

pdfsync.sty because it broke too many of my tools and packages.

:))) Well David, that’s a little dismissive, but you’re one of the

5-or-so ubermasters of TeX and I must just take it. Sorry.

In 2003 people were constantly complaining that they missed

TeXtures so much and how it was wonderful with synchro etc etc.

I started to think a little and came up with this idea.

Tried to convince a couple of TeX gurus, no answer from them,

so I cooked up a quick and dirty style file that sort of worked,

just to entice someone better than me to do something better.

(I’m no coder, just a mathematician!

Sorry that your contribution was kind of extorted, though…

In a similar vein, ports of TeX tend to be just TeX, nothing else,

and/or not useful. And in particular, not pretty, and that means that

nobody bothers working with the results.

That’s a clear answer: porting TeX is not remotely trivial,

and just the wrong thing to do. I was more thinking

of porting selected pieces of TeX, but probably the tangle

(or the web) is too tight.

At the current point of time there are two projects that are somewhat

interesting in that regard: ExTeX (Java again, TeX compatible) and Ant

(OCaml currently, TeX inspired, can work with LaTeX files to some

degree IIRC).

Why Java again? maybe because at the time ruby or python

were not so well accepted?

Thank you for the pointer to Ant, I’ll take a look at it.

Piero

[email protected] writes:

David K. wrote:

Well, I don’t want to sound dismissive either. I read TeX, the

Program, quite thoroughly, and I contributed the last iteration of

pdfsync.sty because it broke too many of my tools and packages.:))) Well David, that’s a little dismissive,

Oh, and I so tried following your lead.

but you’re one of the 5-or-so ubermasters of TeX and I must just

take it. Sorry. In 2003 people were constantly complaining that

they missed TeXtures so much and how it was wonderful with synchro

etc etc. I started to think a little and came up with this idea.

Tried to convince a couple of TeX gurus, no answer from them, so I

cooked up a quick and dirty style file that sort of worked, just to

entice someone better than me to do something better. (I’m no

coder, just a mathematician! Sorry that your contribution was

kind of extorted, though…

Well, these days I don’t produce much apart from the extorted things,

so…

In a similar vein, ports of TeX tend to be just TeX, nothing else,

and/or not useful. And in particular, not pretty, and that means

that nobody bothers working with the results.That’s a clear answer: porting TeX is not remotely trivial,

and just the wrong thing to do. I was more thinking

of porting selected pieces of TeX, but probably the tangle

(or the web) is too tight.

It’s not easy to do. TeXmacs URL:http://www.texmacs.org apparently

implemented quite a number of TeX-based algorithms in either C or

Scheme. But that probably does not meddle with TeX’s grouping,

expansion and variable model mess.

At the current point of time there are two projects that are

somewhat interesting in that regard: ExTeX (Java again, TeX

compatible) and Ant (OCaml currently, TeX inspired, can work with

LaTeX files to some degree IIRC).Why Java again? maybe because at the time ruby or python were not so

well accepted?

Basically it was what the project lead felt comfortable with.

Thank you for the pointer to Ant, I’ll take a look at it.

It was in Scheme at some earlier point of time IIRC, then moved to

OCaml, likely for performance reasons.

[email protected] writes:

the TeXbook quite thoroughly (if you have heard

of pdfsync.sty, I wrote the first iteration of it

Well, I don’t want to sound dismissive either. I read TeX, the

Program, quite thoroughly, and I contributed the last iteration of

pdfsync.sty because it broke too many of my tools and packages.

and consider TeX and the work behind it one

of the gems around here. That said, after all

this work, TeX’s algorithms are now a bunch

of trivial arithmetic, and they should be easy

to replicate in any language…

After all the work, *any* algorithm is just trivial combination of 0s

and 1s. There is never any magic involved, and one can replicate the

work in any language.

But that is not actually a question worth considering, and the various

TeX user groups paid a large price to learn this lesson: NTS was a

commissioned complete port of TeX to Java. The idea was that Java,

instead of the original idiosyncratic Pascal dialect, would lend

itself better to extension and modification.

Which turned out about as successful as porting a violin solo cantata

of Bach to the piano. It is already harmonically complete, and there

is nothing you can sensibly add to it.

One problem is that Knuth uses Pascal like assembly language. The

actual data structures manipulated are not the data structures of

Pascal, but rather Patricia trees, various kinds of linked lists

implemented without pointers and/or new, self-implemented memory

management and allocation using reference counts, compressed hash

tables and so on. And most of the data structures are tied into the

table of equivalents, meaning that they obey TeX’s group structure.

There is a saying “a bad programmer can write Fortran in any language”

which actually is an understatement if you compare “Numerical Recipes”

and “Numerical Recipes in C”: perfectly useful Fortran in the former

got translated into an inefficient abomination of C in the latter

(array indices still starting at 1, 2-dimensional arrays implemented

by row pointer indirection instead of pointer arithmetic and so on).

In a similar vein, ports of TeX tend to be just TeX, nothing else,

and/or not useful. And in particular, not pretty, and that means that

nobody bothers working with the results.

At the current point of time there are two projects that are somewhat

interesting in that regard: ExTeX (Java again, TeX compatible) and Ant

(OCaml currently, TeX inspired, can work with LaTeX files to some

degree IIRC). At least the latter seems to have reached a state where

fiddling with the internals makes sense.