Re: [Freetype] Ambiguously Undefined Glyphs [was: Mozilla needs someinfo on Xft]

[Antoine Leca]

Brian Stell wrote:
> 
> David,

I believe David (and his family) would be pleased if we wait until
he comes back "officially" from his holydays, but never minds...

 
> Any plans to make the LOCA table available?

What is the point to make 'loca' available? I understand this means
you will be able to know if some glyphId is "empty" (i.e. if its
location is the same as the location of the following one), but it may
also happens that it may be "blank", that is a "real" glyph, with a
bounding box and perhaps instructions, but... 0 countours... (and yes,
this makes sense, for example if you want to have instructions that
act upon the advance). Which then needs to investigate 'glyf'!
(a whole lot merrier problem, IMHO)
Or worse, that it may be a composite, which parts are themselves empty
or blank. And it recurses, to become real fun (while I doubt an example
with two-levels "blank" is ever possible outside the lab where
TrueType library are debugged!)

I believe we are (well, I am) quite away from reality. Coming back with
real facts, I notice you gave us yesterday a listing with a lot of fonts
having the problem you describe (and that I failed to catch entirely).
Beside the very Japanese font you commented on, I noticed that most fonts
were lacking a very small number of glyphs. I believe it might help if you
can enhance a bit your test program, and record which are the characters
that according to your test program ought to be glyphed and are not in
the fonts. I am quite sure there are very basic explanations for a number
of them, explanations which do not need anything at 'loca' level to be
handled correctly. Then, we will have a much lower number of exceptions
to handle, and then we might examine the problem from a more practical
point of view (I do not know what have been discussed in the other thread
in the XFree86 forum, but I hear Juliusz vehemently oppose your proposal
because he does not believe this fits the needs, or as he says, ``is
clearly bogus'').


As a side point, I believe what you are proposing (i.e., sorting glyphs
in or out based on properties derived from the character codes) does not
belong to the Freetype library, but to the layout one (that is intended
to be a layer above). But I might easily be wrong.


> David Turner wrote:
> >
> > > It is difficult to say without seeing a dump of the relevant parts of
> > > the fonts, but I'll take a guess.  Assuming that the AUGs' cmap
> > > entries point at valid loca entries, and that the loca entries point
> > > at valid glyph data (you have checked that, haven't you?), I'd be
> > > tempted to believe that they're trying to optimise the size of a type
> > > 4 cmap by having non-zero cmap entries that are aliased to the
> > > undefined glyph through the loca table.
> > >
> > I suspect they've simply been lazy. Most probably, the glyphs were
> > taken out of the original font by simply changing the content of
> > the "loca" and "glyf" table in the most simple way. You can do
> > that with a rather simple C program, or even a Perl script..

That has been my impression too, but Juliusz's explanation in tempting too
(I did not remember just now if it makes more sense for type 2 or type 4
cmap's, though), because IIRC it avoids a lookup, and moreover a lookup
into a rather large table, something that is quite hungry in term of
memory;
and since these fonts, at least the Japanese one, had been developped in
years
where memory was a problem...


Antoine