On Jan 27, 2012, at 9:46 PM, Tom Browder wrote: > I moaned when lgt was deprecated because I had replied on its behavior > to extract various parameters for making to-scale PostScript picture > overlays, and I couldn't seem to get rtedge to maximize the objects in > the view. > > Now I am revisiting rtedge again after Sean and others I believe > applied some changes to rtedge to help the auto-sizing situation.
I wouldn't say it's a done deal yet, but it should be improved. There is still an open to-do item to implement a zoom option for all the rt-style tools (which is really easy, but I don't believe anyone has gotten to it yet). There is a way to set the viewsize, but I don't think the view is not recentered as the field is narrowed or widened so that'd need adjusting. > Now I would like to modify some of the output lines (or add others) to > ease parsing if there are no reasons not to. Specifically, I want > this information in a format similar to this (with leading '#' > characters so as not to interfere with surrounding shell scripts, > colons following keywords, all space-separated, no semicolons or > commas): The main reason against would be usability. Generally what is easiest to parse is far from ideal for reading. Moreover, the prevailing commentary from users has been that the rt* tools blather WAY too much as it is. (Most would prefer silent be the default.) One solution to this dilemma is actually something I'm working on right now with respect to rtarea -- a libbu container interface for outputting data in standardized formats (csv, xls, etc) so that all of the geometry analysis tools have output options geared towards programmatic use. Something to keep in mind (or we can work on implementing it together). The basic idea is to have the tools fill in a simple hierarchical data structure (json-style) instead of merely bu_log'ing to stderr or fprintf'ing to stdout (or worse). Then an output formatter would consistently write the data in a desired format. > I would prefer no leading '# ' (hash space) if possible, but am happy > enough with them. I see no reason for the leading hash. There's no format to the current output as it's all just bu_logged debug info lines. That said, I don't think it's a robust position to rely on so long as the code is still just calling bu_log() or *printf(). At least, it'd be no more robust than it currently is. Any change to the current output text would be just as fuzzy as there's nothing enforcing a format. Plus, changing it without adding/removing information would be causing the exact relatively arbitrary life expectancy issue that you presently fear for any tool currently parsing the output... :) > All that information is there now, but the current format appears > variable and fuzzy enough to make one worry about its life expectancy. I don't think the format of the GETTREE/PREP header section has changed in at least 10 years. You can see benchmark log files in the pix directory that are all at least that old, most much much older. What would be useful to sort out in advance of a libbu container interface is exactly what data is presently output, the usefulness/need for them being displayed, and how they group together. That definition could serve as requirements for a common output structure for all the rt* tools going forward. The wiki page would probably be a good drawing board. An example to get things rolling would be to define the set of high-level categories of information being presently output. Something like "view parameters", "prep metrics", "render metrics", "developer debugging information", "version information", ... ideally non-overlapping if it works out that way. Then for each category there are labels, key value pieces of data, lists of information, and so on. Cheers! Sean ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
