[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.