Live data from Hacker News

The LaTeX cargo cult

joshparsons.net

61–70 of 134 posts

Re: The LaTeX cargo cult

#61
post #8

> LaTeX input files are proprietary to LaTeX, just as .doc is Word. The only definition of LaTeX as a language is “whatever LaTeX does”. I am sorry but I don't see this point... Everybody is free to write a parser for .tex files and use it for whatever reason they want... You are not free to do so with .doc or other proprietary format...

I don't think he understands what the word "proprietary" means. It means that the file format is secret or there are legal constraints on its use. Until recently Word documents clearly counted as prorietary, but now that microsoft has been forced to document its format to some degree .doc is listed as "controversially" proprietary on wikipedia.

http://en.wikipedia.org/wiki/Proprietary_format

Even today you will need to buy Microsoft Word to "properly" read .doc files. There are other readers (libreoffice) but they only do the basics, and in my experience they usually mangle the file.

LaTeX has never been proprietary because it has always been publicly documented.

Re: The LaTeX cargo cult

#62
post #44

I think LaTeX has one disadvantage and it is not mentioned in the linked article. It has nothing to do with this "Cargo cult" thing, which I'm not sure it used correctly in this text but nevermind that. The disadvantage is, that while LaTeX has an excellent support for PDF or PS its support for e.g. EPUB is awful. Otherwise there is nothing better to write longer text than LaTeX.

> The disadvantage is, that while LaTeX has an excellent support for PDF or PS its support for e.g. EPUB is awful. Well, yeah, but ePub is just a packaging format for HTML as input to a system that does its own layout and pagination, LaTeX is a layout/pagination system. Using it to generate ePub makes about as much sense as using ePub reading system to generate LaTeX. It'd be better to just have end-user device-side…

LaTeX is but the code of a LaTeX isn't. You should be able to create whatever you want out of it. The commands in the file (just) have to be interpret differently and yes, this "just" thing is the big point, because it is not easy, especially for a language which is as old as LaTeX.

For me it is odd, I currently rely on LaTeX for my workflow. Creating documents which includes other PDF files and a certain pre defined layout is (for me) very easy to do in LaTeX. Especially if the ground work (layout) is done.

Re: The LaTeX cargo cult

#63
So LaTeX sucks, but there's not a good alternative?

I'm in the midst of creating a document from scratch with LaTeX for the first time (as opposed to using a template provided to me) and while some things have been annoying, it's mostly been the learning curve of figuring how to do what I wanted. Tables are a mess though. It seems like I need to stitch 3 different packages together to do what I want with my tables.

Re: The LaTeX cargo cult

#64
post #54

Earlier quoted context omitted.

The doc (and docx) formats are actually very well documented, thanks to pressure from the EU: [MS-DOC]: Word (.doc) Binary File Format http://msdn.microsoft.com/en-us/library/office/cc313153(v=of... [MS-DOCX]: Word Extensions to the Office Open XML (.docx) File Format http://msdn.microsoft.com/en-us/library/dd773189(v=office.12...

Yep, having options / tags that whose definition is LITERALLY "do whatever [some ancient version of Word] does" is totes well-documented. Implementable, on the other hand, not so much...

If you don't already know how to implement them you aren't supposed to implement them. The spec even tells you not to implement them (and Microsoft does not implement them). They are there for third parties who reverse engineered ancient Word and WordPerfect formats and built tool chains around them, and want to move to a newer format but need to mark places where they depend on quirks of those ancient programs.

Here's the use case this is aimed at. Suppose I run, say, a law office, and we've got an internal document management system that does things like index and cross reference documents, manage citation lists, and stuff like that. The workflow is based on WordPerfect format (WordPerfect was for a long time the de facto standard for lawyers).

Now suppose I want to start moving to a newer format for storage. Say I pick ODF, and start using that for new documents, and make my tools understand it. I'd like to convert my existing WordPerfect documents to ODF. However, there are things in WordPerfect that cannot be reproduced exactly in ODF, and this is a problem. If my tools need to figure out what page something is on, in order to generate a proper citation to that thing, and I've lost some formatting information converting to ODF, I may not get the right cite.

