Summary: | huge performance difference between jpeg and bit device for xl-raster-file | ||
---|---|---|---|
Product: | GhostPCL | Reporter: | norbert.janssen |
Component: | PCL interpreter | Assignee: | Henry Stiles <henry.stiles> |
Status: | NOTIFIED LATER | ||
Severity: | normal | CC: | michael.vrhel |
Priority: | P2 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Customer: | 661 | Word Size: | --- |
Description
norbert.janssen
2010-09-07 13:57:47 UTC
Right because the ghostscript graphics library caches patterns fully rendered (halftoned) so peculiar effects can occur when the pattern and halftone interact. The solution to this was to paint the pattern with width of least common multiple of the halfone width and pattern width see pxink.c for details, this can result in a significantly larger patterns and slower processing times. If you use the contone code path pxink.c:289 such that the "full width" equals the "repeat width" the performance should be fine. The theoretical concerns are real, it is easy to imagine how the halftone screen would be applied incorrectly when tiling an already halftoned pattern, but actual practical problems seem to be rare. PCL XL FTS 3.0 T421 panel 9 is one of the few good examples I've found. Also, I am not sure why we haven't seen this problem in postscript or pdf which, as far as I know, neither increase pattern size to avoid this problem. All leading to the suggestion we could disable the replicating code and document the rare problems that do occur anomalies. I've copied in Michael Vrhel our color expert, he may have some thoughts. (In reply to comment #1) > Right because the ghostscript graphics library caches patterns fully rendered > (halftoned) so peculiar effects can occur when the pattern and halftone > interact. The solution to this was to paint the pattern with width of least > common multiple of the halfone width and pattern width see pxink.c for details, > this can result in a significantly larger patterns and slower processing times. > If you use the contone code path pxink.c:289 such that the "full width" equals > the "repeat width" the performance should be fine. > > The theoretical concerns are real, it is easy to imagine how the halftone > screen would be applied incorrectly when tiling an already halftoned pattern, > but actual practical problems seem to be rare. PCL XL FTS 3.0 T421 panel 9 is > one of the few good examples I've found. Also, I am not sure why we haven't > seen this problem in postscript or pdf which, as far as I know, neither > increase pattern size to avoid this problem. All leading to the suggestion we > could disable the replicating code and document the rare problems that do occur > anomalies. > > I've copied in Michael Vrhel our color expert, he may have some thoughts. I set the limit to 128 (i.s.o. 10000), but this indeed introduces a minor? artefact. Though performance is then as expected. Don't know what is better. I think that with this job it's hardly visible when printed on paper (but have to check that). Resolving to "LATER", Norbert if you want to talk about this more please send me email or reopen the bug. |