Re: [Lib2geom-devel] Generate SVG paths from Geom::PathVector

[Vinícius d. S. O. <vin...@gm...>]

Em Qui, 2013-08-15 às 19:20 +0200, Krzysztof Kosiński escreveu:

> > class SVGPathSink {
> > public:
> >     // ...
> >
> >     // This function will read \p svgpath and make some calls to the
> virtual methods
> >     // moveTo, hlineTo, vlineTo...
> >     void read(const Geom::PathVector &svgpath);
> >
> > }
> 
> Yes, this is what I had in mind, though a better name would be
> "process" or "sink". This method should be virtual, but unlike the
> other virtual methods in this lass it should have a default
> implementation defined.
> 
> > 2. Derive from SVGPathSink and implement SVGPathDataBuilder, a class
> > based on the code in src/svg/path-string.cpp.
> >
> >
> > I'll start from this.
> >
> > The name DataBuilder is a bit generic. What do you think about
> SVGPathTextBuilder? The name clearly exposes the intent.
> 
> "Path data" is the name used for the command string in the SVG
> specification, so I would recommend sticking to that. "Path text" does
> not appear in the specification. You could also use
> "SVGPathCommandStringBuilder", but that's a little too long. One
> possible way to disambiguate is to remove the "SVG" prefix on
> SVGPathSink, because it doesn't have any SVG-specific functionality.
> (I can handle that since it involves regenerating svg-path-builder.cpp
> using Ragel.)


I agree with choices of names now, but this design is more complicated
(for the implementer, not the user) than I initially expected. I'll use
a private copy of the implementation with "poor" and not-reasoned-enough
interface in libdepixelize and continue to do my GSoC tasks. After I
finish my GSoC proposal, I'll come back to contribute to lib2geom and to
change libdepixelize svg generation "backend".


-- 
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker