So the plot files are really cal files?
Or just a very similar, but subtly incompatible variation thereof?
The documentation sometimes talks about "plot files", and sometimes
about "graph files". Are those the same?
SVG has pretty much become the standard for vector graphics on the web
(and elsewhere, such as scalable icons in Linux GUIs). All modern
browsers can render it. As an XML format it may even be embedded
directly
in the HTML of a web page. Pretty much all other relevant and up-to-date
vector graphics software understands the format. The most popular free
tool for editing seems to be Inkscape.
The format has several advanced capabilities that most people rarely
use, if at all, and would probably be irrelevant to us (eg. styling with
external css, animation with Javascript). A file containing a diagram
with some lines, fills, and text can actually be very straightforward
and simple. There are also defined subsets of the format (eg. "SVG
Tiny"),
primarily intended for mobile use.
As long as nobody complains eg. about output resolution, it's clearly
easier to keep working with meta files internally for the moment.
But then, it would still be nice if we could simplify things a bit.
Is there really still a need for pexpand? And I'm not quite sure
what psort is good for to begin with.
Since those tools are not used anywhere else, wouldn't it make sense to
ditch $MLIB, and simply use $RAYPATH/meta instead?
The documentation also mentions (usually under "see also") a number of
manpages that either never existed or have been removed: graph(1G),
plot(1), plot(5), plotout(1), primout(3), t4014(1), mx80(1), impress(1).
And last (for the moment): Looking at the manpage, it appears that
plotin(1) has a very similar if not identical purpose as bgraph(1).
What am I missing there?
Cheers
-schorsch
Am 2016-05-11 01:00, schrieb Gregory J. Ward:
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
--
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
