Re: [ft-devel] Build freetype2 64bit in windows
Dear 晓明, I've just stumbled across your old e-mail from April the 12th. freetype-2.4.9\src\bdf\bdflib.c(772): warning C4244: “function”: conversion from 'ptrdiff_t' to 'unsigned long', possible loss of data error = (*cb)( buf + start, end - start, lineno, (void*)cb, client_data ); Fixed. freetype-2.4.9\src\base(39): warning C4306: “function”: conversion from ' int ' to ' FT_Pointer ' of greater size if ( svc == FT_SERVICE_UNAVAILABLE ) // this line: FT_SERVICE_UNAVAILABLE is defined to ((FT_Pointer)-2) I think I've fixed this and similar issues by using the `logical not' operator (~) instead of a negative value. Please test the current git. freetype-2.4.9\src\type1\t1load.c(618): warning C4244: “function”: conversion from 'FT_PtrDist' to 'FT_Long', possible loss of data if ( FT_ALLOC( blend-axis_names[n], len + 1 ) ) Fixed. If you still get warnings please send the complete output to the list. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Infinality Release
It seems OK, and it compiles fine.
Erik, please have a look at the attached patch. I've `beautified' the
bytecode opcodes, and I've discovered that most of them appear to be
incorrect, compared to the listings in
http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx
Please check that. Have you actually done binary searches in TTFs to
find signatures? Another possibility is to disassemble the `fpgm'
table with TTX, then doing a textual search (`pcregrep' might help for
multiline searches).
Additionally, ttfautohint's bytecode signature has changed; the new
one is
PUSHB_1,
32,
ADD,
FLOOR,
in function 0.
Given that the new ttfautohint bytecode signature is that short, as
are some other snippets in Greg's whitepaper, I think it is best if
you extend the code so that the function number is also checked to
avoid false hits.
Werner
diff --git a/src/truetype/ttinterp.c b/src/truetype/ttinterp.c
index 505168d..440d385 100644
--- a/src/truetype/ttinterp.c
+++ b/src/truetype/ttinterp.c
@@ -4610,25 +4610,90 @@
FT_ULong n;
TT_DefRecord* rec;
TT_DefRecord* limit;
+
#ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING
FT_Byteopcode_pattern[7][12] = {
- /* inline delta function 1 */
- {0x4B,0x53,0x23,0x4B,0x51,0x5A,0x58,0x38,0x1B,0x21,0x21,0x59},
- /* inline delta function 2 */
- {0x4B,0x54,0x58,0x38,0x1B,0x5A,0x21,0x21,0x59,},
- /* diagonal stroke function */
- {0x20,0x20,0x40,0x60,0x47,0x40,0x23,0x42,},
- /* VacuFormRound function */
- {0x45,0x23,0x46,0x60,0x20,},
- /* ttfautohinted */
- {0x20,0x64,0xb0,0x60,0x66,0x23,0xb0,},
- /* spacing functions */
- {0x01,0x41,0x43,0x58,},
- {0x01,0x18,0x41,0x43,0x58,},
+ /* #0 inline delta function 1 */
+ {
+ 0x4B, /* PPEM*/
+ 0x53, /* GTEQ*/
+ 0x23, /* SWAP*/
+ 0x4B, /* PPEM*/
+ 0x51, /* LTEQ*/
+ 0x5A, /* AND */
+ 0x58, /* IF */
+ 0x38, /* SHPIX */
+ 0x1B, /* ELSE*/
+ 0x21, /* POP */
+ 0x21, /* POP */
+ 0x59 /* EIF */
+ },
+ /* #1 inline delta function 2 */
+ {
+ 0x4B, /* PPEM*/
+ 0x54, /* EQ */
+ 0x58, /* IF */
+ 0x38, /* SHPIX */
+ 0x1B, /* ELSE*/
+ 0x21, /* POP */
+ 0x21, /* POP */
+ 0x59 /* EIF */
+ },
+ /* #2 diagonal stroke function */
+ {
+ 0x20, /* DUP */
+ 0x20, /* DUP */
+ 0xB0, /* PUSHB_1 */
+ 0x01, /* 1 */
+ 0x60, /* ADD */
+ 0x46, /* GC_cur */
+ 0xB0, /* PUSHB_1 */
+ 0x40, /* 64*/
+ 0x23, /* SWAP*/
+ 0x42 /* WS */
+ },
+ /* #3 VacuFormRound function */
+ {
+ 0x45, /* RCVT*/
+ 0x23, /* SWAP*/
+ 0x46, /* GC_cur */
+ 0x60, /* ADD */
+ 0x20, /* DUP */
+ 0xB0, /* PUSHB_1 */
+ 0x26, /* 38*/
+ },
+ /* #4 TTFautohint bytecode (old) */
+ {
+ 0x20, /* DUP */
+ 0x64, /* ABS */
+ 0xB0, /* PUSHB_1 */
+ 0x20, /* 32*/
+ 0x60, /* ADD */
+ 0x66, /* FLOOR */
+ 0x23, /* SWAP*/
+ 0xB0 /* PUSHB_1 */
+ },
+ /* #5 spacing function 1 */
+ {
+ 0x01, /* SVTCA_x */
+ 0xB0, /* PUSHB_1 */
+ 0x18, /* 24*/
+ 0x43, /* RS */
+ 0x58 /* IF */
+ },
+ /* #6 spacing function 2 */
+ {
+ 0x01, /* SVTCA_x */
+ 0x18, /* RTG */
+ 0xB0, /* PUSHB_1 */
+ 0x18, /* 24*/
+ 0x43, /* RS */
+ 0x58 /* IF */
+ },
};
FT_UShort opcode_patterns = 7;
-FT_UShort opcode_pointer[7] = {0,0,0,0,0,0,0};
-FT_UShort opcode_size[7]= {12,9,8,5,7,4,5};
+FT_UShort opcode_pointer[7] = { 0, 0, 0, 0,
[ft-devel] Nice TTFAutohint screencasts (Hebrew)
Hi! TTFAutohint is compared to other hinting methods in screencasts on http://openfonts.hagilda.com :-) -- Cheers Dave ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Infinality Release
Have you actually done binary searches in TTFs to find signatures?
Well, only using the code here, not with a hex editor. I have seen
hits in some TTF files where I would not have expected them. May
speak to the issues you mentioned below.
OK. So it's definitely worth some tests :-)
[...] I think it is best if you extend the code so that the
function number is also checked to avoid false hits.
Yes, this makes sense for functions where we know the number, such
as ttfautohint and 0.
Well, most of the bytecode snippets are associated with one or more
fixed function numbers.
But, I think the whitepaper states that on (at least some)
functions, the number varies, which is why you need the detection
code in the first place.
Correct. My concern is that we get false hits due to the shortness of
the snippets.
Regarding the problems with the opcode patterns, what did you see
that was incorrect? From scanning them (quickly) it seemed like it
was mostly correct (perhaps missing the end IF, etc.)
Ah, I see that I've done a mistake, below is a corrected patch
(untested). However, I think that the current method is flawed in
general since arguments to opcodes are completely ignored by
`SKIP_Code'. For example, it is not possible to decide whether the
bytecode is
SVTCA_x
PUSHB_1
24
RS
IF
or
SVTCA_x
PUSHB_1
39
RS
IF
It seems to me that we really have to compare the *complete* bytecode
(including the arguments) within `Ins_FDEF'.
Werner
diff --git a/src/truetype/ttinterp.c b/src/truetype/ttinterp.c
index 505168d..ebd433c 100644
--- a/src/truetype/ttinterp.c
+++ b/src/truetype/ttinterp.c
@@ -4610,25 +4610,91 @@
FT_ULong n;
TT_DefRecord* rec;
TT_DefRecord* limit;
+
#ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING
+/* arguments to opcodes are skipped by `SKIP_Code' */
FT_Byteopcode_pattern[7][12] = {
- /* inline delta function 1 */
- {0x4B,0x53,0x23,0x4B,0x51,0x5A,0x58,0x38,0x1B,0x21,0x21,0x59},
- /* inline delta function 2 */
- {0x4B,0x54,0x58,0x38,0x1B,0x5A,0x21,0x21,0x59,},
- /* diagonal stroke function */
- {0x20,0x20,0x40,0x60,0x47,0x40,0x23,0x42,},
- /* VacuFormRound function */
- {0x45,0x23,0x46,0x60,0x20,},
- /* ttfautohinted */
- {0x20,0x64,0xb0,0x60,0x66,0x23,0xb0,},
- /* spacing functions */
- {0x01,0x41,0x43,0x58,},
- {0x01,0x18,0x41,0x43,0x58,},
+ /* #0 inline delta function 1 */
+ {
+ 0x4B, /* PPEM*/
+ 0x53, /* GTEQ*/
+ 0x23, /* SWAP*/
+ 0x4B, /* PPEM*/
+ 0x51, /* LTEQ*/
+ 0x5A, /* AND */
+ 0x58, /* IF */
+ 0x38, /* SHPIX */
+ 0x1B, /* ELSE*/
+ 0x21, /* POP */
+ 0x21, /* POP */
+ 0x59 /* EIF */
+ },
+ /* #1 inline delta function 2 */
+ {
+ 0x4B, /* PPEM*/
+ 0x54, /* EQ */
+ 0x58, /* IF */
+ 0x38, /* SHPIX */
+ 0x1B, /* ELSE*/
+ 0x21, /* POP */
+ 0x21, /* POP */
+ 0x59 /* EIF */
+ },
+ /* #2 diagonal stroke function */
+ {
+ 0x20, /* DUP */
+ 0x20, /* DUP */
+ 0xB0, /* PUSHB_1 */
+ /* 1 */
+ 0x60, /* ADD */
+ 0x46, /* GC_cur */
+ 0xB0, /* PUSHB_1 */
+ /* 64*/
+ 0x23, /* SWAP*/
+ 0x42 /* WS */
+ },
+ /* #3 VacuFormRound function */
+ {
+ 0x45, /* RCVT*/
+ 0x23, /* SWAP*/
+ 0x46, /* GC_cur */
+ 0x60, /* ADD */
+ 0x20, /* DUP */
+ 0xB0 /* PUSHB_1 */
+ /* 38*/
+ },
+ /* #4 TTFautohint bytecode (old) */
+ {
+ 0x20, /* DUP */
+ 0x64, /* ABS */
+ 0xB0, /* PUSHB_1 */
+ /* 32*/
+ 0x60, /* ADD */
+ 0x66, /* FLOOR */
+ 0x23, /* SWAP*/
+ 0xB0 /* PUSHB_1 */
+ },
+ /* #5 spacing function 1 */
+ {
+ 0x01, /* SVTCA_x */
+ 0xB0, /* PUSHB_1 */
+
Re: [ft-devel] New Infinality Release
Ah, I see that I've done a mistake, below is a corrected patch (untested). However, I think that the current method is flawed in general since arguments to opcodes are completely ignored by `SKIP_Code'. For example, it is not possible to decide whether the bytecode is SVTCA_x PUSHB_1 24 RS IF or SVTCA_x PUSHB_1 39 RS IF It seems to me that we really have to compare the *complete* bytecode (including the arguments) within `Ins_FDEF'. So, I've applied the updated patch you provided. The adjusted opcode sequences for the spacing functions broke Segoe UI Semibold (maybe others too), but I agree that what you did looks correct for those. This, along with the point you mentioned above about not being able to detect the pushed value, makes me think that this piece needs more work before it gets pushed out to a release. I do want to keep one or two of them in there however. I will trim down the code to patterns known to be OK, and push off work on the others until after the release. Does this make sense to you? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Infinality Release
So, I've applied the updated patch you provided. OK. The adjusted opcode sequences for the spacing functions broke Segoe UI Semibold (maybe others too), but I agree that what you did looks correct for those. I'm not completely sure whether the bytecode sequences are correct. For example, Greg sometimes writes #PUSH[], 1 instead of the expected #PUSH 1 This might indicate that the command is actually using NPUSHB 0x01 0x01 instead of PUSHB_1 0x01, or even NPUSHW 0x01 0x00 0x01, but the latter is rather unlikely, so this needs more investigation and pattern searching in real fonts. If you provide me a script or whatever to do such a search, I can use my collection of old fonts as a testbed to search for hits. BTW, what do you think of replacing SPH_DEBUG with FT_TRACE7(( ... )) to get those information with FT2_DEBUG=ttinterp:7 ftview ... ? In case you are not acquainted with FreeType's tracing mechanism, have a look into docs/DEBUG. This, along with the point you mentioned above about not being able to detect the pushed value, makes me think that this piece needs more work before it gets pushed out to a release. I do want to keep one or two of them in there however. I will trim down the code to patterns known to be OK, and push off work on the others until after the release. Thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
