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?
- 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.
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.
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
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.
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)
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:
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
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.
I've not been using Inkscape for a while lately.
Yesterday I made a new drawing and noted a considerable slowdown while
After some investigation, I found that this is mainly due to bounding box
update, i.e. while an object (or a group of objects, but a single one is
enough) is moved, its bounding box is drawn as a dashed rectangle around it;
when I start moving, the rectangle stays in its original position for a
while (and moving is ok), then if I stop moving or after a while it gets
updated in the new position and this takes ages! I can't work with such a
I've got a Pentium IV 3.2 GHz with 2 GB of RAM. I know it can be considered
pretty old a system, but I run all the software I need on it without any
problem. I feel that it should be fairly enough for an application like
Inkscape (I never use filters or other graphical features, only technical
drawing); and it was, up to few weeks ago.
I suspect that the bounding box is continuously recalculated but this is not
needed as the object cannot change while moving it; also, calculating the
bounding box for a single object should not be heavy at all.
So, should I start worrying for Inkscape requiring too much resources for me
in the near future (or even present) or can this be simply considered a bug?
I can easily trigger it by opening a new document, drawing a couple of
circles and a couple of rectangles, selecting all four objects and start
duplicating them with the spacebar: after a few duplications my CPU usage
goes very high and moving objects becomes a pain. It seems related to how
many objects are present in the drawing, which is a nonsense because moving
a single object should not depend on anything else but the object itself (I
tried with all snappings disabled too, of course).
Thanks and regards
View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p32606652.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Given that we are now parted from modevia, how about unloading builds
to graphicall which mostly hosts Blender builds? It already has an
Inkscape section that looks rather lonely.
Who would be interested in a good old fashioned IRC meeting to discuss
various things about the project? It seems like other projects seem to be
able to pull them together (on a regular basis no less), so why not us? I
would especially like if we could get the likes of Krzysztof, Johan,
Tavmjong, Jasper, Jon, Alex, Kris, and anyone else who would be interested.
This especially goes for anyone who lurks on the devel list who is
interested in contributing but still hasn't introduced themselves yet
(they're always around). ;)
I think it would be good to get people together to help us help each other.
I think one of the things we should remember is that sometimes reviewing
others work or just answering questions, can be more valuable than actually
writing code yourself. I'm not asking for a huge time commitment or
anything. If you are interested please chime in with any preferred dates or
times so we can coordinate based on global distribution of participants.
I'll throw out the 18th as a possible date... mainly because it's not
terribly likely that this will happen and the 18th is my birthday so that's
my wish. :P
I don't know what to work on anymore...
Please help me out by test driving the Powerstroke LPE and tell me what
you dislike and what you'd like to be added.
(I already know you want it to work with tablets, I am waiting for my
tablet to arrive...)
A recent commit to lib2geom compressed almost all commits since februari
into one. Very annoying, although I know you can find out what those
individual commits were with some more clicking.
These mistakes don't surprise me; I am scared of the bzr tool that does
things I do not understand.
So to make people aware of the dangers of bzr, I'd like to give advice
to simple folks like me:
I strongly advise you to not work in branches and merge it into trunk,
and stay away from any other so-called convenient advanced functionality
of bzr, like push-pull-whatever. Simply use it in 'svn mode'.
If you have fully understood how bzr works, perhaps you can try to use
the extra functionality. In that case, learn how to foul up the history
(like rev2000 in lib2geom) so you don't type in such commands.
Thank you very very very much,
(PS. no hard feelings to the committer of course! I blame the tool that
allows these things to happen)