> Hi, in poppler we have a bug about a pdf that includes this font
> that freetype (also fontforge if it matters) complains.
>
> Is it broken beyond recovery or could freetype be patched up to read
> it?
Well, the font has no `hmtx' table, which is essential for a TrueType
font. It misses a `ma
>>I think we could then add `-std=c99' to the gcc compiler options
>> (while retaining `-ansi' and `-pedantic').
>
> -ansi is the same as -std=c90. So -std=c99 would replace -ansi.
Ah, ok. I haven't looked it up closely.
Werner
___
Freetype-dev
On Wed, Sep 16, 2015 at 1:12 PM, Werner LEMBERG wrote:
>I think we could then add
> `-std=c99' to the gcc compiler options (while retaining `-ansi' and
> `-pedantic').
-ansi is the same as -std=c90. So -std=c99 would replace -ansi.
___
Freetype-devel m
Hi, in poppler we have a bug about a pdf that includes this font that freetype
(also fontforge if it matters) complains.
Is it broken beyond recovery or could freetype be patched up to read it?
The file also includes the Bold variant that freetype loads correctly, i can
attach it if it helps.
> Maybe I should consider the possibility to extend FreeType building
> system to support C99-to-C89 convertor.
Perhaps a misunderstanding: I don't intend to suddenly use arbitrary
C99 stuff. Such a converter is certainly not needed.
> Could you tell more about the advantages of C99 for FreeTyp
>> And, I'm afraid some legacy platforms in builds lack C99-savvy
>> compilers. They should be dropped?
>
> ... the presence of a `long long'
This is the only feature we really need to support in this day and age
unless specifically rejected by the user in ftoption.h, not the other
way around.
_
>> And, I'm afraid some legacy platforms in builds lack C99-savvy
>> compilers. They should be dropped?
>
> Probably yes. C99 is 15 years old...
Umm. Yet I've not checked how many platforms in
builds directory could move to C99 sources, so
at present it's difficult for me to comment.
Maybe I sh
> APIs would be kept to use C89-compatible types, but C99-only types
> are used in internal part?
Yes. No API changes.
> Some people may want to see the types like int32_t, int16_t...
For the API you mean? Certainly, but this would be FreeType 3...
> And, I'm afraid some legacy platforms in
Dear Werner,
APIs would be kept to use C89-compatible types,
but C99-only types are used in internal part?
Some people may want to see the types like
int32_t, int16_t...
And, I'm afraid some legacy platforms in builds
lack C99-savvy compilers. They should be dropped?
Regards,
mpsuzuki
Werner
Folks,
I wonder whether it makes sense to start using C99 features in
FreeType (or rather a subset of C99 that is compatible with C++).
Are there still *important* compilers that are stuck with C89?
Werner
___
Freetype-devel mailing list
Freetyp
10 matches
Mail list logo