/// /** 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;