[CCing the list – you should always write to the list for such a
general discussion so that other people can chime in!]
> I stumbled on a file called "ttsubpix.c", which already contains a
> database of some kind. Is this the kind of format that would be
> required for the capabilities database?
It's up to you whether it is a format fitting the task. Another
'database' is file `src/autofit/afblue.dat`, which in turn gets
converted to `afblue.c` and `afblue.h` by the script
`src/tools/afblue.pl`, using the template files `afblue.cin` and
`afblue.hin`, respectively. In other words, solving this issue is
part of the GSoC project.
> When I asked the question earlier about the impact to users, I
> actually meant to ask about *breaking changes*. Will the api change
> in any way?
No. However, not all fonts will be able to benefit from the
improvements since the 'database' needs access to the original input
character codes, which can't always be deduced from the glyph indices
FreeType receives.
* In the simplest case the glyph index is present in a cmap; you can
then immediately use the corresponding input character code (mapped
to Unicode).
* If this doesn't deliver a result, check whether the font in question
has glyph names that are compliant to the Adobe Glyph List
convention; it is then straightforward to find the original
character codes.
* If there are no glyph names it is necessary to track glyph indices
back through OpenType features and lookups: You input a glyph index,
and you get back a list of input character sequences that would
cause the glyph index in question as a result. Of course, not all
results make sense; in particular, many-to-many mappings (for
example, mapping input characters ['f' 'o' 'o'] to glyph indices
[n m]) can be immediately dropped, but one-to-many mappings (for
example, mapping ['Q' 'u'] to a 'Qu' ligature) must probably be
investigated and compared to the data in the database, together with
one-to-one mappings.
I've used HarfBuzz 'sets' to map glyph indices to language feature
tags (see file `afshaper.c`); not sure whether HarfBuzz provides
more functionality that could assist you in getting this reverse
mapping, but it certainly makes sense to include Behdad in further
discussions because handling OpenType features is actually outside
of FreeType's scope.
Werner
> On Sun, Mar 19, 2023 at 2:04 AM Werner LEMBERG <w...@gnu.org> wrote:
>
>>
>> Hello Craig,
>>
>>
>> welcome to FreeType!
>>
>> > The project idea about making a capability database for the
>> > auto-hinter caught my eye. I have a few questions about it though:
>> >
>> > - What will be the impact of a capabilities database from the
>> > perspective of end users? Particularly, consumers of the library
>> > and font authors who want their fonts to look right on all sizes.
>>
>> It would have a huge positive impact – just updating FreeType would
>> immediately improve the rendering of many fonts if 'autohinting' is
>> the predominant setting, or if the font doesn't contain hinting
>> instructions.
>>
>> > - The examples used latin characters, but will this also aim to
>> > improve font rendering on other scripts, like Chinese characters?
>>
>> No. There are completely different methods (like stroke removal or
>> stroke unification) to render CJK glyphs at smaller sizes. Actually,
>> the best way to get legible small CJK stuff is to use hand-crafted
>> bitmaps.
>>
>> > - In addition to reviewing the getting started guides and
>> > auto-hinter documentation, are there any other sources that you
>> > recommend I review to better familiarize myself with the problem
>> > and its possible solutions?
>>
>> Not really. If you have specific question, simply ask :-) Of course,
>> there are also typography forums like https://typedrawers.com, which
>> might help with general questions.
>>
>>
>> Werner
>>
