The -r (resolution) option to ftdiff causes anomalies in the
rendering.
Most of the time it just looks like the dri is used only for the
vertical axis, leaving the horizontal dpi at 72.
But sometimes the initial display is severly corrupted. When that
occurs hitting down-up or up-down to toggle a different point size
will give a 'correct' rendering (modulus the first issue). The -s
option may have to also be given to see this corruption.
And the help text for -s should be changed a bit. Perhaps change
'NNN' to 'NN.N'? But definitely change '16' to '16.0', to make it
clear that the arg is not an int but rather a float.
For ths first issue, I think changing _render_state_rescale()
from running:
,----
| FT_Set_Char_Size( state->face, 0, state->char_size * 64,
| 0, state->resolution );
`----
into:
,----
| FT_Set_Char_Size( state->face, 0, state->char_size * 64,
| state->resolution, state->resolution );
`----
will do it, because in ftobjs.c, there is:
,----
| req.horiResolution = ( horz_resolution ) ? horz_resolution : 72;
| req.vertResolution = ( vert_resolution ) ? vert_resolution : 72;
`----
so horz_resolution is indeed staying 72 and _redner_state_rescale()
is only altering vert_resolution. This is unlike char_width and
char_height where if either is 0 it gets set to match the other.
Or perhaps the correct patch is in ftobjs.c to add code to make the
default resolutions the same if one of them is set to 0?
I'm not sure of the fix for the second issue, given that the initial
display is different from a redisplay.
Incidently, ftdiff.c,v is a+x in CVS:
,----{ rsync cvs.sv.gnu.org::sources/freetype/ft2demos/src/ftdiff.c,v }
| -r-xr-xr-x 63623 2007/04/02 09:43:48 ftdiff.c,v
`----
Otherwise: COOL CODE!!
-JimC
--
James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
