home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / postscri / 6408 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  2.5 KB
  1. Path: sparky!uunet!olivea!decwrl!adobe!macne035.boston.us.adobe.com!user
  2. From: zisk@adobe.com (Stephen Zisk)
  3. Newsgroups: comp.lang.postscript
  4. Subject: Re: Printing Images
  5. Message-ID: <zisk-220193103606@macne035.boston.us.adobe.com>
  6. Date: 22 Jan 93 15:50:33 GMT
  7. References: <1993Jan21.040931.3054@pdact.pd.necisa.oz.au>
  8. Sender: usenet@adobe.com (USENET NEWS)
  9. Followup-To: comp.lang.postscript
  10. Organization: Adobe Systems Incorporated
  11. Lines: 39
  12.  
  13. In article <1993Jan21.040931.3054@pdact.pd.necisa.oz.au>,
  14. sfr@pdact.pd.necisa.oz.au (Stephen F. Rothwell) wrote:
  15.  
  16. > [stuff deleted]
  17. > First question: Is the CCITTFaxDecode filter know to be very slow,
  18. > or are we going about this the wrong way?
  19. My first question: what printer are we dealing with here? I am
  20. asking because I want to know what processor and whose implementation.
  21. CCITT group 4 is somewhat slower to decode than group 3, in general.
  22. This may be offset if you are using a very slow comm channel. You
  23. did not say what printer port (or at what speed) you are using.
  24.  
  25. > [more stuff deleted]
  26. > Second question: Is scaling of large images slow?
  27. Scaling of large images is typoically much slower than simply copying
  28. bits. Again, this depends on the processor and implementation. A slow
  29. clock-speed 68000 with a cartridge implementation will be very slow,
  30. while a high clock-speed RISC machine with an interleaved ROM will be
  31. faster. A controller with a floating point processor, which may include
  32. a faster integer multiply, also could be faster.
  33.  
  34. > [more stuff deleted]
  35. > Third question: Does the CCITTFaxDecode filter have this bug?
  36. I have not heard of this bug in Adobe implementations. That does
  37. *not* guarantee it is not there, but on the printers I have access
  38. to, I have sent many group 3 and 4 files, and have also used the
  39. printer itself to encode files, and then sent them. The only bug
  40. I have seen is an endianness problem with some group 3 images. This
  41. was a certain piece of software which chose to order the bits within
  42. a byte "backwards" relative to the printer. When I spoke with the
  43. authors, they claimed that since CCITT is made for a serial stream,
  44. there is nothing in the spec about what order bits should fill a
  45. byte. I do not know if this is true.
  46.  
  47. Stephen Zisk (zisk@adobe.com)  Disclaimer: These are my personal views
  48. Adobe Systems Incorporated     and do not represent the position of
  49. Eastern Regional Office        Adobe Systems Incorporated.
  50. 24 New England Exec. Park
  51. Burlington, MA 01803           They pay me but they don't muzzle me!
  52.