* Different output formats

We have seen possible structure of presentation in xml format. As I said
this morning, xml does not impose semantic rules; you're free to invent
your own structure for your document. Of course, in my case, this structure
shaped by fact that I knew what I wanted to do with my document; I came up
with structure and elements that are derived from way in which presentation
is structured in simpleslides. But this xml structure could be used in
other ways: there's numuber css style sheets which allows to write slides
for presentation in web browser. Would be relatively easy to write xslt
converter which would translate our xml file into this syntax, so you could
put slides on web, everybody could see them in their web browsers. 

My workflow slightly different. I process my slides with ConTeXt, and since
I've been giving lecture courses for 12 years now, I know that I want and
need 3, possibly 4 output formats:

1. 1st of course presentation itself, series of pdf "slides" which I will
   show in classroom with aid of digital projector. This is why I began
   work on simpleslides module, which Aditya has improved immensely: wanted
   nice design for my slides, nice colors, and some eye-candy. I try to
   come up with new design for every class, and I always try to integrate
   something that would be difficult to have in program such as OpenOffice
   Impress or Powerpoint: list of topics in margin, visual counter, some
   randomized graphics. Over years, have seen that there is limited number
   of designs that recur again and again: text + translation, pictures,
   itemizations, a few tables... 
2. Students like to have slides available for download. During 1st years,
   simply put them on website, but they asked to have version which could
   be printed more easily. At first, I simply post-processed them to
   arrange 2x4 (and used mkii for that because I never got mkiv to
   work). But with new xml mechanism, I developed new way: process xml and
   typeset slides without any eye-candy, in sober design which is ideal for
   printing. 
3. My manuscript: at first, I used A6 paper which I arranged on A4, printed
   and cut them (found this more convenient). I still have this output
   option because it allows me to guesstimate length: I know I need around
   20-22 of these index cards for a lecture of 40-45 minutes.
4. As you can see, I have bought me an iPad, so this term, I have for first
   time new output format which I will display on my iPad (synced via
   dropbox). 

* Demonstrating running and output

Let's now have look at these different output formats. 

Process:

- cards: context --environment=karten-style (--mode=arranged) archaik.xml
- presentation: context --environment=presentation-style --mode=11_10_12_a archaik.xml
- handout: context --environment=handout-style --mode=11_10_12_b archaik.xml
- combined: context --environment=combined-style --mode=11_10_12_b archaik.xml

* Looking at different style files

Will not torture you by going through my different styles line by line,
would be way too long. I'll also admit that some problems are not solved
yet - for example, haven't found good way of representing tabulate
environment in xml because setup depends on number of columns. But let us
just look at few highlights:

** cards
As you can see [l. 2], this one processes only slidecomments, not
slidecontent; this makes it simplest of all styles because my lecture text
doesn't contain many complex environments. This one has interactive table
of contents (l. 177-181) and has "arranged" mode to produce A4 paper output
which can then be cut into index cards. Every slide will increment counter,
which will be displayed.

** presentation
This one most similar to what we've covered in 1st part; most environments
etc. lifted straight from this file. Of course, contains lots more,
esp. code for pictures. l.43-65: this code becomes somewhat complex because
I needed to find way to pass options to simpleslides module for picture
macro; took me a while to find nifty command \xmlattdef in documentation:
retrieves xml attribute, set default value if it's not there. Also contains
little cheat: l. 99-104 something that I asked on list in August. If
something just too complex to code in xml, I can always put it into buffer
as TeX code and run it inside my xml file. For this, file PresBuffers
\input, contains pictures as buffers [SHOW]. Do this on regular basis for
metafun pictures, but if I'm pressed for time or have real difficulty, this
cheat I can always use. All the macros, all the useful code that I have
accumulated over years go into this file.

** handout
This contains almost same code as presentation-style, but doesn't use
simpleslides module (this something I may change). Apart from this, most
important stuff in l. 394-428: arranging and drawing frame around single
slides. 

** combined
I'm not quite certain yet how to handle this style. For a while, I wanted
to process both slidecontent and slidecomment, but then it occurred to me
that I might simply reuse presentations which are already there and insert
pictures of their single pages. This presupposes that this combined part
always produced last, but that feasible. I have 2 small problems now, and
maybe I can get help here:
- I define a \newcount and advance it with every slide to retrieve
  corresponding page. My problem was that I needed low-level
  \the\newcount. Shouldn't more ConTeXT-like \getnumber[something] work as
  well? 
- More serious: if I ever forget to bring presentation to its most current
  status, I might demand page that doesn't exist yet. Possible to catch
  this exception with \doifpagenumberexists or something?

We can look at l. 41-64 to see how things are done; you see commented
section where I tried to still process slidecontent and "new" section where
I simply retrieve pages from presentation pdf. Typesets combination of big
red number of slide and frame into which content of slide is placed.

** Strength: independent
Advantage of having these different styles of course that it's easy to
redefine commands so that output can be vey variable

** Weakness: should be made modular
however, I have also seen drawback: difficult to support. I keep copying
and pasting same or very similar code to all styles; when I want to use
new xml tag, need to write definitions in 4 different style files. So once
I have a bit more experience with code, I want to make it more modular:
maybe define one common part in which all identical code will go (stuff
like, say, bold or italic, which is independent from output format) and
then separate code which is unique. But that's stuff for a rainy winter
night. 

* Looking at lua makefile, explaining its structure

Since I found it somewhat tiring to retype all the context
--environment... stuff every time I want to recompile my presentation, I
have for some time been using a makefile. I wanted some special stuff this
term, so I decided to take this approach one step further; wrote makefile
in lua. [SHOW] Since I use both linux and OS X, needed to make everything
as platform independent as possible. In good makefile manner, have defined
everything as variables so that, should I ever want to change anything,
I'll have to change it only once; hopefully, will be able to reuse it for
all lecture courses till my retirement by just changing first line. 

Calling this lua makefile with 2 arguments: TAG refers to presentation we
want to process, TARGET to form of output. Maybe of interest to look at
some special elements: when I typeset as "presentation," output copied to
subdirectory "presentations" in form 11_10_12_a.pdf. "combined" copies to
"archaik_ms.pdf" so this will always be latest version of mss; "cards" to
"archaik_cd.pdf." Maybe most interesting part "handout." Wanted to add bit
of eye candy and bells and whistles, so it does, on top of processing with
right style file, 2 things:

- as very last page, includes slide with qr-code which will direct
  smartphone to download page and has date as sort of watermark;
- as last page but one, runs IBM word cloud: writes content of xml to file
  in /tmp directory and then takes this as input for java engine; include
  resulting picture.

* Bonus for me: problem with <topic>...

This concludes my talk about presentations in xml and ConTeXt. As bonus for
myself: I have a question for gurus. Problem with TOC in side margin which
always adds vertical space. How to implement this? 

OPEN IN MACVIM: 4 different style files, PresBuffers.tex, make.lua
OPEN IN EMACS: archaik.xml
OPEN IN PREVIEW: archaik.pdf