Re: [NTG-context] Migrating from LaTeX (was: A not so short introduction to ConTeXt Mark IV)

Am 04.01.2021 um 14:02 schrieb BPJ :

I understand all that. I just thought that maybe such resources existed which I didn't know.

While as you say the approaches differ it would be nice to have like a FAQ "how do you do what LaTeX package X does in ConTeXt?" I guess that that is what I'm after.

But that’s already a wrong approach IMO – you need to think in goals, not in paths. Most ConTeXt users don’t know what any LaTeX package does, so you need to explain what you want to achieve. Regardless which system you are learning, never assume it would work the same as some other system you know, even if it does the same or shares some concepts. E.g. when I was working at a newspaper, they changed the ad management system; ad vendors were used to give their customers special kinds of discounts and needed some strange workarounds where the old system was lacking. At first, management tried (or had IT dept try) to implement all the old stuff, until it became clear it just made no sense – vendors had to adapt to the new system (that was generally better and more flexible, but of course also lacking a few details). When I recently switched from InDesign/Photoshop to Affinity Publisher/Photo, it was the same re-learning for me, and I’m still much slower with AP, also because I don’t use it daily any more like I was used with ID several years ago. E.g. I needed the experience of several print projects to get colors print right again – the whole color management and PDF export setup is just too different (without it looking too different).

I'm basically still using only LaTeX because I know which packages to use to do the things I want. Perhaps that *is* as good a reason as any to stay with LaTeX

yes it is

but it shouldn't be a barrier to learning ConTeXt which IME it is.

The barrier is in your head. Don’t assume ConTeXt is like LaTeX, but be amazed if it does. ;)

To take but one example: when wearing my linguist hat I deal with obscure scripts and languages, mostly dead languages, which no standard LaTeX index processor can handle (at least not out of the box) so I have my pile of Perl hacks which generate indices using Perl's excellent Unicode capabilities and some excellent modules written by other people.

I don’t know what you’re doing, but since ConTeXt can handle Unicode much better than LaTeX, many of your hacks might be dispensable. For others there might be better solutions, e.g. implement additional sorting mechanisms in Lua within ConTeXt. There should be no need for additional external index processing.

Admittedly it might be just me: I have a hard time knowing where to look in the likewise excellent Vim documentation too: what search terms to use. Finding a LaTeX solution to a problem with Google OTOH usually is pretty fast done — if you can describe your problem in prose you usually don't hit a wall.

Yes, and that’s again true for every system – you need to find your way through the documentation. E.g. GNU LilyPond’s docs are great, but you need to know what’s in the Learning Manual, Reference Manual or extension docs, and that you also might look into the snippet repository LSR or OpenLilyLib. You need to learn the lingo of each system, sometimes something has a strange name due to historical reasons or because the right term was ambiguous or unknown to the developers. – ConTeXt not only calls indexes registers (like also in German), but also imposition arranging...

With knowledge of TeX basics I did not mean a working knowledge of plain TeX but the actual basics: reserved characters, syntax, space after a command is ignored, a blank line makes a paragraph, that sort of things which are common to all flavors.

Yes and no – space handling of course, and, as Hans said, it helps to understand the box composition and expansion (I don’t really, and I guess also most LaTeX users don’t). Reserved characters are already misleading – ConTeXt has far less than LaTeX and uses direct Unicode input as far as possible. Keep trying. Hraban