nulldevice & charpath: rounding and other oddities
jdaw1
following test:
%!
/HelveticaNeue-CondensedBold 24 selectfont
/stringtotest ( K.W.V. ) def
gsave
(plain) =
newpath 0 0 moveto
[ 0 0 0 0 0 0 ] defaultmatrix setmatrix
stringtotest true charpath flattenpath pathbbox = = = =
grestore
gsave
(nulldevice) =
nulldevice
newpath 0 0 moveto
[ 0 0 0 0 0 0 ] defaultmatrix setmatrix
stringtotest true charpath flattenpath pathbbox = = = =
grestore
() =
(Programmer's checks:) =
(countdictstack = ) dup 17 countdictstack ( ) cvs
putinterval =
(countexecstack = ) dup 17 countexecstack ( ) cvs
putinterval = % countexecstack array execstack {==} forall
(pstack start) = pstack (pstack end) =
which via Mac OS X Distiller 7.0, produced the following log:
plain
17.1
65.28
-0.0600281
6.96002
nulldevice
17.0
65.0
0.0
7.0
Programmer's checks:
countdictstack = 3
countexecstack = 11
pstack start
pstack end
Please, why the rounding? And are there other known bugs with charpath
after nulldevice?
François Robert
news:1171509365....@s48g2000cws.googlegroups.com:
>
> Please, why the rounding?
Firstly, the default CTM are not the same for the initial device
and for the nulldevice (for nulldevice, it is the identity by
definition).
Secondly, the path vertices are stored in device space 'pathbbox'
computes the bbox corners in device space before converting back to
user space, and your Distiller seems to round things up in device
space.
A possible explanation : If coordinates in device space incur some
rounding (maybe to the nearest device pixel would make sense ?),
the identity matrix in the null device allows to observe that right
away. In fact, an interesting experiment is to force the first
device CTM to the identity matrix and see the result.
Each interpreter is bound to produce somewhat different results
between those two devices and even the same interpreter could, when
changing the device resolution (/HWResolution array in the
pagedevice dictionary). Vice versa, *if* device space is where
rounding occurs, and given the values you reported, your
/HWResolution array is probably [72 72], something that you can
check as well.
Now, how coordinates are stored in device space is implementation
dependent and using pixel integer coordinates is obviously not the
most accurate way of doing so. (In fact, neither the OS X 10.4
Preview "distiller" component, nor Ghostscript, nor the Windows
Distiller 7.0 have this rounding issue).
> And are there other known bugs with charpath after nulldevice?
_______________________________________________________
François Robert
jdaw1
typeface /HelveticaNeue-CondensedBold when distilled with Distiller
7.0 on Mac OS X, a bug that can be fixed by any of:
-- not invoking nulldevice;
-- removing the period (leaving (K));
-- distilling with Preview.
The problem is not fixed by changing the typeface.
The nulldevice command was there only for computation tidiness, so can
be deleted, but nonetheless this error is somewhat unsatisfactory.
François Robert
"jdaw1" <jdawi...@gmail.com> wrote:
> After a nulldevice there is a bug in the bounding box of (K.)
Sorry, but I fail to see it in the code you posted ?
> in the typeface /HelveticaNeue-CondensedBold when
> distilled with Distiller 7.0 on Mac OS X, a bug that
> can be fixed by any of:
> -- not invoking nulldevice;
> -- removing the period (leaving (K));
> -- distilling with Preview.
>
> The problem is not fixed by changing the typeface.
You mean, *any* typeface (not merely other weights for the Mac's
'Helvetica Neue') would cause wrong bbox calculation (via 'charpath' +
'pathbbox') for the string (K.) but not for (K) ?
"Kerning pair" springs to my mind when mentionning that sort of
symptoms, but I don't see how it could affect a bbox calculation, since
'charpath' simulates a plain 'show' and not one of its more complex
variant ('kshow', 'ashow' etc...).
On my Mac, all HelveticaNeue-* are in a single font suitcase
(/Library/Fonts/HelveticaNeue.dfont). In Preview, the corresponding PS
font is a Type 42 (TrueType). I can only speculate here, but maybe
Distiller somehow takes into account the kerning tables (or some other
Apple Advanced Typography or OpenType table) found in those kind of
fonts (and it shouldn't) ?
> The nulldevice command was there only for computation
> tidiness, so can be deleted, but nonetheless this error
> is somewhat unsatisfactory.
________________________________________________________
François Robert
jdaw1
away using Preview.