I am trying to develop a barebones LaTeX export extension. I have wrote the code mostly based of the PovRay export and included the .h and .cpp file in src/extension/internal/Makefile_insert. libinternal.a includes the extension but the main program does not. Can anyone help me with this?
Thank you.
-Michael Forbes
------------------------------------------------------------ Student System Operator binx.mbhs.edu BEN Manager http://ben.mbhs.edu BNC Internet Division http://bnc.mbhs.edu MBHS Webmaster http://www.mbhs.edu BlazerNet President http://blazernet.mbhs.edu Computer Team Co-President http://computerteam.mbhs.edu MBLUG President http://mblug.mbhs.edu ------------------------------------------------------------
On Tue, 2005-04-19 at 20:38 -0400, Michael Forbes wrote:
I am trying to develop a barebones LaTeX export extension. I have wrote the code mostly based of the PovRay export and included the .h and .cpp file in src/extension/internal/Makefile_insert. libinternal.a includes the extension but the main program does not. Can anyone help me with this?
I guess, what do you mean by the main program not including it? For the internal extensions their init function must be called in init.cpp -- could you not have put that call in? Are you saying that the code isn't getting linked in?
--Ted
PS - LaTeX export would be pretty cool, neat feature.
The init.cpp issue was the problem and now it works (not fully, but at least I can "Save as").
-Michael Forbes
------------------------------------------------------------ Student System Operator binx.mbhs.edu BEN Manager http://ben.mbhs.edu BNC Internet Division http://bnc.mbhs.edu MBHS Webmaster http://www.mbhs.edu BlazerNet President http://blazernet.mbhs.edu Computer Team Co-President http://computerteam.mbhs.edu MBLUG President http://mblug.mbhs.edu ------------------------------------------------------------
On Tue, 19 Apr 2005, Ted Gould wrote:
On Tue, 2005-04-19 at 20:38 -0400, Michael Forbes wrote:
I am trying to develop a barebones LaTeX export extension. I have wrote the code mostly based of the PovRay export and included the .h and .cpp file in src/extension/internal/Makefile_insert. libinternal.a includes the extension but the main program does not. Can anyone help me with this?
I guess, what do you mean by the main program not including it? For the internal extensions their init function must be called in init.cpp -- could you not have put that call in? Are you saying that the code isn't getting linked in?
--TedPS - LaTeX export would be pretty cool, neat feature.
Wow, this'll be a handy extension - how are things going with it?
Bryce
On Wed, Apr 20, 2005 at 07:54:00AM -0400, Michael Forbes wrote:
The init.cpp issue was the problem and now it works (not fully, but at least I can "Save as").
-Michael Forbes
On Tue, 19 Apr 2005, Ted Gould wrote:
On Tue, 2005-04-19 at 20:38 -0400, Michael Forbes wrote:
I am trying to develop a barebones LaTeX export extension. I have wrote the code mostly based of the PovRay export and included the .h and .cpp file in src/extension/internal/Makefile_insert. libinternal.a includes the extension but the main program does not. Can anyone help me with this?
I guess, what do you mean by the main program not including it? For the internal extensions their init function must be called in init.cpp -- could you not have put that call in? Are you saying that the code isn't getting linked in?
--TedPS - LaTeX export would be pretty cool, neat feature.
SVG uses cubic bezier curves but LaTeX only natively supports quadratic curves. PSTricks, a LaTeX add on package does support cubic curves. I was aiming to do the export in eepic macros but I think I will tackle PSTricks first. jPicEdt (http://jpicedt.sourceforge.net/) supports cubic LaTeX output by converting cubic to quadratic. This seems quite hard so I don't know if I want to tackle it (or just stay with PSTricks). I want to encourage many different macro sets since PSTricks can only be exported to PS (and from there can go to PDF). But I would prefer a straight to PDF export.
-Michael Forbes
------------------------------------------------------------ Student System Operator binx.mbhs.edu BEN Manager http://ben.mbhs.edu BNC Internet Division http://bnc.mbhs.edu MBHS Webmaster http://www.mbhs.edu BlazerNet President http://blazernet.mbhs.edu Computer Team Co-President http://computerteam.mbhs.edu MBLUG President http://mblug.mbhs.edu ------------------------------------------------------------
On Fri, 22 Apr 2005, Bryce Harrington wrote:
Wow, this'll be a handy extension - how are things going with it?
Bryce
Quoting Michael Forbes <miforbes@...734...>:
SVG uses cubic bezier curves but LaTeX only natively supports quadratic curves.
SVG supports both cubic and quadratic curves (the C and S versus the Q and T path operators). See sections 8.3.6 and 8.3.7 of the SVG 1.1 specification.
http://www.w3.org/TR/SVG/paths.html#PathDataCubicBezierCommands http://www.w3.org/TR/SVG/paths.html#PathDataQuadraticBezierCommands
Inkscape does only support cubic beziers, but it will convert quadratic beziers to cubic if it encounters them. So you can pass the LaTeX quadratic beziers upstream and let Inkscape worry about the conversion.
-mental
Inkscape does only support cubic beziers, but it will convert quadratic beziers to cubic if it encounters them. So you can pass the LaTeX quadratic beziers upstream and let Inkscape worry about the conversion.
Since LaTeX only does quadratic is it possible for Inkscape to convert from cubic to quadratic since I am working on export?
-Michael Forbes
Quoting Michael Forbes <miforbes@...734...>:
Since LaTeX only does quadratic is it possible for Inkscape to convert from cubic to quadratic since I am working on export?
Ohh.
Hmm. We don't currently have any code to do that, no.
Converting from quadratic to cubic is easy, as any quadratic curve is also (in a degenerate sense) a cubic curve, and you can do some simple math to convert the single control point of the quadratic bezier into the two control points points of a cubic bezier.
Going the other way is a bit harder, since most cubic curves are not directly representable as quadratic ones -- you have to subdivide the cubic curve and approximate pieces of it with quadratic sections.
You may find this link helpful:
http://www.timotheegroleau.com/Flash/articles/cubic_bezier_in_flash.htm
-mental
On Tue, May 03, 2005 at 01:17:41PM -0400, mental@...3... wrote:
Quoting Michael Forbes <miforbes@...734...>:
Since LaTeX only does quadratic is it possible for Inkscape to convert from cubic to quadratic since I am working on export?
This is an interesting mathematical problem; whatever implementation you write, there's a fair chance that someone else will redo it. Thus, to save time, I suggest you just concentrate on choosing the interface, and use a placeholder implementation, and draw people's attention (e.g. here in this thread) to where it is so others can improve it.
The interface should allow any number of quadratic segments to be returned per cubic segment, and should probably pass a strictly positive double saying how far the approximation and the cubic are allowed to differ from each other.
An example placeholder implementation to convert a cubic bezier curve with control points NR::Point const cubic[0..3] to a quadratic bezier curve with control points NR::Point quad[0..2] is:
/* Same endpoints. */ quad[0] = cubic[0]; quad[2] = cubic[3];
/* Yucky first implementation. Doesn't even maintain tangents. */ quad[1] = .5 * (cubic[1] + cubic[2]);
[Return something indicating that one quadratic segment was used.]
Commit such a function as soon as possible (and reply to this message saying where it is), and maybe someone else will already have improved it a little by the time you have the rest checked in.
pjrm.
On Fri, 6 May 2005, Peter Moulder wrote:
On Tue, May 03, 2005 at 01:17:41PM -0400, mental@...3... wrote:
Quoting Michael Forbes <miforbes@...734...>:
Since LaTeX only does quadratic is it possible for Inkscape to convert from cubic to quadratic since I am working on export?
This is an interesting mathematical problem; whatever implementation you write, there's a fair chance that someone else will redo it. Thus, to save time, I suggest you just concentrate on choosing the interface, and use a placeholder implementation, and draw people's attention (e.g. here in this thread) to where it is so others can improve it.
The interface should allow any number of quadratic segments to be returned per cubic segment, and should probably pass a strictly positive double saying how far the approximation and the cubic are allowed to differ from each other.
An example placeholder implementation to convert a cubic bezier curve with control points NR::Point const cubic[0..3] to a quadratic bezier curve with control points NR::Point quad[0..2] is:
/* Same endpoints. */ quad[0] = cubic[0]; quad[2] = cubic[3];
/* Yucky first implementation. Doesn't even maintain tangents. */ quad[1] = .5 * (cubic[1] + cubic[2]);
[Return something indicating that one quadratic segment was used.]
Commit such a function as soon as possible (and reply to this message saying where it is), and maybe someone else will already have improved it a little by the time you have the rest checked in.
pjrm.
For the moment, I am trying to get PSTricks to work. I am fairly new to Inkscape but I am fairly sure PSTricks is easier to implement considering the conversion issues for bezier curves among other things.
-Michael Forbes
For the moment, I am trying to get PSTricks to work. I am fairly new to Inkscape but I am fairly sure PSTricks is easier to implement considering the conversion issues for bezier curves among other things.
PSTricks is not surprisingly almost identical to PostScript. I think it will be possible to implement much of Inkscape using PSTricks. While I am fairly comfortable in writing PSTricks LaTeX, I am having a hard time writing the code to call the functions. It seems that since PSTricks is so similar to PostScript that using a similar interface would make sense. However, PostScript export uses a print-to-file mechanism that seems quite integrated into Inkscape. I would prefer a more encapsulated method but approaches taken by the PovRay export module seem to fail on more complex features such as arrows. Can anyone direct me on the "proper" way to do this?
-Michael Forbes
participants (5)
-
unknown＠example.com -
Bryce Harrington -
Michael Forbes -
Peter Moulder -
Ted Gould