5:24 p.m.
Hello Bruno,
Having been in China for quite a while I understand the situation you're
in using low bandwidth.
It would be way cool to have external style sheet support in Inkscape and
something that has been on my wish list for quite a while, so please
continue. Even if it's ugly coding and creates a performance hit when
loading Inkscape, I think it would be worthwhile to have it. Maybe using a
switch in the prefs to turn it on or off, for performance improvement.
Added to that is another question.
How feasible would it be to use the external style sheet support code
you're currently making to do the same for external <USE
xlink:href="file.svg#objectID"/> ? I have the idea that it would be pretty
similar in scope, reading data from file and changing style attributes for
CSS and reading and adding SVG code to the SVG code in memory (leaving the
file code alone).
If it isn't too much work, could you experiment with it a little to see
how feasible it is? It would kill two BIG flies in one go if it would work
and greatly increase the productivity of Inkscape as an authoring tool.
You'd certainly be one of my hero's if you can make this work in Inkscape.
I can also imagine Tav's Symbol tool to increase usability by using
external links to symbol files rather than embedding them into the code
like it currently does, but that would be food for 0.92 I guess.
Last but not least would be an option to save all linked content into a
single whopper of a file and an option to export all style info and <use>
objects to external files. Hmm,.. you cannot prevent me from dreaming now
can you?
Cheers,
Jelle Mulder
10:21 p.m.
New subject: External CSS support {Spam?}
Ni Hao Jelle,
I'm open for more ideas once I've been able to push me first contribution.
The USE element don't ring any bell for me. Any pointer ?
I'll have to read again your idea when I'm done with this.
My original requirement of external stylesheet was to allow to visualize and work on svg
files under different configurations.
As I say that I realize I don't know if Inkscape allows css media queries.
As far as performance is concerned my change has little impact. I'm just creating a
SPStyleElem before the root from the PI and apply it before. If there is no style in PI
nothing is changed. As mentioned in some comments in the code 2 traversals would be
desirable to be sure all styles fragments are available before the display traversal or as
some browsers are doing is to restart the traversal whenever styles are affecting the
traversal.
I need to refresh my knowledge on svg.
-Bruno
Bruno Winck
Email: bwinck@...2632...
Blog: http://www.kneaver.com/blog
Kneaver Corp http://www.kneaver.com/
Twitter:http://twitter.com/kneaver
PH: +(415) 335-6932
-----Original Message-----
From: Jelle Mulder [mailto:pjmulder@...353...]
Sent: Monday, January 13, 2014 1:55 PM
To: inkscape-devel(a)lists.sourceforge.net
Subject: [Inkscape-devel] External CSS support
Hello Bruno,
Having been in China for quite a while I understand the situation you're
in using low bandwidth.
It would be way cool to have external style sheet support in Inkscape and
something that has been on my wish list for quite a while, so please
continue. Even if it's ugly coding and creates a performance hit when
loading Inkscape, I think it would be worthwhile to have it. Maybe using a
switch in the prefs to turn it on or off, for performance improvement.
Added to that is another question.
How feasible would it be to use the external style sheet support code
you're currently making to do the same for external <USE
xlink:href="file.svg#objectID"/> ? I have the idea that it would be pretty
similar in scope, reading data from file and changing style attributes for
CSS and reading and adding SVG code to the SVG code in memory (leaving the
file code alone).
If it isn't too much work, could you experiment with it a little to see
how feasible it is? It would kill two BIG flies in one go if it would work
and greatly increase the productivity of Inkscape as an authoring tool.
You'd certainly be one of my hero's if you can make this work in Inkscape.
I can also imagine Tav's Symbol tool to increase usability by using
external links to symbol files rather than embedding them into the code
like it currently does, but that would be food for 0.92 I guess.
Last but not least would be an option to save all linked content into a
single whopper of a file and an option to export all style info and <use>
objects to external files. Hmm,.. you cannot prevent me from dreaming now
can you?
Cheers,
Jelle Mulder
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg...
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
1:53 a.m.
New subject: External CSS support {Spam?}
On Mon, 2014-01-13 at 18:51 +0530, Bruno Winck, Kneaver wrote:
As far as performance is concerned my change has little impact.
I'm
just creating a SPStyleElem before the root from the PI and apply it
before. If there is no style in PI nothing is changed. As mentioned in
some comments in the code 2 traversals would be desirable to be sure
all styles fragments are available before the display traversal or as
some browsers are doing is to restart the traversal whenever styles
are affecting the traversal.
There is one other bug that we need to be concerned with:
https://bugs.launchpad.net/inkscape/+bug/167937
This means that styles applied from an external css would be applied
into the element's style when we save the svg. Which would reduce the
usefulness of it.
Best Regards, Martin Owens
11:59 a.m.
New subject: External CSS support {Spam?}
True but this bug is a totally different beast.
Simply add a flag to styles to differentiate those that need to be persistent and others.
Or better maintain two lists : styles defined on the element and styles computed.
Because there is a question of priority with styles. Styles corresponding to largest class
matching will have the highest priority. Inline styles having the upmost priority. So
styles defined are copied to styles computed _after_ all rules applied.
I'm kind of surprised that libcroco don't support all that.
-Bruno
Bruno Winck
Email: bwinck@...2632...
Blog: http://www.kneaver.com/blog
Kneaver Corp http://www.kneaver.com/
Twitter:http://twitter.com/kneaver
PH: +(415) 335-6932
-----Original Message-----
From: Martin Owens [mailto:doctormo@...400...]
Sent: Monday, January 13, 2014 10:24 PM
To: Bruno Winck, Kneaver
Cc: 'Jelle Mulder'; inkscape-devel(a)lists.sourceforge.net
Subject: Re: [Inkscape-devel] External CSS support {Spam?}
On Mon, 2014-01-13 at 18:51 +0530, Bruno Winck, Kneaver wrote:
As far as performance is concerned my change has little impact.
I'm
just creating a SPStyleElem before the root from the PI and apply it
before. If there is no style in PI nothing is changed. As mentioned in
some comments in the code 2 traversals would be desirable to be sure
all styles fragments are available before the display traversal or as
some browsers are doing is to restart the traversal whenever styles
are affecting the traversal.
There is one other bug that we need to be concerned with:
https://bugs.launchpad.net/inkscape/+bug/167937
This means that styles applied from an external css would be applied into the
element's style when we save the svg. Which would reduce the usefulness of it.
Best Regards, Martin Owens
2:28 p.m.
New subject: Build on Windows {Spam?}
Hi All,
I was happy when I started that the project was building flawlessly.
Alas I made the error to do a "bzr update" before start working.
After waiting 2 hours until the whole project recompile due to a change in
src/2geom/affine.h
After fixing my own compilation errors
I'm now spending trying to understand why it's looking for an absent
"src/2geom/svg-path.cpp" (there is such a file in svg sub directory)
Did multiple "bzr update" hoping it would fix it
Eventually I created an empty "svg-path.cpp" (you never know if it was just
dropped replacing by empty one would do the trick).
I got the undefined below
So now I'm stucked.
PS: You can split a large project into dlls and like this save a _lot_ of the time of the
contributors.
" F:\Libs\devlibs/bin/libxml2.dll F:\Libs\devlibs/bin/libxslt.dll
Make error line 437: LINK problem:
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20b
ack_insert_iteratorISt6vectorINS_4PathESaIS3_EEEED1Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std
::allocator<Geom::Path> > > >::~PathIteratorSink()]+0x2e): undefined
reference to `vtable for Geom::PathSink'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P
athESaIS3_EEEED1Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >::~Pat
hIteratorSink()]+0x5d): undefined reference to `vtable for Geom::PathSink'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P
athESaIS3_EEEED0Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >::~Pat
hIteratorSink()]+0x2e): undefined reference to `vtable for Geom::PathSink'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P
athESaIS3_EEEED0Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >::~Pat
hIteratorSink()]+0x61): undefined reference to `vtable for Geom::PathSink'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P
athESaIS3_EEEED2Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >::~Pat
hIteratorSink()]+0x2e): undefined reference to `vtable for Geom::PathSink'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P
athESaIS3_EEEED2Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >::~Pat
hIteratorSink()]+0x5d): more undefined references to `vtable for Geom::PathSink'
follow
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.rdata$_ZTVN4Geom11PathBuilderE[vtable
for Geom::PathBuilder]+0x34): unde
fined reference to `Geom::PathSink::pathvector(std::vector<Geom::Path,
std::allocator<Geom::Path> > const&)'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.rdata$_ZTVN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS
_4PathESaIS3_EEEEE[vtable for
Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path>
> >]+0x34): undefined reference to
`Geom::PathSink::pathvector(std::vector<Geom::Path, std::allocator<Geom::Path>
> const&)'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0xc97):
undefined reference to `vtable for Geom::PathSink'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0xd05): undefined
reference to `vtable for Geom::PathSink'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0x1066): undefined
reference to `vtable for Geom::PathSink
'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0x12fb): undefined
reference to `vtable for Geom::PathSink
'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0x1369): undefined
reference to `vtable for Geom::PathSink
'
build\obj\sp-ellipse.o:sp-ellipse.cpp:(.text+0x2aa7): more undefined references to `vtable
for Geom::PathSink' follow
collect2: ld returned 1 exit status
"
Bruno Winck
Email: bwinck@...2632...
Blog: http://www.kneaver.com/blog
Kneaver Corp http://www.kneaver.com/
Twitter:http://twitter.com/kneaver
PH: +(415) 335-6932
-----Original Message-----
From: Bruno Winck, Kneaver [mailto:bw@...2632...]
Sent: Tuesday, January 14, 2014 8:29 AM
To: Martin Owens
Cc: 'Jelle Mulder'; inkscape-devel(a)lists.sourceforge.net
Subject: RE: [Inkscape-devel] External CSS support {Spam?}
True but this bug is a totally different beast.
Simply add a flag to styles to differentiate those that need to be persistent and others.
Or better maintain two lists : styles defined on the element and styles computed.
Because there is a question of priority with styles. Styles corresponding to largest class
matching will have the highest priority. Inline styles having the upmost priority. So
styles defined are copied to styles computed _after_ all rules applied.
I'm kind of surprised that libcroco don't support all that.
-Bruno
Bruno Winck
Email: bwinck@...2632...
Blog: http://www.kneaver.com/blog
Kneaver Corp http://www.kneaver.com/
Twitter:http://twitter.com/kneaver
PH: +(415) 335-6932
-----Original Message-----
From: Martin Owens [mailto:doctormo@...400...]
Sent: Monday, January 13, 2014 10:24 PM
To: Bruno Winck, Kneaver
Cc: 'Jelle Mulder'; inkscape-devel(a)lists.sourceforge.net
Subject: Re: [Inkscape-devel] External CSS support {Spam?}
On Mon, 2014-01-13 at 18:51 +0530, Bruno Winck, Kneaver wrote:
As far as performance is concerned my change has little impact.
I'm
just creating a SPStyleElem before the root from the PI and apply it
before. If there is no style in PI nothing is changed. As mentioned in
some comments in the code 2 traversals would be desirable to be sure
all styles fragments are available before the display traversal or as
some browsers are doing is to restart the traversal whenever styles
are affecting the traversal.
There is one other bug that we need to be concerned with:
https://bugs.launchpad.net/inkscape/+bug/167937
This means that styles applied from an external css would be applied into the
element's style when we save the svg. Which would reduce the usefulness of it.
Best Regards, Martin Owens
7:35 p.m.
New subject: Build on Windows {Spam?}
Hi Bruno,
I'm sorry for your recompile waiting times, but it's unavoidable pain I'm
afraid.
To fix your problem, you probably just need to rebuild the dependency graph (btool.dep),
so do a
del *.dep
btool -j
and then it should work.
About the compile time: 2 hours is *really* long. What PC are you working on? Does your
processor have multiple cores? If so, you can compile with multiple threads: compile
buildtool.cpp with -fopenmp and run btool with the "-j" option.
For reference, for me a clean build takes about 5 minutes (core-i7, max threads).
regards,
Johan
---- "Bruno Winck wrote:
Hi All,
I was happy when I started that the project was building flawlessly.
Alas I made the error to do a "bzr update" before start working.
After waiting 2 hours until the whole project recompile due to a change in
src/2geom/affine.h
After fixing my own compilation errors
I'm now spending trying to understand why it's looking for an absent
"src/2geom/svg-path.cpp" (there is such a file in svg sub directory)
Did multiple "bzr update" hoping it would fix it
Eventually I created an empty "svg-path.cpp" (you never know if it was just
dropped replacing by empty one would do the trick).
I got the undefined below
So now I'm stucked.
PS: You can split a large project into dlls and like this save a _lot_ of the time of the
contributors.
" F:\Libs\devlibs/bin/libxml2.dll F:\Libs\devlibs/bin/libxslt.dll
Make error line 437: LINK problem:
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20b
ack_insert_iteratorISt6vectorINS_4PathESaIS3_EEEED1Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std
::allocator<Geom::Path> > > >::~PathIteratorSink()]+0x2e): undefined
reference to `vtable for Geom::PathSink'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P
athESaIS3_EEEED1Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >::~Pat
hIteratorSink()]+0x5d): undefined reference to `vtable for Geom::PathSink'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P
athESaIS3_EEEED0Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >::~Pat
hIteratorSink()]+0x2e): undefined reference to `vtable for Geom::PathSink'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P
athESaIS3_EEEED0Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >::~Pat
hIteratorSink()]+0x61): undefined reference to `vtable for Geom::PathSink'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P
athESaIS3_EEEED2Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >::~Pat
hIteratorSink()]+0x2e): undefined reference to `vtable for Geom::PathSink'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P
athESaIS3_EEEED2Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >::~Pat
hIteratorSink()]+0x5d): more undefined references to `vtable for Geom::PathSink'
follow
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.rdata$_ZTVN4Geom11PathBuilderE[vtable
for Geom::PathBuilder]+0x34): unde
fined reference to `Geom::PathSink::pathvector(std::vector<Geom::Path,
std::allocator<Geom::Path> > const&)'
build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.rdata$_ZTVN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS
_4PathESaIS3_EEEEE[vtable for
Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path>
> > >]+0x34): undefined reference to
`Geom::PathSink::pathvector(std::vector<Geom::Path, std::allocator<Geom::Path>
> const&)'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0xc97): undefined
reference to `vtable for Geom::PathSink'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0xd05): undefined
reference to `vtable for Geom::PathSink'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0x1066):
undefined reference to `vtable for Geom::PathSink
'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0x12fb):
undefined reference to `vtable for Geom::PathSink
'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0x1369):
undefined reference to `vtable for Geom::PathSink
'
build\obj\sp-ellipse.o:sp-ellipse.cpp:(.text+0x2aa7): more undefined references to
`vtable for Geom::PathSink' follow
collect2: ld returned 1 exit status
"
Bruno Winck
Email: bwinck@...2632...
Blog: http://www.kneaver.com/blog
Kneaver Corp http://www.kneaver.com/
Twitter:http://twitter.com/kneaver
PH: +(415) 335-6932
-----Original Message-----
From: Bruno Winck, Kneaver [mailto:bw@...2632...]
Sent: Tuesday, January 14, 2014 8:29 AM
To: Martin Owens
Cc: 'Jelle Mulder'; inkscape-devel(a)lists.sourceforge.net
Subject: RE: [Inkscape-devel] External CSS support {Spam?}
True but this bug is a totally different beast.
Simply add a flag to styles to differentiate those that need to be persistent and
others.
Or better maintain two lists : styles defined on the element and styles computed.
Because there is a question of priority with styles. Styles corresponding to largest
class matching will have the highest priority. Inline styles having the upmost priority.
So styles defined are copied to styles computed _after_ all rules applied.
I'm kind of surprised that libcroco don't support all that.
-Bruno
Bruno Winck
Email: bwinck@...2632...
Blog: http://www.kneaver.com/blog
Kneaver Corp http://www.kneaver.com/
Twitter:http://twitter.com/kneaver
PH: +(415) 335-6932
-----Original Message-----
From: Martin Owens [mailto:doctormo@...400...]
Sent: Monday, January 13, 2014 10:24 PM
To: Bruno Winck, Kneaver
Cc: 'Jelle Mulder'; inkscape-devel(a)lists.sourceforge.net
Subject: Re: [Inkscape-devel] External CSS support {Spam?}
On Mon, 2014-01-13 at 18:51 +0530, Bruno Winck, Kneaver wrote:
> As far as performance is concerned my change has little impact. I'm
> just creating a SPStyleElem before the root from the PI and apply it
> before. If there is no style in PI nothing is changed. As mentioned in
> some comments in the code 2 traversals would be desirable to be sure
> all styles fragments are available before the display traversal or as
> some browsers are doing is to restart the traversal whenever styles
> are affecting the traversal.
There is one other bug that we need to be concerned with:
https://bugs.launchpad.net/inkscape/+bug/167937
This means that styles applied from an external css would be applied into the
element's style when we save the svg. Which would reduce the usefulness of it.
Best Regards, Martin Owens
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg...
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
3357
days inactive
3358
days old
inkscape-devel@lists.inkscape.org
5 comments
4 participants
participants (4)
-
unknown＠example.com -
Bruno Winck, Kneaver -
Jelle Mulder -
Martin Owens