I was agog when I downloaded the LaTeX binary install for my new Mac a few years ago and discovered how massive it was. LaTeX is almost as big as the entire operating system disk!
I remember installing it a few weeks ago on ubuntu to update my cv.
The base system was 280+ mb along with 190+ mb of documentation. I found it mildly amusing that I had to download ~500 mb of stuff just to update my cv.
Vast numbers of packages to do just about anything you could possibly want.....
Things like inserting graphics with text flowing around them (picins), or document classes for resumes,or textpos (for absolute text positioning), or......
Basically you have nearly two thousand such packages in TexLive......
The full TexLive distribution contains all officially accepted packages ever written (this includes fonts, iconography, compiled documentation and other heavy stuff), most of the compilers, the LaTeX and Context (MK II and IV) packages and a huge toolchain. For compatibility reasons, packages are (almost) never removed. Also for compatibility reasons, the LPPL (Latex Project Public License) discourages[1] the release of a modified package under the same name, so there are copies within the distribution.
So, the TexLive distribution is the "fire-and-forget"-package in the LaTeX world, thats why it is so big. I use it for around 10 years now and I never had to install an additional package.
[1] It even prohibited that for a while, see Wikipedia.
I was also surprised. I installed miktex which is around 200Mb and then it still automatically downloads and installs even the most basic packages i use from the internet.
Isn't latex from the 80's? I think my first disk that had more than 200Mb is from the early 90's? How did people use it back then? Also it is still horribly slow even on a core2 with 4gb ram and superfetch.
why not? As I understand it, it would, as there would be no need to port (La)Tex to anything: just deploy it in a jailed environment on the server, and the thing you need to have on the ipad is a text editor and a pdf viewer.
It does not solve the problem of writing TeX on an iPad offline, obviously.
This is an interesting solution, because the problem is that the original codebase is messy and therefore not portable. It seems to happen to most software as it ages.
Putting it on a server makes the architecture more robust against messy code (and changes in programming languages and environments), because pieces can be changed independently.
The problem isn't that the original codebase is messy (it's aged, but there are still comparatively new projects working on it e.g. LuaTeX) or that it's non-portable, as demonstrated by the multitude of platforms it's available for.
The problem is roughly equivalent to producing a non-upgradable perl. It's not very useful on its own, but it's completely impractical to include a copy of the entire CPAN with it. And Apple's policies prevent you from downloading additional packages. It's just not worth the effort.
the idea that LaTeX has a messy codebase is almost mindboggling to me--I had assumed that TeX--practically the only code that's published as a book (see: The TeX Book) would be clean. I guess the complaint is mostly about the Pascal + C that's code-generated by TANGLE.
It's not so much core TeX that's a mess as the ecosystem; the set of font-generation, path-management, shell scripts, PS/PDF/DVI code, and special-purpose glue binaries gets pretty hairy.
There certainly must exist some reasonable snapshot that is less than 4GB as I ran Tex on a computer with less than a 1GB HD in the distant past -- and it didn't consume most of the HD at the time.
The price of a LaTeX rewrite would be even higher: incompatibility. If one tries to rewrite TeX, the problem gets much much worse, since TeX is, for all intents and purposes, bug-free. A new implementation will certainly not be. Joel Spolsky said it very well
http://www.joelonsoftware.com/articles/fog0000000069.html
I disagree that the current situation is LaTeX developers' fault. TeX and LaTeX are complex pieces of software, that are developed over time. They were extended as the capabilities of their platforms increased, to take advantage of those capabilities. This requires full access to the OS utilities, and naturally LaTeX environment does that. If anything, this is Apple's fault. For whatever reason, they cannot allow applications to use the existing capabilities of the underlying OS. This goes against the Unix mindset; of course there will be unpleasant consequences, but one cannot hold Unix mindset responsible for these.
The big problem on tablet devices is constraints in memory. Yes the unix way is to have various small utilities work together through pipes and interprocess communications. The big challenge at that point is how to do you manage memory? What if a single process in that huge chain uses up all of the memory and another process gets killed by the OS which was part of that chain (do note, no swap on mobile devices)... How is the calling program supposed to handle one of its subprocesses suddenly dying?
Do note that the same is true on Google's Android OS. You can run as many threads as you want, but no calling other executables to do work in the background ...
A current tablet device, even a cheap one, has about 256Mb of main memory. Android (at least the cyanogen mod kernel) has also the ability to use a part of the main memory to store compressed swap partition data. That leaves about 80 Megabytes to userspace programs (on Android). About the amount a normal desktop computer had in 1998.
LaTex dates back to the beginning of the 80s. Given that it has the ability to create large documents, I doubt that the required amount of main memory scales linearly with the size of the document.
Also, when you use subprocesses, besides checking their return value, you have some sort of interprocess communication which should detect when one process failed to finish his job.
It looks more like the smartphone runtimes and their sandboxes just don't support it at all, because modern GUI applications rarely build upon multiple executables in the background.
Android does have IPC mechanisms (Intents and remote methods) that can be used to have another process do work in the background. The difference is that even if you use them, you're still not likely to wind up with something that looks like a set of cooperating command-line utilities.
In any case, I absolutely agree that resource constraints aren't keeping LaTeX off of our mobile devices.
I have TeX Live available in the Ubuntu chroot on my HP TouchPad, so you're right that it's not a resource thing. Admittedly in this case webOS provides a pretty standard Linux environment under the hood, so it falls pretty firmly outside the Android model (much less iOS).
I'm curious where you get the idea that LaTeX is bug free. In my experience it is rare to find two packages that work together bug free, yet alone the collections of them needed to form even a respectable document.
I assume he meant that core TeX (the part written ages ago by Knuth) is in effect bug-free. However you do have a good point that one effect of core TeX being ancient and not really updated is that, in practice, what people actually use is TeX plus giant macro packages whose size is bigger than TeX itself, and those are certainly not bug-free. It's at least plausible that a rewrite wouldn't lead to more bugs total, if the rewrite made it easier to write less-buggy macro packages that interacted more nicely (the TeX macro/module situation is not great for that).
Nobody uses (Knuth's) TeX anymore. They use PDFTeX, XeTeX and LuaTeX. None of these are as stable as TeX, but in practice a whole lot better than most other software I use.
All of these versions of TeX are just extensions of the original TeX. The core Knuth's code is still used in each one of them. The stability comes from the core, not just from the work of pdftex, xetex and luatex developers.
The stability comes from the core, but the problems arise from the extensions. I have pushed LuaTeX to some limits and seen lots of segfaults and other errors.
It's 'bug-free' in the same sense that qmail is bug free: you take a piece of software, design it very carefully to do only the minimum amount required to make it fulfill its purpose, spend a lot of time on making sure there are no 'bugs' under a very strict technocratic definition of 'bugs' (i.e., few features, slow running speed, idiosyncratic workings aren't 'bugs') and then make a career out of marketing yourself as being able to write 'bug free' code.
Of course to make the software useful in the real world, a lot of things have to be added to it - make sure to not include any of it in the 'core' otherwise the 'bug free' claim will go out the window really quickly.
So yeah, in that sense I guess it's technically (which I use as a euphemism for 'autistically') correct to call TeX bug free (the bounty program for bugs found in it is quite famous, and part of fore-mentioned marketing).
You think Donald Knuth has made a career for himself out of being able to right 'bug free code'?
Really?
He's made a career for himself out of being an extremely creative computer scientist and writing outstandingly scholarly books about programming. Far from marketing himself as producing bug-free code, he has published articles entirely devoted to the history of bugs found in his software.
(As for the bits that turn TeX into LaTeX, no one is making a career out of claiming that they are bug free -- for the simple reason that no one thinks they are.)
Of course not, it's hyperbole to illustrate the point. In the specific cases of Qmail and TeX, the 'bug free' aspect of it however is overblown and a marketing gimmick. It's not that hard (given enough time) to make something bug free, it's a whole different thing when the software needs to evolve at the same time to meet the (changing and expanding) requirements of actual users.
TeX wasn't born in a night and suddenly appear in binary form. Knuth worked a hell lot to make it clean, make it work and make it fast. At least, for when he wrote it. Go and read The TeXbook
Actually, the reason for not evolving/rewriting TeX is so that old documents can be typeset and produce the same results. I find that an appealing goal.
Unless I'm forgetting something from the article, the author never said it was the LaTeX developer's fault -- he simply said Apple was right for not allowing it in its current state. Not all situations are someone's "fault", and thus just because Apple is not at fault doesn't mean the developers are. It's just as you declared it, an unfortunate result of many decisions which were right at the time.
That being said, I also think you have a low bar for definitions of "bugs". Terrible performance is very much a "bug" in my book. Even the things that aren't "bugs" in the strictest sense can still make for bad software. The executable described here is 4GB, that's 1/4 thte total space on a low end iPad! Also, if tomorrow someone does discover a bug, it sounds like this would be a mess to fix. The jumble of source simply won't be attracting many new developers (whether it be to fix existing bugs, add new features, or port to new platforms).
The LaTeX executable isn't 4GB, it's 3MB or so (pdflatex/pdftex) or 16MB in the case of XeLaTeX. The 4GB consists of billions of extension/modules/packages for typesetting documents.
Yes I noticed that in the comments before I posted which is why I was careful to specifically say "The executable described here is 4GB" so as to refer to whatever it is he was trying to work with. I suppose whether all of the 4GB is needed for what he wanted, whether it could easily be taken apart, or could now be remade in a much smaller package, are all valid questions.
4G is a bit over the top. My install (TeXLive 2010 on OpenBSD) is ~2G, and that includes gobs of rarely-used packages and documentation.
Really, borrowing MikTeX's install-on-first-use for packages and making documentation optional should result in a much more reasonable size. If you want to get fancy, teach LaTeX how to decompress packages on demand.
Here comes the problem: Apple requires it to be a single binary, distributed once. You can't install packages the LaTeX ways should you want to, so you have to bundle most (if not all) packages into the single binary.
You could use a virtual machine library (if anything suitable exists) and run everything inside one executable - it would probably have horrid performance but you get rid of the single binary restriction. You can put on a nice front-end and tell the user how much longer he has to wait until the operation is complete.
Virtual machines are generally prohibited by the guidelines as well. (Exceptions exist for things like script interpreters, which need to be present for some games to run, e.g. Lua.)
Apple wants to restrict the platform options available to preserve their user lock-in. They were sort of forced to make an exception for games because they had no alternative to offer.
It seems the cult of Apple is touchy today and can't detect a joke. I'm sorry if I have inadvertently hurt your feelings - I will be sure to clearly state my humorous intentions next time. </humour>
For the record, I do not own devices based on iOS or Android and I don't care for your little Apple-Google feud with which you seem to be so concerned with. So please, carry on with those market statistics about Android, I am dying to know more.
I think the difference here is between interpreting scripts that come with the binary, and downloading new scripts from the internet (or other untrusted locations). The latter is prohibited.
To get around it, you'd have to make it In App Purchases, because these also come from a the App Store.
Well you obviously weren't careful enough. Nowhere in the article does he talk about a 4 GB binary or binaries. To quote him:"A 4GB Tex distribution dependant on over a 100 binaries" He is talking about the _whole_ distribution not a single or several binaries. So even though you were careful, you still misquoted the article.
"The App Store guidelines insist that any iPad app be a single executable. Jailbreaking would ease this restriction, but in this case Apple’s gatekeepers are right. A 4GB TeX distribution dependant on over 100 binaries is not acceptable on the iPad."
From that quote ("A 4GB TeX distribution dependant on over 100 binaries is not acceptable on the iPad."), it is clear that he is musing about a scenario where he ships all 4GB. As stated many times (and also in that same quote), on the iPhone you are forced to ship something as one executable. Thus, the theoretical distribution he is referring to would in fact be a single executable of about 4GB. In fact I think that's the whole point of those two sentences. So it appears that I was indeed quite careful.
> As stated many times (and also in that same quote), on the iPhone you are forced to ship something as one executable.
On the other hand, yes the executable must be "one". On the other hand you can download stuff (either directly or via DLC). The issue is that while Apple has relaxed their restrictions on bundling interpreters in applications (you can do that), they have not relaxed their restrictions on downloading interpretable code: it's not allowed. So downloading even styles would be verboten, since styles are TeX, and TeX is executable code.
I think you are missing the point. The apple guidelines do not state that a program can only consist of an executable. That would not make any sense. Rather they state that any application can only consist of a single executable in addition to whatever resource files are included. In the case of the Latex distribution in question one would have to convert all 100 executables into one executable, my guess would be perhaps 100 megabytes. In addition one would have to include lots of resource files, mainly sty-files bringing the whole bundle of an executable + resource files up to 4GB.
AFAIK Apple doesn't restrict you from bundling files in your application. That simply wouldn't make any sense.
The point here is that he is talking about an application consisting of a single runnable binary of size X with tons of bundled .sty-files that brings the whole application up to 4GB.
Previously, this would not be allowed, since .sty-files are interpreted (which in turn would make it impossible to implement LaTeX on the iPhone), but that really wasn't the point here. The point is simply that this wouldn't be a single 4GB executable, but a an executable of perhaps 100MB bundled with a whole bunch of .sty (and other) files to a total size of 4 GB.
Edit: Fixed typos. Sorry. HN doesn't work very well on my phone.
"""The price of a LaTeX rewrite would be even higher: incompatibility."""
Yeah. The only benefit is a codebase that reflects current needs and can grow in new directions and follow current practices, that programmers of today are familiar with. And also be faster, and more flexible. But what are those compared to compatibility right?
(Of course people interested in pure compatibility could just continue to use the old version, until the new is compatible enough, or they don't need compatibility anymore).
"""If one tries to rewrite TeX, the problem gets much much worse, since TeX is, for all intents and purposes, bug-free."""
And your wrong assumption is a) that a problem has to be bug free to be useful or b) that a new effort can't produce a relatively bug free codebase?
And your wrong assumption is a) that a problem has to be bug free to be useful or b) that a new effort can't produce a relatively bug free codebase?
How are either of those requirements wrong? I certainly expect my programs to be bug free. LaTeX is a tool that's older than many GNU utilities. It's been reviewed and tested numerous times over by the harshest test suite of all: the real world.
Yes, in theory, you could rewrite TeX to be cleaner, while maintaining backwards compatibility and lack of bugs and regressions. In practice, this is very very hard. It's so hard that no one, no individual or company has managed to pull it off.
But hey, who knows? You could be the first. The LaTeX codebase is open-source. If you think you can pull off what the most talented software engineers in the world haven't been able to do, go right ahead.
"""How are either of those requirements wrong? I certainly expect my programs to be bug free."""
Good luck with that. What I said, though, was that "a problem has to be bug free to be useful" is a wrong assumption. We all use programs that have bugs, and still found them immensely useful.
"""Yes, in theory, you could rewrite TeX to be cleaner, while maintaining backwards compatibility and lack of bugs and regressions. In practice, this is very very hard. It's so hard that no one, no individual or company has managed to pull it off."""
What are you talking about? Tons of people have written TeX versions of their own, even in Lua, and most of those are widely used.
"""But hey, who knows? You could be the first."""
Hardly. There is LuaTex, XeTeX (even more widely used) and others. Are you just talking out of your ass? (Not to mention several other modern typesetting engines that are not TeX based. You make it sound like TeX is an impossible achievement).
Now, what I said I'd like to see was not a rewriting of TeX itself, but a modern version of a TeX like engine, with or without compatibility. Programs like XeTeX and Omega for example provide Unicode support and TTF/OT support to TeX, but I'd like to see something more modular, and with a more streamlined markup than TeX+LaTeX. While we're at it, even scriptable.
There are also some improvements found since in typesetting, like those employed in the InDesign layout engine concerning edge text and hyphenation.
Thanks. A have given lout a look in the past, but I though it wasn't actively developed anymore. I also liked Prince, but it is proprietary unfortunately.
Both LuaTeX and XeTeX have the original TeX code at their core, so they are not bottom-up rewrites.
The purpose and benefit of backward compatibility for TeX is that a 30 year old manuscript written in TeX can be fed to the latest version and produce identical output to what was produced 30 years ago. (Of course, you'd also have to archive the macro packages and font files you were using, but those were never machine dependent).
Don't you think intelligent people have better things to do than to rewrite old code, just because Apple's platform lacks important features that have been well-known for several decades?
The notion that every time we have a new language/platform, we must REWRITE THE WORLD!! is absurd and a huge waste of resources. We should stop making excuses for it.
"""Don't you think intelligent people have better things to do than to rewrite old code, just because Apple's platform lacks important features that have been well-known for several decades?"""
Yeah, you probably missed the whole point of the comment, TFA, and several other stuff besides.
It's not Apple's platform that's the problem, is TeX/LaTeX that is lacking important features. In EVERY platform.
People have been hacking them on to it, but having a better codebase to start off, without the assumptions TeX/LaTeX make would really make it so much easier.
"""The notion that every time we have a new language/platform, we must REWRITE THE WORLD!! is absurd and a huge waste of resources."""
Yeah, good thing that nobody suggested anything like that in the thread.
Btw, the notion that you can add your worthless reply without first understanding what the parent poster says is absurd. You should stop making excuses for it.
The only think i 'd keep from old tex is part of the mathematical notation. Otherwise, it's bloated, quirky and doesn't handle international text well.
> For whatever reason, they cannot allow applications to use the existing capabilities of the underlying OS. This goes against the Unix mindset; of course there will be unpleasant consequences, but one cannot hold Unix mindset responsible for these.
Using the native capabilities of the OS in the sense you mean - allowing TeX to use its ancient, hideous bitmap font system, goes against:
- Unix philisophy - do one thing well, link against or pipe to other apps/libraries that do their thing well
- Simplicity. The user should not be forced to make an unnecessary choice where one option is almost always superor to the other.
Knuth's concept of 'bug free' is one of an academic computer scientist. TeX has many, many issues: unnecessary dependencies, a horrible build process, and many UX issues that stopped TeX from reaching TeX's original goal of 'allowing anyone to create typeset documents'. This is fine: Knuth is a mathematically focused computer scientist from a period where everyone who had access to a computer was a programmer. It was valid in this era.
TeX's original goal of 'allowing anyone to create typeset documents'
Actually, according to this interview[1], speaking of the very first version of TeX, "I should mention that I had no idea that I was designing a typesetting system that anybody else in the world would ever use, besides me and my secretary. My idea was that I would teach Phyllis, who was my secretary for almost 20 years… So Phyllis and I were going to be the users of this TeX system. … I tried to design it just good enough to do my books and no other books."
Even with the released version, I don't think TeX was ever intended to be the last word on typesetting; it was simply his best attempt at a decent markup. He then froze the features so that previously typeset books could be corrected and reprinted using the same source. He left it up to future programs to innovate.
It is also worth pointing out Joel says "don't rewrite" specifically in the context of a software company, where I strongly believe it is largely correct. In the context of a decades-old open source project the decision may be quite different for legitimate reasons.
I find it likely that you'd be better off performing an algorithm extraction and doing a true from-scratch rewrite than trying to incrementally translate TeX and LaTeX.
Hear, hear! This post provides a perfect example of the utter failure of software engineering in the real world. I am reminded of it every time I try to install software, with all the ridiculous dependencies and multiple versions. Instead of addressing the serious foundational issues facing software development and architecture, the geniuses are busy inventing the latest, greatest programming language, creating even more problems.
Computer science and engineering departments should use these situations to train their students.
> the geniuses are busy inventing the latest, greatest programming language, creating even more problems.
There is some truth in your microrant here. I would restate it like this: Instead of getting excited with how expressive is a new sexy multi-injection functional language when you write the nth Fibonacci sequence, I would think it more realist and constructive to get excited with how a new language or a new extension of an existing language allow to handle module and package dependencies in a clean, safe and explicit way.
It resonates also with my work today: I spend a few hours removing those evil "import *" from our codebase... (Python's "we are grownups" mantra is nice, but I think a piece of the quote is missing: "we are grownups, thus we run pylint and comply to all the rules, except a few carefully chosen ones")
Sorry, but I fail to understand, why any serious TeX-Head would say that. The platform is crippled and your problem shows it. You are ranting in the wrong direction.
"Beautiful" has nothing to do with whether it's crippled or not. In any case, how is a 4GB executable + several-second runtime for trivial documents Apple's fault? Is the iPad crippled because it can't run a crappy cross-compiled version of OpenOffice with a PS/2 mouse?
I guess the argument is that it's apple's "fault" because the restrictions of the platform require the whole package to be bundled as a single binary, instead of allowing a more modular distribution mechanism. Most of the contents in the 4G are extension packages.
But I am not sure if "fault" is an appropriate term here anyway, we're simply observing two different approaches to software bundling that happen to be incompatible.
The restrictions are what they are, but TeX doesn't help at all by being large with an internal (circular!) dependency tree that would (should) get you fired in a flash from a commercial software house.
Apart from the fact that trees cannot be circular ;-) LaTeX installations work like a charm for other forms of distributions. I think it's really just a clash of philosophies here.
The author is not a TeX-head, or he wouldn't be surprised about WEB, Pascal and wouldn't confuse Plain TeX with LaTeX (the documentation of TeX is the former not the latter).
I don't see any reason why LaTeX should be shelling out to bash. And having a mish-mash of loads of different languages creates unmaintainable bloatware.
I don't see any reason why it should _not_ shell out to bash. TeX/LaTeX was developed in a UNIX environment, which has the explicit philosophy of "the tool box with lots of little tools which do whatever little they do extremely good".
The iOS Philosophy of "It has to be one binary app" resembles the philosophy of Windows Programs. Big single programs with lots of functionality unter one big GUI.
How can anyone really be suprised that one of the oldest and mightiest gods of one religion can not be coerced into the shrine of a completely different religion?
Personally, I'm in the camp of "rely on as little as you can". This includes not shelling out to bash unless you really really really can't achieve the same thing with a bit of more code. Apart from making the app less portable, more bug prone, less maintainable etc, it's just ugly.
Fully agree; computer is something on which you can write, compile and run a native program without using external machines. And TeX is a computer typesetting system.
This is a total 'Bed of Procrustes' argument. In order to deal with the problem of this ONE device and in particular the App Store guidelines, you want to cut off the legs of the source code.
* First of all, the OP mixes up LaTeX and TeX. TeX is written in a very portable language and has been ported to more platforms than most other software, including PDP-10 and others.
* You only need one binary to work with TeX. Either PDFTeX or LuaTeX. All other binaries are just glue code (for example to generate missing Metafont fonts, but who wants them these days anyway?
> * You only need one binary to work with TeX. Either PDFTeX or LuaTeX. All other binaries are just glue code (for example to generate missing Metafont fonts, but who wants them these days anyway?
A lot of TeX uses Computer Modern to typeset the body (a metafont font) and I don't think I have ever see a TeX document that doesn't use Computer Modern or Euler (another metafont font) for equation typesetting.
I also wonder whether it's possible to achieve the excellent equation typesetting capabilities of TeX without metafont.
Metafont is hardly used these days. All TeX distributions use either a Type1 font of Computer Modern or Latin Modern. And the equation typesetting has nothing(!) to do with Metafont. Everything is set into the TeX binary (and its formats). You just need a good math font (and that is not trivial, but not related to Metafont)
Yep, it always surprises me how few people change off the default Computer Modern -- which I find really spindly and ugly -- given that a single \usepackage{...} will give you a beautiful Palatino, for example. I sometimes suspect they're just wanting to hit me in the face with the fact that they're LaTeX users...
Palatino for text is fine, but what math fonts go well with it? I think them main reason I use Computer Modern is that the math and text fonts look so good together.
Computer modern is a nice font for documents that contain equations. I suspect that it is because of the subtle changes in density. But for normal prose it really doesn't work very well.
"One binary" is a bit optimistic; even if you never do anything fancy with fonts, you'll want bibtex. And makeindex, if you're writing a large work. PSTricks does not work with PDFLaTeX (Tikz is arguably better than PSTricks, but PSTricks won't be dead anytime soon). XeLaTeX is required to use system fonts easily.
And that's before getting into anything truly gross.
I am running a TeX distribution with only one binary. And with bibliography and index: these could be done with the Lua part of LuaTeX. True about the others.
Indeed, Norman Ramsey essentially reimplemented Bibtex in Lua: look at bibtex.lua.in in his Nbibtex; tarball avilable from http://www.cs.tufts.edu/~nr/nbibtex/
In this paper[1], they say that much of the latex running time is eaten up in the startup and shutdown of the program
and the actual typesetting time is in the microseconds.
A long-running process (daemon) is therefore a much more efficient way to run (La)TeX.
[1] www.tug.org/TUGboat/tb27-0/fine.pdf
"""
On my current 800 MHz PC, the command
$ tex story \\end
takes about 0.137 seconds, while
$ tex \\end
takes 0.133 seconds. The first command typesets a small page of material; the second does nothing but start TEX and then exit. Thus, typesetting the small page takes about 0.004 seconds.
"""
It strikes me that TeX ought to take a page from Lisp interpreters and dump core after loading all the standard configuration files, so that future runs won't need to waste so much time on initialization.
It does, that's how LaTeX starts up and why you have to run it as latex instead of tex. Ditto texinfo, and probably ConTeXt. For a variety of reasons the TeX engine still has to reload a lot of stuff because it might possibly have changed, which is a suboptimal situation; but there is a concept of a "dump" state that has most of the kernel initialized. I suspect people don't care enough to work around it, and the people most likely to do the work (TeX kernel hackers) are also the people who are most likely to be inconvenienced by it not noticing the tweaking they're doing.
Um, for about any other reason that you would want to use document editing software on a tablet? For instance, I use LibreOffice and its ilk only for the most throwaway documents (and open others' files). Having an iPad means I don't need to lug my laptop around to work on my thesis (I run Emacs on a VPS via SSH to do it, and while personally I don't particularly care about the aesthetics, I'd say the use case is certainly there).
I use a ZaggMate which doubles as protection, weighs about the same as any other case and is not bulky at all. It works quite well.
> Maybe you just need a smaller laptop ..
No, I don't want to have a small laptop as my main computer. I had an Eee before the iPad, but the difference in the writing experience is not too different in the end and the other advantages of the iPad are greater. In any case, you can hardly call me a person who unreasonably hangs on to Apple stuff: I'm writing this under Linux which I installed on the MBP my university gave me. I hardly ever boot into OS X here.
> Also, terminals are great, but writing anything serious without X is a pain.
Why? Emacs doesn't really need X, and I don't need to re-typeset my work every five minutes.
Guess this depends on how you work. I often find myself starting many instances of the editor[1] which is a pain if you have to create a new ssh connection for each (or use ctrl-z etc).
"the writing experience is not too different [..] the other advantages of the iPad are greater."
Guess the real difference between us is that you see something great in the iPad, so you are willing to live with its obvious shortcomings[2] compared to a laptop.
I have yet to discover why it's so amazing, and only see a small, but pretty much useless gadget. It could be used for reading I guess..
[1] yes, it has tabs.. still
[2] low resolution, can't run what I want to run, can't type on it without a keyboard, and at that point you could just as easily carry a small laptop (not an Eee ffs, a real laptop).
Oh, absolutely. If I were a actual road warrior, the iPad wouldn't work at all for me. However, between my laptops at home and at work I don't really need a third one, and since I already have the iPad I'd rather make as much I can with it for short trips where I am not going have too much time and/or wifi to pull sustained work sessions.
> It could be used for reading I guess..
That too. For an academic, GoodReader is a blessing. I have finally stopped printing out loads of articles and/or finding that I printed out this same article a couple of years ago. Not to mention Kindle etc. Again, if I were spending significant amounts of time away from either home or the office, I'd consider investing in a proper portable laptop; but I'm not, and for my use case the iPad is ideal.
> can't run what I want to run
Yep, I agree that it's frustrating.
> (not an Eee ffs, a real laptop).
No everybody can afford another proper laptop that's as easy to carry around as an iPad, y'know.
Anyway, YMMV, of course. I was just pointing out that solutions are available.
I've got a dell mini running Ubuntu. I wouldn't recommend it due to a bug in the graphics drivers that causes a crash on resume from hibernate, but, it is a great machine and works perfectly for LaTeX.
If you're mobile, carrying around a keyboard negates the value of the iPad. If you're stationary, a real computer gives you far more flexibility. Then you have the issue of unbearably long compiles, as the article stated. The iPad is not the right tool for the job of TeX editing.
Maybe we should let LaTex be the way it is now and focus instead on generating better HTML authoring tools. With eBooks becoming more popular, there is certainly a need for such tools. While I understand HTML is no match for the power of LaTex currently, we need to think ahead and maybe help to create a platform for the future rather than getting bogged down by technologies of the past.
I didn't downvote but, pretty much every academic in the CS/physics/stats/math I've met uses LaTeX. Even a bunch of linguists I know use LaTeX.
It's definitely not perfect--I really wish there were something better--but for writing technical academic papers, it seems like far and away the best.
Go and find some download stats for some LaTeX distributions. LaTeX is still used in academia everyday, and I conject that it is used to generate docs in business too.
LaTeX is about as far from dead as the desktop computer.
Only someone not related to typesetting can say that LaTeX is dead. Exactly the opposite is true. Even though there are good alternatives these days such as InDesign and (I hate to say that:) MS Word (which now has a much better formula editor and OpenType Math fonts), great developments are taking place, for example LuaTeX. Not directly LaTeX but TeX: I have built a high quality database publishing system based on LuaTeX: http://speedata.github.com/publisher/
I think that page could benefit from some examples created by speedataPublisher; now I only see a list of features and requirements, not what I'm able to create with it.
I had to write a paper with it. I found it so horrible that I ended up not writing the paper (on a very interesting topic) and failed class. I just assumed the professor was nutty and kept onto some weird niche software.
Nope, the professor was requesting that you use the standard typesetting software. Some of your classmates might have to write many papers, and hence it's good that they start learning.
Apparently. It's a shame that researchers hae to use such software. Probably part of why research is so conservative and slow. Why not a funky html "paper"? With interactive formulae, clickable links (hey, wasn't PageRank based on references? Maybe time to turn that around) to references. Most important, a clickable link to an academic profile.
Please explain to me how to type the fraction (a^2+b^2-c^2)/(2ab), which is the simple $\frac{a^2+b^2-c^2}{2ab}$ in TeX, so that the numerator appears above the denominator in HTML. Or any non-TeX layout.
I'd rather go with a rewrite that also redesigns the typesetting language. It feels like C++ of typesetting to me, although of course maybe I'm just not familiar enough with the language to see its key concepts clearly.
Maybe the Lout system will pick enough traction one day.
It's a quirky mess, but none of the others, to my knowledge (and I've used most of them, which certainly includes Lout) do nearly as good a job typesetting. Lout does a bunch of things subtly wrong that I can't remember right now but that are very visually distinct, and troff is so far down that road I can recognize troff typeset documents at six feet from a glance.
Lout's equation formatting is especially primitive as I recall, and that is a huge amount of work to get TeX-like quality for. I am unaware of any system that typesets mathematics as nicely as TeX does.
Yeah, I'd like to see someone do a modern rewrite of the whole TeX/LaTeX/XeTeX/XeLaTeX/etc. mess. Something that has modern syntax and support for modern features (such as output to PDF, HTML, even OOXML).
It would be good to see UTF-8 natively supported, and for all the common packages to be absorbed into the core libraries. Right now, you can sometimes find 2 or 3 different packages that do the same thing, often with varying benefits. Take the best package, add the missing features from the other packages, and bundle it all into one distribution. For example, the absolutely horrible table support, where merging cells is a nightmare.
Indeed, once you get set up with LaTeX it's okay, but if I were to go and make a new essay I'd have a hard time remembering wtf packages I used for the last one and what they actually did.
I don't know, maybe the author is trying to do something with the iPad which is simply not supposed to do. The iPad is beautiful, pleasant to use etc. but writing a book on the iPad is maybe not the things one does.
I use my tablet to write — quite a lot — way slower than on my regular keyboard, but with time to think. Everything is in text files, synced to my desktop where the typesetting is really performed.
Writing publications or books is a long process where basically the final rendering is taken care at the end because the quality of the wording is more important.
So, just a text editor with hard work on the words, sentences, ideas are where 99% of the time is spent.
Maybe the author can provide an extremely pleasant way to write on the iPad and on the Mac with syncing of the work to have the feeling that the work is never lost, that one can always update a bit of the manuscript and just run "make" on the Mac some times to times. Everything in a smooth workflow.
What if you just wanted to implement a TeX based ebook reader? I think the fact that you can't think of a use-case doesn't negate the problems he's facing.
"""I don't know, maybe the author is trying to do something with the iPad which is simply not supposed to do. The iPad is beautiful, pleasant to use etc. but writing a book on the iPad is maybe not the things one does. I use my tablet to write — quite a lot — way slower than on my regular keyboard, but with time to think."""
You can pair the iPad with a bluetooth keyboard and write away at full speed.
And with something like LaTeX you won't even have formatting to slow you down.
I understand that tablets are a wonderfully portable device but you can't expect to get 100% desktop functionality. Sometimes you have to find the limit of your software/hardware.
I don't own an iPad, but is there git or the like? If so syncing and keeping track of changes would be simple.
> Sometimes you have to find the limit of your software/hardware.
The point is that there does seem to be a software limit, but there shouldn't need to be a particular limit there. There's certainly not a hardware limit, since an iPad can run circles around almost all of the computers of the era when LaTeX was written. Unless you believe that the TeX system represents an almost magical, once-in-a-lifetime, impossible to replicate achievement in software engineering, there's shouldn't be a software limit either, but the code base is so complicated that there does seem to be one.
From what I can tell, the software limit is that everybody has a different set of custom macros and styles that they use, and that distributing extra code is a violation of Apple policy, one that can't be fixed unless you get rid of not only the reality of LaTeX but the idea of LaTeX as a macro system.
2 cent take: While it may have been an epic build story to get LaTeX running on an iPad, I guess I gotta ask why not just install an iPad ssh client (iSSH, Prompt, etc.) and run LaTeX remotely? Or if you really insist on building a native client, why not one that talks to daemon on a system with LaTeX installed?
Viewing the output would be trivial: convert the output to PDF. For the ssh client case, push the PDF to a cloud file service like Dropbox. In the native client case, have the daemon push back the PDF for native client to render.
In fact, you could run a remote Emacs and edit LaTeX with it, using the excellent AUCTeX package. Of course, that means you need to have a network connection plus a server you can ssh into.
I've never tried using auctex remotely, but in general if you have a file open in Tramp, you can also run arbitrary shell commands with M-! and M-& remotely, as well as opening shell buffers that let you run commands remotely as normal.
Yeah, that's right... You could scp the .pdf back to the iPad, but that's a bit cumbersome. Oh, well, unless you give Emacs advice to do that for you after each latex command...
Perhaps LaTeX creation system should move to the cloud, think of a google-docs like service which will offer a rich, reliable and simple set of tools to create, publish and collaboratively work on documents.
has anyone thought of just having a bunch of cloud servers with LaTeX built there, and then writing a front-end which uploads your docs, compiles them and downloads the resulting PDF? with fast enough servers and good enough data speeds, this might even rival the estimated 10 seconds for a fully ported LaTeX app.
I'm assuming it's been ruled out for other reasons though.
EDIT: this would also make it trivial to use it on android/blackberry, without any extra effort. apparently, also, http://www.scribtex.com/
I wouldn't sasume it has been ruled out - people (myself included) sometimes get mentally stuck on one solution and fail to spot another obvious avenue.
At ScribTeX we regularly get comments from users about how fast our compiling is. Even with the round trip to the server, the PDF appears in the user's browser quicker than if they compile it locally. This isn't due to anything especially clever that we've done but instead stands as a testament to data speeds, and the performance of the Linodes that we compile on. Particularly with Linode, I think the high disk IO performance makes for a very quick LaTeX compile.
Having ported a TeX distribution to MacOS classic some 15 years ago, I feel that the author overstates some of the difficulties. In particular, it's not all that hard to get kpathsea to work without callouts to bash scripts (it's not like Mac OS classic supported system() or anything like it). Basically, kpathsea is an API, and the implementation can be switched out (e.g. I implemented a dbm based file name cache).
Admittedly, getting everything linked into a single binary might be fairly hard.
"... A 4GB TeX distribution dependant on over 100 binaries is not acceptable on the iPad. It is incapable of delivering the slick user experience that the iOS platform’s adherents expect and love ..."
246 comments
[ 2.7 ms ] story [ 180 ms ] threadWhat on earth is in there?
http://www.amazon.com/Computers-Typesetting-Volumes-Boxed-Se...
[looks sadly at own unread copy sigh]
The base system was 280+ mb along with 190+ mb of documentation. I found it mildly amusing that I had to download ~500 mb of stuff just to update my cv.
http://www.tug.org/mactex/morepackages.html
Things like inserting graphics with text flowing around them (picins), or document classes for resumes,or textpos (for absolute text positioning), or......
Basically you have nearly two thousand such packages in TexLive......
So, the TexLive distribution is the "fire-and-forget"-package in the LaTeX world, thats why it is so big. I use it for around 10 years now and I never had to install an additional package.
[1] It even prohibited that for a while, see Wikipedia.
Isn't latex from the 80's? I think my first disk that had more than 200Mb is from the early 90's? How did people use it back then? Also it is still horribly slow even on a core2 with 4gb ram and superfetch.
Yeah, that's what TeX does.
It does not solve the problem of writing TeX on an iPad offline, obviously.
Putting it on a server makes the architecture more robust against messy code (and changes in programming languages and environments), because pieces can be changed independently.
The problem is roughly equivalent to producing a non-upgradable perl. It's not very useful on its own, but it's completely impractical to include a copy of the entire CPAN with it. And Apple's policies prevent you from downloading additional packages. It's just not worth the effort.
I disagree that the current situation is LaTeX developers' fault. TeX and LaTeX are complex pieces of software, that are developed over time. They were extended as the capabilities of their platforms increased, to take advantage of those capabilities. This requires full access to the OS utilities, and naturally LaTeX environment does that. If anything, this is Apple's fault. For whatever reason, they cannot allow applications to use the existing capabilities of the underlying OS. This goes against the Unix mindset; of course there will be unpleasant consequences, but one cannot hold Unix mindset responsible for these.
Do note that the same is true on Google's Android OS. You can run as many threads as you want, but no calling other executables to do work in the background ...
LaTex dates back to the beginning of the 80s. Given that it has the ability to create large documents, I doubt that the required amount of main memory scales linearly with the size of the document.
Also, when you use subprocesses, besides checking their return value, you have some sort of interprocess communication which should detect when one process failed to finish his job.
It looks more like the smartphone runtimes and their sandboxes just don't support it at all, because modern GUI applications rarely build upon multiple executables in the background.
In any case, I absolutely agree that resource constraints aren't keeping LaTeX off of our mobile devices.
Of course to make the software useful in the real world, a lot of things have to be added to it - make sure to not include any of it in the 'core' otherwise the 'bug free' claim will go out the window really quickly.
So yeah, in that sense I guess it's technically (which I use as a euphemism for 'autistically') correct to call TeX bug free (the bounty program for bugs found in it is quite famous, and part of fore-mentioned marketing).
Really?
He's made a career for himself out of being an extremely creative computer scientist and writing outstandingly scholarly books about programming. Far from marketing himself as producing bug-free code, he has published articles entirely devoted to the history of bugs found in his software.
(As for the bits that turn TeX into LaTeX, no one is making a career out of claiming that they are bug free -- for the simple reason that no one thinks they are.)
The point those packages make is that some problems can have a solution that lasts years or decades instead of mere months.
That being said, I also think you have a low bar for definitions of "bugs". Terrible performance is very much a "bug" in my book. Even the things that aren't "bugs" in the strictest sense can still make for bad software. The executable described here is 4GB, that's 1/4 thte total space on a low end iPad! Also, if tomorrow someone does discover a bug, it sounds like this would be a mess to fix. The jumble of source simply won't be attracting many new developers (whether it be to fix existing bugs, add new features, or port to new platforms).
Really, borrowing MikTeX's install-on-first-use for packages and making documentation optional should result in a much more reasonable size. If you want to get fancy, teach LaTeX how to decompress packages on demand.
For the record, I do not own devices based on iOS or Android and I don't care for your little Apple-Google feud with which you seem to be so concerned with. So please, carry on with those market statistics about Android, I am dying to know more.
To get around it, you'd have to make it In App Purchases, because these also come from a the App Store.
From that quote ("A 4GB TeX distribution dependant on over 100 binaries is not acceptable on the iPad."), it is clear that he is musing about a scenario where he ships all 4GB. As stated many times (and also in that same quote), on the iPhone you are forced to ship something as one executable. Thus, the theoretical distribution he is referring to would in fact be a single executable of about 4GB. In fact I think that's the whole point of those two sentences. So it appears that I was indeed quite careful.
On the other hand, yes the executable must be "one". On the other hand you can download stuff (either directly or via DLC). The issue is that while Apple has relaxed their restrictions on bundling interpreters in applications (you can do that), they have not relaxed their restrictions on downloading interpretable code: it's not allowed. So downloading even styles would be verboten, since styles are TeX, and TeX is executable code.
AFAIK Apple doesn't restrict you from bundling files in your application. That simply wouldn't make any sense.
The point here is that he is talking about an application consisting of a single runnable binary of size X with tons of bundled .sty-files that brings the whole application up to 4GB.
Previously, this would not be allowed, since .sty-files are interpreted (which in turn would make it impossible to implement LaTeX on the iPhone), but that really wasn't the point here. The point is simply that this wouldn't be a single 4GB executable, but a an executable of perhaps 100MB bundled with a whole bunch of .sty (and other) files to a total size of 4 GB.
Edit: Fixed typos. Sorry. HN doesn't work very well on my phone.
I'm interested to see how this could be justified, instead of "hit'n'run" style.
Noting here that other than the source problems, performance was a considerable issue.
Yeah. The only benefit is a codebase that reflects current needs and can grow in new directions and follow current practices, that programmers of today are familiar with. And also be faster, and more flexible. But what are those compared to compatibility right?
(Of course people interested in pure compatibility could just continue to use the old version, until the new is compatible enough, or they don't need compatibility anymore).
"""If one tries to rewrite TeX, the problem gets much much worse, since TeX is, for all intents and purposes, bug-free."""
And your wrong assumption is a) that a problem has to be bug free to be useful or b) that a new effort can't produce a relatively bug free codebase?
How are either of those requirements wrong? I certainly expect my programs to be bug free. LaTeX is a tool that's older than many GNU utilities. It's been reviewed and tested numerous times over by the harshest test suite of all: the real world.
Yes, in theory, you could rewrite TeX to be cleaner, while maintaining backwards compatibility and lack of bugs and regressions. In practice, this is very very hard. It's so hard that no one, no individual or company has managed to pull it off.
But hey, who knows? You could be the first. The LaTeX codebase is open-source. If you think you can pull off what the most talented software engineers in the world haven't been able to do, go right ahead.
Good luck with that. What I said, though, was that "a problem has to be bug free to be useful" is a wrong assumption. We all use programs that have bugs, and still found them immensely useful.
"""Yes, in theory, you could rewrite TeX to be cleaner, while maintaining backwards compatibility and lack of bugs and regressions. In practice, this is very very hard. It's so hard that no one, no individual or company has managed to pull it off."""
What are you talking about? Tons of people have written TeX versions of their own, even in Lua, and most of those are widely used.
"""But hey, who knows? You could be the first."""
Hardly. There is LuaTex, XeTeX (even more widely used) and others. Are you just talking out of your ass? (Not to mention several other modern typesetting engines that are not TeX based. You make it sound like TeX is an impossible achievement).
Now, what I said I'd like to see was not a rewriting of TeX itself, but a modern version of a TeX like engine, with or without compatibility. Programs like XeTeX and Omega for example provide Unicode support and TTF/OT support to TeX, but I'd like to see something more modular, and with a more streamlined markup than TeX+LaTeX. While we're at it, even scriptable.
There are also some improvements found since in typesetting, like those employed in the InDesign layout engine concerning edge text and hyphenation.
The purpose and benefit of backward compatibility for TeX is that a 30 year old manuscript written in TeX can be fed to the latest version and produce identical output to what was produced 30 years ago. (Of course, you'd also have to archive the macro packages and font files you were using, but those were never machine dependent).
The notion that every time we have a new language/platform, we must REWRITE THE WORLD!! is absurd and a huge waste of resources. We should stop making excuses for it.
Yeah, you probably missed the whole point of the comment, TFA, and several other stuff besides.
It's not Apple's platform that's the problem, is TeX/LaTeX that is lacking important features. In EVERY platform.
People have been hacking them on to it, but having a better codebase to start off, without the assumptions TeX/LaTeX make would really make it so much easier.
"""The notion that every time we have a new language/platform, we must REWRITE THE WORLD!! is absurd and a huge waste of resources."""
Yeah, good thing that nobody suggested anything like that in the thread.
Btw, the notion that you can add your worthless reply without first understanding what the parent poster says is absurd. You should stop making excuses for it.
Using the native capabilities of the OS in the sense you mean - allowing TeX to use its ancient, hideous bitmap font system, goes against:
- Unix philisophy - do one thing well, link against or pipe to other apps/libraries that do their thing well
- Simplicity. The user should not be forced to make an unnecessary choice where one option is almost always superor to the other.
Knuth's concept of 'bug free' is one of an academic computer scientist. TeX has many, many issues: unnecessary dependencies, a horrible build process, and many UX issues that stopped TeX from reaching TeX's original goal of 'allowing anyone to create typeset documents'. This is fine: Knuth is a mathematically focused computer scientist from a period where everyone who had access to a computer was a programmer. It was valid in this era.
All kidding aside, I use (La)TeX almost every day and it's bulletproof. It's not going anywhere, so you might as well learn to love it, worts and all.
Even with the released version, I don't think TeX was ever intended to be the last word on typesetting; it was simply his best attempt at a decent markup. He then froze the features so that previously typeset books could be corrected and reprinted using the same source. He left it up to future programs to innovate.
[1]: http://www.webofstories.com/play/17118
But I don't think Joel is against a slow, one line at a time, working on the old code base rewrite.
It is not clear what kind of re-write the OP is advocating. But I would be surprised if he is pro the start from scratch kind.
But it might be just my biased perception.
I find it likely that you'd be better off performing an algorithm extraction and doing a true from-scratch rewrite than trying to incrementally translate TeX and LaTeX.
For the reader's convenience and reference: http://www.joelonsoftware.com/articles/fog0000000069.html
Computer science and engineering departments should use these situations to train their students.
There is some truth in your microrant here. I would restate it like this: Instead of getting excited with how expressive is a new sexy multi-injection functional language when you write the nth Fibonacci sequence, I would think it more realist and constructive to get excited with how a new language or a new extension of an existing language allow to handle module and package dependencies in a clean, safe and explicit way.
It resonates also with my work today: I spend a few hours removing those evil "import *" from our codebase... (Python's "we are grownups" mantra is nice, but I think a piece of the quote is missing: "we are grownups, thus we run pylint and comply to all the rules, except a few carefully chosen ones")
Sorry, but I fail to understand, why any serious TeX-Head would say that. The platform is crippled and your problem shows it. You are ranting in the wrong direction.
-jsl
But I am not sure if "fault" is an appropriate term here anyway, we're simply observing two different approaches to software bundling that happen to be incompatible.
How can anyone really be suprised that one of the oldest and mightiest gods of one religion can not be coerced into the shrine of a completely different religion?
Personally, I'm in the camp of "rely on as little as you can". This includes not shelling out to bash unless you really really really can't achieve the same thing with a bit of more code. Apart from making the app less portable, more bug prone, less maintainable etc, it's just ugly.
Does it have a good selection of packages, or just the bare-bones?
Then good luck! Please post again once you've finished the rewrite.
* LaTeX is working on the iPad, see for example: http://meeting.contextgarden.net/2010/talks/2010-09-14-arthu...
* LuaTeX (http://luatex.org) is written in C, not WEB.
* You only need one binary to work with TeX. Either PDFTeX or LuaTeX. All other binaries are just glue code (for example to generate missing Metafont fonts, but who wants them these days anyway?
A lot of TeX uses Computer Modern to typeset the body (a metafont font) and I don't think I have ever see a TeX document that doesn't use Computer Modern or Euler (another metafont font) for equation typesetting.
I also wonder whether it's possible to achieve the excellent equation typesetting capabilities of TeX without metafont.
I can think of no reason to prefer CM to LM for typesetting purposes.
And that's before getting into anything truly gross.
A long-running process (daemon) is therefore a much more efficient way to run (La)TeX.
[1] www.tug.org/TUGboat/tb27-0/fine.pdf
""" On my current 800 MHz PC, the command
takes about 0.137 seconds, while takes 0.133 seconds. The first command typesets a small page of material; the second does nothing but start TEX and then exit. Thus, typesetting the small page takes about 0.004 seconds. """Which is not to say it's not a good idea here.
Maybe you just need a smaller laptop ..
Also, terminals are great, but writing anything serious without X is a pain.
> Maybe you just need a smaller laptop ..
No, I don't want to have a small laptop as my main computer. I had an Eee before the iPad, but the difference in the writing experience is not too different in the end and the other advantages of the iPad are greater. In any case, you can hardly call me a person who unreasonably hangs on to Apple stuff: I'm writing this under Linux which I installed on the MBP my university gave me. I hardly ever boot into OS X here.
> Also, terminals are great, but writing anything serious without X is a pain.
Why? Emacs doesn't really need X, and I don't need to re-typeset my work every five minutes.
Guess this depends on how you work. I often find myself starting many instances of the editor[1] which is a pain if you have to create a new ssh connection for each (or use ctrl-z etc).
"the writing experience is not too different [..] the other advantages of the iPad are greater."
Guess the real difference between us is that you see something great in the iPad, so you are willing to live with its obvious shortcomings[2] compared to a laptop. I have yet to discover why it's so amazing, and only see a small, but pretty much useless gadget. It could be used for reading I guess..
[1] yes, it has tabs.. still
[2] low resolution, can't run what I want to run, can't type on it without a keyboard, and at that point you could just as easily carry a small laptop (not an Eee ffs, a real laptop).
Well, ok, I use screen to detach irssi etc.. but not as a "window" manager
Oh, absolutely. If I were a actual road warrior, the iPad wouldn't work at all for me. However, between my laptops at home and at work I don't really need a third one, and since I already have the iPad I'd rather make as much I can with it for short trips where I am not going have too much time and/or wifi to pull sustained work sessions.
> It could be used for reading I guess..
That too. For an academic, GoodReader is a blessing. I have finally stopped printing out loads of articles and/or finding that I printed out this same article a couple of years ago. Not to mention Kindle etc. Again, if I were spending significant amounts of time away from either home or the office, I'd consider investing in a proper portable laptop; but I'm not, and for my use case the iPad is ideal.
> can't run what I want to run
Yep, I agree that it's frustrating.
> (not an Eee ffs, a real laptop).
No everybody can afford another proper laptop that's as easy to carry around as an iPad, y'know.
Anyway, YMMV, of course. I was just pointing out that solutions are available.
It's definitely not perfect--I really wish there were something better--but for writing technical academic papers, it seems like far and away the best.
LaTeX is about as far from dead as the desktop computer.
Hilariously, they screwed up the implementation, which does not match the specification in their tech report: http://tex.stackexchange.com/questions/20487/why-does-ms-wor...
And if you're including mathematical formulae, which scientific academia will do, HTML is rubbish for formulae.
Maybe the Lout system will pick enough traction one day.
Lout's equation formatting is especially primitive as I recall, and that is a huge amount of work to get TeX-like quality for. I am unaware of any system that typesets mathematics as nicely as TeX does.
It would be good to see UTF-8 natively supported, and for all the common packages to be absorbed into the core libraries. Right now, you can sometimes find 2 or 3 different packages that do the same thing, often with varying benefits. Take the best package, add the missing features from the other packages, and bundle it all into one distribution. For example, the absolutely horrible table support, where merging cells is a nightmare.
I use my tablet to write — quite a lot — way slower than on my regular keyboard, but with time to think. Everything is in text files, synced to my desktop where the typesetting is really performed.
Writing publications or books is a long process where basically the final rendering is taken care at the end because the quality of the wording is more important.
So, just a text editor with hard work on the words, sentences, ideas are where 99% of the time is spent.
Maybe the author can provide an extremely pleasant way to write on the iPad and on the Mac with syncing of the work to have the feeling that the work is never lost, that one can always update a bit of the manuscript and just run "make" on the Mac some times to times. Everything in a smooth workflow.
You can pair the iPad with a bluetooth keyboard and write away at full speed.
And with something like LaTeX you won't even have formatting to slow you down.
I understand that tablets are a wonderfully portable device but you can't expect to get 100% desktop functionality. Sometimes you have to find the limit of your software/hardware.
I don't own an iPad, but is there git or the like? If so syncing and keeping track of changes would be simple.
The point is that there does seem to be a software limit, but there shouldn't need to be a particular limit there. There's certainly not a hardware limit, since an iPad can run circles around almost all of the computers of the era when LaTeX was written. Unless you believe that the TeX system represents an almost magical, once-in-a-lifetime, impossible to replicate achievement in software engineering, there's shouldn't be a software limit either, but the code base is so complicated that there does seem to be one.
That, or Apple changes their policies.
Viewing the output would be trivial: convert the output to PDF. For the ssh client case, push the PDF to a cloud file service like Dropbox. In the native client case, have the daemon push back the PDF for native client to render.
Why have no one suggested to split LaTeX into two parts like the Emacs server, or something?
With a client and a server to run on your desktop/laptop/etc.
Edit: Clarity.
I'm assuming it's been ruled out for other reasons though.
EDIT: this would also make it trivial to use it on android/blackberry, without any extra effort. apparently, also, http://www.scribtex.com/
I wouldn't sasume it has been ruled out - people (myself included) sometimes get mentally stuck on one solution and fail to spot another obvious avenue.
Admittedly, getting everything linked into a single binary might be fairly hard.
Xterm (iSSH) to linux box? ~ http://news.ycombinator.com/item?id=280730