Live data from Hacker News

Finl is not LaTeX

finl.xyz

41–47 of 47 posts

Re: Finl is not LaTeX

#41

> It’s time to separate out the language for formatting the document from the language for writing the document, so, docbook + XSLT? :)

Shudder. Haha. XSLT was actually conceptually a good idea. Just quite hard to read once written in lines and lines of XML. In the 2000s I wrote a web site in mod_perl/Axkit that used XSLT to translate pure XML files into readable XHTML 1.0 for web browsers and WAP (!) for phones.

My personal website was generated using XSLT and some perl scripts to generate mostly static HTML files. I lost the master scripts during a computer upgrade somewhere but the only parts I update these days are backed by a database and that's the stuff I need to update.

Re: Finl is not LaTeX

#42
post #15
post #8

Earlier quoted context omitted.

Not exactly. Originally LaTeX3 was going to be a complete rewrite of LaTeX2e. In the last year or so, there was essentially a declaration of surrender and LaTeX2e+expl3/xparse is now LaTeX3 but still called LaTeX2e. There will never be a LaTeX3 exactly. Some issues with LaTeX development are essentially intractable. They're doable in theory (because TeX is Turing complete), but not in practice.

> Some issues with LaTeX development are essentially intractable. Could you perhaps open this claim a little? What's wrong with the L3 programming layer? ( https://www.alanshawn.com/latex3-tutorial/ - Already integrated to the format)

It's ultimately still macro expansion. Don't get me wrong, I think that the work of Frank Mittelbach et al is nothing short of miraculous (and has been for the roughly thirty years since Frank burst upon the scene). If you look under the hood it gets clear just how tough programming in TeX macros is. I have a half-finished extension to expl3 to create a zip function that will take two lists and a macro to zip the two lists into a single list (half-finished because the motivating factor was a tex.stackexchange question and there's a similar function that's underdocumented and not a proper zip that I was able to use to provide an answer).

Re: Finl is not LaTeX

#43
post #10

Earlier quoted context omitted.

I've decided on Rust. I'm in the midst of a "short story" exploration of Rust and PDF typesetting with a replacement for gftodvi (gftopdf) which, while it will have a potential userbase in the high single digits, gives me a low-risk way to experiment with typesetting to PDF. One of the sub libraries of finl (the charsub module) will be part of this code in the 1.0 release and potentially other sub libraries will be i…

Out of curiousity, did you look at nom at all for parsing?

I have a bit. I really want to avoid writing code as much as possible. The flip side is that I've noticed that a lot of people in the Rust community are too quick to reach for a library. For gftopdf, I had someone suggest that I use nom to parse the GF byte code, but there's enough impedance mismatch and missing functionality (I don't know that 24-bit integers exist outside of Knuthian binary formats) and the functionality was simple enough (four short functions to read values of u8, u16, u24 and i32 into an i32 container, plus a read a string with a 1–3 byte length parameter at the beginning) that it didn't seem appropriate to have the overhead of an external dependency. On the flip side, I was more than happy to use anyhow, thiserror and structopt for their functionality.

I suspect though, given how input will get tokenized, though, that I may not be able to use a generic library.

Re: Finl is not LaTeX

#44

> It’s time to separate out the language for formatting the document from the language for writing the document, so, docbook + XSLT? :)

Shudder. Haha. XSLT was actually conceptually a good idea. Just quite hard to read once written in lines and lines of XML. In the 2000s I wrote a web site in mod_perl/Axkit that used XSLT to translate pure XML files into readable XHTML 1.0 for web browsers and WAP (!) for phones.

I swear there was an alternative non-XML syntax for XSLT, but now my Google-Fu seems to be failing me. Maybe I was just imagining it.

Re: Finl is not LaTeX

#45
This is so much what I am thinking each time I'm forced to write in LaTeX. But then again, there is already a ton of alternatives out there. HTML + CSS + JS for screens. Word, InDesign, Scribus for pdf.

The one thing that forces me back to LaTeX is bibtex. There is simply nothing that can replace it. Some tools come close, like Mendeley for Word, but they have issues too (like being controlled by a giant company).

I'll switch for anything that lets me markup documents, render equations, and use bibtex. At present LaTeX is the most comfortable option to do all these three, in spite of the countless issues I have with it.

Re: Finl is not LaTeX

#46
post #6

Earlier quoted context omitted.

It's real, but at very early stages. I wouldn't have posted the link yet myself.

"finl is not attempting to replicate TeX and LaTeX but to reimagine and replace it. It’s more like Java vs C++" So what will it be: Java or C++. No,... don't answer... Joke aside, LaTeX was a pain to use 20 years ago and still is, so good luck on your endeavor !

The idea being that much as Java relieves some of the pain of writing object oriented code in C++, finl relieves some of the pain of writing documents in LaTeX. It helps, of course, to have a deep understanding of TeX and LaTeX in doing so. Looking at sile, for example, on my initial look, it seems that the creators didn't fully understand LaTeX or what makes LaTeX worth re-imagining. At the risk of being insulting, it kind of feels less like C++ to Java and more like Perl to PHP, where the creators of PHP were clearly influenced by Perl, but didn't understand why Perl works the way it does.

Re: Finl is not LaTeX

#47
post #30

> Imagine if a user of Word could access a plugin that let her type \sum_{i=0}... MS Word in Office 360 provides direct support for the LaTeX syntax in formulas.

Yeah, I learned about that after I wrote that post.
Post reply on HN