Am Montag, den 21.01.2008, 18:03 +0100 schrieb Ulrich von Zadow:
> Frederik Elwert wrote:
> > As a side note, when looking into AVG, I was sometimes wondering why you
> > didn't stick more to SVG's concepts and design AVG as a subset of SVG
> > with necessary extensions (like camera support). But that's more of a
> > debate of principles that doesn't belong to the topic at hand...
>
> Well, there are some design differences: avg is made to be
> human-readable and -writeable to a greater extent than svg is, so for
> instance something like the matrix() attribute you describe would be out
> of the question. Also, I confess to not knowing enough about the svg
> standard to always make sure things were similar.
Yes, SVG has some glitches regarding simplicity. The matrix() thing
definitely isn't made for hand-writing. But you don't have to use it,
you can achieve it all by using the more verbose commands.
So one could either decide that libavg supports something linke matrix()
for files that aren't handcrafted, or one would need the filter to
translate the matrix into something that libavg understands. I don't
know about libavg's internals, but with more complex transformations,
I'd think that libavg has to work with a transformation matrix
internally, anyway, so I'd guess it would be only a question of what to
expose in the XML part?
> I'm open to discussing syntactical and semantic improvements, though. We
> only need to make sure that we break backwards compatibility in the
> least intrusive manner possible. That probably means changing things
> only once, having clear improvements and doing the change at an
> appropriate time.
Ok, I'll take a minute and think about that. I think that most things
AVG supports can be expressed using pure SVG Tiny 1.2. Some nearly
identical like images, or opacity in general:
AVG:
<image x="50" y="50" width="100" height="80" href="image.png"/>
SVG:
<image x="50" y="50" width="100" height="80" xlink:href="image.png"/>
some with a different syntax, like group transformations:
AVG:
<div x="10" y="10"><image href="image.png/></div>
SVG:
<g transform="translate(10,10)"><image xlink:href="image.png"/></g>
but, some have quite differenc concepts, like text layout. Now that I
have understood how AVG deals with text (thanks for the hints!), I see
that this is quite different to how this is handled in SVG:
AVG creates an invisible rect of width "parawidth" with its upper left
corner at "x,y" and renders the text into this rect with variable
height:
<words x="10" y="10" parawidth="50">Text goes here and continues
here</words>
x,y|<- parawidth ->|
+---------------+
|Text goes here |
|and continues |
|here
The alignment controls the alignment inside the box, not the
positioning:
alignment="center"
x,y|<- parawidth ->|
+---------------+
|Text goes here |
| and continues |
| here |
SVG text traditionally defines an anchor at "x,y" that corresponds to
the text baseline and positions the text according to the "alignment":
<text x="10" y="10">Text goes here</text>
text-anchor="left"
.Text goes here
x,y
text-anchor="middle"
Text go.es here
x,y
But luckily, SVG-T 1.2 has something similar to AVG - the textArea
element:
<textArea x="10" y="10" width="50" height="100">Text goes here and
continues here</textArea>
I don't know if the height attribute is necessary, and I can't test,
since I don't know of any implementation so far. And this is somewhat
the other side of the medal: SVG Full 1.2 provides a far more
sophisticated model for flowed text that is beyond the scope of AVG, as
I'd think. This is currently used in Inkscape for flowed text:
<flowRoot>
<flowRegion>
<rect x="10" x="10" width="50" height="100"/>
</flowRegion>
<flowPara>Text goes here and continues here</flowPara>
</flowRoot>
I didn't implement this in the filter, yet. But for the simple use case
of text flowing in a rect (it can flow in any shape), it might be worth
the work as it matches AVG's model much better than the pure <text>
thing.
This just as a quick (hm, not really, I suspect... ;-)) overview about
some of the similarities and differences between AVG and SVG. When I
find the time, I might make a more detailed comparison, if anyone's
interested. I'm open for discussions about making AVG more compatible
with SVG, maybe at least for future extensions of AVG's feature set.
Personally, I think it would even be possible to make AVG a compatible
implementation of a subset of SVG-T. But I can totally understand if no
one really wants to work on that... ;-)
> > Video is now supported by SVG 1.2, which is great. But I think it will
> > need some time until Inkscape supports it as well. So for the time being
> > I thought of a somewhat hackish approach: One could use a rect as a
> > placeholder for videos in the SVG file, and make use of inkscape:label
> > to specify something like "video://path/to/file" or "camera://source".
> > The filter would then translate them into video or camera elements.
>
> Sounds like an appropriate solution.
Ok, I'll see when I find the time to do that.
> > By the way, does anyone have any comments regarding my initial issue,
> > the cropped text? Can anyone confirm it, or am I the only one?
>
> I wrote a response (Jan. 20, 4:40 am) - have a look at the list archives
> if you didn't get it.
Sorry, my email provider's junk filter caught that, I should check that
more often... :-(
So thanks for your help, and I'm looking forward to interesting projects
with AVG!
Cheers,
Frederik
--
Frederik Elwert
JabberID [EMAIL PROTECTED]
_______________________________________________
libavg-users mailing list
[email protected]
https://mail.datenhain.de/mailman/listinfo/libavg-users
