Issue 68841 - Please provide native (non-macro) means to use EAN13 barcodes in OO docs
Summary: Please provide native (non-macro) means to use EAN13 barcodes in OO docs
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: current
Hardware: All Windows, all
: P3 Trivial with 22 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2006-08-21 20:48 UTC by kpalagin
Modified: 2013-02-07 22:36 UTC (History)
5 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description kpalagin 2006-08-21 20:48:22 UTC
Please provide native (not based on macro) means to insert EAN13 barcodes in 
OO documents, for example via Insert, Object, Barcode menu.
Macro-based solution works fine with tech savvy userbase, which is not always 
the case, and requires significant training effort.

Required .ttf font, released under GPL license, is available at

Open source bar-code generator

Explanation of how symbols are generated
Comment 1 rosspjohnson 2006-08-24 04:45:34 UTC
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.
Comment 2 thorsten.martens 2006-08-25 06:44:51 UTC
TM->requirements: please have a look, thanks !
Comment 3 nuomo 2007-02-16 09:35:58 UTC
*** Issue 68841 has been confirmed by votes. ***
Comment 4 hans_werner67 2007-06-18 12:56:44 UTC
I've an additional proposal to generate a barcode inside OOo:

What about using a graphic to deal with barcodes?
- 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())


Kind regards,
Comment 5 hans_werner67 2007-06-18 12:57:14 UTC
cc fma
Comment 6 kpalagin 2007-06-18 21:39:02 UTC
IMHO, generating barcode as bitmap would open possibility for abuse via resize 
with end result of barcode becoming unreadable by te scanner.
Comment 7 hans_werner67 2007-06-19 08:50:24 UTC
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 It offers SVG/EPS as garphic-type to
generate a barcode. Currently beta but an active project :-)
Comment 8 lohmaier 2007-06-22 19:12:24 UTC 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.
Comment 9 rosspjohnson 2007-06-23 05:37:13 UTC
I like aspects of using both fonts and graphic generators with respect to how
they might be used in OpenOffice:-

Comment 10 rosspjohnson 2007-06-23 06:03:34 UTC
[Sorry, I hit Tab then Return thinking I was in an editor.]

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

  - 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.
Comment 11 vorchun 2009-03-21 10:26:27 UTC
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.
Comment 12 terryburton 2009-03-21 13:42:36 UTC
I have previously recommended [1] the use of my PostScript-based barcode
generator (BWIPP) [2].


Comment 13 terryburton 2009-03-21 13:47:00 UTC
Apologies. Above link should have been:
Comment 14 rosspjohnson 2009-03-28 00:54:30 UTC
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
Comment 15 vorchun 2009-03-30 06:06:22 UTC
Rosspjohnson, your comment about 2D barcodes is right in context of the
simplification of the algorithmic realization.