2:20 p.m.
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
2:55 p.m.
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
5:37 p.m.
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.
6:38 a.m.
New subject: 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
6:54 a.m.
New subject: Show revisions affecting specific file?
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/d...
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
6:55 a.m.
New subject: Show revisions affecting specific file?
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-he...
Cheers,
Veronika
-----Original Message-----
From: mathog
Sent: Wednesday, May 09, 2012 2:38 PM
To: inkscape-devel(a)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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
6:21 a.m.
New subject: btool -j switch?
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
7:11 a.m.
New subject: Windows binary with much improved EMF import/export and some other patches
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_...
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
7:08 p.m.
New subject: Windows binary with much improved EMF import/export and some other patches
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.)
12:53 a.m.
New subject: Windows binary with much improved EMF import/export and some other patches
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
6:17 p.m.
New subject: Windows binary with much improved EMF import/export and some other patches
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
6:32 p.m.
New subject: Windows binary with much improved EMF import/export and some other patches
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
8:11 p.m.
New subject: Windows binary with much improved EMF import/export and some other patches
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.)
12:40 a.m.
New subject: Windows binary with much improved EMF import/export and some other patches
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
7:06 p.m.
New subject: btool -j switch?
On 2012-05-10 23:21, mathog wrote:
g++ buildtool.cpp -o btool -fopenmp
btool -j 2
Is 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.)
12:59 a.m.
New subject: btool -j switch?
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
4:33 p.m.
New subject: btool -j switch?
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?
1:59 a.m.
New subject: btool -j switch?
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
4:41 p.m.
New subject: btool -j switch?
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).
12:49 a.m.
New subject: btool -j switch?
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
3:17 a.m.
New subject: First shot at building trunk on Linux, autoconf version issue
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.
3:44 a.m.
New subject: First shot at building trunk on Linux, autoconf version issue
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
3:48 a.m.
New subject: First shot at building trunk on Linux, autoconf version issue
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
4:46 a.m.
New subject: First shot at building trunk on Linux, autoconf version issue
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
4:33 a.m.
New subject: How to get configure to see another library (like libavoid)
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
5:58 a.m.
New subject: How to get configure to see another library (like libavoid)
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:/confi...
And that'll add all the flags and appropriate libs in.
--Ted
6:41 a.m.
New subject: How to get configure to see another library (like libavoid)
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
9:45 a.m.
New subject: How to get configure to see another library (like libavoid)
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
6:24 a.m.
New subject: How to get configure to see another library (like libavoid)
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
9:31 a.m.
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
3:31 a.m.
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....
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
9:12 a.m.
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....
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
3974
days inactive
4040
days old
inkscape-devel@lists.inkscape.org
31 comments
9 participants
participants (9)
-
Alex Valavanis -
alvinpenner -
Jasper van de Gronde -
Krzysztof Kosiński -
mathog -
Solor Vox -
Ted Gould -
Veronika -
~suv