Kent, The guidelines I was working under was: If the image was based on a dxf file retain that file so changes could be made if needed in the future. Use png images when possible (always use png was the actual guideline).
I have no idea what the guidelines for 2.5 is as it has been completely changed... I tried to keep/move all images and dxf files in the /images directory. I'm sure that many if not most of the screen shots are out of date and need replacing with 2.5 screen shots. I'm happy to work on this, but I'm not until I get some assurance that all my work is not going to be tossed in the trash again. John On 11/13/2011 10:19 AM, Kent A. Reed wrote: > Gentle persons: > > 1. image file format > > Taking a survey of the files in the 2.5 docs/src directory and below, I > find we have 368 image files in dxf, eps, gif, jpg, png, and ps format. > (Yes, I know some of the images appear in multiple formats, but that's > not the main issue here). > > I think it is fine that we use every means at our disposal to create > image files, ranging from screen capture to cad. > > However, I recommend that we restrict the production image files (e.g., > the files actually invoked in the asciidoc .txt files) to just two* > formats---gif and png. Yes, it is possible to jiggery-pokery the > toolchain to convert formats automagically, but it adds to the headaches > of developers and maintainers, and it causes problems such as the > missing eps figures in the current html output (see, for example, the > missing Figure 2 and above in > http://www.linuxcnc.org/docs/2.5/html/hal/rtcomps.html). > > Recommendation 1a : > > Use convert (from the ImageMagick suite) to create png files from the > eps files either all at once as a separate task (my preference) or as > part of the make process. > > At a minimum, the invocation would be > > convert -flatten<name>.eps<name>.png > > where using the flatten option produces a white rather than transparent > background. > > For black-and-white line art, the invocation would be > > convert -flatten -monochrome<infile.eps> <outfile.png> > > where using the monochrome option improves image quality. > > Caveat: I haven't investigated this issue closely enough to know if one > should specify image size or density to get a satisfactory result when > placed in the EMC2 docs. > > Recommendation 1b : > > Along with the above, edit the offending txt files, listed below, to > invoke png rather than eps files (for brevity, I list the English files > only; the situation is the same in their French, German, and Spanish > versions). > > ./common/Integrator_Concepts.txt:image::images/servo-feedback.eps[] > ./code/Code_Notes.txt:image::CMS_buffer.eps[] > ./drivers/pluto_p.txt:image::images/pluto-pinout.eps[] > ./drivers/pluto_p.txt:image::images/pluto-step-pinout.eps[] > ./drivers/pluto_p.txt:image::images/pluto_step_waveform.eps[] > ./config/ini_homing.txt:image::images/emc2-motion-homing-diag.eps[] > ./config/stepconf.txt:image::images/switch-nc-series.eps[] > ./config/stepconf.txt:image::images/switch-no-parallel.eps[] > ./hal/parallel_port.txt:image::parport-block-diag.eps[] > ./hal/rtcomps.txt:image::stepgen-block-diag.eps[] > ./hal/rtcomps.txt:image::freqgen-block-diag.eps[] > ./hal/rtcomps.txt:image::stepgen-type0.eps[] > ./hal/rtcomps.txt:image::stepgen-type2-4.eps[] > ./hal/rtcomps.txt:image::stepgen-type5-10.eps[] > ./hal/rtcomps.txt:image::stepgen-type11-14.eps[] > ./hal/rtcomps.txt:image::encoder-block-diag.eps[] > ./hal/rtcomps.txt:image::pid-block-diag.eps[] > > Recommendation 1c : > > If possible, I would recapture images currently in jpg format in png > format instead. While the jpg files work, they suffer from the lossy > jpeg compression. Converting them from jpg to png just preserves the loss. > > > 2. image file organization > > There is an apparent file structure to the EMC2 sources of the form > docs/src/<topic>/... and docs/src/<topic>/images/... > > I applaud this. Despite Emerson's famous quip about a foolish > consistency, being consistent with file structures and file names can > only help EMC2 developers and maintainers. > > Unfortunately, image files have been leaking out. Of the 368 image files > in the 2.5 docs/src tree, 114 are not in an images subdirectory. I'm not > going to list them here but can send the list separately if you wish. It > would be possible to make a mass change both to file locations and to > file references, but this has to be planned carefully since editors have > various pieces in play. > > That's all for now. > > Regards, > Kent > > * actually, I'd like to see the gif files converted too, but it doesn't > have to happen within the 2.5-release time frame. As well, in future I'd > hope to see svg format used for the vector graphics that we now hold in > dxf/eps, but again, the clock is ticking. > > PS- I apologize for my erratic on-again/off-again behavior. I used to > think retirement would mean I had at least 8 more hours a day to devote > to things I wanted to do. Life has a way of interrupting one's plans. > Between being my wife's care-giver and my grandkids' mentor, I have less > time than ever. So be it. > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
