[patch] ox-koma-letter

[patch] ox-koma-letter

[Rasmus]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

Hi,

I have been working on extending the KOMA letter support in Org.  The
backend is still rough and I would like to more stuff such as
designing firstfood and firsthead with org elements (e.g. I use a
tabularx for my firstfood with varioues stuff).

I have changed the following objects:

  1. Make keys sane; no reason why open pdf is O rather than o and why
     k is used in place of l (as in the tex exporter).
  2. Added AFTER_CLOSING and AFTER_LETTER keywords for arbitrary code
     after \closing{.} and \end{letter}, respectively.
     a. A weird bug I don't understand is why I cannot have
        #+AFTER_CLOSING{\ps{ps:}}
     b. Would it be better to have a dedicated, say, PS and ENCL rather
        than the generic AFTER_CLOSING?
  3. Added from-bank, invoice and other keywords like that.  Still
     many to go, but some of them would probably need some thought.
     For instance firstfoot should work differently depending on
     whether it is given a NAMEd table or a string.  Any though? 

I'm not a good programmer, so if someone could look through it, and
say whether it's OK it'd be happy to work more on in and submit it a
proper patch if deemed worthy.

Also, if someone has thoughts on how to improve the letter experience
that would be interesting to hear.  

I'd love to hear an explanation of point a. above.

Further, perhaps we should remove all the silly defaults from the
defcustoms in ox-koma-letter?  

–Rasmus

-- 
. . . Stallman was indeed the tallest possible mountain and by
standing on his shoulders you could see forever. . .

