Hello,
I've been trying to solve a 2+ year issue with inkscape and my printing device (laser cutter) not accepting paths as vectors. All I can seem to get out of inkscape is rastered images. Yes, exporting to PDF works, but it's not a fix and not a great solution either.
As such, I've been digging in the code to inkscape versions 0.46 to 0.48.2 on a win32 platform.
Why was a call to cairo PS level 3 commented out on line 101? And can you tell me if the call to renderItem() is sending bitmap or vector data to the surface? Where in the code chain might the vector paths be rastered?
Cheers, sV
On 07/05/2012 07:20, Solor Vox wrote:
I've been trying to solve a 2+ year issue with inkscape and my printing device (laser cutter) not accepting paths as vectors. All I can seem to get out of inkscape is rastered images. Yes, exporting to PDF works, but it's not a fix and not a great solution either.
As such, I've been digging in the code to inkscape versions 0.46 to 0.48.2 on a win32 platform.
Why was a call to cairo PS level 3 commented out on line 101? And can you tell me if the call to renderItem() is sending bitmap or vector data to the surface? Where in the code chain might the vector paths be rastered?
Related report in the bug tracker (with sample files): Bug #630639 "printing rasterizes images" https://bugs.launchpad.net/inkscape/+bug/630639
~suv
On 07-05-12 07:20, Solor Vox wrote:
Hello,
I've been trying to solve a 2+ year issue with inkscape and my printing device (laser cutter) not accepting paths as vectors. All I can seem to get out of inkscape is rastered images. Yes, exporting to PDF works, but it's not a fix and not a great solution either.
As such, I've been digging in the code to inkscape versions 0.46 to 0.48.2 on a win32 platform.
Why was a call to cairo PS level 3 commented out on line 101? And can you tell me if the call to renderItem() is sending bitmap or vector data to the surface? Where in the code chain might the vector paths be rastered?
My guess is that there were so many issues with trying to print vector images that someone just figured it would be easier to print a bitmap. Inkscape's rasterization is in general done in the src\display directory.
For more detailed info on the specific things you mentioned, it would be great if you could tell us what file you're looking at.
Is there some way in launchpad to get a list of revisions that changed a specific file?
For instance, I'm looking a little deeper at this bug:
https://bugs.launchpad.net/inkscape/+bug/987962
and have just discovered that when it crashes, it always does so in
SPDesktop::set_display_area (part of desktop.cpp)
when it is called with: x0,y0,x1,y1,border = -146.429,154.286,896.429,885.714,0
The negative x0 seems to make Cairo unhappy, sometimes enough to crash the program. The natural next step would be to look at the revisions for desktop.cpp to see if one of these corresponds to the start of revisions that cause problems. But I do not see a way to do that, short of trudging through all of the revisions and checking the files in each. Is there an easier way?
Thank you,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
You can use "bzr log <filename>" to find the commits that touched a particular file, so...
bzr log src/desktop.cpp
If you want to use the web interface, just navigate to the file in question[1] and then click "view changes to this file" at the top of the page.
[1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/desk...
On 9 May 2012 22:38, mathog <mathog@...1176...> wrote:
Is there some way in launchpad to get a list of revisions that changed a specific file?
For instance, I'm looking a little deeper at this bug:
https://bugs.launchpad.net/inkscape/+bug/987962
and have just discovered that when it crashes, it always does so in
SPDesktop::set_display_area (part of desktop.cpp)
when it is called with: x0,y0,x1,y1,border = -146.429,154.286,896.429,885.714,0
The negative x0 seems to make Cairo unhappy, sometimes enough to crash the program. The natural next step would be to look at the revisions for desktop.cpp to see if one of these corresponds to the start of revisions that cause problems. But I do not see a way to do that, short of trudging through all of the revisions and checking the files in each. Is there an easier way?
Thank you,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I use the "bazaar log" command to see the history of a file:
http://doc.bazaar.canonical.com/development/en/user-reference/log-help.html
(Actually I use the bazaar plugin for eclipse which uses the bazaar log command and shows me the results in a nice table and then allows me to compare revisions to each other or to the current file in my workspace).
I also find the "bazaar annotate" command quite useful for seeing when a line in the current version of a file was last modified:
http://doc.bazaar.canonical.com/development/en/user-reference/annotate-help....
Cheers, Veronika
-----Original Message----- From: mathog Sent: Wednesday, May 09, 2012 2:38 PM To: inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Show revisions affecting specific file?
Is there some way in launchpad to get a list of revisions that changed a specific file?
For instance, I'm looking a little deeper at this bug:
https://bugs.launchpad.net/inkscape/+bug/987962
and have just discovered that when it crashes, it always does so in
SPDesktop::set_display_area (part of desktop.cpp)
when it is called with: x0,y0,x1,y1,border = -146.429,154.286,896.429,885.714,0
The negative x0 seems to make Cairo unhappy, sometimes enough to crash the program. The natural next step would be to look at the revisions for desktop.cpp to see if one of these corresponds to the start of revisions that cause problems. But I do not see a way to do that, short of trudging through all of the revisions and checking the files in each. Is there an easier way?
Thank you,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
on Mingw when I build btool like:
g++ buildtool.cpp -o btool -fopenmp
and then run it like
btool -j 2
or
btool -j
on a dual core machine Windows Task Manager shows the idle process at 50% and the various compiler tools at up to 50%. That is, it is not using both cores.
Is there some other trick that is needed for a threaded compile?
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Since my EMF related (and other) patches aren't making it into trunk very quickly I have put together a zip file with binaries that incorporate those changes. For anybody who actually needs a more solid EMF import/export than either trunk or the release branches offer. Or for anyone who wants to acid test my new code. The zip file also includes the dbg files. No installer, just unpack and double click on the .exe to run it. (A DOS window will open, like any other mingw trunk build.) This zip file is available here:
http://saf.bio.caltech.edu/pub/software/windows/inkscape_r11289.zip
This is trunk revision 11289 with the file substitutions here:
http://saf.bio.caltech.edu/pub/software/windows/inkscape_changes_2012_05_10....
This is mostly the omnibus EMF patch
https://bugs.launchpad.net/inkscape/+bug/988601
plus the patched libglib described here
https://bugzilla.gnome.org/show_bug.cgi?id=675695
that resolves the 15% idle CPU problem on mingw (at least on my system), plus the fix (probably more of a work around) for the 50% crash problem that afflicted recent trunk builds:
https://bugs.launchpad.net/inkscape/+bug/987962
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 2012-05-10 23:21, mathog wrote:
g++ buildtool.cpp -o btool -fopenmp btool -j 2Is there some other trick that is needed for a threaded compile?
The above seems to work for me. But be aware that only the compilation step is done in parallel (as far as I can tell). So linking for example is not done in parallel.
(BTW, you mentioned using MingW, I'm assuming you're using a recent version of TDM's gcc.)
On 2012-05-11 00:11, mathog wrote:
Since my EMF related (and other) patches aren't making it into trunk very quickly I have put together
EMF patches? Is there any reason for them not to be applied to trunk? If not, feel free to point us in the right direction. (If you brought them under our attention earlier and we missed it, sorry.)
On 11-May-2012 03:08, Jasper van de Gronde wrote:
On 2012-05-11 00:11, mathog wrote:
Since my EMF related (and other) patches aren't making it into trunk very quickly I have put together
EMF patches? Is there any reason for them not to be applied to trunk? If not, feel free to point us in the right direction. (If you brought them under our attention earlier and we missed it, sorry.)
They have not been tested on other platforms.
Not that most of them are actually built there, since the EMF stuff seems to be specific to the Windows version. It probably shouldn't be though, as the Mac versions of PowerPoint (PowerPoint is the ultimate target of the inkscape graphics, and many of the end users have Macs) does have an "insert picture from file" that will accept an EMF file. Also there is a project libemf which could be linked in on Macs or Linux to support EMF. I have never used it, but it looks pretty complete and it uses the same names as the native Windows functions:
http://libemf.sourceforge.net/
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 11-May-2012 03:06, Jasper van de Gronde wrote:
(BTW, you mentioned using MingW, I'm assuming you're using a recent version of TDM's gcc.)
The last one was downloaded from sourceforge rather than TDM
http://sourceforge.net/projects/mingw/files/
but seems to work as well as the last one I tried from TDM (which was downloaded about a year ago.
gcc --version gcc.exe (GCC) 4.6.2 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 11-05-12 17:59, mathog wrote:
On 11-May-2012 03:06, Jasper van de Gronde wrote:
(BTW, you mentioned using MingW, I'm assuming you're using a recent version of TDM's gcc.)
The last one was downloaded from sourceforge rather than TDM
http://sourceforge.net/projects/mingw/files/but seems to work as well as the last one I tried from TDM (which was downloaded about a year ago.
Interesting. So you tried both, and in both cases you are unable to get buildtool to compile multiple files in parallel?
Do you have access to trunk? (I don't think not being tested on other platforms should necessarily be a blocker.)
On 11-05-12 17:53, mathog wrote:
On 11-May-2012 03:08, Jasper van de Gronde wrote:
On 2012-05-11 00:11, mathog wrote:
Since my EMF related (and other) patches aren't making it into trunk very quickly I have put together
EMF patches? Is there any reason for them not to be applied to trunk? If not, feel free to point us in the right direction. (If you brought them under our attention earlier and we missed it, sorry.)
They have not been tested on other platforms.
Not that most of them are actually built there, since the EMF stuff seems to be specific to the Windows version. It probably shouldn't be though, as the Mac versions of PowerPoint (PowerPoint is the ultimate target of the inkscape graphics, and many of the end users have Macs) does have an "insert picture from file" that will accept an EMF file. Also there is a project libemf which could be linked in on Macs or Linux to support EMF. I have never used it, but it looks pretty complete and it uses the same names as the native Windows functions:
http://libemf.sourceforge.net/
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 14/05/2012 11:17, Jasper van de Gronde wrote:
On 11-05-12 17:53, mathog wrote:
On 11-May-2012 03:08, Jasper van de Gronde wrote:
On 2012-05-11 00:11, mathog wrote:
Since my EMF related (and other) patches aren't making it into trunk very quickly I have put together
EMF patches? Is there any reason for them not to be applied to trunk?
If not, feel free to point us in the right direction. (If you brought them under our attention earlier and we missed it, sorry.)
They have not been tested on other platforms.
Do you have access to trunk? (I don't think not being tested on other platforms should necessarily be a blocker.)
If the proposed patch breaks building on other platforms (it does), it should not be applied as is.
Please read more details (and open questions) in the bug report David referred to in his earlier message:
- Bug #988601 "omnibus EMF issue patch" https://bugs.launchpad.net/inkscape/+bug/988601
V
On 14-05-12 11:32, ~suv wrote:
... Please read more details (and open questions) in the bug report David referred to in his earlier message:
- Bug #988601 "omnibus EMF issue patch" https://bugs.launchpad.net/inkscape/+bug/988601
Thanks! Had missed that, sure clears up a few things. (Taking the discussion to that thread.)
On 14-May-2012 02:17, Jasper van de Gronde wrote:
Do you have access to trunk? (I don't think not being tested on other platforms should necessarily be a blocker.)
One big problem is that the EOL sequence in mingw is "\r\n", so it is painfully easy to convert files from "\n" to "\r\n" EOLs just by changing a character and then saving them. The extra carriage return can be a problem on linux/unix systems.
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 14-May-2012 00:33, Jasper van de Gronde wrote:
Interesting. So you tried both, and in both cases you are unable to get buildtool to compile multiple files in parallel?
No, I only tried the parallel on the most recent one (straight from sourceforge). Btool seems to think it is doing the right thing:
btool -j 2 ...
##### Target : compile ##### compile the source to .o --- compile / cc cc : compile with 2 threads in parallel cc : compile of build/obj/arc-context.o required by source: src/arc-context.cpp ============ cmd ============
but task manager shows it never breaks 50%, with idle always >=50%. Near as I can tell it is only ever trying to compile one thing at a time. Strange, the vast majority of the dll's are the same (except possibly different versions). The newer one has pthreadGC2.dll whereas the older has libpthread-2.dll.
Some sort of threads is working in this mingw because when I break in inkscape itself gdb sees multiple threads.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 15-05-12 18:59, mathog wrote:
On 14-May-2012 00:33, Jasper van de Gronde wrote:
Interesting. So you tried both, and in both cases you are unable to get buildtool to compile multiple files in parallel?
No, I only tried the parallel on the most recent one (straight from sourceforge). Btool seems to think it is doing the right thing: ... but task manager shows it never breaks 50%, with idle always >=50%. Near as I can tell it is only ever trying to compile one thing at a time. Strange, the vast majority of the dll's are the same (except possibly different versions). The newer one has pthreadGC2.dll whereas the older has libpthread-2.dll.
Some sort of threads is working in this mingw because when I break in inkscape itself gdb sees multiple threads.
Hmm... I think task manager should be able to tell you how many threads btool is using. If it is using 2 threads, the process could in principle be IO bound. Also, you might try increasing the thread count (hyper threading and such might be playing tricks on you).
On 16-May-2012 00:41, Jasper van de Gronde wrote:
Some sort of threads is working in this mingw because when I break in inkscape itself gdb sees multiple threads.
Hmm... I think task manager should be able to tell you how many threads btool is using. If it is using 2 threads, the process could in principle be IO bound. Also, you might try increasing the thread count (hyper threading and such might be playing tricks on you).
Good idea. With -j 2 task manager showed btool with 2 threads, -j 3 showed three. In neither case though did it actually do two compiles at the same time.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On a newly upgraded 12.04LTS Ubuntu trying to build a freshly downloaded (via bazaar at around 9:00AM PST today) copy of trunk. Autogen.sh seems a bit confused about autoconf. At one point it checks for >2.52 (which passes, as it is 2.59) then later it blows up saying it needs 2.62 or higher. See log following my signature (it will wrap, sorry).
Workaround???
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
./autogen.sh ============================================================================= When you report a trouble about building BZR version of inkscape, Please report following information about distro and tools version, too.
--1. distribution------------------------------------------------------------ Debian GNU/Linux release wheezy/sid
--2. tools------------------------------------------------------------------- /usr/bin/m4: m4 (GNU M4) 1.4.16 /usr/local/bin/autoconf: autoconf (GNU Autoconf) 2.59 /usr/local/bin/autoheader: autoheader (GNU Autoconf) 2.59 /usr/local/bin/automake: Can't locate Automake/Struct.pm in @INC (@INC contains: /usr/local/share/automake-1.9 /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/local/bin/automake line 47. BEGIN failed--compilation aborted at /usr/local/bin/automake line 47. automake-1.7: not found automake-1.8: not found /usr/local/bin/automake-1.9: Can't locate Automake/Struct.pm in @INC (@INC contains: /usr/local/share/automake-1.9 /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/local/bin/automake-1.9 line 47. BEGIN failed--compilation aborted at /usr/local/bin/automake-1.9 line 47. /usr/local/bin/aclocal: Can't locate Automake/Config.pm in @INC (@INC contains: /usr/local/share/automake-1.9 /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/local/bin/aclocal line 36. BEGIN failed--compilation aborted at /usr/local/bin/aclocal line 36. aclocal-1.7: not found aclocal-1.8: not found /usr/local/bin/aclocal-1.9: Can't locate Automake/Config.pm in @INC (@INC contains: /usr/local/share/automake-1.9 /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/local/bin/aclocal-1.9 line 36. BEGIN failed--compilation aborted at /usr/local/bin/aclocal-1.9 line 36. /usr/bin/intltoolize: intltoolize (GNU intltool) 0.50.2 /usr/bin/gettextize: /usr/bin/gettextize (GNU gettext-tools) 0.18.1
--3. environment variables--------------------------------------------------- LANGUAGE= PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LANG=en_US.UTF-8
=============================================================================
I am testing that you have the required versions of autoconf, automake, glib-gettextize and intltoolize. This test is not foolproof and if anything goes wrong, there may be guidance in the file HACKING.txt
checking for autoconf >= 2.52 ... yes (version 2.59) checking for automake >= 1.10 ... yes (version 1.11.3) checking for glib-gettextize >= 2.0.0 ... yes (version 2.32.1) checking for intltool >= 0.17 ... yes (version 0.50.2)
Running aclocal-1.11 ... configure.ac:14: error: Autoconf version 2.62 or higher is required /usr/share/aclocal-1.11/init.m4:26: AM_INIT_AUTOMAKE is expanded from... configure.ac:14: the top level autom4te: /usr/bin/m4 failed with exit status: 63 aclocal-1.11: autom4te failed with exit status: 63 Please fix the error conditions and try again.
Even though it blew up it did create a configure file of size 401738. Don't know if it is complete though. It ends right after the
echo " Configuration: (lots of stuff) "
Is that all there should be?
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
configure may be complete, but no install.sh was created, so configure will not actually run.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Never mind, found it. Long ago I had to install an old version of all the auto* tools on this machine into /usr/local in order to build another piece of software, and those were still in the path ahead of the current versions.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Sort question: I need to find out how to kick configure/autoconf/automake so that it will include another library equivalent to libavoid.
Long form (background):
On a linux system I'm trying to get the emf stuff using with the libEMF library. Then Inkscape will support emf on all platforms - not just win32.
So far:
1. unpacked libEMF under .../inkscape/src/libEMF 2. built it with its own configure 3. moved libemf.o and all the header files to .../inkscape/src/libEMF 4. modified header file includes to look for "libEMF/header_name.h" 5. modified the win32 emf-win32-print and emf-win32-inout to use libemf. (required some modifications to the libEMF header files, and oddly, to style.h) until a clean compile resulted.
Now I'm stuck trying to get the Makefiles produced by configure for Inkscape to actually build libemf.a (or libemf.o) a:
6. copied this from libavoid and changed libavoid to libEMF: cat inkscape/src/libEMF/makefile.in # Convenience stub makefile to call the real Makefile.
@SET_MAKE@
OBJEXT = @OBJEXT@
# Explicit so that it's the default rule. all: cd .. && $(MAKE) libEMF/all
clean %.a %.$(OBJEXT): cd .. && $(MAKE) libEMF/$@
.PHONY: all clean
.SUFFIXES: .SUFFIXES: .a .$(OBJEXT)
7. based this on libavoid example: cat inkscape/src/libEMF/Makefile_insert ## Makefile.am fragment sourced by src/Makefile.am.
ink_common_sources += \ libEMF/libemf.cpp \ libEMF/basetsd.h \ libEMF/emf.h \ libEMF/guiddef.h \ libEMF/libemf.h \ libEMF/poppack.h \ libEMF/pshpack2.h \ libEMF/pshpack4.h \ libEMF/w16.h \ libEMF/winbase.h \ libEMF/windef.h \ libEMF/winerror.h \ libEMF/wingdi.h \ libEMF/winnt.h \ libEMF/winuser.h
8. in src, put libEMF stuff in where libavoid is (1:1): diff Makefile.am Makefile.am.dist 33d32 < libEMF/libemf.a \ 131d129 < include libEMF/Makefile_insert 181d178 < libEMF/makefile.in \
9 in inkscape (top directory), again, put libEMF stuff in where libavoid is (1:1) diff configure.ac configure.ac.dist 1035d1034 < src/libEMF/makefile
modified configure so that there was a matching line for libEMF everywhere there was one for libavoid
10. ./configure runs, but no new makefile.in is created in src. Consequently when a build is attempted:
11. (inkscape, top level) make configure.ac:68: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from... configure.ac:68: the top level (many similar messages for different configure.ac lines) src/Makefile.am: object `libEMF/libemf.$(OBJEXT)' created by `libEMF/libemf.cpp' and `libEMF/libemf.c' make: *** [Makefile.in] Error 1
Suggestions?
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On Fri, 2012-05-18 at 12:33 -0700, mathog wrote:
Sort question: I need to find out how to kick configure/autoconf/automake so that it will include another library equivalent to libavoid.
What's important to realize here is that we *really* don't want to include libraries in the Inkscape codebase. It's a bad habit that we really need to kick :-) The libraries that are in the Inkscape codebase today are ones that were developed by Inkscape developers along side, or ones that we had to patch significantly.
So what you should be doing is installing libemf in the system and then using the system version of libemf. I'm not familiar with libemf, but typically libraries install a package config file in /usr/lib/pkgconfig that is something like "emf-1.0.pc". You can then add the name to the list of packages we check for, similar to little CMS:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/configur...
And that'll add all the flags and appropriate libs in.
--Ted
On 18-May-2012 12:33, mathog wrote:
Figured out this part:
configure.ac:68: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from... configure.ac:68: the top level
Had to change configure.ac like:
< AC_COMPILE_IFELSE(AC_LANG_PROGRAM([]), [ink_opt_ok=yes], [ink_opt_ok=no]) ---
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])], [ink_opt_ok=yes], [ink_opt_ok=no])
and
< AC_COMPILE_IFELSE([ ---
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
599c599 < ], [popplercolor=yes]) ---
])], [popplercolor=yes])
Presumably (yet another) incompatibility between autoconf version (this is 2.68).
That leaves:
src/Makefile.am: object `libEMF/libemf.$(OBJEXT)' created by `libEMF/libemf.cpp' and `libEMF/libemf.c' make: *** [Makefile.in] Error 1
which is really crazy because in the entire source tree there are only libemf.cpp and libemf.h, so where it is pulling "libemf.c" from I have no idea. I did try renaming libemf.h to libemf.hpp (dittof ro anything that referenced it) but it made no difference.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 18-May-2012 13:58, Ted Gould wrote:
What's important to realize here is that we *really* don't want to include libraries in the Inkscape codebase. It's a bad habit that we really need to kick :-) The libraries that are in the Inkscape codebase today are ones that were developed by Inkscape developers along side, or ones that we had to patch significantly.
The problem here is that I had to modify the code in libemf somewhat to get it to work. Also it isn't a very common library, so very few machines are going to have it installed.
Perhaps "library" really isn't the right term here. The 10 or so files live in one directory, but it doesn't need to build to a .a or .so or .dll, just to a .o (or .obj) which is linked into the one big inkscape library.
And that'll add all the flags and appropriate libs in.
Or not, it seems to be triggering some sort of autoconf bug/incompatibility, where it thinks there are both libemf.c and libemf.cpp, but only the latter file actually exists.
Tbanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
2012/5/8 Jasper van de Gronde <th.v.d.gronde@...528...>:
On 07-05-12 07:20, Solor Vox wrote:
Hello,
I've been trying to solve a 2+ year issue with inkscape and my printing device (laser cutter) not accepting paths as vectors. All I can seem to get out of inkscape is rastered images. Yes, exporting to PDF works, but it's not a fix and not a great solution either.
As such, I've been digging in the code to inkscape versions 0.46 to 0.48.2 on a win32 platform.
Why was a call to cairo PS level 3 commented out on line 101? And can you tell me if the call to renderItem() is sending bitmap or vector data to the surface? Where in the code chain might the vector paths be rastered?
My guess is that there were so many issues with trying to print vector images that someone just figured it would be easier to print a bitmap. Inkscape's rasterization is in general done in the src\display directory.
Probably that's true, or the incorrect rasterizer was used.
There are actually *two* renderers in Inkscape: one is used for interactive display and PNG export and produces bitmaps exclusively, the other is used for e.g. PDF export, is noninteractive and can also produce vector images. It should be fairly simple to handle printing through a slightly modified form of the PDF exporter.
Regards, Krzysztof
2012/5/18 mathog <mathog@...1176...>:
On 18-May-2012 13:58, Ted Gould wrote:
What's important to realize here is that we *really* don't want to include libraries in the Inkscape codebase. It's a bad habit that we really need to kick :-) The libraries that are in the Inkscape codebase today are ones that were developed by Inkscape developers along side, or ones that we had to patch significantly.
The problem here is that I had to modify the code in libemf somewhat to get it to work.
In this case it's best to submit these modifications upstream.
Also it isn't a very common library, so very few machines are going to have it installed.
The presence of this library should not be required to compile Inkscape - the autoconf script should detect whether it's available.
Perhaps "library" really isn't the right term here. The 10 or so files live in one directory, but it doesn't need to build to a .a or .so or .dll, just to a .o (or .obj) which is linked into the one big inkscape library.
This will increase link time for no good reason. If you really want to do this, just copy the approach used for libavoid, libcroco, and lib2geom, which discards all of the original autoconf files and builds the library as a local .a file.
Regards, Krzysztof
attached is a proposal to produce a vector graphics printout for Windows. This particular method will work only on Windows, but if I understand the various reports correctly, this rasterization problem occurs only on Windows.
The method is based on the file dxf_outlines.py which has been rewritten to use gdi32.dll for printing. It runs as an Inkscape Python extension and will produce a vector output if the linewidth is 1 printer pixel or less. The necessary files are attached here:
Further info is available at https://bugs.launchpad.net/inkscape/+bug/630639 comment 12
Since I do not have access to a true laser cutter, any feedback would be more than welcome.
hth, Alvin http://inkscape.13.n6.nabble.com/file/n4964892/print_win32_vector.py print_win32_vector.py http://inkscape.13.n6.nabble.com/file/n4964892/print_win32_vector.inx print_win32_vector.inx
-- View this message in context: http://inkscape.13.n6.nabble.com/vector-printing-win32-tp4957076p4964892.htm... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
any objections if I commit this Python code to trunk? it appears to be working, according to https://bugs.launchpad.net/inkscape/+bug/966244/comments/2
The reason I'm asking, I suppose, is because it is a Windows-specific solution to a Windows problem. On the other hand, is it possible, or acceptable, to limit it to only the Windows distribution by deliberately not including it in the Makefile.am file?
- Alvin
-- View this message in context: http://inkscape.13.n6.nabble.com/vector-printing-win32-tp4957076p4964916.htm... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
participants (9)
-
Alex Valavanis -
alvinpenner -
Jasper van de Gronde -
Krzysztof Kosiński -
mathog -
Solor Vox -
Ted Gould -
Veronika -
~suv