Mike Cooper
Thanks David!
I don't think I've ever been quite so frustrated at trying to learn anything else in my life! If it wasn't required by my job, I wouldn't have made it past the first day or two (3 months ago). But I'm slogging away and it's gradually coming together (I think). I spent my whole day yesterday figuring out how to do some very basic formatting/layout that would have taken 5-10 minutes in Word or HTML/CSS.
People have been very helpful and patient with me!! Thanks to all of you for that!
And thanks David for this explanation of the situation.
regards, Mike
You may already be doing what I'm about to suggest. If so, please disregard. One source that has helped me a lot is the archive of this mailing list, where I've searched for any messages that mention whatever it is that I'm looking for. Of course such a search is slower than scrolling through the index of a manual, and sometimes it's hard to figure out "What keyword do I search on? If I knew the correct keyword, I'd be done this already!" - but quite often I've "hit the jackpot" and found exactly what I needed, or close enough that I only had to change some details. You will soon notice that there are some people on the list who consistently see through the problems that are presented, and who say something like "I think you probably want something like this:" - followed by a solution that makes you say confidently "A-ha! So THAT'S how that's done!". The really good problem-solving sessions on the list, both the elegant answers and the questions that precede them, could form a pretty good start on a manual. Of course such a method is hit-or-miss, but in this case there are quite a few hits. Just watch out (in much older messages) that you're not fully relying on an answer based on ConTeXt Mk II, because many of those solutions no longer work in the newer versions. ... which has accidentally led me to another documentation comment. Hans's programming philosophy is not something I'm an expert on, but it seems clear that he values "usability, good function, and getting the job done well" much higher than he values "backward compatibility forever". In other words, if something is broken or not good enough, he doesn't hesitate to fix it or improve it in the best way he can see. This is good for the software in that it is constantly improving in every direction, but it does also make it a bit more of a challenge to document, and a bit more of a challenge to find someone who *wants* to document it - "How ConTeXt Used To Work Last Year" is clearly not going to be a top-selling title. :) But despite that, the majority of what you want to know has not changed in quite some time, and usually only *very* old solutions will fail completely. I want to finish this message by saying: When you read through "SomeFile.tex" that you've created, every switch and command in it should make sense to you. In the beginning that might not always be the case, but it's easier for you to get there than it might sound, and you'll see that all the best solutions you get from others share that quality of "Ah, I see, that makes sense, I get how this works". Most of the time, a solution that doesn't give you that feeling is not quite the right way to do it. Of course a poor solution is better than nothing, but please don't stay satisfied with hairy-looking clusters of commands that sort of work but no one knows why. (I've written lots of those, that's why I say this.) :) Simple and direct writing means the mistakes will soon become obvious; the worst thing to do in ConTeXt is to make a complicated mysterious mistake that you can't even find. Well. THAT turned out longer than I intended. :) -- David