Menu
▾
▴
lib2geom-devel
|
From: Vinícius d. S. O. <vin...@gm...> - 2013-08-13 06:06:19
Attachments:
signature.asc
|
Hi 2geom developers, I'm playing with 2geom and I can see which code I can use to read from SVG files. I can use the function Geom::parse_svg_path and pass a Geom::PathBuiler as the second parameter. In the end, I'll be able to extract the Geom::PathVector through the method PathBuilder::peek. Anyway, what I need is to do the other way back (generate a SVG file from some Geom::PathVector). The only code I found related to this functionality lies in the toys (not part of the lib) and uses a complicated scheme involving cairo and a lot of virtual func calls. Is there another way? If there is not, I want to implement it and I want to implement it fast. Would be possible to release another lib2geom version fast if code goes okay? -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker |
|
From: Nathan H. <nj...@nj...> - 2013-08-13 13:54:11
|
On Tue, Aug 13, 2013 at 03:05:59AM -0300, Vin?cius dos Santos Oliveira wrote: > Hi 2geom developers, > > I'm playing with 2geom and I can see which code I can use to read from > SVG files. I can use the function Geom::parse_svg_path and pass a > Geom::PathBuiler as the second parameter. In the end, I'll be able to > extract the Geom::PathVector through the method PathBuilder::peek. > > Anyway, what I need is to do the other way back (generate a SVG file > from some Geom::PathVector). The only code I found related to this > functionality lies in the toys (not part of the lib) and uses a > complicated scheme involving cairo and a lot of virtual func calls. Is > there another way? If there is not, I want to implement it and I want to > implement it fast. I think you should be able to write something using direct string concatenation in an afternoon. > Would be possible to release another lib2geom version > fast if code goes okay? Absolutely, indeed I think we should just give your write access to the repo (given you're already an inkscape dev). Who remembers how to do this? njh |
|
From: Vinícius d. S. O. <vin...@gm...> - 2013-08-14 00:23:33
Attachments:
signature.asc
|
Em Ter, 2013-08-13 às 23:13 +1000, Nathan Hurst escreveu: > I think you should be able to write something using direct string > concatenation in an afternoon. I already started coding, but I want to share design ideas sooner. There will be a function, called render_svg_path (declared under svg-path-render.h file), analogous to parse_svg_path. This function will receive an ostream object and a PathVector. I still didn't reasoned enough to conclude if this should be an operator overload or a normal function, but I think it should be a normal function to maintain consistency. parse_svg_path only treats the "d" attribute, so should render_svg_path (this english sentence I don't know if it's correct, I'm trying to use the same grammar technique from Donnie Darko movie: <https://gist.github.com/vinipsmaker/6226845#file-donnie-darko-part-L11>). My tests ran fine and I don't think I'll have much trouble, but lib2geom needs some love as a "standalone" installed library. When I tried to compile-and-link my tests to a system-installed-dynamic-lib 2geom, there where some include files errors due to missing installed files (numeric folder). I fixed this error locally, but I'll share the results soon. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker |
|
From: Nathan H. <nj...@nj...> - 2013-08-14 14:19:04
|
On Tue, Aug 13, 2013 at 09:23:14PM -0300, Vin?cius dos Santos Oliveira wrote: > Em Ter, 2013-08-13 ??s 23:13 +1000, Nathan Hurst escreveu: > > > I think you should be able to write something using direct string > > concatenation in an afternoon. > > > I already started coding, but I want to share design ideas sooner. > > There will be a function, called render_svg_path (declared under > svg-path-render.h file), analogous to parse_svg_path. This function will > receive an ostream object and a PathVector. I still didn't reasoned > enough to conclude if this should be an operator overload or a normal > function, but I think it should be a normal function to maintain > consistency. This all sounds great. > parse_svg_path only treats the "d" attribute, so should render_svg_path This sentence is correct (if you add the . at the end :) > (this english sentence I don't know if it's correct, I'm trying to use > the same grammar technique from Donnie Darko movie: > <https://gist.github.com/vinipsmaker/6226845#file-donnie-darko-part-L11>). This sentence is incorrect (or at least a non-typical construction): normally you would put the subject at the front of the sentence. "I don't know if this sentence is correct, I'm..." > My tests ran fine and I don't think I'll have much trouble, but lib2geom > needs some love as a "standalone" installed library. Yes, it really needs a new, passionate, maintainer with the right personality and skills to refine it into the elegant and widely used library it should be. > When I tried to > compile-and-link my tests to a system-installed-dynamic-lib 2geom, there > where some include files errors due to missing installed files (numeric > folder). I fixed this error locally, but I'll share the results soon. njh |
|
From: Vinícius d. S. O. <vin...@gm...> - 2013-08-15 01:31:46
Attachments:
signature.asc
|
Em Ter, 2013-08-13 às 21:23 -0300, Vinícius dos Santos Oliveira escreveu: > My tests ran fine and I don't think I'll have much trouble, but > lib2geom needs some love as a "standalone" installed library. When I > tried to compile-and-link my tests to a system-installed-dynamic-lib > 2geom, there where some include files errors due to missing installed > files (numeric folder). I fixed this error locally, but I'll share the > results soon. This issue was already fixed in latest VCS code. Then all I need to code/share is the PathVector::toSVG() code. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker |
|
From: Vinícius d. S. O. <vin...@gm...> - 2013-08-14 05:31:46
Attachments:
signature.asc
render.patch
|
Em Ter, 2013-08-13 às 23:13 +1000, Nathan Hurst escreveu: > I think you should be able to write something using direct string > concatenation in an afternoon. I made too many mistakes and took longer than expected, but code is done now (patch attached). I'd appreciate if any "veteran" lib2geom developer review the code. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker |
|
From: Nathan H. <nj...@nj...> - 2013-08-14 14:30:14
|
On Wed, Aug 14, 2013 at 02:31:27AM -0300, Vin?cius dos Santos Oliveira wrote: > Em Ter, 2013-08-13 ??s 23:13 +1000, Nathan Hurst escreveu: > > > I think you should be able to write something using direct string > > concatenation in an afternoon. > > > I made too many mistakes and took longer than expected, but code is done > now (patch attached). > > I'd appreciate if any "veteran" lib2geom developer review the code. The code looks fine to me. Is it worth pulling the 'point to string' iterator code out into a helper method - DRY? I agree about the dynamic dispatch, if you can find a good solution to this we should use it in multiple places. Btw, I've added you to the admin team, feel free to commit all your changes. njh |
|
From: Vinícius d. S. O. <vin...@gm...> - 2013-08-14 21:14:25
Attachments:
signature.asc
|
Em Qui, 2013-08-15 às 00:31 +1000, Nathan Hurst escreveu: > The code looks fine to me. Is it worth pulling the 'point to string' > iterator code out into a helper method - DRY? By "point to string...", what part of the code are you referring to? > I agree about the dynamic dispatch, if you can find a good solution to > this we should use it in multiple places. I didn't know this pattern is used in many different places. My original plan was the suggestion in the TODO comment, but now that I know this info, I could look for some viable, "embedable" and multiplatform lib. > Btw, I've added you to the admin team, feel free to commit all your > changes. Thank you, I'll start committing the changes needed to cleanly install and use lib2geom in a modern system. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker |
|
From: Krzysztof K. <twe...@gm...> - 2013-08-15 00:11:58
|
2013/8/13 Nathan Hurst <nj...@nj...>: >> Would be possible to release another lib2geom version >> fast if code goes okay? > > Absolutely, indeed I think we should just give your write access to > the repo (given you're already an inkscape dev). Who remembers how to > do this? I can add Vinicius to the hackers team. Vinicius, please give me your Launchpad login or propose yourself as a member on this page: https://launchpad.net/~lib2geom-hackers Regards, Krzysztof |
|
From: Vinícius d. S. O. <vin...@gm...> - 2013-08-15 00:19:21
Attachments:
signature.asc
|
Em Qui, 2013-08-15 às 02:11 +0200, Krzysztof Kosiński escreveu: > I can add Vinicius to the hackers team. Vinicius, please give me your > Launchpad login or propose yourself as a member on this page: > https://launchpad.net/~lib2geom-hackers https://launchpad.net/~vinipsmaker -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker |
|
From: Krzysztof K. <twe...@gm...> - 2013-08-15 00:48:16
|
2013/8/13 Vinícius dos Santos Oliveira <vin...@gm...> > Anyway, what I need is to do the other way back (generate a SVG file from some Geom::PathVector). The only code I found related to this functionality lies in the toys (not part of the lib) and uses a complicated scheme involving cairo and a lot of virtual func calls. Is there another way? If there is not, I want to implement it and I want to implement it fast. Would be possible to release another lib2geom version fast if code goes okay? This functionality is already present in Inkscape, see src/svg/path-string.cpp. However, it would be a good idea to move it into 2Geom. Here is the optimal plan: 1. Make a method on SVGPathSink to output a PathVector into it. You can copy the relevant code with some modification from Inkscape, see src/svg/svg-path.cpp, or generalize the output_svg_path function. 2. Derive from SVGPathSink and implement SVGPathDataBuilder, a class based on the code in src/svg/path-string.cpp. Regards, Krzysztof |
|
From: Vinícius d. S. O. <vin...@gm...> - 2013-08-15 03:16:40
Attachments:
signature.asc
|
Em Qui, 2013-08-15 às 02:48 +0200, Krzysztof Kosiński escreveu:
> 2013/8/13 Vinícius dos Santos Oliveira <vin...@gm...>
> > Anyway, what I need is to do the other way back (generate a SVG file
> from some Geom::PathVector). The only code I found related to this
> functionality lies in the toys (not part of the lib) and uses a
> complicated scheme involving cairo and a lot of virtual func calls. Is
> there another way? If there is not, I want to implement it and I want
> to implement it fast. Would be possible to release another lib2geom
> version fast if code goes okay?
>
> This functionality is already present in Inkscape, see
> src/svg/path-string.cpp. However, it would be a good idea to move it
> into 2Geom. Here is the optimal plan:
Should Inkscape::SVG::PathString become a wrapper around the
Geom::PathSink... like SPCurve is a wrapper around Geom::PathVector?
> 1. Make a method on SVGPathSink to output a PathVector into it. You
> can copy the relevant code with some modification from Inkscape, see
> src/svg/svg-path.cpp, or generalize the output_svg_path function.
I'm not sure if I understood what you mean. What I understood:
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);
}
> 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.
--
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker
|
|
From: Krzysztof K. <twe...@gm...> - 2013-08-15 17:20:29
|
2013/8/15 Vinícius dos Santos Oliveira <vin...@gm...>
> Should Inkscape::SVG::PathString become a wrapper around the Geom::PathSink... like SPCurve is a wrapper around Geom::PathVector?
More or less. Ideally the only specific functionality of
Inkscape::SVG::PathString would be to read Inkscape preferences and
set the path data output parameters based on them.
> 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.)
Regards, Krzysztof
|
|
From: Vinícius d. S. O. <vin...@gm...> - 2013-08-18 23:27:26
Attachments:
signature.asc
|
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X