Hello,
I wrote a blog post<http://davidmburke.com/2011/08/10/mail-merge-in-libreoffice/>awhile
ago about mail merge in LibreOffice. As with most of my posts it is
rather critical, so I apologize for that. It's a very popular post and I
think it highlights there are issues with the official documentation.
In my opinion, based on working with schools and seeing the response to my
blog, the official documentation is difficult to follow for the most common
use cases. I'll start by defining use cases I think of.
- User needs to print labels for envelopes or sticky labels
- User needs to insert variables in a document from a spreadsheet (ods,
xls, etc)
The issues I see
1. Searching Mail
Merge<https://help.libreoffice.org/index.php?search=mail+merge&title=Special%3ASearch>
yields
a good number of articles. These range of various quality. Not one of them
includes a full walk through to go from a odt and ods file to a mail merged
document.
2. Most users (I have only anecdotal evidence) do not know what a
database is. LO docs talks about a lot about database sources. In my
experience a user has a xls or ods file and wants the fields to go into a
document. They are not thinking in terms of data sources and certainly not
"Exchange Databases"
3. Exchange Databases are a critical feature as explained in my blog
post. I see no way of using a xls file as a data source without clicking
Edit, Exchange Databases. However I cannot find this documented anywhere in
LO docs.
4. Possibly more of a bug - but as Juanito points out on my blog, having
an address block that doesn't print blank lines on a label is absurdly
difficult. I think this is a common use case. I suppose however we could
say this is a feature LO is lacking and not a documentation issue.
Juanito's work around is quite creative. However documenting deficiencies
would be useful.
I'd be happy to help contribute to cleaning up things. Let me know what you
think. Carl Taylor commented that he attempted to rewrite docs but I don't
see where this went, if it happened at all.
Best,
David Burke
davidmburke.com