Frederik Elwert wrote: > 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?
You're right, it's not a question of coding it - that's not very complicated. It's more a question of how much documentation a new libavg user has to sift through to understand it. Interfaces should be complete but minimal :-). > 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> I actually think the avg syntax is better here :-). divs also crop. How is that 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. Sounds good. One thing I'd like to change is to remove the cropping behaviour from the <words> node, because <div> nodes can always be used for this. Then parawidth becomes unneeded and can be replaced by width... what do people think about that? > 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. Yes, this is definitely interesting! >>> 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. Great. I assume you want publish this at some point? Where? There's room in libavg svn for the development and room in the wiki for documentation :-). Cheers, Uli -- Ulrich von Zadow | +49-172-7872715 Jabber: [EMAIL PROTECTED] Skype: uzadow _______________________________________________ libavg-users mailing list [email protected] https://mail.datenhain.de/mailman/listinfo/libavg-users
