On Sun, Nov 13, 2011 at 11:19:40AM -0500, Kent A. Reed wrote: > 1. image file format First, sorry for late response... > 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). ... > 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.
Including raster formats like png or gif into pdf give horrible result compared to vector ones. Also converting vector schemas to bitmap limits you in editing. > 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 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). > ... > ./hal/rtcomps.txt:image::pid-block-diag.eps[] Problem with this files is that there is no .png file for .eps one. If there is such we can just use image::pid-block-diag.*[] And get good result both for html and pdf. > 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. Agree here. > 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. It would be nice to move them all into images/ subdir. I have not touched them during transition to asciidoc just not to clutter things more. > * 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. Converting gif to png is a matter of half an hour. Vector would take a bit longer. However if somebody will help me with converting dxf to svg it would not take much time. > 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. So my bet is to use png for truly raster images like screenshots and svg for vector data. Last but not least is that SVG images are translatable. For example theese are same images with .ru derived from english one automaticaly: http://psha.org.ru/tmp/svg2po/tool_positions.svg http://psha.org.ru/tmp/svg2po/tool_positions.ru.svg Pavel ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
