Re: [ft-devel] Registration of a set of trickyfonts by NEC

[mpsuzuki]

Ah, Bevan's proposal is reasonable...

I selected 3 Type42-required subtables (cvt/fpgm/prep)
which are very difficult to subset without detailed
interpretation of glyf program. So, even if the embedded
fonts are subsetted, usually they are same with original
fonts.

# If they are modified, it means that the embedder should
# have some TrueType instruction interpreter, so I want
# the embedder to care about the hinting.

And, FT2 has builtin checksum calculater. In fact, some
PDF generators don't write the checksum at all (maybe
they don't want spend CPU cycles to recalculate checksums
for subsetted tables like loca, glyf, etc), in such case,
FT2 calculate the checksum by itself.

When I designed so, I was thinking that most TrueType
embedders may calculate the checksum correctly, or copy
the checksum, or leave the checksum as 0x00000000, so,
skipping the checksum recalculation for non-zero value
makes the tricky font checking faster. In fact, now,
the trickyness check by the checksum is executed for most
non-tricky TrueType fonts (it's ironic!)

Anyway, my assumption might be wrong. I should check the
cost of checksum recalculation by some benchmarks...

Regards,
mpsuzuki

On Thu, 28 Apr 2011 11:43:13 +0200 (CEST)
Werner LEMBERG <address@hidden> wrote:

>
>> For some reason I assumed that FreeType would be calculating the
>> checksum. I'm sure there's lots of code that doesn't bother to set
>> the checksums at all.
>
>The problem are subsetted fonts, I believe.
>
>
>   Werner