freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] proposed patch for diagnostics (Re: implementing detectio


From: Hin-Tak Leung
Subject: Re: [ft-devel] proposed patch for diagnostics (Re: implementing detection of hinting/rasterization errors in fonts)
Date: Mon, 4 Jul 2016 22:00:18 +0000 (UTC)

--------------------------------------------
On Mon, 4/7/16, Behdad Esfahbod <address@hidden> wrote:
 
> The use of a
 global variable is not desirable.  Put it on the FT_Library
 at least.

I sort of thought about that for a bit - it would be a ABI breakage, expanding 
existing structures. The new static variable (just one - the pointer to a 
diagnostic messaging routine) is logically a per-library handle, but within the 
context I am adding it, the byte code interpreter doesn't really have the 
library handle (or a handle to the current glyph, or actually a handle to the 
current size. It only knows about the current stream of byte codes - I only 
found the face handle), so I am changing the diagnostics routine per glyph+size 
on the C# side. I would have loved to put the current glyph index as well as 
the size into the message routine, without caching and post-processing those on 
the C# end, too. If I can get at the glyph index or the current size, I'd only 
need to switch/set at the beginning of accessing the library, instead of per 
size+glyph as I am doing now. This would do for now.

You are welcomed to improve on the patch, and possibly add that to 
FontTools/ttx's work flow, of course. :-). That's the whole point of posting it 
to you and others. The bulk of the FontVal users are Mac OS X, windows (in that 
order), and no known linux user except me. I already bundled freetype for both 
Mac OS X and windows, so there is no urgency - or indeed, incentive - to 
upstream this patch to freetype.

Though the current patch does not affect normal freetype usage and can be 
mostly added as is, I and Werner had some brief discussion some months ago that 
eventually, some changes might need to be semi-permanently maintained outside 
freetype, because fundamentally the objective of a fast quiet rendering engine 
vs loud and detailed (i.e. slow) diagnostics may not co-exist. We have not 
reached the point where we have to go separate direction yet.


reply via email to

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