TeX Live 2019
tug.org
tug.org
Or a local group:
https://tug.org/usergroups.html
One of the perks of TUG membership is that you get free TeXLive install DVDs sent to your door every year (as many as you need, in my experience).
You also get a subscription to TugBoat, the TeX Users Group Magazine, which is full of curios for the TeX aficionado.
[Edited to replace UK TUG group link with link to global TUG directory]
Some people also prefer the layout (where various configuration files are kept, for instance).
tlmgr update --all
[0] https://tug.org/texlive/doc/texlive-en/texlive-en.html#x1-18...
Then there are many packages that contain pictures or logos. As a single random example, texmf-dist/tex/latex/fithesis is 2.4M, of which 2.1M are in fithesis/logo.
It is missing most packages though, but only ~76M.
Windows users have the option of installing via MiKTeX instead of TeXLive, the benefit being that MiKTeX has a package management system which installs the base packages at start and then automatically downloads the others as and when they are needed. [1]
Not sure if that's possible in other OS'?
I think KerTeX (http://www.kergis.com/en/kertex.html) now allows a similar style of pick-and-choose package installation, but it doesn't support a lot of packages (yet?).
I must admit I speak as a Linux user who's installed TeX on Windows machines, but not really gone into detail myself, so please correct me if I'm wrong.
tlmgr install <package>On macOS:
brew install tectonic
tectonic mypaper.tex
Thanks.
ConTeXt is from about a decade later, after some lessons were learned.
More here:
- https://tex.stackexchange.com/questions/223177/what-is-the-m...
- https://tex.stackexchange.com/questions/4987/why-should-i-be...
- https://tex.stackexchange.com/questions/1887/what-typesettin...
- https://tug.org/interviews/hagen.html
- https://tex.stackexchange.com/questions/29979/how-do-latex3-...
- https://tex.stackexchange.com/questions/447566/health-of-con...
My impression: What you get with LaTeX is a larger ecosystem and greater likelihood that someone has already done what you need (in some package or other, though it may be only "close" and figuring out how to improve it may be hard). What you get with ConTeXt, at the cost of having to re-learn everything you learned about LaTeX and not being able to use any of the LaTeX packages, is a more consistently designed interface, a greater understanding of what's going on, more ease of modifying things (instead of the "there's a package for that" phenomenon), and best of all not having to "program" in the TeX macro "language" (you can use Lua).
Wait was this released yesterday or a year ago yesterday?
One technology that has stood the test of time- amazingly well designed TeX by Donald Knuth and LaTeX by Leslie Lamport.
Plain TeX can be a bit beginner unfriendly because most beginners use LaTeX and experienced people have their own 'coding style' but it's amazingly powerful.
I only wish somebody would add the minimum required primitives to plain TeX to render reflowable text in browsers and ebook readers
TeX was designed for "beautiful" typesetting but it gives you much more control than that IMHO. I'd urge everyone to try it out once, I use it offline but I think overleaf.com allows for plain TeX too. (XeTeX may work best for unicode, it's plain tex + minimal additions for Unicode)
On that note- I am not fond of PDFs because of their awfully poor unicode search support- does anybody knowledgeable know of a good target format I should use (and the appropriate drivers?)
What primitives do you think need adding to TeX? LaTeXML, which powers Engrafo, does a pretty good job of converting plain TeX, as well as LaTeX.
I might suggest Bitstream Charter for a well-designed and readable analogue to CMR for digital use.
[1] https://www.typografie.info/3/topic/22238-ist-die-computer-m... (German language)
This is why we don't use PDF for web pages.
Regardless of what one thinks of their other qualities, if a PDF can be searched in Adobe Reader or Acrobat, then the file is probably OK but the PDF reader that you were trying to search it with has a bug on its end (or more likely, some unimplemented dark corner of the PDF spec).
On the other hand, if the file isn't searchable via Reader/Acrobat, then the problem is most likely with the authoring of the file itself. The most common thing that breaks searching is when instead of embedding all fonts used, a PDF refers to fonts by name from the local system. This can cause unpredictable issues when reading the PDF from another OS that can't resolve those font names.
Another common breaker of search that seems to be much more common with TeX are workflows which somehow produce PDFs that have embedded Type 3 fonts. Type 3 fonts represent glyphs using PDF drawing instructions. It's less a file format than something that only exists as an embedded font within a PDF, but I've only seen them in the wild when authored by pdflatex or similar. It seems like TrueType or OpenType are the most reliable formats to embed across the most commonly used PDF implementations, but that's an educated guess. Type 3 font support is spotty in non-Adobe implementations.
Finally, font subsetting might screw up search. Most software that knows how to produce PDFs can produce PDFs with embedded but subsetted fonts. This means the software that created the file embedded TrueType fonts (for example), but created a special version of the font for embedding that only contained the glyphs used in the PDF. Depending on the quality of the software used to do the font subsetting, the output PDF might not retain the mapping of glyphs back to Unicode characters. If that happens, text using that font in the PDF becomes unsearchable, but the PDF remains renderable.
None of this is meant to excuse the shortcomings of the format, it's clearly overcomplicated and fragile. But when I've seen problems with searchability of PDFs, it's most often been with the software that was used to create the files, or how that software was configured by the author. And when it is a problem with the authored file itself, it's almost always because of fonts. Either the fonts aren't embedded, or they're embedded in a slightly oddball format that's in spec for PDF but not perfectly, universally supported by all of the various non-Adobe PDF implementations.
That said, and despite your yourself having mentioned that there is no excuse for the shortcomings, I feel like this decision in particular is just plain inexcusable anyway because if you're going to write portable document, at least use some form of UTF encoding rather than indexing into glyphs (or on top of !)
There are some experimental JavaScript implementations, but without browser support reflowing high-quality justified text is a non-starter on the web.
That's a fair response, but how about changing the (CSS) specs to allow better line breaking? Surely that would take less time than WebUSB, and Google or Mozilla could quickly push it through the IETF.
Remember, TeX was written to be usable on a 1 megabyte, 10 megahertz machine, where it ran about a page a second. One of my contributions at the time was to modify the Pascal compiler on the Sail PDP10 to count cycles for every machine instruction executed by TeX over all users over a number of months, and Knuth fine-tuned the inner-loops of TeX here and there based on the results (the code that automatically inserts kerns and ligatures got the most attention, IIRC).
I'm much more sympathetic to the point that, while TeX's line-breaking algorithm can easily handle paragraphs with different line lengths for each line, it needs to know at the start what the different line lengths are. It's not clear how to generalize it to be able to handle layouts where the length of the nth line of a paragraph depends on the earlier (or later!) line breaks. Think tall floating figures which impinge on the text area of the paragraph they're in. I'm guessing that was the real impediment in using it in Web-land.
I was deep into LaTeX during the 90's while at the university, my Lamport's book copy state reflects how much I used to refer back to it.
Nowadays I rather prefer the convenience of something like FrameMaker.
It depends on the document, a pdf page could be:
1) Text
2) An image of text
3) Lines/Curves that happen to be in the shape of letters/text
If it's text it perfectly searchable. If it's one of the others the creator has to also OCR it and add the text behind the image or in front but invisible (no stroke or fill).