hrs1@cbnewsi.att.com (herman.r.silbiger) (08/31/90)
In article <1990Aug29.200555.21009@math.lsa.umich.edu>, andrea@sdd.hp.com (Andrea K. Frankel) writes: > > Here's a question I hope someone reading this group can answer: > > CCITT Group 3 encoding has explicit end-of-line codes. Some implementations > (hardware and software) appear to require all lines to be the same > length, fully encoded up to the row width (which must be specified in > some way external to the encoded file), or else they fail. > > - Is this a valid, conforming implementation? > > - Or should a robust implementation be able to decode > Group 3 files where some rows are ended "early" with an EOL > (in which case presumably the rest of the row is white)? The line length is specified in T.4, and has to be maintained. Therefore, no short lines. Even in T.6, where there are no EOLs, the number of pels/line is fixed. Herman Silbiger hsilbiger@attmail.com
eli@pws.bull.com (Steve Elias) (09/04/90)
andrea@sdd.hp.com (Andrea K. Frankel) writes: >[Reposted to alt.fax from the newsgroup(s) comp.std.internat. >CCITT Group 3 encoding has explicit end-of-line codes. Some implementations >(hardware and software) appear to require all lines to be the same >length, fully encoded up to the row width (which must be specified in >some way external to the encoded file), or else they fail. > > - Is this a valid, conforming implementation? yes, i think so. although conforming to the standard might not give you conformance with all existing fax systems. > - Or should a robust implementation be able to decode > Group 3 files where some rows are ended "early" with an EOL > (in which case presumably the rest of the row is white)? i'm not sure i would call such an application "robust". instead, i'd call it "forgiving". if robustness is what you're interested in, you might like to allow a G3 output option which provides byte-aligned EOLs, as this is "required" by the TIFF/G standard, much to the chagrin of typists everywhere. :) also, you should include support for G3 images with scan widths longer than 1728 pixels. this doesn't seem to be allowed by the T.4 spec, but there are fax systems out there which work with such images. they're often used in newspaper/typesetting/mapping environments, i think. >(When responding to this question, please give document references and/or >your "credentials" which I can use to establish the credibility of the >argument to the key managers involved.) hmm. credentials? i'm a typist who has been engineering computerfax, messaging, and networking software & systems for about 7 years. >Below is a message from an engineer heavily involved in the >implementation, giving his arguments as to why it should be OK to blow >up on "early" EOL's: good arguments. but a "forgiving" application, would do something "nice" with early EOLs, as well as perhaps emailing an error message to the engineer who wanted things to "blow up" on early EOL! :) >> And finally, the AMD chip for G3 encoding/decoding, used in PC boards, >> requires explicit knowledge of the image width, but does not allow for early >> EOL's. This chip apparently "sets the standard." here i disagree. simply because AMD has coded something in silicon doesn't make it a standard, de facto or otherwise. is anyone aware of any products which actually use this chip? Kofax boards, perhaps? software G3 encoding/decoding is fast enough for many applications. (not to slam AMD, or anything -- they're great siliconians! hi there John Jaeger -- remember the Lake House?! :) -- /* eli@pws.bull.com 617 932 5598 fax 508 294 0101 */