Indeed, the metafile tools were dragged into Radiance at some point I wanted to be able to script things like plots and diagrams when doing data analysis, and it was just more convenient. They have very little in common with the rest of Radiance, though they were the first appearance of the .cal language in tools like bgraph.
We can pipe the output of psmeta to ps2pdf or similar. How is SVG supported on different systems? I hadn't heard of it before. Can you just send output to a web browser, or ?? As I said, these tools have been no effort for me to maintain for many decades, so unless we really need better vector output for some reason, it's not that big a deal to write a converter to SVG or PDF if that's all we're talking about. On the other hand, it wouldn't be that difficult to replace it as far as Radiance is concerned -- I would still use it for automating plot generation, since I've no way to pipe data to Excel. Cheers, -Greg > From: Georg Mischler <[email protected]> > Subject: Re: [Radiance-dev] Meta files and library > Date: May 10, 2016 3:41:21 PM PDT > > Ah, I didn't remember that the history of meta files goes that far back. > > If I understand it right, the primary purpose of the package is to > create diagrams from tabular numerical data. Its functionality is almost > completely independent from the rest of Radiance, with mgf2meta as the > lonely exception that actually processes Radiance specific data. > > Compared to more "friendly" ways to create diagrams (spreadsheets, > statistical software), the current approach has the following > advantages: > > - simple implementation > - included in the distribution > - scriptable within pipelines > - no thirdparty dependencies > > The disadvantages: > > - limited output connectivity (conversion is currently only possible > into Windows bitmaps, targa, and postscript). > - limited graphics resolution (2^14 units), possibly not accurate > enough for large format high resolution output > - limited graphics capabilities (no curves, only 5 colors) > > So what we're looking for would be a diagramming toolkit with more > flexibility on the output side, and not too many other disadvantages. > > The least invasive solution would be to simply add a few converters, > eg. meta2svg or meta2pdf. This would at least widen the path to > downstream processing. > > On the other hand, if we ignore mgf2meta, we could use pretty much any > open source diagramming tool out there that we like. There will be > nothing that is "preinstalled everywhere" though, the topic is simply > too diverse for that. > > In between, using eg. SVG as an internal format might be an option. > Writing is easy, since we have very simple content. Reading is slightly > more involved, even when we're restricting it to our self-generated files. > But then we already have ezxml in the distribution, so it might actually > be manageable. > > Cheers > -schorsch > > > Am 2016-05-10 16:48, schrieb Gregory J. Ward: >> Hi Schorsch, >> Yes, "MLIB" was probably not the best choice of environment variable, >> and there are more standardized vector graphics formats around these >> days. The reason behind these choices is mostly historical. When I >> developed this format circa 1984, there wasn't much else around other >> than the plot package, which wasn't very capable and wasn't portable >> across architectures. At the time, I was relying on CP/M as well as >> Unix, and dot matrix printers for most of my output, so I rolled my >> own solution. >> If you have a good, cross-platform alternative that wouldn't require >> much work or additional dependencies, we could certainly look into >> replacing this, but I've found it difficult to come up with something >> easier than just maintaining what we have. >> Cheers, >> -Greg >>> From: Georg Mischler <[email protected]> >>> Subject: [Radiance-dev] Meta files and library >>> Date: May 10, 2016 1:02:07 AM PDT >>> Hi, >>> our volunteer Sarith Subramaniam is currently working on objline.py. >>> When trying to test it, he noticed that the NREL releases do not include >>> the supporting meta files in lib/meta. Since they do include the >>> executables that require those files, that seems slightly suboptimal... >>> But it shouldn't be hard to fix. Just copy over "ray/lib/meta/*.mta". >>> I've found a previous mention of the topic here: >>> http://radiance-online.org/pipermail/radiance-general/2015-October/011273.html >>> Some unsorted thoughts on the topic of meta files in general, given that >>> due to the availability of objline.csh/py, and some newer tutorials, they >>> will inevitably get more attention in times to come: >>> A few messages down the above thread, Greg mentions the undocumented(!) >>> envvar "MLIB". The first thing running through my mind seeing this was: >>> "This must be the worst possible name for an environment variable, ever" >>> (way to generic). >>> I also never quite understood the point of inventing yet another >>> proprietary vector format just for Radiance. Or are such meta files used >>> anywhere else that I'm not aware of? >>> They do not seem to be the same as the ISO standardized "Computer Graphics >>> Meta Files" (http://www.fileformat.info/format/cgm/egff.htm), which would >>> be a possible candidate for something like that. >>> Another possible approach would be SVG (or a suitable subset thereof), >>> which has excellent support libaries available nowadays. >>> Of course, I haven't looked into how much work it would be to use either >>> of those (or yet something else), so this basically just amounts to me >>> ranting at the moment without any real purpose. But I'm still just curious >>> what the motivation behind this format was (or which format it actually >>> is), and what other people are thinking about possible alternatives. >>> Cheers >>> -schorsch _______________________________________________ Radiance-dev mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/radiance-dev