[-- Attachment #2: koma.diff --]
[-- Type: text/plain, Size: 4111 bytes --]

diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 07633e3..069d458 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -91,6 +91,23 @@
   :group 'org-export-koma-letter
   :type 'string)
 
+(defcustom org-koma-letter-from-bank ""
+  "Sender's bank account, as a string."
+  :group 'org-export-koma-letter
+  :type 'string)
+
+(defcustom org-koma-letter-from-fax ""
+  "Sender's fax number, as a string."
+  :group 'org-export-koma-letter
+  :type 'string)
+
+(defcustom org-koma-letter-from-url ""
+  "Sender's url, as a string."
+  :group 'org-export-koma-letter
+  :type 'string)
+
+
+
 (defcustom org-koma-letter-opening "Dear Sir,"
   "Letter's opening, as a string."
   :group 'org-export-koma-letter
@@ -106,33 +123,42 @@
   :group 'org-export-koma-letter
   :type 'string)
 
-\f
+
 ;;; Define Back-End
 
 (org-export-define-derived-backend koma-letter latex
   :options-alist
-  ((:closing "CLOSING" nil org-koma-letter-closing)
+  ((:after-closing "AFTER_CLOSING" nil "" newline)
+   (:after-letter "AFTER_LETTER" nil "" newline)
+   (:closing "CLOSING" nil org-koma-letter-closing)
    (:from-address "FROM_ADDRESS" nil org-koma-letter-from-address newline)
+   (:from-bank "FROM_BANK" nil org-koma-letter-from-bank t)
+   (:from-fax "FROM_FAX" nil org-koma-letter-from-fax t)
+   (:from-url "FROM_FAX" nil org-koma-letter-from-url t)
+   (:invoice "INVOICE" nil "" t)
+   (:my-ref "MY_REF" nil "" t)
+   (:your-ref "YOUR_REF" nil "" t)
    (:lco "LCO" nil org-koma-letter-class-option-file)
    (:opening "OPENING" nil org-koma-letter-opening)
    (:phone-number "PHONE_NUMBER" nil org-koma-letter-phone-number)
-   (:signature "SIGNATURE" nil nil newline)
-   (:to-address "TO_ADDRESS" nil nil newline))
+   (:signature "SIGNATURE" nil user-full-name newline)
+   (:to-address "TO_ADDRESS" nil nil newline)
+   )
   :translate-alist ((export-block . org-koma-letter-export-block)
                     (export-snippet . org-koma-letter-export-snippet)
                     (keyword . org-koma-letter-keyword)
                     (template . org-koma-letter-template))
   :menu-entry
   (?k "Export with KOMA Scrlttr2"
-      ((?K "As LaTeX buffer" org-koma-letter-export-as-latex)
-       (?k "As LaTeX file" org-koma-letter-export-to-latex)
+      ((?L "As LaTeX buffer" org-koma-letter-export-as-latex)
+       (?l "As LaTeX file" org-koma-letter-export-to-latex)
        (?p "As PDF file" org-koma-letter-export-to-pdf)
-       (?O "As PDF file and open"
+       (?o "As PDF file and open"
            (lambda (a s v b)
              (if a (org-koma-letter-export-to-pdf t s v b)
 	       (org-open-file (org-koma-letter-export-to-pdf nil s v b))))))))
 
-\f
+
 ;;; Transcode Functions
 
 ;;;; Export Block
@@ -204,7 +230,15 @@ holding export options."
    (format "\\setkomavar{signature}{%s}\n" (plist-get info :signature))
    (format "\\setkomavar{fromemail}{%s}\n"
            (org-export-data (plist-get info :email) info))
+   (format "\\setkomavar{frombank}{%s}\n"
+           (org-export-data (plist-get info :from-bank) info))
    (format "\\setkomavar{fromphone}{%s}\n" (plist-get info :phone-number))
+   (format "\\setkomavar{frombank}{%s}\n" (plist-get info :from-bank))
+   (format "\\setkomavar{fromfax}{%s}\n" (plist-get info :from-fax))
+   (format "\\setkomavar{fromurl}{%s}\n" (plist-get info :from-url))
+   (format "\\setkomavar{myref}{%s}\n" (plist-get info :my-ref))
+   (format "\\setkomavar{yourref}{%s}\n" (plist-get info :your-ref))
+   (format "\\setkomavar{invoice}{%s}\n" (plist-get info :invoice))
    ;; Date.
    (format "\\date{%s}\n" (org-export-data (plist-get info :date) info))
    ;; Letter Class Option File
@@ -221,11 +255,13 @@ holding export options."
    contents
    ;; Closing.
    (format "\n\\closing{%s}\n\n" (plist-get info :closing))
+   (format "\n%s\n" (plist-get info :after-closing))
    ;; Letter end.
-   "\\end{letter}\n\\end{document}"))
+   "\\end{letter}\n\n"
+   (format "%s" (plist-get info :after-letter))
+   "\\end{document}"))
 
 
-\f
 ;;; Commands
 
 ;;;###autoload

Re: [patch] ox-koma-letter

[Bastien]

Hi Rasmus,

Rasmus <rasmus@gmx.us> writes:

> I have been working on extending the KOMA letter support in Org.  The
> backend is still rough and I would like to more stuff such as
> designing firstfood and firsthead with org elements (e.g. I use a
> tabularx for my firstfood with varioues stuff).

Thanks for the patch -- I'll let Nicolas and Alan comment it
feature-wise.  Just wanted to throw the usual reminder: please
add a changelog to it, so that our commit history is as useful
as possible.  (But maybe you planned this already for the final
version of it, in that case just ignore my comment.)

Thanks!

-- 
 Bastien

Re: [patch] ox-koma-letter

[Rasmus]

Bastien <bzg@altern.org> writes:

>> I have been working on extending the KOMA letter support in Org.  The
>> backend is still rough and I would like to more stuff such as
>> designing firstfood and firsthead with org elements (e.g. I use a
>> tabularx for my firstfood with varioues stuff).
>
> Thanks for the patch -- I'll let Nicolas and Alan comment it
> feature-wise.  Just wanted to throw the usual reminder: please
> add a changelog to it, so that our commit history is as useful
> as possible.  (But maybe you planned this already for the final
> version of it, in that case just ignore my comment.)

Yeah, I followed the "Sending quick fixes for testing purpose" on the
Worg Contribute page.  If I do stuff in a "wrong way"ᵀᴹ it's better to
know about it early. . .

–Rasmus

-- 
And let me remind you also that moderation in the pursuit of justice
is no virtue

Re: [patch] ox-koma-letter

[Michael Strey]

Hi Rasmus,

Thank you for sharing this patch.  I have changed ox-koma-letter.el as
well to fit my needs but didn't publish my changes.

On Mon, Feb 25, 2013 at 09:25:58PM +0100, Rasmus wrote:

[...]

> I have been working on extending the KOMA letter support in Org.  The
> backend is still rough and I would like to more stuff such as
> designing firstfood and firsthead with org elements (e.g. I use a
> tabularx for my firstfood with varioues stuff).
> 
> I have changed the following objects:
[...]
>   3. Added from-bank, invoice and other keywords like that.  Still
>      many to go, but some of them would probably need some thought.
>      For instance firstfoot should work differently depending on
>      whether it is given a NAMEd table or a string.  Any though? 
[...]

IMO your approach goes into a questionable direction here.  Following it
we will end up defining the complete letterhead and letter layout by
setting org-mode variables.  Wouldn't it be better to use Markus Kohm's
concept of letter class options to set all the static stuff?

If I write a letter, I would like to say "this is a business letter from
Michael Strey", give the address the date and maybe some references and start
writing.  I do not want to give in my phone number, my e-mail address or my
backaddress.  I don't even want to see them in the org-mode document.
Therefore I have two letter class options, one for my private letters and
one for my business letters that contain the complete letter head and
foot, phone number, backaddress, e-mail address and so on.

Following this concept ox-koma-letter.el should support LCO and the
following variables and nothing else:

- customer
- date
- invoice
- myref
- specialmail
- subject
- title
- yourmail
- yourref
- address
- opening
- closing
- cc
- encl
- ps
- language


>   2. Added AFTER_CLOSING and AFTER_LETTER keywords for arbitrary code
>      after \closing{.} and \end{letter}, respectively.
>      a. A weird bug I don't understand is why I cannot have
>         #+AFTER_CLOSING{\ps{ps:}}
>      b. Would it be better to have a dedicated, say, PS and ENCL rather
>         than the generic AFTER_CLOSING?

I would opt for dedicated variables.

Regards,
-- 
Michael Strey 
www.strey.biz

Re: [patch] ox-koma-letter

[Rasmus]

>> I have been working on extending the KOMA letter support in Org.  The
>> backend is still rough and I would like to more stuff such as
>> designing firstfood and firsthead with org elements (e.g. I use a
>> tabularx for my firstfood with varioues stuff).
>> 
>> I have changed the following objects:
> [...]
>>   3. Added from-bank, invoice and other keywords like that.  Still
>>      many to go, but some of them would probably need some thought.
>>      For instance firstfoot should work differently depending on
>>      whether it is given a NAMEd table or a string.  Any though? 
> [...]
>
> IMO your approach goes into a questionable direction here.  Following it
> we will end up defining the complete letterhead and letter layout by
> setting org-mode variables.  Wouldn't it be better to use Markus Kohm's
> concept of letter class options to set all the static stuff?

Potentially.  What do you mean by "letter class options"?  Are you
referring to customized LCO files or do you refer to e.g. customized
org-latex-classes?  

One reason for adopting such variables might be that it would, in a
very long run, allow for export into other formats that scrlttr2.

Even when using a dedicated LCO files and or org-latex-classes it
might be appropriate to overwrite variables.  

In any case I don't have a strong opinion on this issue and your
approach also makes sense.


>>   2. Added AFTER_CLOSING and AFTER_LETTER keywords for arbitrary code
>>      after \closing{.} and \end{letter}, respectively.
>>      [...]
>>      b. Would it be better to have a dedicated, say, PS and ENCL rather
>>         than the generic AFTER_CLOSING?
> I would opt for dedicated variables.

Fine by be..  At the very least these should come in the order that
they are specified in the document, I guess.  E.g. I should be able to
place ENCL before PS in the output, if I so desire.

For arbitrary code I find AFTER_CLOSING and AFTER_LETTER nice.
E.g. for pdfpages inclusions.

-- 
May contains speling mistake

Re: [patch] ox-koma-letter

[Michael Strey]

On Tue, Feb 26, 2013 at 10:14:28PM +0100, Rasmus wrote:

[...]

> > Wouldn't it be better to use Markus Kohm's concept of letter class
> > options to set all the static stuff?
> 
> Potentially.  What do you mean by "letter class options"?  Are you
> referring to customized LCO files or do you refer to e.g. customized
> org-latex-classes?  

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.


[...]

> Even when using a dedicated LCO files and or org-latex-classes it
> might be appropriate to overwrite variables.  

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'.


> In any case I don't have a strong opinion on this issue and your
> approach also makes sense.

Maybe we should write a user guide *before* further implementation steps.


> >>   2. Added AFTER_CLOSING and AFTER_LETTER keywords for arbitrary code
> >>      after \closing{.} and \end{letter}, respectively.
> >>      [...]
> >>      b. Would it be better to have a dedicated, say, PS and ENCL rather
> >>         than the generic AFTER_CLOSING?
> > I would opt for dedicated variables.
> 
> Fine by be..  At the very least these should come in the order that
> they are specified in the document, I guess.  E.g. I should be able to
> place ENCL before PS in the output, if I so desire.

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.

> For arbitrary code I find AFTER_CLOSING and AFTER_LETTER nice.
> E.g. for pdfpages inclusions.

Agreed.

Best regards
-- 
Michael Strey 
www.strey.biz

Re: [patch] ox-koma-letter

[Rasmus]

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!

Re: [patch] ox-koma-letter

[Sebastien Vauban]

Hi,

Rasmus wrote:
>> 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.

That could be "isodoc" for which I have a bit of experience with. I'd enjoy to
try and plug it in the current "org-letter" implementation.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [patch] ox-koma-letter

[Rasmus]

"Sebastien Vauban"
<wxhgmqzgwmuf@spammotel.com> writes:

> Hi,
>
> Rasmus wrote:
>>> 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.
>
> That could be "isodoc" for which I have a bit of experience
> with. I'd enjoy to try and plug it in the current "org-letter"
> implementation.

True.  And it even produces beautiful documents, as far as I remember.
There's even the standard LaTeX letter class.

Say we define a variable ORG_LETTER_X.  Then we'd need a table of
corresponding values in export type Y.  Probably this would be easiest
to do in terms of the export function.

–Rasmus

-- 
Don't panic!!!

Re: [patch] ox-koma-letter

[Michael Strey]

Rasmus,

On Wed, Feb 27, 2013 at 01:13:25PM +0100, Rasmus wrote:

[...]

> 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.

After this remark I checked my changes and compared them with the
default code and behaviour of ox-koma-letter with the result that I
reverted all of my deletions.  The mentioned feature provides just the right
hierarchy for my use case.

    - LCO overrides everything
    - options in the file override options in customization
    - options in customization override defaults in ox-koma-letter

Nevertheless I agree that the "nil check" solution would allow more
flexibility.

[...]

> > 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.

IMO one *good* solution for writing letters is enough.  scrlttr2 is
perfect for me and covers at least European conventions about how
letters should look like.  I don't know which LaTeX classes people from
other parts of the globe prefer.

At least we should try to make the user interface (the list of
variables) universal enough to cover other classes as well.


> 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?

Good plan.  I will provide you with the last version of my modification
by PM and write a How To.

Best regards
-- 
Michael Strey 
www.strey.biz

Re: [patch] ox-koma-letter

[Alan Schmitt]

Hi,

Sorry for not replying earlier, I've been in a mode where I let my
orgmode mail accumulate.

Rasmus writes:

> I have changed the following objects:
>
>   1. Make keys sane; no reason why open pdf is O rather than o and why
>      k is used in place of l (as in the tex exporter).

Yes, it's nice to be consistent with the other exporters. Keys were
chosen when latex export was not hierarchic, so keys had to be disjoint.

>   2. Added AFTER_CLOSING and AFTER_LETTER keywords for arbitrary code
>      after \closing{.} and \end{letter}, respectively.
>      a. A weird bug I don't understand is why I cannot have
>         #+AFTER_CLOSING{\ps{ps:}}
>      b. Would it be better to have a dedicated, say, PS and ENCL rather
>         than the generic AFTER_CLOSING?

As the order matters, as said in some replies, I prefer the
AFTER_CLOSING approach.

>   3. Added from-bank, invoice and other keywords like that.  Still
>      many to go, but some of them would probably need some thought.
>      For instance firstfoot should work differently depending on
>      whether it is given a NAMEd table or a string.  Any though? 

I rely on an lco for that. To give you an idea of my setup, here it is.

A letter starts like this:

#+BEGIN_SRC org
#+latex_class: my-letter-fr
#+lco: InriaRennesFR
#+title: Lettre de Recommandation pour ...
#+opening: ~
#+closing: ~

blah blah
#+END_SRC

My latex class looks like this:

#+BEGIN_SRC elisp
(add-to-list 'org-latex-classes
             '("my-letter-fr"
               "\\documentclass\[%
  DIV=14,
  fontsize=10pt,
  parskip=half,
  subject=untitled,
  backaddress=true,
  fromalign=right,
  fromemail=true,
  fromphone=false\]\{scrlttr2\}
  \[DEFAULT-PACKAGES]
  \[PACKAGES]
  \[EXTRA]"))
#+END_SRC

(I realize writing this that it is ugly: some should go in the lco
file. I just hacked this until it worked.)

Finally, my lco file

#+BEGIN_SRC latex
\ProvidesFile{InriaRennesFR.lco}

\usepackage[french]{babel}
\usepackage{xltxtra}

\setkomavar{fromname}{Alan Schmitt}
\setkomavar{fromaddress}{Projet ...\\Company}
\setkomavar{place}{blab bla}
\setkomavar{date}{le \today}

\setkomavar{signature}{\includegraphics[width=2.5cm]{AlanSig}\\Alan Schmitt}

\KOMAoptions{fromlogo=true,foldmarks=off,subject=left,addrfield=false}
\setkomavar{fromlogo}{\includegraphics[width=59mm]{somelogo}}
\@addtoplength{firstfootvpos}{-2cm}
\setkomavar{firstfoot}{\includegraphics[width=4cm]{another logo}}
\setkomavar{fromemail}{alan.schmitt@...}

\endinput
#+END_SRC

I found that with this setup I can quickly write a letter. If someday
I need letters with a different setup, I just need to change the lco.

Alan

Re: [patch] ox-koma-letter

[Bastien]

Hi Alan,

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> To give you an idea of my setup, here it is.

This is nice -- would you share it on Worg?

Thanks!

-- 
 Bastien

Re: [patch] ox-koma-letter

[Alan Schmitt]

Bastien writes:

> Hi Alan,
>
> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
>> To give you an idea of my setup, here it is.
>
> This is nice -- would you share it on Worg?

Sure. Should it go there :
http://orgmode.org/worg/exporters/index.html ?

I'll send you my ssh key.

Alan

Re: [patch] ox-koma-letter

[Rasmus]

Michael Strey <mstrey@strey.biz> writes:> Rasmus,


>> 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.
>
> After this remark I checked my changes and compared them with the
> default code and behaviour of ox-koma-letter with the result that I
> reverted all of my deletions.  The mentioned feature provides just the right
> hierarchy for my use case.
>
>     - LCO overrides everything
>     - options in the file override options in customization
>     - options in customization override defaults in ox-koma-letter
>
> Nevertheless I agree that the "nil check" solution would allow more
> flexibility.


Cool, I'll look at it when time permits (which will not be next
week).

>> > 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.
>
> IMO one *good* solution for writing letters is enough.  scrlttr2 is
> perfect for me and covers at least European conventions about how
> letters should look like.  I don't know which LaTeX classes people from
> other parts of the globe prefer.
>
> At least we should try to make the user interface (the list of
> variables) universal enough to cover other classes as well.

I agree on semi-universal arguments and retaining the current
specialization to scrlttr2.

  


-- 
m-mm-mmm-mmmm bacon!

Re: [patch] ox-koma-letter

[Rasmus]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

Michael Strey <mstrey@strey.biz> writes:> Rasmus,


>> 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.
>
> After this remark I checked my changes and compared them with the
> default code and behaviour of ox-koma-letter with the result that I
> reverted all of my deletions.  The mentioned feature provides just the right
> hierarchy for my use case.
>
>     - LCO overrides everything
>     - options in the file override options in customization
>     - options in customization override defaults in ox-koma-letter
>
> Nevertheless I agree that the "nil check" solution would allow more
> flexibility.


Cool, I'll look at it when time permits (which will not be next
week).

>> > 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.
>
> IMO one *good* solution for writing letters is enough.  scrlttr2 is
> perfect for me and covers at least European conventions about how
> letters should look like.  I don't know which LaTeX classes people from
> other parts of the globe prefer.
>
> At least we should try to make the user interface (the list of
> variables) universal enough to cover other classes as well.

I agree on semi-universal arguments and retaining the current
specialization to scrlttr2.

-- 
If you can mix business and politics wonderful things can happen!

Re: [patch] ox-koma-letter

[Rasmus]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:


> As the order matters, as said in some replies, I prefer the
> AFTER_CLOSING approach.

How can one use the a `:' in a AFTER_CLOSEing?


> I rely on an lco for that. To give you an idea of my setup, here it is.
> I found that with this setup I can quickly write a letter. If someday
> I need letters with a different setup, I just need to change the lco.

But it lacks generality and it relies heavily on a LCO file, which I
am not sure it entirely desirable.

–Rasmus 

-- 
. . . It begins of course with The Internet.  A Net of Peers.

Re: [patch] ox-koma-letter

[Bastien]

Hi Alan,

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Bastien writes:
>
>> Hi Alan,
>>
>> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>>
>>> To give you an idea of my setup, here it is.
>>
>> This is nice -- would you share it on Worg?
>
> Sure. Should it go there :
> http://orgmode.org/worg/exporters/index.html ?

Yes, please.  Thanks,

-- 
 Bastien

Re: [patch] ox-koma-letter

[Alan Schmitt]

Rasmus writes:

> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
> > As the order matters, as said in some replies, I prefer the
> > AFTER_CLOSING approach.
>
> How can one use the a `:' in a AFTER_CLOSEing?

Sorry, I don't know. I thought it was the approach you were suggesting.

> > I rely on an lco for that. To give you an idea of my setup, here it is.
> > I found that with this setup I can quickly write a letter. If someday
> > I need letters with a different setup, I just need to change the lco.
>
> But it lacks generality and it relies heavily on a LCO file, which I
> am not sure it entirely desirable.

Yes, it lacks generality. But I find it works great for me. Writing
letters in latex before was a pain, so I was doing it in Pages. I
consider this is an improvement ;-)

