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
After a nulldevice there is a bug in the bounding box of (K.) 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.
The nulldevice command was there only for computation tidiness, so can be deleted, but nonetheless this error is somewhat unsatisfactory.
In article <1171600481.718227.204...@v33g2000cwv.googlegroups.com>,
"jdaw1" <jdawise...@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
