Michael,
> I mean customized LCO files. For my former company I had made a
> letter class for business letters based on scrlttr2.cls with two LCO
> files. the first LCO file *company.lco* contained the general
> information about the company (address, bank account, etc.). A
> second LCO file *my_name.lco* contained the personal information of
> (e-mail address, name, phone extension). With *my_name.lco* calling
> *company.lco* the document class command for my letter finally was:
>
> \documentclass[my_name]{our_company_letter_class}
>
> With suitable setting of org-latex-classes not even the LCO feature
> would be needed in ox-koma-letter. However I would leave it there for
> more flexibility.
That's cool. Personally, I like this approach. But while lco files
are still readable they are not very nice. But not that terrible
either.
In fact to use the scrlttr2 support in Org I had to adjust a LCO files
because it's currently loaded after LATEX_HEADER arguments (so all
customization was overwritten). I didn't like that.
> Yes, I can imagine such cases. My problem with the current
> implementation was, that for instance, the phone number was preset in
> org-latex-classes. That urged me to customize this variable although
> everything was already well defined in *my_name.lco*. So, please take
> care to preset such variables with nil, where nil shall have the
> meaning
> of 'ignore this variable'.
I agree. This is anything but flexible, and I didn't even consider
it. I also noted that there's a lot of silly defaults. So probably
we should set everything to nil and do a "nil check" before inserting
stuff into the TeX file. This would also make for a clearer output
file, which is in itself something we should aim for.
> Maybe we should write a user guide *before* further implementation
> steps.
I agree. A "question zero" is whether we eventually want to have an
org-letter which could, in principle, output to something different
than scrlttr2.
Other things:
- Cleaning defaults
- Only insert KOMAVARs when non-nil.
- Which variables to include. E.g. Michael's list vs. every
komavar.
- consider the order of KOMAVARs, e.g. do we really want
LATEX_HEADER before LCO-like stuff? Do we want a KOMA_HEADER
(or LETTER_HEADER) which comes after LCO?
What to you think?
> Mmmh ... never thought about this aspect. I simply dictated the order
> of CC, ENCL and PS in my implementation. Thus your current
> AFTER_CLOSING is the best solution, if you want to provide full
> flexibility.
Or having the order of ENCL, PS, CC and "AFTER_CLOSING" in the TeX
file be governed by the order in the Org file. I guess this should be
feasible, although I currently do not know how to code. I think it's
desireable, though.
–Rasmus
--
When in doubt, do it!