Alan

Re: [patch] ox-koma-letter

[Rasmus]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Rasmus writes:
>
>> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>>
>> > As the order matters, as said in some replies, I prefer the
>> > AFTER_CLOSING approach.
>>
>> How can one use the a `:' in a AFTER_CLOSEing?
>
> Sorry, I don't know. I thought it was the approach you were
> suggesting.

Export the following to LaTeX:

#+BEGIN_SRC Org
#+TITLE:test
#+LATEX_HEADER:\newcommand{test}{\textsc{ps}:this is a test}
#+LATEX_HEADER:\newcommand{ttest}{\textsc{ps}\:this is a test}
#+LATEX_HEADER:\newcommand{tttest}{\textsc{ps}\\:this is a test}
#+LATEX_HEADER:\newcommand{ttttest}{\textsc{ps}$\colon$this is a test}

this is a test
#+END_SRC

-- 
El Rey ha muerto. ¡Larga vida al Rey!

Re: [patch] ox-koma-letter

[Alan Schmitt]

Rasmus writes:

> Export the following to LaTeX:
>
> #+BEGIN_SRC Org
> #+TITLE:test
> #+LATEX_HEADER:\newcommand{test}{\textsc{ps}:this is a test}
> #+LATEX_HEADER:\newcommand{ttest}{\textsc{ps}\:this is a test}
> #+LATEX_HEADER:\newcommand{tttest}{\textsc{ps}\\:this is a test}
> #+LATEX_HEADER:\newcommand{ttttest}{\textsc{ps}$\colon$this is a test}
>
> this is a test
> #+END_SRC

I see, and this is quite a serious issue. It also means we cannot put a
':' in any other field, like the opening or closing of the letter. And
multiline "ps" are going to be tricky.

Maybe we could have a way to set the "closing" at the spot where we want
it to happen, then write the ps and encl manually. I don't really know
how to tweak the exporter for this to happen, though.

Alan

Re: [patch] ox-koma-letter

[Nicolas Goaziou]

Hello,

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Rasmus writes:
>
>> Export the following to LaTeX:
>>
>> #+BEGIN_SRC Org
>> #+TITLE:test
>> #+LATEX_HEADER:\newcommand{test}{\textsc{ps}:this is a test}
>> #+LATEX_HEADER:\newcommand{ttest}{\textsc{ps}\:this is a test}
>> #+LATEX_HEADER:\newcommand{tttest}{\textsc{ps}\\:this is a test}
>> #+LATEX_HEADER:\newcommand{ttttest}{\textsc{ps}$\colon$this is a test}
>>
>> this is a test
>> #+END_SRC

I didn't read the thread carefully, but there should be a space after
"#+LATEX_HEADER:".


Regards,

-- 
Nicolas Goaziou

Re: [patch] ox-koma-letter

[Alan Schmitt]

Hi Nicolas,

Nicolas Goaziou writes:

> Hello,
>
> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
>> Rasmus writes:
>>
>>> Export the following to LaTeX:
>>>
>>> #+BEGIN_SRC Org
>>> #+TITLE:test
>>> #+LATEX_HEADER:\newcommand{test}{\textsc{ps}:this is a test}
>>> #+LATEX_HEADER:\newcommand{ttest}{\textsc{ps}\:this is a test}
>>> #+LATEX_HEADER:\newcommand{tttest}{\textsc{ps}\\:this is a test}
>>> #+LATEX_HEADER:\newcommand{ttttest}{\textsc{ps}$\colon$this is a test}
>>>
>>> this is a test
>>> #+END_SRC
>
> I didn't read the thread carefully, but there should be a space after
> "#+LATEX_HEADER:".

Yes, this changes everything, thanks for spotting it.

So I guess the only part of the letter design I'm worried about is
having a 'ps' with several paragraphs. (I guess it's related to the footnote
with multiple paragraphs questions, but I guess the two blank lines
approach is only for footnotes.)

Alan

Re: [patch] ox-koma-letter

[Nicolas Goaziou]

Hello,

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> So I guess the only part of the letter design I'm worried about is
> having a 'ps' with several paragraphs. (I guess it's related to the footnote
> with multiple paragraphs questions, but I guess the two blank lines
> approach is only for footnotes.)

I have trouble understanding the relationship between footnotes and a ps
with several paragraphs. Would you mind explaining what you need wrt to
ps?


Regards,

-- 
Nicolas Goaziou

Re: [patch] ox-koma-letter

[Alan Schmitt]

Nicolas Goaziou writes:

> Hello,
>
> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
>> So I guess the only part of the letter design I'm worried about is
>> having a 'ps' with several paragraphs. (I guess it's related to the footnote
>> with multiple paragraphs questions, but I guess the two blank lines
>> approach is only for footnotes.)
>
> I have trouble understanding the relationship between footnotes and a ps
> with several paragraphs. Would you mind explaining what you need wrt to
> ps?

Sorry, I should have been clearer. We are currently looking at how to
extend ox-koma-letter.el to support additional structure, in particular
how to add "ps" at the end of the letter. One suggestion was to simply
have a:

#+AFTER_CLOSING: text that goes after closing, such as \ps{my ps}

What worries me about this is that we'll probably want something with
paragraphs. Is it possible? If not, could the approach taken with
footnotes be also allowed here?

Thanks,

Alan

Re: [patch] ox-koma-letter

[Rasmus]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> #+AFTER_CLOSING: text that goes after closing, such as \ps{my ps}
>
> What worries me about this is that we'll probably want something with
> paragraphs. Is it possible? If not, could the approach taken with
> footnotes be also allowed here?

With my suggestion you could simply do:

#+AFTER_CLOSING: \ps{PS:
#+AFTER_CLOSING: line 1
#+AFTER_CLOSING:
#+AFTER_CLOSING: line 2}

e.g. write what you want and use C-x r t.

–Rasmus

-- 
A clever person solves a problem. A wise person avoids it

Re: [patch] ox-koma-letter

[Michael Strey]

Hi Alan,

On Mon, Mar 04, 2013 at 08:19:58AM +0100, Alan Schmitt wrote:

[...]

> So I guess the only part of the letter design I'm worried about is
> having a 'ps' with several paragraphs.

The option below makes an opening with two paragraphs.

#+BEGIN_SRC org
#+OPENING: Sehr geehrter Herr Meier,\\liebe Frau Schulze,
#+END_SRC

So where is the problem with PS?

BTW: Do you use PS in printed letters?

Regards,
-- 
Michael Strey 
www.strey.biz

Re: [patch] ox-koma-letter

[Alan Schmitt]

Michael Strey writes:

> Hi Alan,
>
> On Mon, Mar 04, 2013 at 08:19:58AM +0100, Alan Schmitt wrote:
>
> [...]
>
>> So I guess the only part of the letter design I'm worried about is
>> having a 'ps' with several paragraphs.
>
> The option below makes an opening with two paragraphs.
>
> #+BEGIN_SRC org
> #+OPENING: Sehr geehrter Herr Meier,\\liebe Frau Schulze,
> #+END_SRC

Well, technically, it's a new line, not a new paragraph (indentation may
be different). But it does not really matter to me because ...

> BTW: Do you use PS in printed letters?

No. But since the feature has been asked, I guess some do.

Alan

Re: [patch] ox-koma-letter

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
>> #+AFTER_CLOSING: text that goes after closing, such as \ps{my ps}
>>
>> What worries me about this is that we'll probably want something with
>> paragraphs. Is it possible? If not, could the approach taken with
>> footnotes be also allowed here?
>
> With my suggestion you could simply do:
>
> #+AFTER_CLOSING: \ps{PS:
> #+AFTER_CLOSING: line 1
> #+AFTER_CLOSING:
> #+AFTER_CLOSING: line 2}
>
> e.g. write what you want and use C-x r t.

Headlines are also possible, with a :location: property, which could be
set to, e.g. "closing". See also:

  http://orgmode.org/worg/org-tutorials/org-e-groff-documentation.html

for a syntax based on headlines.

Another possibility is to use a special block. E.g.:

  #+begin_closing
  ...
  #+end_closing

The advantage of previous solutions is that it allows contents to be in
Org syntax whereas "AFTER_CLOSING" keywords require it to be in LaTeX
syntax.


Regards,

-- 
Nicolas Goaziou

Re: [patch] ox-koma-letter

[Rasmus]

Michael Strey <mstrey@strey.biz> writes:

> So where is the problem with PS?
>
> BTW: Do you use PS in printed letters?

Yes.  Recently: "PS: If you need to contact me via snail mail in
country X do send it to this C/O-address "

–Rasmus

-- 
Powered by magic pixies!

Re: [patch] ox-koma-letter

[Alan Schmitt]

Hello,

Nicolas Goaziou writes:

> Headlines are also possible, with a :location: property, which could be
> set to, e.g. "closing". See also:
>
>   http://orgmode.org/worg/org-tutorials/org-e-groff-documentation.html
>
> for a syntax based on headlines.
>
> Another possibility is to use a special block. E.g.:
>
>   #+begin_closing
>   ...
>   #+end_closing
>
> The advantage of previous solutions is that it allows contents to be in
> Org syntax whereas "AFTER_CLOSING" keywords require it to be in LaTeX
> syntax.

These two approaches look great. Do you have a pointer to some could I
should look at to try to integrate them in ox-koma?

Thanks,

Alan

Re: [patch] ox-koma-letter

[Nicolas Goaziou]

Hello,

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Nicolas Goaziou writes:
>
>> Headlines are also possible, with a :location: property, which could be
>> set to, e.g. "closing". See also:
>>
>>   http://orgmode.org/worg/org-tutorials/org-e-groff-documentation.html
>>
>> for a syntax based on headlines.
>>
>> Another possibility is to use a special block. E.g.:
>>
>>   #+begin_closing
>>   ...
>>   #+end_closing
>>
>> The advantage of previous solutions is that it allows contents to be in
>> Org syntax whereas "AFTER_CLOSING" keywords require it to be in LaTeX
>> syntax.
>
> These two approaches look great. Do you have a pointer to some could I
> should look at to try to integrate them in ox-koma?

The principle is the same in both cases. You explicitly ignore the
construct (i.e. return nil) in the transcoding function normally
handling the same type of element. E.g.:

#+begin_src emacs-lisp
(defun org-koma-letter-headline (headline contents info)
  (unless (equal (org-element-property :LOCATION headline) "closing")
    (org-export-with-backend 'latex headline contents info)))
#+end_src

Then, when at the appropriate environment (i.e. template), you
explicitly search for these constructs with `org-element-map' and insert
them here:

