3 ms·
From the blog posts, it looks like they were still deciding what language to write this idea in.
by salamanderman 5y ago
From the blog posts, it looks like they were still deciding what language to write this idea in.
- dhosek 5y agoI'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 incorporated as development continues.
- jamincan 5y agoOut of curiousity, did you look at nom at all for parsing?
- dhosek 5y agoI 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.