Such a facility would be a great asset for OOo. I have a couple of suggestions:

As requested by kpalagin, where available, include freely distributable versions
of the fonts in the OOo install package and include the encoding macros in the
standard OOo macro modules.

Commercial font vendors already provide fonts and macros for OOo Calc but these
are not easily used from within Writer, so a mechanism to allow this would
facilitate and increase the value of existing commercial support for OOo.

For mail merges, to use either the free or commercial barcode encoding macros it
is currently necessary to set up a separate spreadsheet as a data source to call
the macros to calculate the barcode encodings. To eliminate this step, consider
extending the functionaility of formulas in text documents (F2 function) to
enable them to call parameterised macros (as can be done in spreadsheet cells)
specifying another document field or data source field reference as arguments.
I.e. to extend the predefined function set to include user-defined functions and
accept field references.

A fast access entry in the Insert - Fields menu for barcodes could perhaps call
a wizard to make this easier as a special case, and could handle both one-off
barcode requirements and mail merge barcode field insertions.

TM->requirements: please have a look, thanks !

*** Issue 68841 has been confirmed by votes. ***

I've an additional proposal to generate a barcode inside OOo:

What about using a graphic to deal with barcodes?
Pro:
- easy resizing, positioning etc.
- no need of additional fonts
- needs only a platform independent barcode-creator, in my mind I think about
vector and bitmap graphics (e.g. svg, png, jpg).
- possibility to use this inside macros via basic, like:
dispatcher.executeDispatch(document, ".uno:InsertBarcode", "", 0, args())

Cons:
?

Kind regards,
Frank

cc fma

IMHO, generating barcode as bitmap would open possibility for abuse via resize 
with end result of barcode becoming unreadable by te scanner.

Yes, correct, but the creation process should define a default AND a custom size
for the barcode to avoid these problem. The default should be good enough to
full fil most use cases.

Scalable graphics are better but can also only resized in one axis and then
unreadable for a scanner of course. My focus is to guarantee platform
independency and this in the build and usage. Just my 2ct's. A little search
gave me a hint of an opensource library written in java
http://sourceforge.net/projects/barbecue/ It offers SVG/EPS as garphic-type to
generate a barcode. Currently beta but an active project :-)

http://barcode4j.sf.net is another alternative.

wrt resizing barcodes:I don't think it matters too much for EAN codes. The ratio
of the width is what counts, not the absolute size. And other barcode types have
strict rules regarding the dimensions that don't allow resizing at all, so that
should not be too much of a problem.
barcode4j is under Apache-License, and I already used it to create PostNet
barcodes without any problem.

I like aspects of using both fonts and graphic generators with respect to how
they might be used in OpenOffice:-

Fonts:

[Sorry, I hit Tab then Return thinking I was in an editor.]

I like aspects of using both fonts and graphic generators:-

Fonts:
  - the size can easily be set precisely as a character attribute in the
    document. Sizing graphics I think is a little harder and less precise.
  - the size is more easily transported, e.g. 12 point is 12 point everywhere.
  - I can include the code as human readable text in any font anywhere in the
    document using the same encoding functions/macros as generate the barcode.
    Converting a document to text format will automatically include a human
    readable version of the barcode.
  - not limited to those encodings built-in to the graphic barcode generator.

Graphics (scalable):
  - I don't need to buy or find barcode fonts.
  - users sometimes find barcodes as fonts hard to grasp.
  - will transport easier to other document formats (e.g. web) without the need
    to include fonts, but size may not be guarranteed.

In my mind, it will be better if OpenOffice support not only EAN13, but some
additional barcode standards, for example ISBN, ISSN, Code 39, Code 128, DPF417,
DataMatrix and postal bar codes for Europe and USA.

I have previously recommended [1] the use of my PostScript-based barcode
generator (BWIPP) [2].

[1] http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=22432
[2] http://www.terryburton.co.uk/barcodewriter/generator/

Apologies. Above link should have been:

http://www.terryburton.co.uk/barcodewriter/

Terry's comment above, and particularly the whole thread at link [1] above I
thought was a very good definition of what we need and the issues that need to
be resolved to support barcode generation within OpenOffice.

As a simple user of barcodes, I wasn't aware of 2D matrix codes and AFAICS these
can't be done using fonts, so for me that only leaves graphic generation. For
me, generating barcodes at the printer is not an option. I need them to be
rendered on screen and carried as graphics within the ODF document so that
conversion to other document formats or the Web carries the rendered barcode,
and particularly so that those ODF documents are not locked to OpenOffice.org.

Rosspjohnson, your comment about 2D barcodes is right in context of the
simplification of the algorithmic realization.