#+begin_src emacs-lisp
(defun org-koma-letter-template (contents info)
  (concat
   ...
   ;; Letter body.
   contents
   ;; Closing.
   (format "\n\\closing{%s}\n\n" (plist-get info :closing))
   ;; Add contents of all headlines with "closing" location.
   (mapconcat
    'identity
    (delq nil
          (org-element-map (plist-get info :parse-buffer) 'headline
            (lambda (hl)
              (and (equal (org-element-property :LOCATION hl) "closing")
                   ;; Ignore headline's title.  Focus on contents.
                   (org-export-data (org-element-contents hl) info)))
            info)) "\n")
   ;; Letter end.
   "\\end{letter}\n\\end{document}"))
#+end_src

This is untested, but should get you started.


Regards,

-- 
Nicolas Goaziou

Re: [patch] ox-koma-letter

[Michael Strey]

Hello,

On Mon, Mar 04, 2013 at 09:38:38PM +0100, Nicolas Goaziou wrote:

[...]

> Headlines are also possible, with a :location: property, which could be
> set to, e.g. "closing". See also:
> 
>   http://orgmode.org/worg/org-tutorials/org-e-groff-documentation.html
> 
> for a syntax based on headlines.
 
Here is a draft proposal for a user interface using Nicola's suggestion:

