Summary: | Problem with cross-compiling | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Marcos H. Woehrmann <marcos.woehrmann> |
Component: | Build Process | Assignee: | Robin Watts <robin.watts> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 8.71 | ||
Hardware: | PC | ||
OS: | All | ||
Customer: | new customer | Word Size: | --- |
Attachments: | arch.h |
Description
Marcos H. Woehrmann
2011-02-22 18:54:46 UTC
Further customer information: Some additional information regarding the problem described in the mail below: we found that when printing this PDF with Adobe Reader with the advanced print option 'let printer determine colors' enabled, the problem goes away. It seems that Adobe Reader converts the images into a different format, using different colorsettings. I'm attaching the resulting Postscript files as reference, where PDFTest_prn_colors.ps is the file that prints correctly on our printer, and PDFTest.ps prints as a black box. It looks like there's something wrong with the handling of a certain colorspace on our PowerPC target.. This file prints correctly with the same GS configuration on a native x86 system. Note that the 'detailed bitmap debug info' (-ZB debug flag) shows the same results on PowerPC and x86, so at that point the bitmap still seems correct. I've attached PDFTest_bad-ZB.log that shows the -ZB debug output as reference. And more customer comments: No other relevant Ghostscript options were used, only -dNOPAUSE. Note that resolution doesn't seem to matter, nor does the outputdevice. I tried pcxmono and bmpmono at 300x300 today, which show the same problem. Also tried the grayscale device 'pcxgray' without success. Note that I attempted to duplicate this problem on a big-endian sun-sparc unix system, but couldn't get it to fail either. I only see the problem with GS running embedded in our PowerPC based printer (8241 family PowerPC, 32-bit, big endian).. GS is built with only the following enabled features: FEATURE_DEVS=$(PSD)psl3.dev $(PSD)pdf.dev Robin had some suggestions in an email: Cross-compiling GS is a tricky business, due to the way we do the build; we build various executables during build that are expected to run on the host machine (such as gsecho etc), and some that are (AIUI) expected to be run on the target machine (genarch). This is made worse by autoconf etc - it's very easy to configure for the host instead of the target and not realise. When I build for ARM targets for instance, I tend to run the autoconf on an x86 machine, and tweak the produced files by hand - fortunately as x86 and (most) ARMs are all little endian there are fairly few differences, so this works for me. Ray may have more experience in doing this 'properly'. I'd like to ask the customer to: 1) do a completely clean build and record the logs for us to look at (so we can see all the build steps he does, commands and all) 2) to get the produced arch.h file for us to check 3) to get him to send us a diff of his changes from the vanilla 8.71 sources. Created attachment 7277 [details]
arch.h
This is the arch.h file generated when I natively compile on an iMac G5.
This was fixed in revision 12205 in SVN (http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=7d3b6018360889d13b08be40bc8ac1a63baba8be). Was due to floating point rounding issues. |