[ANN] star-tex: a Go engine for TeX

[Sebastien Binet]

hi there,

I'd like to introduce star-tex[1], a (Work In Progress) TeX engine.

it wraps the output of the official texlive tex.w WEB file (ie: C/C++
files) as a CGo package.

the idea is to replace in an adiabatical fashion the C bits with their
Go equivalent.

there's already code that can correctly decode TeX Font metrics files.

$> go get git.sr.ht/~sbinet/star-tex/cmd/star-tex

$> star-tex ./testdata/hello.tex out.div
$> dvipdf out.dvi
$> pdf out.pdf


PR and patches welcomed :)

-s

[1]: https://sr.ht/~sbinet/star-tex

[Patrick]

Hi Sebastien,

a few years ago I started with dvitype

https://github.com/speedata/gotex

Patrick

[Sebastien Binet]

Hi Patrick,

Nice!

Did you manually translated it or was it done with some tooling?

-s

-------- Original Message --------

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/53f9b35a-eedd-401c-9b7d-8d1bf7dd9977n%40googlegroups.com.

[Patrick]

Hi Sebastien,

that was a manual translation of the web file. My plan was to do more than that, ... TeX is such a beast.

Patrick

[Sebastien Binet]

yeah... "how hard would it be to translate ~20k lines of C/C++ code (or
6k lines of obfuscated Pascal code) into a set of nicely structured Go
packages" ? :)

my initial strategy to have something working in a mixture of Go and
C/C++ (I am in the middle of getting rid of the C++ part), is OK to get
some PDFs out of the gate, but I think I need to invest in the tooling
to do the automatic web->Go translation. (either web->Pascal->Go or
web->C->Go.)
tex.web doesn't change too much nor too often, but 3.141592653 was just
"released" after I had started my C/C++->Go migration (bummer), so it
does happen.

-s

[Patrick]

My problem with the TeX code base was that TeX is mainly spaghetti code (once untangled) and has many places where one would rather use Go code instead of the 'hacks' DEK has used to ensure compatibility (for example the ASCII input/output). So it is really hard to follow the code. 

And from there it is still only possible to read / write 8bit TFM/DVI. So a more modern approach would be to translate LuaTeX or PDFTeX, but this aint easy either.

Patrick

[Sebastien Binet]

On Sun Feb 21, 2021 at 18:19 CET, Patrick wrote:
> My problem with the TeX code base was that TeX is mainly spaghetti code
> (once untangled) and has many places where one would rather use Go code
> instead of the 'hacks' DEK has used to ensure compatibility (for example the
> ASCII input/output). So it is really hard to follow the code.
>
> And from there it is still only possible to read / write 8bit TFM/DVI.
> So a more modern approach would be to translate LuaTeX or PDFTeX,
> but this aint easy either.

right. it's also (at least for LuaTeX) not written in a BSD friendly
license.

I agree, it's a long journey.

-s

[Bakul Shah]

On Feb 21, 2021, at 9:14 AM, Sebastien Binet <s...@sbinet.org> wrote:
>
> On Sun Feb 21, 2021 at 17:46 CET, Patrick wrote:
>> Hi Sebastien,
>>
>> that was a manual translation of the web file.
>> My plan was to do more than that, ... TeX is such a beast.
>
> yeah... "how hard would it be to translate ~20k lines of C/C++ code (or
> 6k lines of obfuscated Pascal code) into a set of nicely structured Go
> packages" ? :)

Aren't you supposed to read Knuth's TeX: The Program book instead of
the 6k lines of Pascal?!

Also, I don't understand why anyone would want to do that.

>
> my initial strategy to have something working in a mixture of Go and
> C/C++ (I am in the middle of getting rid of the C++ part), is OK to get
> some PDFs out of the gate, but I think I need to invest in the tooling
> to do the automatic web->Go translation. (either web->Pascal->Go or
> web->C->Go.)

Doesn't web2c directly translate the web sources to C?

[Sebastien Binet]

On Sun Feb 21, 2021 at 18:54 CET, Bakul Shah wrote:
> On Feb 21, 2021, at 9:14 AM, Sebastien Binet <s...@sbinet.org> wrote:
> >
> > On Sun Feb 21, 2021 at 17:46 CET, Patrick wrote:
> >> Hi Sebastien,
> >>
> >> that was a manual translation of the web file.
> >> My plan was to do more than that, ... TeX is such a beast.
> >
> > yeah... "how hard would it be to translate ~20k lines of C/C++ code (or
> > 6k lines of obfuscated Pascal code) into a set of nicely structured Go
> > packages" ? :)
>
>
> Aren't you supposed to read Knuth's TeX: The Program book instead of
> the 6k lines of Pascal?!

of course, reading the thorough documentation is always a good thing.
but why spend the time to re-write something that works from scratch
instead of trying to to automatically, mecanically, translate it to some
target?

the way I see it, anyone who wants to have a TeX engine in language XYZ,
has 3 broad choices:
a) write from scratch, reading the TeX book documentation;
this will produce a new engine that will have its own set of bugs, and
can be called a "real" TeX engine only when it passes the "trip" test,
b) write the tooling to translate the WEB "specification" into language
XYZ (either directly from WEB, which, in the case of tex.web is a
Pascal dialect, or from the already targeted languages: Pascal, C or C++)
c) wrap the output of one of the already targeted languages in the desired
language XYZ.

I went with c) first as it seemed the best strategy to have something
working, with the "full" pipeline enabled, allowing to have the usual
"edit && go test ./..." refactor cycle at the ready.

>
> Also, I don't understand why anyone would want to do that.
>
> >
> > my initial strategy to have something working in a mixture of Go and
> > C/C++ (I am in the middle of getting rid of the C++ part), is OK to get
> > some PDFs out of the gate, but I think I need to invest in the tooling
> > to do the automatic web->Go translation. (either web->Pascal->Go or
> > web->C->Go.)
>
> Doesn't web2c directly translate the web sources to C?

yes.
but it does so with a lot of global state, preventing the output to be
(easily) used as a library.

I figured the adiabatical migration from a C++ output to a C one and
then to a pure-Go one would be easier (migrating each C++ class field to
a C struct field, each C++ method to a C-struct+func one, etc...) - a
process that could be done piece-wise, while still maintaining the
"go test ./..." green light at each commit (instead of a big bang
migration.)

those were my assumptions and work hypotheses.
I of course can't claim they will hold true for the complete process :)

-s