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
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
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.
10 years, 9 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
10 years, 9 months
Inkscape slowing down
by LucaDC
I've not been using Inkscape for a while lately.
Yesterday I made a new drawing and noted a considerable slowdown while
moving objects.
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
slow update.
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
Luca
--
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.
11 years, 1 month
Re: [Inkscape-devel] Powerstroke requests
by Valerie
Weird behavior to report:
1. Make a powerstroke (example: triangle in)
2. Make a duplicate (ctrl+D)
3. Move some of the nodes of the second powerstroke
4. Modify the width of the second powerstroke
Behavior: the width of the first powerstroke gets modified as well.
This does not happen if you select and move the second
powerstroke with F1 before modifying its width.
This does not happen with ctrl+C.
I was trying to trying to do easy eyelashes by making one
powerstroke the shape I wanted, duplicating it, moving the end
slightly and modifying the width slightly (to have a bit of variety).
I was also trying to do some sketchy effects with the same
method.
Any clue?
11 years, 1 month
Inkscape 0.48.3?
by Alex Valavanis
Hi All,
Any thoughts about when we're going to release Inkscape 0.48.3?
Coming at this from an Ubuntu maintenance perspective, the next LTS
release (12.04 - "Precise Pangolin") will hit feature freeze on Feb
16, so it would be great to update the binary-package in the
Ubuntu-main repository before that date. Large numbers of Ubuntu
desktop users could potentially end up sticking with it for a couple
of years, so I think it makes sense to squash as many bugs as
possible!
Does anyone else agree with releasing 0.48.3 in the very near future?
Is there any reason to hold back?
If we're going to do this, we'd need to release a source tarball by ~9
Feb. We've already committed a fair number of bug fixes in 0.48.3[1],
so it would probably already be useful to users in its current form.
However, perhaps a two-week bug-squashing session would be nice before
we go ahead.
Best wishes,
AV
[1] https://launchpad.net/inkscape/+milestone/0.48.3
11 years, 1 month
inkscape at graphicall
by Alexandre Prokoudine
Hello gang,
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.
Alexandre Prokoudine
http://libregraphicsworld.org
11 years, 1 month
support multiple extension locations
by Tim Cuthbertson
I was looking into how one might provide inkscape extensions using
0install[1], which basically amounts to adding extensions _without_
touching any well-known paths, typically using environment variables.
I've done the same thing for gnome-shell, by essentially adding each
extension's location to $XDG_DATA_DIRS. So for example to run
gnome-shell with the shellshape extension[2], $XDG_DATA_DIRS might
contain the following dir:
/home/tim/.cache/0install.net/implementations/sha256=2437376cd245ee4f09b0738e1cc7392a04750a9cec4b0875bf71606703d9ee01/xdg
which contains a `gnome-shell` directory with the files you would
normally put in /usr/share/gnome-shell if you were installing them
system-wide.
I wondered if this would work for inkscape as well, but after having a
look at the source, it doesn't seem likely. Based on the
`profile_path` function in inkscape.cpp:
- inkscape seems to assume that there will be at most one folder for
each of (user, system) level preferences
- it assumes preferences and extensions will all live in the same location.
These both go against the XDG spec[3], which recommends that config
and data live in different locations and should be able to be looked
up in a cascading fashion (i.e supporting multiple paths in
$XDG_DATA_DIRS). These restrictions also make it very difficult to use
0install to distribute extensions since that would require:
- readonly `extensions` directories - all 0install implementation
directories must be read-only as they can be shared between users
(among other reasons)
- cascading lookup of extensions in _all_ paths in $XDG_DATA_DIRS -
adding or removing plugins must be possible by affecting what is in
XDG_DATA_DIRS, rather than modifying folders in the filesystem.
So, I guess my questions are:
- am I wrong about my conclusions here? I've looked at the source,
but may have missed something.
- is there any interest in extending the extension loading mechanism
to support loading extensions across all $XDG_DATA_DIRS? Presumably
this would be implemented for _all_ data types (gradients, icons, etc)
as well as just extensions.
Cheers,
- Tim.
[1]: http://0install.net/
[2]: http://gfxmonk.net/dist/0install/shellshape.xml
[3]: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
11 years, 1 month
