All topics
36 / 55
Publisherintermediate

Output Formats, Fonts, Barcodes & Localization

Explain how BI Publisher handles multiple output formats, embedded barcodes/special fonts, and multi-language/locale-aware document generation.

One data model and one template can produce very different outputs, and the practical detail is in the edges.

It's like a single master recipe (data model + template) that a good chef can plate as a formal dinner (PDF), pack as takeout containers (Excel export), or convert into freeze-dried rations for a totally different delivery system (EDI feed) — same ingredients, same recipe, radically different final packaging depending on who's receiving it.

Key Concepts

1
The formats.
    PDF        print and archival. The usual default.
    RTF/Word   when the recipient must edit it
    Excel      native XLSX, for data the finance team manipulates
    HTML       viewing in a browser
    eText      fixed-width and delimited, for banks and EDI
    PowerPoint, CSV, XML
2
Fonts are the recurring PDF problem. A PDF displays correctly on the machine that made it and shows boxes elsewhere, because the font was not embedded.
3
    the font must be registered with BI Publisher
    and mapped, so the engine embeds it in the PDF
4
This matters most for scripts outside the default set — Devanagari, Arabic, Chinese — where the fallback font has no glyphs at all.
5
Barcodes need the right font plus an encoding step. A Code 128 barcode is not the digits in a barcode font; the value must be encoded with check characters first, using a supplied encoding function, and then rendered in the font.
6
Skipping the encoding produces a barcode that looks convincing and does not scan, which is discovered at the warehouse rather than in testing.
7
Localisation works at three levels.
    translation   an XLIFF file per language holds the template's
                  static text
    locale        number, date and currency formatting per locale
    a template    per language, where the layout itself differs
8
XLIFF is the mechanism to name. Export the template's translatable strings, have them translated, and upload the file per locale. One template then serves every language, and adding one is a file rather than a new template.
9
Where a separate template is still needed. Right-to-left layouts, and countries whose statutory form prescribes a different structure. Formatting differences are handled by locale; structural ones are not.
10
The practical check. Generate the output in every format the report claims to support, on a machine that is not the developer's, with realistic data. Most defects here — missing glyphs, an unscannable barcode, an Excel export that renders as one column — appear only under exactly those conditions.
11
What the interviewer is probing.1. "What determines which output formats a template supports?" Probing: the detail. Stalls: "Any format." Moves up: the template type — RTF covers most, eText is text only, and Excel templates target spreadsheet output specifically.
12
2. "What is the usual font problem?" Probing: experience. Stalls: "None." Moves up: a font present on the developer machine but not on the server, so PDF output falls back and the layout shifts — fonts must be deployed and mapped.
13
3. "How are barcodes produced?" Probing: the mechanics. Stalls: "An image." Moves up: a barcode font with an encoding function registered in the font mapping, since the raw value usually needs check digits and start/stop characters.
14
4. "What does localisation require beyond translation?" Probing: the thoroughness. Stalls: "Text." Moves up: date, number and currency formats, right-to-left layout where relevant, and fonts carrying the required character set.
Use cases:output-formatslocalizationbarcodes