#+BEGIN_SRC org
#+LATEX_CLASS: letter
#+LCO: strey_consult, DINmtext, sections
#+LANGUAGE: en
#+AUTHOR: Michael Strey
#+EMAIL: mstrey@strey.biz
#+DATE: \today
#+TITLE: KomaScript Allows Title and Subject
#+SUBJECT: User interface of org-koma-letter.el
#+SPECIALMAIL: by registered mail
#+TO_ADDRESS: Name\\Street\\Postcode City
#+YOURREF: LT/21/20
#+YOURMAIL: 20.09.2012
#+MYREF: St/foo/bar
#+CUSTOMER: customer name
#+INVOICE: invoice no.
#+OPENING: Dear Org-Mode user,\\dear developers,
#+CLOSING: Regards,
#+AFTER_LETTER: here is code to go after \end{letter}, e.g. for pdfpages inclusion

* About this document                                                   :BODY:
This is an example of a letter that contains all options allowed in
Koma-Script letters.  It shall illustrate the proposed user interface
of ox-koma-letter.el for further discussion.

I used properties for all information having a fixed place in the
letter layout and headlines with tags for those parts of the content of
of the letter that have to be typeset in a distinct order.

* Sectioning in Letters                                                 :BODY:
With the letter class option =sections.lco= KomaScript supports
sectioning in the body of a letter.  Advocates like this feature.

