Print

Print


Joseph Wright wrote:
> On 06/03/2011 10:47, Arno Trautmann wrote:
>>> When I rewrote the coffins code, I originally included "c" variants, but
>>> decided to leave them out pending seeing whether they were needed. I've
>>> no objection to them, I was just trying to avoid 'variant overkill'.
>>> Note that if you allow "c"-type names, then it's not just \coffin_new:N
>>> that needs variants. All of the 'code-level interface' functions should
>>> be done for consistency. This is the work of 5 minutes: shall I make the
>>> change?
>>
>> If no one else has needed it so far, I'll just add it to my package. I
>> only asked to see if there was a special reason that coffin names should
>> not be handled this way.
> 
> As I said, what would be nice is an idea of the context. It may well be
> that we need the "c" variants: after all, until people try these things
> out then it's hard to know.

Ok, to go into detail: I wrote a class for typesetting flashcards to
prepare for exams. The user writes something like

\card
question1

answer1

etc. The blank lines are just to minimize writing effort. The questions
are then set on the front side of a paper, the answers on the back side.
Now, question and answer have to fit together, so I have to store
content in boxes and putting them in the correct order onto a grid on
both sides of a page.
Using LaTeX2ε, I stored the content in macros with names given by a
counter (question@page) that is raised for every question on one page:

\expandafter\def\csname answer@\thequestion@page \endcsname{#3}

and placed them using minipages and reversed textdirection (rtl) for the
answers. That was not very robust and the code looks ugly, so I am
looking for a more stable way and coffins seem to be helpful here.

Hope this is enough information; the code is on github:
https://github.com/alt/lernkarten

cheers
Arno