Hello! I have been updating an tool (based on the DWFStrings sample program) from DWFToolKit 7.6 to 7.7, and discovered that on 64-bit Linux builds, for some of the test files it was dropping strings from the output. I believe the failing test files are taken directly from the DWFStrings sample program, so you should be easily able to replicate the problem.
I traced the problem down to a change in dwf/whiptk/typedefs_defines.h, which changes this line:
typedef int32_t WT_Integer32;
to
typedef long WT_Integer32;
This change is erroneous on the face of it; on 64-bit Linux, a long is a 64-bit integer, not a 32-bit integer. The same error is of course repeated with WT_Unsigned_Integer32 -- and, in fact, both of these errors lead to misread files, in different cases.
I have not tracked down the exact mechanism by which these files cause things to be misread, but I have confirmed that changing "long" to "int" in the following lines will fix the problem. This is almost certainly the correct fix if for some reason you don't want to rely on int32_t and the related names that are intended for cases like this where you actually do need a specific bit width.
dwf/whiptk/color.cpp, line 46
dwf/whiptk/ellipse.cpp, lines 230 and 232
dwf/whiptk/transform.h, lines 35 and 84
dwf/whiptk/typedefs_defines.h, lines 34 and 42
Hopefully we will see this bug fixed in version 7.8.
