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.
5 years, 11 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
8 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>
8 years, 6 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
8 years, 7 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
-------------------
8 years, 8 months
Inkscape 0.48.3.1
by Ted Gould
Hey,
So if you're on these mailing list, you know the deal :-) There are a
couple build fixes in this update.
Sourceforge:
http://sourceforge.net/projects/inkscape/files/inkscape/0.48.3.1/
Launchpad:
https://launchpad.net/inkscape/0.48.x/0.48.3.1
MD5 Sums
f0fcc02088cc643634806064e7ab4ec3 inkscape-0.48.3.1.tar.bz2
3e956cd9cf6cf0a22b64a821f5a4084d inkscape-0.48.3.1.tar.bz2.asc
ccf8ccd9e66199badb8c35ea3851a888 inkscape-0.48.3.1.tar.gz
aded57e1a851a5f3d763fd892c085fe1 inkscape-0.48.3.1.tar.gz.asc
b1bbe021af4eab8a4c6bb2e4833c6eaf inkscape-0.48.3.1.zip
d9f81d36f1e5a9679911dbc12d53d2b9 inkscape-0.48.3.1.zip.asc
SHA1 Sums
23344555a1b5cc7909ad01d926cfaddb67bfbde9 inkscape-0.48.3.1.tar.bz2
780bf43ce5148df35420926702b05afadfade239 inkscape-0.48.3.1.tar.bz2.asc
9a09a97d184e09c2ee7f9956bfe073b7313e919e inkscape-0.48.3.1.tar.gz
c8b963d43f56fb7bf42e9474b1b0de7d91be3433 inkscape-0.48.3.1.tar.gz.asc
b6de562e8c11442afb3d67a59d4d6f82f0c6edd6 inkscape-0.48.3.1.zip
a17c423b151110d2dab6fd770beb20aaf134caa4 inkscape-0.48.3.1.zip.asc
--Ted
8 years, 9 months
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
libvisio is available
by Alexandre Prokoudine
Hi,
During this GSoC a LibreOffice student and her mentor implemented
support for VSD, binary Microsoft Visio documents, that Microsoft
never bothered to publish a specification on. The student managed to
do far more that she expected and ended up with a nice C++ library for
parsing VSD called libvisio that supports all geometric primitives,
formatted text, embedded stencils, all kinds of fills and strokes etc.
The long story is here:
http://libregraphicsworld.org/articles.php?article_id=41
Now, the short story is that the libvisio library (currently at
v0.0.7) has a tool called vsd2xhtml which converts VSD to SVG
documents and embeds them into XHTML documents. So it looks like it's
possible to write an extension for loading VSD directly to Inkscape.
Otherwise you have to do some text editing to get an SVG out of that
XHTML.
Howevere there is a party trick involved. Since VSD files are often
multipage, the convertor dumps every page into same XHTML file one by
one. So if someone decides to have a go at it, I think it would rather
be loader similar to our PDF loader which provides preview for letting
a user to choose a page for importing.
Alexandre Prokoudine
http://libregraphicsworld.org
8 years, 10 months
0.48.3.1 Windows installer
by Krzysztof Kosiński
Hello all
I have a Windows installer ready, and it seems to work correctly. It
is 36 MB, so too big to send via email. Where should I upload it so
that others might test?
Regards, Krzysztof
9 years, 1 month
New Cairo release rumors...
by Tavmjong Bah
A couple of weeks ago on the Cairo mailing list there was a request for
a release engineer to drive Cairo 1.12 home. Do we have anything that we
want to see in the next Cairo release? I seem to recall there being an
issue with being able to set the EPS bounding box. Any others?
Tav
9 years, 1 month
