[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