On Tuesday 12 June 2007 02:29, Benjamin Huot wrote: It also works with Firefox on my Linux system. -- John Culleton Able Indexing and Typesetting Precision typesetting (tm) at reasonable cost. Satisfaction guaranteed. http://wexfordpress.com

On Wed, 13 Jun 2007 08:32:51 +0300, "Nicu Buculei (OCAL)" <nicu@...143...> wrote: My understanding is that Google does not currently index SVG content, though there's no technical reason why they couldn't; it'll probably require people writing SVG websites to change their mind. -mental

MenTaLguY wrote: This is also what I suspect looking at their Webmasters Tools reports for my personal clipart site. However, this is a vicious circle: people don't write SVG websites because those are not indexed by Google and Google does not index them because they are so few. Which is a shame, as Inkscape with only a few added features could be an awesome website authoring tool (for SVG websites) and the upcoming Gecko 1.9 (Firefox 3.0) will allow users to fully enjoy those sites. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Open Clip Art Library: http://www.openclipart.org my cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ my clipart collection: http://clipart.nicubunu.ro/

Nicu Buculei (OCAL) wrote: That's an interesting experiment. One significant deficiency of the current Inkscape is evident in your webpage: if I were to use Inkscape to author a collection of webpages, I would want two more features: 1. better support for <style> blocks and external stylesheets. Putting all the styles inline is just what many people have been trying to educate HTML authors /not/ to do. Doing just that with SVG is, shall we say, less than ideal. Unfortunately, current Roadmap (http://wiki.inkscape.org/wiki/index.php/Roadmap) doesn't include improving CSS support, which suggests that the developers are not very interested in producing SVG for the Web at the moment. :( [Further discussion - http://wiki.inkscape.org/wiki/index.php/CSS_Support]] 2. support for mixed namespace XML, in particular XHTML+SVG+MathML, which is a really good way to get the best of both HTML and SVG worlds. (I have humbly to confess I've never used MathML yet!). I think Inkscape could do this by being namespace-aware and editing SVG fragments within XHTML in-place, leaving the XHTML (/MathML) untouched. Inkscape would have to pay attention to external and internal CSS settings in the XHTML namespace, as well as within the SVG namespace. I guess this is a long way off yet. However, it would be sensible for the underlying architecture to be steered so that namespace support is easy to add later. Rick -- Richard Beton BSc (Hons) Consultant Tel: +44 (0)1794 833458 Fax: +44 (0)1794 833434 richard.beton@...559... -- Roke Manor Research Ltd, Romsey, Hampshire, SO51 0ZN, United Kingdom A Siemens company Registered in England & Wales at: Siemens House, Oldbury, Bracknell Berks RG12 8FZ. Number 267550 ------------------------------------------------------------------------ Visit our website at www.roke.co.uk ------------------------------------------------------------------------ The information contained in this e-mail and any attachments is proprietary to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. ------------------------------------------------------------------------ Please consider the environment before printing this email

Hi, is it possible to set a background color (or image)? Like in html 0:-) I tried to open a simple svg in iceweasel / firefox I created with inkscape, but the background appeared white... Thanks, Florian

On Saturday, September 1, 2007, 3:13:10 AM, Haakon wrote: HME> So, how to proceed? According to the SVG specification over at the World HME> Wide Web Consortium, www.w3.org/TR/SVG/, the "svg" element itself cannot HME> have a "fill" attribute, but we can use a rectangle - the "rect"element HME> - as our background. HME> The "rect" element's upper left corner is determined from the x and y HME> attribute, and the lower right corner from the width and height HME> attributes. We probably want x and y set to zero, which will start in HME> the upper left corner of our browser's main viewport. Set width and HME> height to 100% in both the svg element and the rectangle element, and we HME> have our coloured background. By using percentages in stead of pixels we HME> make sure our background fills the main viewport regardless of the HME> current window size Yes, you can do that. In SVG 1.2 there is a viewport-fill property to do pretty much what pagecolor seems to be doing. http://www.w3.org/TR/SVGMobile12/painting.html#viewport-fill-property Notice (Example: 11_03.svg) the difference between that and a 100% rect, when the aspect ratio of the viewBox and the aspect ratio of the canvas are different. The usual hack to cover that in SVG 1.1 is to have your background rect be something like <rect x="-200%" y="-200%" width="500%" height="500%" /> which covers a modest amount of zooming out as well. -- Chris Lilley mailto:chris@...214... Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG

On Monday, September 10, 2007, 10:04:00 PM, Haakon wrote: HME> Chris Lilley wrote: HME> Thanks Chris, good to know! From the above, we know SVG allows us a HME> coloured background. Since most of us don't want to read specs when HME> drawing, how do you recommend the budding SVG web-site artist go about HME> configuring Inkscape to take advantage of this in the easiest manner HME> possible? I was more noting it for future reference - its an SVG 1.2 feature, which means that to date, only mobile phones (and Opera 9.5 alpha, i believe) support it. For now, the rectangle hacks are more dependable in deployed content. However, if Inkscape were to offer a UI to set the backhround, Inkscape could make rectangles now , and make viewport-fill later, without changing the UI (or by providing options on export). HME> There seems to be different zooming implementations in Mozilla Firefox HME> 2.x and Konqueror 3.5.x. It is fairly easy to enlarge the entire drawing HME> using Konqueror. I've used it many times to enlarge an SVG drawing, then HME> right-clicked and selected Save as PNG, which I then could use in word HME> processors or presentations which didn't support SVG. This can also more conveniently be done on a command line, using Batik. you can get the bitmap as large as you want, not limited by your screen size. HME> Mozilla Firefox HME> zooming seems to work on some elements and not on others, but maybe I'm HME> doing something wrong. Do you know more about the zooming capabilities HME> of different browsers - are there any rules for the artist? SVG says that there must be a zooming mechanism, but not how the user gets to it. For that reason, some people provide their own mechanisms (eg map thumbnail viewers, if the svg content is a map) and zoom by editing the viewBox by script. HME> Cheers, HME> Haakon -- Chris Lilley mailto:chris@...214... Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG