Hi, On Sun, Apr 14, 2002 at 03:01:42PM +0200, Oliver Rauch wrote: > sane2.tex is the SANE2 standard proposal
Some questions and comments that came to my mind while reading the standard the first time (so I may have missed something): * 3.2 Image data format and 3.2.1 Image transmission: The radical change in frame types and frame transmission should be mentioned earlier in the text. We don't know if all the information about 1, 8, 16 bits per sample are true for some MIME format, do we? I'm not sure if we should even mention the old SANE1 frame types. If someone really wants to use them, he should looak at the SANE1 standard. Or is tehre a special reason for this? Add a reference to the chapter about sane_get_parameters fort the exact meaning of formatdesc. By the way: Shouldn't the name be "format_desc"? * SANE_Device.email_backend_author: I'm not sure, if this really belongs into the structure (and not into the man page and HTML page). If it's in the code, I would prefer to also have the name of the author in this entry. This makes it easier to find him when the email address doesn't exist any longer. * SANE_Device.device_location: I don't understand this one. Which location? My device is on the table 1.5m to the right of me :-) Do you mean the backend? A URL to the vendor? Or a path name? And why should it be read from the config file (the backend doesn't even need one and I'm not sure if we should mention this). * SANE_Device.backend_version_code: This one is a pretty good idea. I already thought about how to find out the version number of a backend connected to dll and there is currently no way. * SANE_Device.backend_capability_flags: Can you give an example for such a flag and what the frontend should do with it? * 4.2.10 InternationAlization (missing "a"). Be clear. "Should" is should. There is no "preferrable" necessary. Maybe we should cite the RFCs' meaning of "MUST" and "SHOULD" somewhere in the standard? "member", not "memeber". * 4.3.3 (Backend implementation note): "The same information is ..." (instead of informtation). * 4.3.4: The SANE_Status sane_open ..." line is too long. * SANE_Parameters.flags: To be consistent with SANE_FLAG_LAST_FRAME shouldn't the next falg be the other way round: SANE_FLAG_LAST_IMAGE? Or is this for SANE1-Compatibility? * 4.3.8 "Note that flags are compatible" (not compatibel). * 4.3.8 SANE_Parameters.bytes_per_line: I would move the comment about block sizes to sane_read(). * 4.3.8 SANE_Parameters.depth: See comment on 3.2 abouth depth. * 4.3.8 SANE_FRAME_MIME: "within" insted of "whithin", "frame" insetad of "framy". "Other formats may be ... but the only..." (the "as" is too much). * 4.3.8 SANE_Parameters.proposed_filename: The sentence starting with "Special care..." contains a bit too much brackets :-) It also references a point "a)" which doesnt exist as "a)". Maybe: "...not an issue here, because that's only a propose filename extension as mentioned above." As an addition, we should make clear what can be changed in a SANE_Option_Descriptor and when. Currently it must only be "vaild" and the address stay the same. E.g. is the backend allowed to change the type of option? Or only capabilities? * 4.4: "the individual channels of the ..." (the "in" is too much). Bye, Henning
