On Aug 11, 2009, at 3:14 PM, Sergiu Dumitriu wrote:
Answering the questions:
Sergiu Dumitriu wrote:
Q: Should I leave just PNG as the output format?
It seems that keeping JPG and GIF is still needed. Now, I'm thinking
that my initial approach (making this a per image option) is not good,
and instead it should be a per user/global option. It is more likely
that one user would want to see all images in the .gif format than an
author wanting to create an image in the .gif format for everybody
else.
Q: Is the default DPI setting OK?
Nobody commented on this, so I'm going to assume it's OK.
Q: Does anybody know of any security issues with
running latex,
dvips or
convert? Especially with the \openin and \openout commands?
This question still needs some answers.
Q: Is the macro name appropriate? Do you know of
a better one?
Point taken: formula is better than equation. Actually, initially it
was
named "formula", but I didn't like it that much. Anyway, the community
has spoken.
Point not taken: rendering is the right name IMO. Before xwiki-
rendering
as a syntax converter, rendering has a widely accepted sense as
generating raster graphics. From Wikipedia: "Rendering is the
process of
generating an image from a model, by means of computer programs". This
is what the module does, and the fact that we have another thing
called
"rendering" doesn't mean that we must invent new names for something
standard.
I'd agree to use rendering but *only* if:
* It's integrated inside the xwiki-rendering module
* It's implemented as a XWiki Parser and Renderer (and thus we
introduce a syntax for it)
I think it could fit well in the xwiki-rendering module. We'll need to
adjust a few things (since it would be the first renderer to generate
binary data) but that's a good thing.
WDYT?
Thanks
-Vincent
Plotting is different, it involves vectorial graphics,
and I tend to
associate it with Logo and its turtle. Displayer is different, it
means
actually presenting the image to the user. LCDs display, papers
display,
but this module is just creating raster images in memory.
Future work:
- make sure that there are no security issues with the Native backend
- add support for MathML display for the clients that understand it
- improve the alignment of images (especially for the Native
backend),
as right now they are a bit raised above the text baseline
Add: making it work with PDFs and other exports.