2014-02-13 15:01 GMT+01:00 Tavmjong Bah <tavmjong@...8...>:
On Thu, 2014-02-13 at 14:41 +0100, Krzysztof Kosiński wrote:
2014-02-13 4:10 GMT+01:00 Martin Owens <doctormo@...400...>:
On Thu, 2014-02-13 at 00:03 +0100, Krzysztof Kosiński wrote:
This would require some rewriting in the LaTeX and EMF renderers. On the other hand, adding new output formats would become much much
If we were to go ideal, would we not hack every export but Inkscape SVG out of inkscape proper and force them into extensions? That would at least give plenty of impetus to have a decent extensions system that could interact with the inkscape codebase fundamentally.
Moving the exporters to extensions does not conflict with introducing the visitor pattern, in fact it makes doing that a lot simpler.
I've looked up the visitor pattern and wrote a little toy program using the pattern but I am having a little trouble seeing how it would work with the SPxxx structure? Could you elaborate a little bit?
- There would be a class called e.g. SPTreeVisitor, with an accept method for each of the SP tree node types. The default implementation would be to simply call the accept method for the supertype with the same parameter.
- SP tree nodes would expose a "visit" method taking SPTreeVisitor as a parameter, which would simply call the relevant accept method on the visitor.
- The exporters and the offline Cairo renderer (used for PDF and PS export) would derive from SPTreeVisitor, possibly via an intermediate base class which would provide default implementation of the accept methods in terms of simpler primitives (e.g. translating a spiral to a path).
Regards, Krzysztof