So what am I going to do? I'm going to add some extra, proprietary markup of my own to ODF that lets me include my reverse engineered WordPerfect knowledge when I convert my old documents to ODF, and my new tools will be modified to understand this. Now my ODF workflow can generate correct cites for old documents. Note that LibreOffice won't understand my additional markup, and will presumably lose it if I edit a document, but that's OK. The old documents I converted should be read-only.

Of course, I'm not the only person doing this. Suppose you also run a law office, with a WordPerfect work flow, and are converting to an ODF work flow. You are likely going to add some proprietary markup, just like I did. We'll both end up embedding the same WordPerfect information in our converted legacy documents, but we'll probably pick different markup for it. It would be nice if we could get together, make a list of things we've reverse engineered, and agree to use the same markup when embedding that stuff in ODF.

And that's essentially what they did in OOXML. They realized there would be people like us with our law offices, who have reverse engineered legacy data, that will be extending the markup. So they made a list of a bunch of things from assorted past proprietary programs that were likely to have been reverse engineered by various third parties, and reserved some markup for each.

Re: The LaTeX cargo cult

#65
post #43

Earlier quoted context omitted.

"Very well" is a euphemism here, I assume? I worked in Windows Server when Microsoft was under the US DOJ consent decree and had to document every thing that looked at all like an API--even internal things that were just APIfied for design reasons / ease of testability / to make servicing simpler. I can say with some confidence that no one gave a shit about producing good quality docs. Without exception, people viewe…

That is really a shame that you guys didn't use this new requirement to improve your product and internal process. Your comment comes off as a group that was just obeying the letter of the law, but not the spirit of the law and I could only guess that this would easily spill over into all cases of documentation even the cases where it matters. Having a large group of developers believe that it isn't worth the time to…

I can see how this comes off as an insular group sticking it to the government, but that's not the case.

If I gave the impression that we didn't create good APIs or good docs, I apologize.

We did, but that's not what the government wanted, so we gave them what they would accept. The government just was not very good at deciding what has to be documented and what doesn't. e.g., we had to document sample wire traces of messages that are all auto generated through IDLs and sent over a standard protocol. Rather than 2 page of IDL and a comment saying we use transport X (which is defined in RFC blah), we were actually required to submit 100-pages of traces. That obscures, that does not help.

Even if you wanted to do a great job of producing docs, we quickly learned that the process wasn't about creating great docs; it was about producing docs that the government would accept. Have you seen Office Space? It's that. It's thankless, because you're generating shit docs that aren't relevant that are judged by people who don't have the skills to judge them.

Re: The LaTeX cargo cult

#66
post #16

Good news for the OP: The OP seems to want more output options than just paper or PDF. It appears that the OP also wants HTML output. Okay. TeX and LaTeX say next to nothing about the final physical form of the document and, instead, leave all that to an appropriate device driver . Or, TeX (and likely LaTeX) puts out a file called device independent with three letter file name extension DVI. Basically a DVI file says…

There are latex to HTML converters and they only work for a subset of latex functionality. It is not as simple as defining a driver that outputs HTML. Latex and HTML work in fundamentally different ways: latex typesets for a fixed paper size, and specifies its coordinates in physical dimensions. HTML is free flowing; if the user resizes the window the layout should adapt, they layout has to work on mobile devices, et…

Let me be more clear: Long ago a friend kept suggesting that I write a converter from TeX (maybe also LaTeX) to HTML. I kept telling him that that was essentially impossible because TeX is a programming language, likely Turing machine equivalent, complete with if-then-else, allocate-free, file read-write, while HTML is just a text markup language. No doubt JavaScript is Turning machine equivalent, but I'd have a tough time believing that HTML is.

So, my suggestion here was not to convert TeX input to HTML.

Instead my suggestion was just to convert TeX output, that is, a DVI file, to HTML. Why? Because a DVI file is essentially just text, or, as I outlined, it specifies put this character at these coordinates on the page, put that character there on the page, go to a new page, etc.

To be more clear, say, about the file reading-writing, that happens when the TeX program reads the user's TeX input and before the DVI file is generated. Given only the DVI file and displaying it, there is no file reading-writing.

So, it looks like could convert TeX DVI output to HTML.

