I found in parstxtr.cpp in Parse_Image that there is intelligent feature for
file recognition. It assume that when image has not specified type before
filename then it thinks image has the same type as outputed image. There is no
tiff autorecognition case becouse there is no tiff output. But there is jpeg
case. It is left by accident or becouse planned jpeg output ? IIRC there was
no plans for jpeg output - it would be mostly useless. But perhaps situation
has changes somehow ? So can I enclose it with 
  #ifdef REMOVE_NOT_USED_CODE
  ...
  #endif
?

ABX

Post a reply to this message

In article <dde2qu4ukgdd7l5h68tprm3a1bbk6ijtmb@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> I found in parstxtr.cpp in Parse_Image that there is intelligent feature for
> file recognition. It assume that when image has not specified type before
> filename then it thinks image has the same type as outputed image. There is no
> tiff autorecognition case becouse there is no tiff output. But there is jpeg
> case. It is left by accident or becouse planned jpeg output ?

Not because of planned JPEG output, but because specifying JPEG output by
the user is intentionally disabled.  That does not mean here is no JPEG
output!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Mon, 07 Oct 2002 10:04:23 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> Not because of planned JPEG output, but because specifying JPEG output by
> the user is intentionally disabled.  That does not mean here is no JPEG
> output!

Hmm. There is no switch for JPEG output, so I assumed there is no JPEG output.
'If JPEG_FILE can't appear in opts.Output_File_Type then why such case in
switch' I thought. Now, I see in optin.cpp and optout.cpp ...

ABX

Post a reply to this message