Frederik Elwert wrote: > Am Montag, den 21.01.2008, 15:57 +0100 schrieb Ulrich von Zadow: >> A short executive summary in english: >> >> Frederik is using XSLT to build a libavg export filter for inkscape >> 0.4.6. It currently supports text and images but not the rotation of >> objects or scaling of complete divs. > > Thanks for the summary. :-) > >> Yes, libavg can't scale complete divs, but since we can rotate divs and >> thus already have a local coordinate system in place, scaling should >> really be pretty easy to implement. > > That sounds good. In fact, as someone who has loosely followed the > development of SVG for some time, I'd be happy to see AVG adapt some of > the concepts of SVG. > > 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. 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. >> And... I haven't quite understood the difficulty in implementing >> rotation. Can you elaborate? Why are matrix transforms needed? > > SVG has two possibilities to express transformations: Either in "human > readable" form as "translate(20,30)", "rotate(45,50,50)", "scale(2)", or > in "machine readable" matrix form "matrix(a,b,c,d,e,f)". Inkscape uses > "translate" for simple translation transformations, but for more complex > transformations, it uses "matrix". So to really convert SVG to AVG, one > must not only take the simple forms into account, which can be easily > translated into their AVG counterparts, but also decompose a given > matrix into its components. This is what I didn't manage yet. > >> Also: How difficult would it be to support video? > > 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. > 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. 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
