NEW: <style> rendering support
Inkscape now understands <style> elements: it correctly renders the following simple document:
<svg> <defs> <style type="text/css"> .strokeblue {stroke:blue;stroke-width:5} .fillred {fill:red} </style> </defs> <rect x="10" y="10" width="50" height="50" /> <rect x="70" y="10" width="50" height="50" class="strokeblue" /> <rect x="130" y="10" width="50" height="50" class="fillred" /> <rect x="190" y="10" width="50" height="50" class="fillred strokeblue" /> </svg>
There are a number of limitations:
- Allows a single <style> element in the document. Doesn't allow external stylesheets, doesn't allow more than one <style> element. (Or rather it ignores all but one of the <style> elements, possibly changing which one it respects based on which was most recently re-read.) See notes below.
- No editing interface other than the XML editor.
(There are two parts to this: (i) editing the stylesheet; (ii) specifying what classes each object belongs to.)
- Doesn't respect media restrictions (e.g. ignores "this rule applies only to non-visual media" directives, and doesn't allow having one style for print and another style for on-screen).
- Someone more familiar with how to subclass an SPObject (i.e. what methods need to be instantiated and how) should have a look at sp-style-elem.cpp.
- Not tested much.
As members of the s4-p18, me Mamdouh El Tabech and Nicolas Jacquey, we are interested now in trying to solve the bug of global style.
The problem is divided into two, whether the style was included in the beginning of the document or it was in an extra file.
Do you have any idea to help us in where and what to change?
The limitation of just one author stylesheet per document is an oversight in libcroco datastructures. Dodji (libcroco maintainer) agrees it's a libcroco bug, and the CRCascade or CRStyleSheet data structure can be changed accordingly.
(The way most of libcroco implements `list of T' is for the T struct to get next/prev members, i.e. add next & prev members to CRStyleSheet, add cr_stylesheet_* functions for accessing this list, and leave CRCascade unchanged. Not saying I like the current scheme, but I think we should use the same scheme throughout libcroco, and consider changing the scheme throughout libcroco at once.)
Meanwhile, Inkscape will also need changing: SPStyleElem's read_content method will need to update just its own CRStyleSheet, and we'll need to make sure that the list of stylesheets in the CRCascade matches the order of their occurrence in the document, so that we get the right precedence when stylesheets conflict with each other.
I don't know the right way of handling external stylesheets. Does any other part of inkscape allow external xlink:href's ? libcroco's CRInput either already allows URLs or at least has it planned. (I don't have the source code handy here.)
Handling @media rules and <style>'s media attribute is a Simple Matter of Programming. Existing code: SPStyleElem has a media field defined in media.{cpp,h}, initialized to all media.
pjrm.
Peter Moulder wrote:
The limitation of just one author stylesheet per document is an oversight in libcroco datastructures. Dodji (libcroco maintainer) agrees it's a libcroco bug, and the CRCascade or CRStyleSheet data structure can be changed accordingly.
(The way most of libcroco implements `list of T' is for the T struct to get next/prev members, i.e. add next & prev members to CRStyleSheet, add cr_stylesheet_* functions for accessing this list, and leave CRCascade unchanged. Not saying I like the current scheme, but I think we should use the same scheme throughout libcroco, and consider changing the scheme throughout libcroco at once.)
Meanwhile, Inkscape will also need changing: SPStyleElem's read_content method will need to update just its own CRStyleSheet, and we'll need to make sure that the list of stylesheets in the CRCascade matches the order of their occurrence in the document, so that we get the right precedence when stylesheets conflict with each other.
This is odd. I would have thought that Libcroco would have come across this problem before. Inkscape, at a bare minimum, will probably need to allow 2 <style> sections: 1 for the <svg> chunk, and 1 for the surrounding document from which it will inherit style. More precisely, for an <svg> element embedded in an xhtml document.
However, this is an excellent update. It will probably be a big feature for those people exporting svg from other programs.
Bob
participants (2)
-
Bob Jamison
-
Peter Moulder