>
>
> - The preview data may be only in SANE_FRAME_GRAY,
> SANE_FRAME_RGB, SANE_FRAME_RED, ...GREEN, ...BLUE. If
> necessary, the backend must transform some other internal
> data content or data representation into one of these
> formats. (For "better known" data representations like
> xyz-compression and "better known" data contents like RGB +
> "infrared for dust removal" library functions might be
> developed which transform the scan data into RGB or gray
> scale.
>
Hi Abel,
the question is if we should include functions like JPEG->PNG conversion
in each backend that needs it or should we make filters that work as
a "midend" (like sane-dll) that does the conversion.
>
> Finally, I think that a major revision of Sane should
> include language support.
> I know some users who would really
> appreciate it, if it would be possible to display e.g. the
> resolution option as "Auflösung".
>
> A very rough, incomplete and perhaps too simple suggestion
> for two library functions:
>
> Instead of simply displaying a variable of the type
> SANE_String, a frontend should call a function
>
> SANE_String* sane_translate_from_english(const SANE_String* text,
> const SANE_String* language)
>
> and display the result of this function.
>
> When handing a SANE_String value to the backend, a frontend
> should call
>
> SANE_String* sane_translate_into_english(const SANE_String* text,
> const SANE_String* language)
I don`t know if it is a good idea to include language support into the backend.
I think all the work should be done by the frontend. We only need a
translation table. The rest can be done by NLS/gettext.
Bye
Oliver
-- EMAIL: Oliver.Rauch@Wolfsburg.DE WWW: http://www.wolfsburg.de/~rauch
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com