freetype-devel
[Top][All Lists]
Advanced

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

[ft-devel] the fontval enum patch


From: Hin-Tak Leung
Subject: [ft-devel] the fontval enum patch
Date: Wed, 20 Sep 2017 11:36:48 +0000 (UTC)

Hi Werner,

Here is the 92 enum's currently documented, massaged to fit into freetype's 
FT_Err_* , as FT_Err_FONTVAL_*

As FreeType only have 95 before that, this doubts your original list to 187.

Here is a run through:

- 76 of them were documented in FontVal 1.0, 2 AFAIK unused, 4 are emitted by
the C# side of things so in reality irrelevant:

- - A_ExceptionUnhandled: generic "shit happens". Currently also covers 
FreeType existing
with an error code, but I think I'll split off and create a 93th to distinguish 
between Freetype errors
and non-Freetype errors.

- - E_rasterization: when font does not pass preliminary check and does not 
proceed
to be analysed hinting-instructions wise; like missing other tables, etc.

-- P_rasterization: this isn't an error but the absence of everything else.

-- I_rasterization: CFF font, not going through freetype.


- "W_Need_Newer_FreeType" was the 77th added two years ago, as a place-holder
for eventually things being merged into freetype and doing version checks. 
Currently unused.

- the 15 *_FT_* ones were added between FontVal 2.0 and 2.1. I know we don't 
agree on 
W_FT_VALUE_OUT_OF_RANGE_SLOOP_ZERO . I'll think about it some more;
the actual cases affected are in fact small.

- I_FT_Error_Supplymentary_Info is a generic "more information" delaying and 
anticipating
a "A_ExceptionUnhandled" .

- I'll likely add a 93th to split off generic 'misc shit happens' from 
'freetype shit happens'.

====

Although I did put a place holder for freetype version check two years ago, and 
intended future code
to be merged/mergeable at some point, I am increasingly not convinced that it 
is a good idea for the clutter
it would create. I don't think you would like it either - doubling the number 
of error codes
for one application's use.

But anyway, this is to standardise the interface, to prevent time being wasted 
by/on people forking
the code in an incompatible way in the future.

If you want to re-arrange/re-number them, etc, I am okay with it, as long as 
the last part
e.g. "I_FT_Error_Supplymentary_Info" of the string-form stays the same. (or 
I'll need to change
the c# side to cope).


P.S. curiously the incompatible fork uses 72 enums, but at least one from the 
C# side.
So it only has 71 of the correct enums. Sigh.


 


 

Attachment: enum.patch
Description: Text Data


reply via email to

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