You pointed out that maybe HTML with a browser has more flexibility than TeX output. Okay, maybe. But I didn't claim that, given an HTML file, there would be a TeX input file and a corresponding TeX DVI output file that my envisioned converter would convert to the given HTML file. Instead, I just claimed that for a given TeX and DVI file, the converter would generate an HTML file.

Or the converter would be a function from the set of all TeX DVI files to the set of all HTML files. That is, for each TeX DVI file there would be a corresponding HTML file from the converter. But the function would not be onto the set of HTML files, that is, not all HTML files would be a value of the converter; not all HTML files could be obtained by using TeX input, the TeX program, the DVI file and the envisioned converter.

You also mentioned some ways in which HTML, say, with , is more flexible than TeX. Fine. But I was discussing just converting TeX DVI to HTML.

And, again, I see no way to convert TeX input, which is a programming language, to HTML, which is not a programming language.

Whew!

More clear now?

Re: The LaTeX cargo cult

#67

The biggest advantage of latex is that by (mostly) separating content from presentation, you can use revision control systems like git or svn to collaborate on papers. You can be in that final hour before the paper submission deadline, on a skype call with four authors scattered around the world, all simultaneously editing the paper (each using whatever tools they prefer), and be reasonably confident it won't all end…

I agree with this, my thesis committee wanted my thesis as a research paper (irrespective of whether my work was going to be published or not) but in the final stages the graduate college declined to approve it in spite of my committee's approval because they require a predefined format of the thesis. The change of format took me a few minutes, thanks to latex. I can't begin to imagine how much work and anxiety it would have taken to change the entire format at the last minute otherwise.

Re: The LaTeX cargo cult

#68

The biggest advantage of latex is that by (mostly) separating content from presentation, you can use revision control systems like git or svn to collaborate on papers. You can be in that final hour before the paper submission deadline, on a skype call with four authors scattered around the world, all simultaneously editing the paper (each using whatever tools they prefer), and be reasonably confident it won't all end…

I always see this claim that latex separates content from presentation, but I don't see how it's true. As the article says, \emph{hello} is implemented in terms of font commands; it entangles the semantics (emphasis) and the presentation (italicisation), and there is no way to extract the semantics of a latex document and render it in a different format the way you can with e.g. Markdown.

Re: The LaTeX cargo cult

#69
When I started grad school, I initially used LaTeX to prepare my articles. But then my advisor tried to open one of my documents on his machine (Windows, I'm using a Mac) and some kind of weird error came up. So we spent one whole advising session with him searching for MiKTeX and installing it, whereupon my document still wouldn't load for whatever reason.

Then once BibTeX got in the mix, it became even messier. Well, I finally finished the article and submitted it to a journal, but they had so many requirements for LaTeX submissions that it took a while to change everything for it. Once I finally submitted it -- surprise! -- their online LaTeX compiler came back with another weird error. It took me about 8 more submission attempts to isolate the "bug" (which was some kind of issue due to differences in versions and default packages installed on their machine vs mine), and I finally got a PDF generated. Except it still didn't look the same as mine for whatever reason.

Well, the article got rejected from that journal, and so as I'm applying for another journal, I read "Word documents only".

So I gave up on LaTeX. Too much of a hassle for me. Maybe it's a smooth process for everyone else, but I don't have any problems just typing a Word document and sending it off. (Although I do miss LaTeX's equation typesetting system.)

Re: The LaTeX cargo cult

#70
post #8

> LaTeX input files are proprietary to LaTeX, just as .doc is Word. The only definition of LaTeX as a language is “whatever LaTeX does”. I am sorry but I don't see this point... Everybody is free to write a parser for .tex files and use it for whatever reason they want... You are not free to do so with .doc or other proprietary format...

> I am sorry but I don't see this point... Everybody is free to write a parser for .tex files and use it for whatever reason they want...

It's great that you have the freedom to do that in theory. But it doesn't work in practice. The .tex format doesn't have a spec or independent implementations; it's complex and idiosyncratic, and there are no good general-purpose conversions from .tex to other formats (e.g. markdown, html). The only program you can really use .tex with is latex.

Post reply on HN