///
/**
A Font's "Differences" field describes any differences from the encoding (i.e.,
the mappping from character codes to glyph names) specified by BaseEncoding or,
if BaseEncoding is absent, from the implicit base encoding.
(See PDF32000_2008.pdf:9.6.6.1, Table 114)
This function takes that heterogenous array and returns a glyphmap, i.e., an array
mapping character codes to the glyphnames that differ from the base / inferred encoding.
*/
export declare function expandDifferences(differences: Array): string[];
/**
encoding.Mapping primarily resolves arrays of bytes (often, character codes)
to native Javascript (unicode) strings.
*/
export interface Encoding {
/**
Returns a native (unicode) Javascript string representing the given character
codes. These character codes may have nothing to do with Latin-1, directly,
but can be mapped to unicode via the Font dictionary's Encoding or ToUnicode
fields, and can be assigned widths via the Font dictionary's Widths or
BaseFont fields.
*/
mapping: string[];
characterByteLength: number;
}
/**
Normalization:
1. Combining diacritics combine with the character that precedes them.
A high-order character with diacritic (like "LATIN SMALL LETTER C WITH CARON")
is decomposed into a pair [lowercase c, combining caron]. This is what we deal
with below, by decomposing lone diacritics into [space, combining diacritic]
pairs, removing the space, and recomposing, so that the diacritic combines
with the previous character, as the PDF writer intended.
E.g., Preot¸iuc (from P14-6001.pdf), where the U+00B8 "CEDILLA" combines with
the character preceding it.
Actually, apparently that's an oddity. There's a huge (positive) TJ spacing
argument in between the two arguments: (eot) 333 (¸iuc)
2. We also need to deal with modifier diacritics, which precede the character
they modify. For example, Hajiˇc (from P14-5021.pdf), where the intended č
is designated by a (U+02C7 "CARON", U+0063 "LATIN SMALL LETTER C") pair.
("CARON" is a Modifier_Letter)
Actually, I'm not sure how to tell these apart. "¸", which joins with the
preceding character, has a decomposition specified, as (SPACE, COMBINING CEDILLA),
but is otherwise a modifier character as usual.
So, it's ambiguous?
*/
export declare function normalize(raw: string): string;
/**
Use the glyphlist to convert an ASCII glyphname to the appropriate unicode
string, or via the special "uni" specification format.
Returns undefined when the glyphname is '.notdef' or cannot be found in the
glyphlist.
*/
export declare function decodeGlyphname(glyphname: string): string;
/**
Bytes that represent characters that shall be encoded using either
PDFDocEncoding or UTF-16BE with a leading byte-order marker. (PDF32000_2008.pdf:7.9.1)
You can also do some funny stuff with U+001B, which acts as an escape, for
signaling language codes. (PDF32000_2008.pdf:7.9.2.2)
*/
export declare function decodeBuffer(buffer: Buffer): string;