* Enclosures                                                            :ENCL:
a first attachment\\a second one

* Copies go to                                                            :CC:
Worg\\Org-Mode mailing list

* PS                                                                      :PS:
PS: Usually a postsriptum is a short trailer but for those who like
to write more, it should allow multiple paragraphs.

Here is one.
#+END_SRC

Regards,
-- 
Michael Strey 
www.strey.biz

Re: [patch] ox-koma-letter

[Rasmus]

Michael Strey <mstrey@strey.biz> writes:

> Here is a draft proposal for a user interface using Nicola's
> suggestion:

Looks nice.  What happens to headlines without a tag?  Would they be
read as part of the body or would untagged headliens just be ignored?

–Rasmus

-- 
This is the kind of tedious nonsense up with which I will not put

Re: [patch] ox-koma-letter

[Michael Strey]

On Tue, Mar 05, 2013 at 01:23:40PM +0100, Rasmus wrote:

[...]

> What happens to headlines without a tag?  Would they be
> read as part of the body or would untagged headliens just be ignored?

Untagged sections shall be treated as body.

Updated proposal:

#+BEGIN_SRC org
#+LATEX_CLASS: letter
#+LCO: strey_consult, DINmtext, sections
#+LANGUAGE: en
#+AUTHOR: Michael Strey
#+EMAIL: mstrey@strey.biz
#+DATE: \today
#+TITLE: KomaScript Allows Title and Subject
#+SUBJECT: User interface of org-koma-letter.el
#+SPECIALMAIL: by registered mail
#+TO_ADDRESS: Name\\Street\\Postcode City
#+YOURREF: LT/21/20
#+YOURMAIL: 20.09.2012
#+MYREF: St/foo/bar
#+CUSTOMER: customer name
#+INVOICE: invoice no.
#+OPENING: Dear Org-Mode user,\\dear developers,
#+CLOSING: Regards,
#+AFTER_LETTER: here is code to go after \end{letter}, e.g. for pdfpages inclusion

