[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ft-devel] FontVal 2.2 plan and the enums
From: |
Hin-Tak Leung |
Subject: |
[ft-devel] FontVal 2.2 plan and the enums |
Date: |
Sat, 16 Sep 2017 13:52:31 +0000 (UTC) |
Hi Werner and others,
I am going to just say it once - I am not happy that somebody tries to create a
incompatable fork of Font Validator''s backend code, breaking it up, while
contributing nothing code wise or resource wise.
The FontVal freetype-backend patch set has never been posted in full, mostly
because it has always been a work-in-progress and was never considered complete
. It was only considered feature-complete with FontVal 2.1.1 (not even 2.1) 3
weeks ago, to do more or less everything the legacy backend does, plus more.
There is honestly nothing much in it that should be in upstream freetype. If I
think there is, I'd extract that part, and send it upstream, and shrinking what
it is, a gigantic 3000-line patch. A few patches in the past happen that way.
Unfortunately when somebody tries to break your 2-year work up and making an
incompatable fork, the only reaction one can have is (1) stop feeding it - i.e.
no more posting of the more interesting parts, (2) standardize the interfaces
so that nobody has any incentives to create an incompatible fork in the future.
For (2), that means unfortunately, work needs to be done to make it possible to
run FontVal against the desktop's copy of (modified-)FreeType. I don't run it
that way, and I don't considered it a good idea to run it that way. There is
also no need to run it that way with FontVal 2.1.1 - I have added this
paragraph to the FAQ:
https://github.com/HinTak/Font-Validator/wiki/FAQ#when-will-the-full-patch-set-be-posted
<quote>
Note: Apple announced they will stop LD*/DYLD* overrides to stop people hacking
their system binaries with custom library overrides. The Mono people came up
with a new and clever way of bundling host-native libraries to cope, without
depending on these variables. The FontVal 2.1.1 binaries (Mac OS X and Unbuntu)
were built in the new way, and fully operational without a visible custom
freetype hanging around. It was a very rough ride to try out the new
technology, and Christian Demmer offered his help to try my Mac OS X binaries
seven times before I did it correctly. He deserves honorary mention in the
2.1.1 release notes. I am offended that people won't even give it a try and
insist that they need to build freetype themselves on Linux. They do not.
</quote>
i.e. It is more or less a waste of time, just because somebody wants to break
up your work.
I think I have got a handle on the global variable situation - It is simply
that thinking doing it for more than a year, somebody else tries to do it
quickly in front of you. It gets quite obvious which parts are good and which
parts are bad/disastrous, and also what else is missing. There is not much else
there.
So we have got the enum situation left. The current FontVal code has about 92
enums of the form _rast_[WPIEA]_{stuff}. I am thinking of getting an entire
block of 256 - e.g. something like this:
<quote>
FT_ERRORDEF_( _rast_[WPIEA]_XXXXXXXX, 0x1XX,
"Description" )
</quote>
Between the backend and the front end, I am thinking of sending both the value
and the name, and let the client chooses which one to process. The
communication macro will be changed to this form:
<quote>
#define DIAGNOSTICS( message, context ) ...
@@ -158,7 +159,7 @@
do \
{ \
if ( diagnostics ) \
- (*diagnostics)( message, \
+ (*diagnostics)( message, #message, \
opcode_name[(context)->opcode] + 2, \
( (context)->callTop \
? (context)->callStack->Caller_Range \
</quote>
and calling with the bare unquoted enum, and let the macro quotes it.
i.e.
<quote>
diff --git a/src/truetype/ttinterp.c b/src/truetype/ttinterp.c
index e6680c5fb..e5ed500e8 100644
--- a/src/truetype/ttinterp.c
+++ b/src/truetype/ttinterp.c
@@ -1826,7 +1826,7 @@
if ( FT_ABS( F_dot_P ) < 0x400L )
{
if ( ( moved_x == 0 || moved_y == 0 ) && distance != 0 )
- DIAGNOSTICS( "_rast_W_PF_VECTORS_AT_OR_NEAR_PERP", exc );
+ DIAGNOSTICS( _rast_W_PF_VECTORS_AT_OR_NEAR_PERP, exc );
}
}
</quote>
This also has the advantage that the compiler checks for spelling mistakes in
the enums, compared to it being a string - yes, this has been a local/temporary
modification for a while, for exactly this reason: check for my own typos.
So I think mostly this message is about asking for a block of 256 enums in
FT_ERRORDEF_( _rast_[WPIEA]_XXXXXXXX, 0x1XX, "Description") , or something
similiar.
And as for FontVal 2.2 - I am thinking of making the switch (the global
variable and the enums) in 18 month's time, and Font Val 2.2 will be tested
against desktop (modified-)freetype before release, against the entire font set
of fedora 29. I don't want to spend time in that direction, I think it is a
waste of time, but it needs to be done to stop people trying to break it up.
Hin-Tak
- [ft-devel] FontVal 2.2 plan and the enums,
Hin-Tak Leung <=