Re: [avr-libc-dev] pngtopnm

[Theodore A. Roth]

On Fri, 8 Nov 2002, E. Weddington wrote:

:) Yeah, "should be portable", but I'm dealing with Windoze. I'm not
:) about to go off and create a port of graphics software that's really
:) just auxillary to get a compiler up and running. I barely have enough
:) time to try to get a Win32 distro built (and especially before
:) December ;-)).
:)
:)
:) > > Can an alternate solution be
:) > > found for all platforms, without trying to create a win32 version of
:) > > pngtopnm?
:) >
:) > Well, you can always pick the latest generated graphics files from
:) > some other source, like the official documentation on the Web page.
:) > They are just generated from the .fig (vector graphics) input files,
:) > so unless these input files are changed, the generated files will
:) > never be modified.
:) >
:) > Do you have a ppmtogif tool for Win32?
:)
:) No. fig2dev came with ppm2pcx and gif2pnm. And cygwin came with
:) ppm2tiff.
:)
:) > If so, you can revert to
:) > GIF since your Win32 build has no restrictions unlike the nongnu.org
:) > servers that forbid to use it. ;-)  See the diffs between 1.23 and
:) > 1.24 of doc/api/Makefile.am, and 1.3 and 1.4 of doc/api/malloc.dox.
:) > Basically, by reverting them, you'll get it all in GIF.  You need to
:) > apply a similar patch for the doc/examples/demo part.
:)
:) Why does the project have all these auxillary graphics conversions as
:) part of its make in the first place?

png for html
eps for ps
pdf for pdf

:)
:) Why does the .fig have to be a part of the source? Why not convert it
:) to .png before adding it to CVS and leave out all this conversion in
:) the make? You said "so unless these input files are changed, the
:) generated files will never be modified." Will they ever be frequently
:) modified enough to warrant this?

The .fig is part of the source so that it can be changed is the user finds
a problem. I we only get them the generated files, the can fix them. Think
of the .fig as the "source" for the images.

Also, .fig is an ascii file, thus easily handled by cvs.

I don't want binary files in cvs if it can be avoided. The user of the
tarballs doesn't have to be able to build the dox (thus they should not be
built by default), only the library. The dox for a stable release will
always be on the website for download too.

Ted Roth