From Peter Moulder Tue May 10 00:56:03 2005
From: Peter Moulder
To: inkscape-devel@lists.inkscape.org
Subject: [Inkscape-devel] NEW: <style> rendering support
Date: Tue, 10 May 2005 17:52:05 +1000
Message-ID: <20050510075205.GA29888@...89...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1960275495308197181=="

--===============1960275495308197181==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Inkscape now understands <style> elements: it correctly renders the
following simple document:

  <svg>
   <defs>
    <style type=3D"text/css">
      .strokeblue {stroke:blue;stroke-width:5}
      .fillred {fill:red}
    </style>
   </defs>
   <rect x=3D"10" y=3D"10" width=3D"50" height=3D"50" />
   <rect x=3D"70" y=3D"10" width=3D"50" height=3D"50" class=3D"strokeblue" />
   <rect x=3D"130" y=3D"10" width=3D"50" height=3D"50" class=3D"fillred" />
   <rect x=3D"190" y=3D"10" width=3D"50" height=3D"50" class=3D"fillred strok=
eblue" />
  </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.
>=20
> > The problem is divided into two, whether the style was included in the
> > beginning of the document or it was in an extra file.
>=20
> > 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.


--=20
bbyak: swatches, rich text, gradient on canvas...
JonCruz: The answer to the ultimate question of life, the universe, and every=
thing...
JonCruz: Inkscape 0.42!!!!!!!


--===============1960275495308197181==--


From Bob Jamison Tue May 10 07:07:16 2005
From: Bob Jamison
To: inkscape-devel@lists.inkscape.org
Subject: Re: [Inkscape-devel] NEW: <style> rendering support
Date: Tue, 10 May 2005 09:05:17 -0500
Message-ID: <4280BF9D.6040809@...357...>
In-Reply-To: <20050510075205.GA29888@...89...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6817447964753141602=="

--===============6817447964753141602==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

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




--===============6817447964753141602==--