non-Unicode symbol fonts do not work on Windows. Bug 165665. Do we need the flag USE_PANGO_WIN32 ?
by Alvin Penner
ref : https://bugs.launchpad.net/inkscape/+bug/165665
I believe this bug can be fixed by disabling the flag USE_PANGO_WIN32 in
line 19 of src/libnrtype/FontFactory.h. When I do this on Windows XP, I gain
about 35 new fonts. Not all of these new fonts are useable, but the most
interesting ones, such as CommercialPi, Symbol, Technic, Webdings,
Wingdings, MonoType Sorts, TechnicLite are working well, both in Inkscape
and in IE9.
This is a Windows-specific bug which hides symbol fonts, and does not
occur in Gimp 2.6 on Win XP. As far as I can tell, the Gimp source code does
not contain any analogue or equivalent of the flag USE_PANGO_WIN32.
Would there be any objection if I disable this flag, or does it serve a
specific purpose that is essential?
tia
- Alvin Penner
--
View this message in context: http://old.nabble.com/non-Unicode-symbol-fonts-do-not-work-on-Windows.-Bu...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
7 years, 10 months
Rendering cache committed
by Krzysztof Kosiński
Hello
I committed the rendering cache work in revision 10579 of trunk.
If you encounter serious problems, you can turn off caching completely
by defining the environment variable _INKSCAPE_DISABLE_CACHE. For
example, run inkscape as:
$ _INKSCAPE_DISABLE_CACHE=1 inkscape
By default, each drawing will use up to 64 MB of memory for rendering
data. It can be set in the "Rendering" page of the preferences
(renamed from "Filters").
As usual, problem reports are welcome.
Regards, Krzysztof
10 years, 5 months
Building .app on Mac OS X with Macports
by Frank Schima
I'm trying to build inkscape 0.48.2 as a Mac .app application using Macports. I'm on Mac OS X 10.7.3 with Xcode 4.2.1 and Macports python 2.7.2 with numpy and lxml. According to the wiki page [1], I should use the osx-app.sh shell script to create it. So I attempted to run the script as stated in the wiki but it did not work for me, saying that it wants the python modules directory to be specified.
$ pwd
/opt/local/var/macports/build/_opt_mports_trunk_dports_graphics_inkscape/inkscape/work/inkscape-0.48.2/packaging/macosx
$ ./osx-app.sh -s -b /opt/local/var/macports/build/_opt_mports_trunk_dports_graphics_inkscape/inkscape/work/destroot/opt/local/bin/inkscape -p ../../Info.plist
CREATE INKSCAPE APP BUNDLE
Python modules directory not specified.
Python modules can be downloaded from:
http://inkscape.modevia.com/macosx-snap/Python-packages.dmg
So I next attempted to specify the python directory.
$ ./osx-app.sh -s -b /opt/local/var/macports/build/_opt_mports_trunk_dports_graphics_inkscape/inkscape/work/destroot/opt/local/bin/inkscape -p ../../Info.plist -py /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
CREATE INKSCAPE APP BUNDLE
Directory does not appear to contain the i386 and ppc python modules:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
Python modules can be downloaded from:
http://inkscape.modevia.com/macosx-snap/Python-packages.dmg
I tried the download link but that does not resolve.
Can anyone tell me what I'm doing wrong, and more importantly how I can build inkscape as a Mac .app with Macports?
Cheers!
Frank
[1] <http://wiki.inkscape.org/wiki/index.php/CompilingMacOsX>
10 years, 5 months
Complete removal of libnr
by Krzysztof Kosiński
Hello all.
Revision 10589 removes all trace of libnr from Inkscape's code, which
was a major refactoring goal. This is a rather big change and might
break various things. Here is a short summary of the changes:
1. NRRect was replaced by Geom:Rect and Geom::OptRect as appropriate.
2. NRRectL was replaced by Geom::IntRect and Geom::OptIntRect as
appropriate. Note that the semantics of Geom::IntRect's contains()
function for points are slightly incorrect at this time, as max() will
be considered part of the rectangle even though it should not be. This
doesn't cause any obvious problems for now.
3. SPItem bounding box methods were rewritten. There are now methods
for bounding boxes in 3 different coordinate systems:
- visualBounds(), geometricBounds(), bounds() - bounds in the item's
own coord system
- desktopVisualBounds(), desktopGeometricBounds(), desktopBounds() -
bounds in desktop coordinate system (origin in bottom left, but
user-editable in the future)
- documentVisualBounds(), documentGeometricBounds(), documentBounds()
- bounds in SVG coordinate system
The "geometric" version returns the object bounding box as defined by
SVG (does not consider stroke, filters, clipping paths, masks, etc.).
The "visual" version considers all of this to return the bounds of the
area affected by the object. The legacy "approximate bbox" was
removed.
4. NRActiveObject was used only by SPAction. SPAction was converted to
GObject and NRActiveObject listeners were replaced by signals. Some
changes to verbs were made along the way.
5. nr-point-fns.h was used by some things in the gradient editor and
was replaced with code using Geom::LineSegment.
Regards, Krzysztof
10 years, 6 months
Creating color managed PDFs
by Adrian Johnson
I have been working on an experimental branch of cairo that supports
color management for the image and pdf surfaces. I'm currently trying to
get Inkscape to use this API so I can test creating color managed PDF
files. I'm not familiar with SVG or the Inkscape source and have some
questions.
The SVG specification says that compositing can be performed in sRGB or
linear RGB color space. I could not find where this is supported in
Inkscape. For now I've set the PDF surface color space to sRGB.
What color space are gradients interpolated in? Are all gradient stops
the same color space? In my patch I have assumed that all stops have the
same color space and used this color space as the interpolation color space.
Can a color space be set for an image?
If anyone is interested the code is here:
http://cgit.freedesktop.org/~ajohnson/
To simplify the implementation only RGB color spaces are currently
supported.
10 years, 6 months
Windows build issues
by Kris De Gussem
Header adaptations in r10986 break windows building.
One of the modifications in
src/extension/implementation/implementation.h is the culprit.
-------------------------------
Make error line 289: problem compiling: In file included from c:\devlibs/include
/sigc++-2.0/sigc++/signal.h:8:0,
from src/extension/implementation/implementation.h:16,
from src/extension/implementation/implementation.cpp:16:
c:\devlibs/include/sigc++-2.0/sigc++/signal_base.h:48:11: error: 'size_t' does n
ot name a type
c:\devlibs/include/sigc++-2.0/sigc++/signal_base.h:97:3: error: 'size_type' does
not name a type
c:\devlibs/include/sigc++-2.0/sigc++/signal_base.h:241:11: error: 'size_t' does
not name a type
c:\devlibs/include/sigc++-2.0/sigc++/signal_base.h:263:3: error: 'size_type' doe
s not name a type
In file included from src/extension/implementation/implementation.h:16:0,
from src/extension/implementation/implementation.cpp:16:
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:33:11: error: 'size_t' does not na
me a type
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:34:11: error: 'ptrdiff_t' does not
name a type
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:99:11: error: 'size_t' does not na
me a type
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:100:11: error: 'ptrdiff_t' does no
t name a type
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:276:11: error: 'size_t' does not n
ame a type
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:277:11: error: 'ptrdiff_t' does no
t name a type
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:359:11: error: 'size_t' does not n
ame a type
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:360:11: error: 'ptrdiff_t' does no
t name a type
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:430:11: error: 'size_t' does not n
ame a type
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:431:11: error: 'ptrdiff_t' does no
t name a type
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:515:11: error: 'size_t' does not n
ame a type
c:\devlibs/include/sigc++-2.0/sigc++/signal.h:516:11: error: 'ptrdiff_t' does no
t name a type
-------------------
10 years, 7 months
Re: [Inkscape-devel] Powerstroke: adding/deleting width nodes
by Valerie
Augh, can someone do something about those "WARNING **:
Inkscape currently only supports color-interpolation-filters = sRGB"
messages? They're clogging up my console while I'm trying to get
other bug messages. :( (but all my text tool problems are gone, yay!)
Anyway, sorry for the delay.
> This is weird, because it is exactly these two things that I fixed!
> Can you send me an example file?
Still Inkscape 0.48+devel r11297.
There are two files attached:
- The New doc file is the first file that crashed when I was testing
Powerstroke. In fact, even now, it crashes Right when I open it. :P
Which is rather fortunate because I wasn't able to get a second
file that crashed once to crash again, nor the Tests file.
- The Tests file is my more systematic attempt to reproduce the
error messages. I basically started with the same-ish shape for
different algorithms and cusps and attempted to torture the lines
until I got a proper error message.
In particular, I've marked one shape where it was quite easy to
reproduce this error message:
WARNING **: Exception during LPE [Unstable!] Power stroke execution.
lib2geom exception: Invariants violation (./2geom/piecewise.h:144)
Just select with the F2 tool, and drag the diamond back and forth
between where the two lines point at.
The error message should pop up. I was able to reproduce that
error in several other lines but not as systematically. It seems
to affect mostly the Linear and Spiro algorithms, though it may
affect other line types too. It usually happens when editing the
powerstroke width.
No matter what I did though, I wasn't able to reproduce a crash in
this session (and not for lack of trying).
10 years, 7 months
GTK+ 3 build complete
by Alex Valavanis
Hi All,
Trunk now builds against GTK+ 3. We now need to do a serious amount of
testing... there are bound to be a large number of runtime errors!
To build against GTK+ 3, you need to have upstream gdl installed.
Configure the build using "configure --enable-gtk3-experimental" then
run "make" as normal.
Cheers,
AV
10 years, 8 months
Exchanging lcms dll
by Jasper van de Gronde
There appears to be a relocation related problem with the Little CMS dll
on Windows, see this bug:
https://bugs.launchpad.net/inkscape/+bug/453931
Now, someone pointed to an alternative version of the dll that seems to
behave better in this respect. Can we just swap out our version of the
dll for that one, or am I overlooking something? Perhaps we desperately
need lcms to be compiled with certain settings? (The alternative is
probably to try and recompile it ourselves and see where that gets us.)
10 years, 8 months
