freetype-devel
[Top][All Lists]
Advanced

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]