freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] updated patch for 2.6.4 Re: proposed patch for diagnostic


From: Werner LEMBERG
Subject: Re: [ft-devel] updated patch for 2.6.4 Re: proposed patch for diagnostics
Date: Wed, 06 Jul 2016 11:46:22 +0200 (CEST)

> I'd likely just use your patch instead, when I do the win32/64 and
> mac os x binaries in the next couple of days.

This is just a suggestion, so please massage it as needed!

> I thought about the enum vs string issue (FT_DIAG_XXX) a bit, as I
> mentioned at the beginning - the problem I am facing is that it is 6
> out of 77 out of about 800 of the master list.  The master enum list
> will change when new opentype-table tests are added, so the raster
> test subset of enum will change.  If I have it as a enum on the
> freetype side, that means I have to have another on the C# side to
> do a small enum to large enum look-up, and maintaining two
> additional tables, one on freetype side and one on C# side; and
> forever keeping them in sync...

I have no idea about C# programming, but wouldn't it be possible to
share a file between C and C#, using the preprocessor to provide the
necessary glue to create valid C code?

> I didn't think a FT_DIAGNOSTICS except the first one is necessary,
> as '#define DIAGNOSTICS( message, context ) do { } while ( 0 )'
> should kill off the whole patch to nothing.  I didn't want to add
> #ifdef in the latter parts, for readability, like you just did; but
> if your like a few more #ifdef FT_DIAGNOSTICS I'm okay with that
> (when I add more things, in the future).

IIRC you get compiler warnings if you have code in conditionals that
does nothing, so I think the use of FT_DIAGNOSTICS is justified.

> Sadly I know of no other linux/unix users of this code other than
> meĀ :-(.  So the issue of bundled patched freetype vs upstream/system
> freetype affects exactly one person...

:-)

> Speaking of which, I am a bit surprised that with freetype 2.6.4,
> subpixel hinting is enabled by default - are you sure about that?

Actually yes.  Why not?  Today, you get superior rendering results for
most recent fonts.

> I have opted to revert that in my bundled patched freetype: I want
> subpixel hinting available and dynamically switchable between B/W,
> gray, cleartype testing, via property_set, but kept the older
> default of subpixel hinting off, for now.

You still can switch at runtime between all modes, cf. the demo
programs.


    Werner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]