File Content Extraction 26.1
Filter SDK .NET Programming Guide

# Field Standardization

Common metadata fields such as "Title", "Author", and "Subject" exist in many different file formats, but can be stored in different ways. For instance, one raster image format may store the image width as a key-value pair with key `Width`. Another format may store the image width in bytes 16-19 of the file. You might want to access the width of all raster images in the same way, regardless of the source format. Field standardization provides standard keys for some common metadata so that you can use the same code to handle many different file formats.

Many metadata field values are scalar values, and can be understood without reference to units – for example, page count. However, some values can be expressed in multiple units, and different file formats might store the same type of information in different units – for example, image width could be stored in pixels, twips, or another graphic unit. When a field is standardized, File Content Extraction converts its value to the documented units, so all standardized fields that have the same key have a value that uses the same units.

The exception to this is string values - File Content Extraction outputs a string as it appears in the document. For example, depending on how the author field is stored in the document, it might be output as “John Smith”, “Smith, John”, “J. Smith”, or another form.

## Duplicate Fields

The same logical piece of metadata can appear multiple times in the metadata that File Content Extraction outputs for a document:

- The same information might occur multiple times in the source document. For example, when a raster image stores its width in both EXIF and XMP metadata, File Content Extraction can output an element for each.

- File Content Extraction can output both a standardized element, and a non-standard element with its original key and value. The API provides a way to distinguish between standard and non-standard elements, and provides a way to identify non-standard elements that have a standardized alternative.

- File Content Extraction can output multiple non-standard elements for the same piece of metadata, with different keys or value types, to maintain backwards compatibility. Elements that are present to maintain backwards compatibility are identified as "superseded".

The File Content Extraction API therefore provides a way to access common fields, and a way to process native fields that were not standardized, without having to process the same logical piece of metadata more than once.

## Absence of Fields

The absence of a field in the metadata output by File Content Extraction does not imply a value for that field. For instance, if the standardized field `CharacterCount` is not present, that does not imply that the document contains zero characters: instead, it indicates either that the document does not contain a "character count" metadata field, or that File Content Extraction does not support that field for that format.

If a field is not present in the document, File Content Extraction does not attempt to construct that field, even where the value could be calculated from other information. For example, if the word count is missing from a word processing document, File Content Extraction does not attempt to calculate it by counting the number of words in the file.

## Similar Standardized Fields

Some standardized fields have similar meanings. For example, `Author` and `Artist` both represent people who in some way created the content of the document. File Content Extraction does not attempt to interpret or define the meaning of these fields. File Content Extraction standardizes an `author` field as `Author`, and standardizes an `artist` field as `Artist`. File Content Extraction does not attempt to determine if an author is an artist or vice versa.

## Metadata is not Validated

File Content Extraction outputs metadata fields based on metadata stored within the document, but does not attempt to validate the information. For example, File Content Extraction does not:

- check the word count stored in the metadata matches the actual number of words present in the document.
- validate that the MIP Label stored in a document can be used to decrypt the document.
- check that the signature in a signed executable is authentic.
- check that a PDF marked as being PDF/A conformant actually conforms.

Copyright 1997-2025 Open Text
Version 26.1 | Last updated January 2026

Send documentation feedback

Close

Send documentation feedback

To send feedback using your default email client, open an email window.

Otherwise, send your feedback and the information below to MFI-swpdl.idoldocsfeedback@opentext.com.

We appreciate your feedback!

Product: File Content Extraction 26.1

Topic Title: Field Standardization