| Summary: | bbox device doesn't allow min coords < 0 | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | L. Peter Deutsch <ghost> |
| Component: | Other Driver | Assignee: | Ray Johnston <ray.johnston> |
| Status: | NOTIFIED WONTFIX | ||
| Severity: | normal | CC: | tez |
| Priority: | P1 | ||
| Version: | master | ||
| Hardware: | All | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
|
Description
L. Peter Deutsch
2000-03-09 07:17:33 UTC
Comment originally by lpd@users.sourceforge.net (Ghostscript version: 6.0) This is an architectural restriction in Ghostscript: all devices impose an implicit clipping region of [0 0 infinity infinity] in device space, in addition to the region set by setclip. We might be able to work around it by making the default/initial CTM for the bbox device include a large positive translation, and then biasing the bounding box that the device reports, but it\'s unlikely that we will get to this soon. Comment originally by rayjj@users.sourceforge.net I don\'t know how \"kosher\" it is, but I\'ve noticed that if the bbox device has negative coordinates for the ImagingBBox[0] and [1] values, then negative values ARE handled. For example: % gs -q -sDEVICE=bbox -dNOPAUSE GS><< /ImagingBBox [ -4000. -4000. 4000. 4000. ] >> setpagedevice GS>-100 -200 moveto 300 400 lineto stroke GS>showpage %%BoundingBox: -101 -201 301 401 %%HiResBoundingBox: -100.416020 -200.277345 300.416018 400.277348 GS>quit ====================================================== L. Peter Deutsch replied: > I\'m pretty sure you can\'t rely on this -- I think there are several places > in the graphics library that assume that a device\'s coordinate space is all > in the first quadrant. But it\'s a reasonable shot at a workaround. Comment originally by jch@users.sourceforge.net I had a similar problem, and solved it by removing the implicit clipping in my private version of GS (I'm relying on the driver to do clipping for me). Mostly, this consisted in replacing all the clipping macros with dummies, defining my own initial clippath function, and fixing a few modulus operations that assumed positive device coordinates. The changes are not quite complete, and I still sometimes have incorrect rendering with halftones which I suspect to be due clipping. For what it's worth, the changes are available, albeit lost in the mass of the DPS patches. dps.sourceforge.net Comment originally by rayjj@users.sourceforge.net Logged In: YES user_id=11206 We acknowledge that this is a valid issue, but we do not have resources available to address this at this time. This problem report has been moved to doc/Issues.htm where it may remain open for some time. Relevant comments are captured there along with the ID# of this report. By moving this issue to the widely distributed Ghostscript documentation, we wish to make this issue well known and solicit help in improving Ghostscript in this area. Thanks for your input! Re-opening so we can close this with a different resolution. The architectural changes mentioned by 'jch' never materialized, and this hasn't surfaced as an issue for anyone else in the past 8 years, so I am closing this as WONTFIX. Note that the 'work around' mentioned in Comment #2 is probably the best: << /ImagingBBox [ -4000. -4000. 4000. 4000. ] >> setpagedevice The published workaround no longer appears to work: $ gs --version 9.10 $ gs -q -sDEVICE=bbox -dNOPAUSE GS><< /ImagingBBox [ -4000. -4000. 4000. 4000. ] >> setpagedevice GS>-100 -200 moveto 300 400 lineto stroke GS>showpage %%BoundingBox: 32 0 301 401 %%HiResBoundingBox: 32.723999 0.000000 300.419991 400.283988 GS> quit |