* About this document                                                   :BODY:
This is an example of a letter that contains all options allowed in
Koma-Script letters.  It shall illustrate the proposed user interface
of ox-koma-letter.el for further discussion.

I used properties for all information having a fixed place in the
letter layout and headlines with tags for those parts of the content of
of the letter that have to be typeset in a distinct order.

* Sectioning in letters                                                 :BODY:
With the letter class option =sections.lco= KomaScript supports
sectioning in the body of a letter.  Advocates like this feature.

If =sections.lco= was not loaded, headlines shall be ignored.

* Sections without tags
Sections without tags should be read as if they had the tag =:BODY:=.

* Enclosures                                                            :ENCL:
a first attachment\\a second one

* Copies go to                                                            :CC:
Worg\\Org-Mode mailing list

* PS                                                                      :PS:
PS: Usually a postsriptum is a short trailer but for those who like
to write more, it should allow multiple paragraphs.

Here is one.
#+END_SRC

-- 
Michael Strey 
www.strey.biz

Re: [patch] ox-koma-letter

[Alan Schmitt]

Michael Strey writes:

> Here is a draft proposal for a user interface using Nicola's suggestion:

I like this. About the :BODY: tag, do we really need it if it's
optional? Also, do we enfore the order: what if there is a section after
we start on the ENCL or PS tags?

Alan

Re: [patch] ox-koma-letter

[Nicolas Goaziou]

Hello,

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Michael Strey writes:
>
>> Here is a draft proposal for a user interface using Nicola's suggestion:
>
> I like this. About the :BODY: tag, do we really need it if it's
> optional? Also, do we enfore the order: what if there is a section after
> we start on the ENCL or PS tags?

FWIW, there's no need to enforce a specific for headlines if you use the
deferred headline export technique.

Though, a defcustom can specify an order in the letter, assuming it's
not standard. E.g.

  '(body encl cc ps)


Regards,

-- 
Nicolas Goaziou