pdf import again: poppler native vs. poppler cairo
by the Adib
Hello All,
as the problem is still there I would propose following intermediate solution:
currently in the codebasis there is also an pdf import via
poppler-cairo. This one is disabled.
I would like to enable this as an additional pdf import possibility.
We have to decide later when it comes to the release which one to
integrate into the release.
so we can test in parallel the two options.
we have a big tester basis (compared to separate launchpad branch)
we get the possibility to switch to an tested poppler-internals
independent solution (while using poppler)
I there is no big NONO I will go forward and enable this within the next days.
attached the patch that is needed for this (tested on windows, should
work on Linux)
regards,
Adib.
8 years, 10 months
Usability development help for Inkscape available
by Aslak Karsi
Hello
We are a group of five students from Finland, studying at University of
Oulu, Department of Information Processing Science. We are currently working
on a project assignment to offer help in usability development for an open
source software project of our choice.
Past few weeks we have been familiarizing ourselves with Inkscape and its
community and now we would like to offer our work resources for your use.
We have already figured out a few ideas of what we could do for the Inkscape
project:
* Heuristic evaluation
* Usability testing
* Prioritization of usability related bugs on the buglist
To produce as useful results as possible, we would like to hear your ideas.
How do you feel about the tasks suggested? Is there some specific part of
the software we should focus on? Any ideas and feedback at this point would
be greatly appreciated.
Project leader Aslak Karsi
Marko Arffman
Matias Patosalmi
Jouni Rissanen
Matti Siipola
10 years
Howto - linker dependent linker flags in makefile - help needed
by the Adib
Hello developers,
we run into a little problem while dealing with upcoming gcc 4.6 compatibility.
Any help for a "good" solution appreciated. Full story below. Thanks, Adib.
--
There should be linker flags leading by "-Wl" curently there is not
such option. Gcc fails builing without.
But under OSX a native apple darwin compiler is used that do not know
this option.
I modified makefile to test for osx:
src/Makefile.am:
...
if PLATFORM_OSX
inkscape_LDFLAGS = --export-dynamic $(kdeldflags) $(mwindows)
else
inkscape_LDFLAGS = -Wl,--export-dynamic $(kdeldflags) $(mwindows)
endif
...
and conficure.ac:
...
dnl ******************************
dnl MacOS X
dnl ******************************
AC_MSG_CHECKING([for OSX platform])
if test "x$build_vendor" = "xapple" ; then
platform_osx=yes
else
platform_osx=no
fi
AC_MSG_RESULT([$platform_osx])
AM_CONDITIONAL(PLATFORM_OSX, test "$platform_osx" = "yes")
...
But we should test for linker not a gnu linker.
There is such test in aclocal.m4:
...
# _LT_PATH_LD_GNU
#- --------------
m4_defun([_LT_PATH_LD_GNU],
[AC_CACHE_CHECK([if the linker ($LD) is GNU ld], lt_cv_prog_gnu_ld,
[# I'd rather use --version here, but apparently some GNU lds only accept -v.
case `$LD -v 2>&1 </dev/null` in
*GNU* | *'with BFD'*)
lt_cv_prog_gnu_ld=yes
;;
*)
lt_cv_prog_gnu_ld=no
;;
esac])
with_gnu_ld=$lt_cv_prog_gnu_ld
])# _LT_PATH_LD_GNU
...
So the question is how to modify those files that gnu linker is
checked and in case on gnu linker we put "-Wl" in front of those
linkre oprtions?
Thanks for patience, Adib.
10 years
Regarding GSOC 2011 - Project Continuing C++ification
by Abhishek Sharma
Hi everybody,
It feels pretty nostalgic to be back to coding for inkscape after the last
gsoc year. Last year along with Jon Cruz, we achieved some of object
oriented build up in the codebase. This GSOC as well I would wish to
continue on the same. I'll be glad to have community's views over this years
milestone. As in what code customizations and cleanup and further
enhancements are supposed to be done this year. I will be delighted to have
responses over this.
--
Regards,
Abhishek Sharma
10 years
Re: [Inkscape-devel] Multipage support as a GSoC project?
by gespertino＠...400...
> So, yes, we could implement a "simple" fix that lets users specify a
> font size in points. We could even just use the SVG unit pt, as that is
> also defined as an "appropriate" multiple of px. And perhaps we should
> do this if people find it useful. But I think it would give the wrong
> impression (that you were actually using an absolute unit) and it could
> lead to weird issues once Inkscape will let the user specify the
> coordinate system (do we then stick to the somewhat arbitrary scaling
> factor or do we want true points?). I admit that it's a slightly
> academic debate, but still, what's the point if you're not really using
> points?
As I see it, we already have real world units in inkscape UI
everywhere, all of them assuming a resolution of 90dpi. People is
using those "real world units" based on that: the default document is
A4, if inches or centimeters are selected as default units for the
document, that's what the user gets in inkscape.
Of course it's a problem when you want to take the artwork created in
Inkscape to other applications (for instance Scribus, which apparently
uses 72 dpi for imported SVGs)
I'm aware that adding that option (real world units in the type dialog
assuming 90dpi) won't be a good long-term solution, but I'm sure it
will be well received by a lot of people as an acceptable interim
solution.
Type size in pixels was reported as a bug several times. Probably
people working for web don't care, but designers creating brochures,
posters and things that have to end up printed, are more used to DTP
points than to any other unit for type.
With that change things will be better for that part of the userbase,
and won't be worse for anybody, since the real units confusion is
already installed with the current implementation in most of the
tools.
10 years
Multipage support as a GSoC project?
by Jason Creighton
Hi All,
I'm a student considering applying to GSoC for Inkscape, and I'm
wondering how you guys feel about multipage support as a project.
I asked about this on the IRC channel and it was pointed out to me that
multipage support was dropped from SVG 1.2, so the state of this in the
SVG standard is kind of up in the air.
Is the lack of an official standard a show-stopper?
If not, is this even something you'd like to see worked on at this time?
Or are there other, more pressing, features or issues that you'd prefer
to see applications on?
Thanks,
Jason
10 years
Doxygen cleanup
by Jon Cruz
First of all, is anyone using our doxygen docs, or does anyone care about the format?
Our current usage is a bit inefficient, so I've been thinking of cleaning it up a bit. First on the hit list are those annoying "@brief" instances.
Or config file has this:
> # If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
> # will interpret the first line (until the first dot) of a JavaDoc-style
> # comment as the brief description. If set to NO, the JavaDoc
> # comments will behave just like regular Qt-style comments
> # (thus requiring an explicit @brief command for a brief description.)
>
> JAVADOC_AUTOBRIEF = YES
So that means instead of :
/**
* @brief XML - prefs observer bridge
*
* This is an XML node observer that watches for changes in the XML document storing the preferences.
* It is used to implement preference observers.
*/
We can do:
/**
* XML - prefs observer bridge.
*
* This is an XML node observer that watches for changes in the XML document storing the preferences.
* It is used to implement preference observers.
*/
The key point is to just have a single period so that the first sentence *is* the brief description. No need for additional work or @ tags.
10 years
proposal to enhance the python extensions
by Mark Schafer
Hi everyone,
I've been lurking on this list and making extensions for Inkscape in python.
(I'm also keen on the dbus scripting but I use windows so no good for me
right now...)
I have had difficulty understanding what some of the extensions do and
in writing my own I have discovered the notebook tab.
I want to suggest using the notebook tab at the top of each extension to
help document how they work.
Here is a screenshot of a suggested UI from my Lasercut box extension.
http://www.flickr.com/photos/33807726@...2603.../5569339514/
Extra tabs could break up the info for clarity and show data like
author,url, etc
So I propose:
- supply a template for people writing extensions to use as a starter
- and some docs/tutorials on making extensions in python
- modify the existing extensions included in Inkscape to follow this
guideline
- maybe fix broken extensions if there are any (I haven't tried every one)
But I don't want to do something the dev team thinks is a waste of time,
and I am unsure of the translation issues with such an approach.
Any thoughts ?
Mark...
10 years
