Re: [Devel] Adding a new function, question about face's allocedmemory

[Antoine Leca]

Hi Tom,

Tom Kacvinsky wrote:
> 
> Hi Antoine,
> 
> (where were you at in Amsterdam?)

To make a long and painful story short, I went, but I was unable to read
my mail the day before, so I did miss the meeting point. And at 12 o'clock,
there were nobody at the station... I turned back at 3 pm, because I were
a bit ill and sick; I neglect to enter a cyberplace to check my mail, which
it later appears to be an error :-(


> > > The idea is for this function to be used with non-CID keyed CFF fonts
> > > and Type 1 fonts (hence, the char code is always in the range 0 -- 255,
> > > which is why I chose FT_Byte for the char_code parameter).
> >
> > Hmmm, this is the kind of "optimizations" I do not find useful.
> >
> > I see the same function as useful for type 4.0 'post' tables in 'sfnt'
> > (TrueType) fonts, where the names of the characters, highly repetitive
> > (like a0101, a0102, a0103, etc.) are encoded as 16-bit quantities;
> > however, there may be as much as 65,536 characters in such a font, so
> > your function won't do the job. :-(
> >
> 
> I guess you did not read that this function is for (pure) non-CID CFF and
> Type 1 fonts, which can only encode 256 glyphs at a time.

I did (and I know the fact), but I miss what is the planned status of your
function. If it is to be specific to T1/non-CID, I then miss how it
integrates in the Freetype 2 framework (but I must confess I did not toy
with Freetype 2).

At the contrary, if this is intended to be exposed at the "normal", visible
side of the library, i.e. the API, then I believe we should _permit_ to
re-use this entry point for similar uses, whatever they may be; and this
means we should never restrict parameter ranges, particularly when it does
not cost anything.


> Unless you were proposing that I write this function to additionally get
> glyph names for a given char code when working with TT fonts.

No, I do not propose that. I only propose that it should be made possible
in the future, if such a need do come.
I defer on David commenting if my position does make sence, or not.


> In which case, I have to take into account cmaps.  Which is what
> I wanted to avoid in the first place...

:-)  Yep, I did caught that very well...


Antoine