lib2geom Mac OS X build
by Laurent Zubiaur
Hi,
I managed to build lib2geom on OS X. Since it was not an easy task I
thought it might be useful to share the information with the community.
I planned to write a small tutorial and make it available soon. But first
I'd like to request some advice regarding the following issues I faced
during the build.
1. Avoid glib dependency
I wanted to link lib2geom against my application without having to link
against glib too so I replaced the following line in
src/2geom/svg-path-parser.cpp:
_push(g_ascii_strtod(buf.c_str(), NULL));
with
_push(strtod(buf.c_str(), NULL));
and removed the glib.h include.
2. Removing librt
Since librt does not exist in OS X (and is not required too) I removed the
following line in src/2geom/toys/CMakeLists.txt
TARGET_LINK_LIBRARIES(lpetoy "-lrt")
TARGET_LINK_LIBRARIES(toy-2 "-lrt")
3. Call to pow is ambiguous
Call to the pow function is ambiguous so I forced the call with casting by
replacing
pow( ..., ... )
with
pow( (double) ..., (double) …)
in the following files:
boolops-topo.cpp
intersect-data.cpp
levelsets-test.cpp
pencil-2.cpp
pencil.cpp
sb-to-bez.cpp
sketch-fitter.cpp
sweeper-toy.cpp
4. clock_gettime does not exist on OS X
In src/2geom/toys/toy-framework-2.h I replaced the following code snippet:
#ifdef WIN32
clock_gettime(clock, &ts);
ns = ts.tv_sec * NS_PER_SECOND + ts.tv_nsec / NS_PER_NS;
#else
ns = 0;
#endif
with
#ifdef __MACH__ // OS X does not have clock_gettime, use clock_get_time
clock_serv_t cclock;
mach_timespec_t mts;
host_get_clock_service(mach_host_self(), CALENDAR_CLOCK, &cclock);
clock_get_time(cclock, &mts);
mach_port_deallocate(mach_task_self(), cclock);
ts.tv_sec = mts.tv_sec;
ts.tv_nsec = mts.tv_nsec;
ns = ts.tv_sec * NS_PER_SECOND + ts.tv_nsec / NS_PER_NS;
#elif WIN32
clock_gettime(clock, &ts);
ns = ts.tv_sec * NS_PER_SECOND + ts.tv_nsec / NS_PER_NS;
#else
ns = 0;
#endif
and add the required includes at the beginning of the file.
#ifdef __MACH__
# include <mach/clock.h>
# include <mach/mach.h>
#endif
See
http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-m...
5. Cannot compile pw-toy.cpp
I was not able to compile src/2geom/toys/pw-toy.cpp so I simply disable it
in src/2geom/toys/CmakeLists.txt.
src/2geom/toys/pw-toy.cpp:48:30: error: variable length array of non-POD
element type 'Piecewise<Geom::SBasis>'
Piecewise<SBasis> pws[curves];
6. Missing return value
Added “return 0;” at the end of the function “cmpy” in uncross.cpp.
src/2geom/toys/uncross.cpp:175:5: error: control may reach end of non-void
function [-Werror,-Wreturn-type]
That's all! :)
Thanks in advance
Regards.
10 years, 1 month
Inkscape Release Report 4
by Martin Owens
Hey Devs,
This is another report on how our release items are shaping up. The past
two weeks we've got the same three blockers:
Blockers: 3
* High #1163449 Imported bitmap appear blurry when zoomed in
* Medium #953992 Imported pattern fill disappears while transforming
* Medium #1005892 Patterns applied to text objects are blurred
I don't know if 953992 is still really in progress, but we should make
sure the bug status is kept up to date. If you're working on one of
these bugs, do set the status so duplication is avoided.
We have 59 targeted bugs for the next release. That's +10 from two weeks
ago.
http://tiny.cc/q3y34w
If you can see a bug you can fix, give it a go. Any help is useful.
Status: Release Readiness
Freeze: None
Thanks for everyone's work in the past two weeks towards release.
Best Regards, Martin Owens
10 years, 1 month
plotter support
by TimeWaster
hi, nice to hear that there will be a new release soon.
i would like to add something to the release:
out of the basic hpgl export i have developed a complete plotter
solution for inkscape (yes, i know of inkcut, but it doesn't run on
windows), with it you can drive your plotter directly over the HPGL
command language and a serial connection. it has overcut, tool offset
correction and many more features.
two of my blog readers have already tested it extensively.
you can test it on my branch:
https://code.launchpad.net/~sebi-k/inkscape/HpglAndPlotter
i would like to get it into the 0.49 (or whatever it will be called)
release, and i have a couple of questions about it:
1. is it ok to merge to trunk now?
2. what wiki / release notes / other stuff do i have to bring up to date
to reflect my changes?
3. anything else i have to consider?
4. how are code review requests done here? i didnt found much about
it...
also it would be really nice if everyone with a plotter / cutting
plotter could test it!
regards,
TimeWaster
On 28.10.2013 15:22, Martin Owens wrote:
> Hey Devs,
>
> This is another report on how our release items are shaping up. The
> past
> two weeks we've got the same three blockers:
>
> Blockers: 3
> * High #1163449 Imported bitmap appear blurry when zoomed in
> * Medium #953992 Imported pattern fill disappears while transforming
> * Medium #1005892 Patterns applied to text objects are blurred
>
> I don't know if 953992 is still really in progress, but we should make
> sure the bug status is kept up to date. If you're working on one of
> these bugs, do set the status so duplication is avoided.
>
> We have 59 targeted bugs for the next release. That's +10 from two
> weeks
> ago.
>
> http://tiny.cc/q3y34w
>
> If you can see a bug you can fix, give it a go. Any help is useful.
>
> Status: Release Readiness
> Freeze: None
>
> Thanks for everyone's work in the past two weeks towards release.
>
> Best Regards, Martin Owens
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most from
> the latest Intel processors and coprocessors. See abstracts and
> register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
10 years, 1 month
Post-merge EMF work
by Krzysztof Kosiński
The cross-platform EMF/WMF support that was merged recently needs some cleanups.
1. libunicode-convert. I don't exactly see why this particular set of
functions was separated into a mini-library; I would expect that to be
part of libuemf. It is also somewhat misleadingly named. I would name
these files e.g. ms-symbol-font-utils.[hc].
2. I think libuemf should be in a separate directory, like libcola,
not tucked away in src/extension/internal.
3. The new code should be made to conform to the Inkscape coding
style. In most places it's a matter of running the code through astyle
to fix the spacing, but in some cases manual adjustments are needed.
For example, the function names in libunicode-convert are utterly
non-descriptive ('isNon()' and 'CanUTN()' are not good names for
library functions), and the return statements in
src/extension/emf-inout.cpp incorrectly use parentheses around return
values.
http://staging.inkscape.org/en/develop/coding-style/
4. Some functions, such as msdepua(), have a rather strange mode of
operation, modifying the string in place. The interface of those
should be changed so that they are easier to use.
Regards, Krzysztof
10 years, 1 month
OS X Mavericks and C++
by David Evans
OS X Mavericks (10.9) is released today (Free upgrade in App Store.)
Please see the following email to MacPorts developers today concerning C++
compatibility and need to build with clang++.
Note that inkscape (0.48.4) is a current issue because it doesn't build
with clang++. I'm hoping that backporting the current upstream patches
concerning
clang compatibility for this branch will solve the problem.
Dave Evans
devans@...2376...
10 years, 1 month
Re: [Inkscape-devel] Version number
by Jared Meidal
I've seen documentation of roadmaps and releases refer to the version numbering as possibly up for consideration of revision:
"Evaluate changing the numbering scheme to a date-based one, or setting more realistic goals for major (1.0, 2.0) releases" <http://wiki.inkscape.org/wiki/index.php/Roadmap>
I can see the next major release after 0.48.x as a candidate for change as the "9'er" may lend itself toward a new scheme.
* 0.49.0 --> 0.90.0 (followed by 1.0, 1.1, 2.0...)
* 0.49.0 --> Inkscape 9 (followed by Inkscape 9.1, 10.0...)
There have been a lot of excellent developments to be release in the next release, including C++, cairo, alignment/distribution along with new possible builds on win64-bit (Partha's help), and native Mac OS X (some almost-ready builds are out there). If these all reach maturity for the release the new builds are providing an increase audience and userbase. A changing version numbering scheme could reflect the developers' acknowledgement of this and demonstrate the activity of the software project.
Just IMHO,
--Jared
10 years, 1 month
Big epsilon in 2geom/coord.h
by Markus Engel
Hi,
in 2geom/coord.h there is an epsilon defined as 1e-5. This is used in many
ways, e. g. in Geom::are_near, .
Now I'm wondering why this value is that big. This causes at least one
problem, see the last two comments here:
https://bugs.launchpad.net/inkscape/+bug/1231990
Is there any reason why "1e-18" has been commented out?
Regards,
Markus
10 years, 1 month
