Hi Thorsten,
Thorsten Behrens schrieb:
Kai Ahrens wrote:
Taking a look at both existing 'extensions', I don't consider
them as a final solution for the problem. As Thorsten already
mentioned, they don't touch the internals of OOo, which is
good on the one hand but doesn't allow us to get a really
well designed, tight integration into OOo on the other hand,
which seems to be needed if it should be a 'real' replacement
of our current internal vector graphic representation.
Hi Kai, all,
right, in general - so, the existing solution for importing svg as
an image (like e.g. you can insert png or wmf graphics) is limited
by the capabilities of the StarView metafile format, so everything
that needs to get us better svg image fidelity needs to either
enhance svm, circumvent it, or replace it entirely as the way vector
graphics are transported inside OOo.
Replacing SVM entirely would be my choice #1, although this will
require quite a _lot_ of effort. Maybe an intermediate solution
would be to still use the GDIMetaFile internally for transportation
reasons, but switch to SVG use when it comes to external usage.
E..g seomething like 'GDIMetaFile::is/getSVG()' ...
It's basically the same story for the document import, only that, in
order to improve on this, we'd not only need to enhance the
applications cores, but also the ODF file format (something I'd be
very interested in; ideally svg would be fully embeddable inside
ODF).
Sure, this is what I meant with external usage. Their would
only be the SVG or original file format used inside ODF, which
of course requires stable SVG import, export and display possibilities.
I talked with several people inside the Sun-OOo group and
as a result of these discussions, I finally put this on top
of my ToDo list, which means that I will come up with a proposal
and even a first prototype for evaluation purposes very soon.
Please read 'Soon' as a time span of a few weeks and _not_ years.
As soon as I'll have a proposal/prototype ready, I'll come back
to you and will announce it on the appropriate lists/blog for
further discussions.
It would be helpful to have this discussion, _before_ embarking on an
implementation, on the public mailing lists; I'm convinced there are
a lot of people that are interested in this topic.
As said, I will not come up with a complete implementation, but with
a proposal and maybe a first prototype instead. So, there will be enough
time for discussions, but for the beginning, I'd like to think of a
concept at all before going public.
At the moment, I'm very optimistic to get it into the next major
release, which will be OOo 3.3.
So, do I get this right, you're suggesting not to offer a bug
bounty, but instead have this implemented internally at Sun?
No, that'll be not the case. At the moment, I think of a combined
effort, meaning to agree on a concept in the first run and
to do some basics initially on the Sun/... side. Further efforts could
then be combined with a bug bounty program. As you do know very well,
there are quite a lot of things to consider for replacing the
GDIMetaFile at whole and I doubt that there are more than a handful of
people (including you) at the moment, knowing all possible pitfalls.
With best regards
Kai
F'up on [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
