[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Regarding FT_CMap_ClassRec
From: |
Werner LEMBERG |
Subject: |
Re: [ft-devel] Regarding FT_CMap_ClassRec |
Date: |
Wed, 23 May 2018 18:34:24 +0200 (CEST) |
> Actually I was studying the implementation of `gf_cmap_class`.
> While understanding certain things I got confused with the working
> of CMap_Class of each driver.
>
> Now after some research, I understand certain points they are:
>
> 1. Each font file may have multiple charmaps for different
> characters.
This is a confusing formulation. I would rather say that a font face
(to use FreeType speak) can have multiple charmaps, where a charmap
maps from input character codes to glyph indices.
> 2. The functions in FT_CMap_ClassRec i.e cmap_init, cmap_done, etc.,
> initialize the charmaps of different characters in FT_Face
> according to the font file.
There are two possibilities:
. Charmaps that are part of the font (e.g., OpenType's `cmap'
tables).
. Synthesized charmaps (e.g., Type 1 fonts).
> Now bdf fonts are ASCII encoded,
What do you mean with `ASCII encoded'? BDF fonts themselves are plain
text files containing only ASCII characters, right, but this is
completely irrelevant. For example, I have a constructed a BDF file
for the now defunct CCCII encoding, which was a 21bit encoding (using
three bytes for a character code)!
> then why is their a provision of multiple encodings in its
> implementation?
`encoding' in the BDF driver essentially means `glyph index' (or
`character code') in other drivers. This discrepancy in terminology
is for historical reasons. BDF fonts only support a single (FreeType)
charmap.
> Also, bdf fonts maintain a table for character wise encodings,
> whereas winfonts just maintains a pointer to the first character and
> a counter of number of characters to return character wise charmaps.
Different people wrote different code... In particular, the BDF
driver was contributed.
> Now gf files are ASCII encoded, then what type of implementation
> should it have?
First of all, GF files are *not* ASCII encoded. Please be careful in
using the correct terminology! ASCII is a 7-bit character set and
encoding. GF files, however, support up to 256 glyphs (and please
ignore its extension for 16bit stuff; this was never used in reality).
Normally, the used encoding/character set is given by the
`codingscheme' keyword in the GF file, for example
codingscheme=TeX text
which indicates `OT1' font encoding (as used in LaTeX; say `texdoc
fontenc' to get a description). See into directory
<TEXMF>/fonts/source/public/cm>
of your TeX distribution and do
grep font_coding_scheme *.mf
to see the other possible values for Knuth's CM fonts. Jörg Knappen's
`EC' fonts are using the LaTeX `T1' encoding, for example
codingscheme=Extended TeX Font Encoding - Latin
etc., etc.
It might be useful if the GF driver provides mappings for the most
common LaTeX encodings so that we can synthesize Unicode encodings – I
think it is sufficient if you check the METAFONT files from TeXLive.
Werner