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
--
Georg Mischler -- simulations developer -- schorsch at schorsch
com
+schorsch.com+ -- lighting design tools --
http://www.schorsch.com/
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
