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
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@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.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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@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
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 ::allocatorGeom::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::allocatorGeom::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::allocatorGeom::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::allocatorGeom::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::allocatorGeom::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::allocatorGeom::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::allocatorGeom::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::allocatorGeom::Path
]+0x34): undefined reference to `Geom::PathSink::pathvector(std::vector<Geom::Path, std::allocatorGeom::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@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@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
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 ::allocatorGeom::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::allocatorGeom::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::allocatorGeom::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::allocatorGeom::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::allocatorGeom::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::allocatorGeom::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::allocatorGeom::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::allocatorGeom::Path
]+0x34): undefined reference to `Geom::PathSink::pathvector(std::vector<Geom::Path, std::allocatorGeom::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@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@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.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (4)
-
unknown＠example.com -
Bruno Winck, Kneaver -
Jelle Mulder -
Martin Owens