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, 4 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, 8 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
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
Powerstroke requests
by Johan Engelen
Hi all,
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...)
Ciao,
Johan
11 years, 1 month
Re: [Inkscape-devel] OCAL Dialog Redesign
by Andrew
Hi Guys,
So I have been doing a lot of work on the Import from OCAL dialog and I
have finally finished! I was wondering whether I could get some testing,
especially on some different platforms with different internet connections.
All you need to do is get my branch using:
bzr branch lp:~and471/inkscape/ocal-dialog-improvements
And then compile as usual. You will find the dialog in File > Import
Clip Art
So yeah, basically I want a lot of testing, to iron out any errors that
I have missed and also feedback on the stuff I have done. Then once that
is all done, I shall propose for merging into trunk.
A list of changes is below, as well as a link to screenshots of the new
dialog.
Thanks!
--
Andrew
Screenshots:
http://wiki.inkscape.org/wiki/index.php/OCAL_Dialog_Re-Design
== Changes ==
* UI Redesign (which includes)
- Altered the padding and packing of all widgets
- Added search entry with clear and search icons
- Added OCAL Logo overlay
- Put descriptions inline in list
- New preview widget that shows extra metadata
- New status widget to notify on errors/success etc.
- Dialog is now persistent (retains state)
- Better messages for the user
- Changed title/menuitem to 'Import Clip Art'
* Backend stuff (which includes)
- Use new GFile API instead of depreciated GNOMEVFS
- Use async methods so the UI isn't blocked
- Use smaller, thumbnail images in the preview widget (save on
bandwidth and increase speed)
- Implement cancelling of operations
- Put downloaded resources into one directory, from which we can
use later
- Big cleanup in terms of code
11 years, 2 months
Cleaning up Inkscape's SVG output.
by Tavmjong Bah
Hi,
I have just checked into trunk some of the fruits of Abhishek's GSOC
project to improve Inkscape's SVG output. Abhishek wrote the core
routines to which I added a variety of utility functions. This code can
result in cleaner and smaller SVG. It does the following things:
For a given element (<rect>, <path>, etc.) it checks:
1. That all attributes are valid.[1]
2. That properties are appropriate.[2]
3. That properties are useful.[3]
What Inkscape does when it finds a problem is controlled by settings
under the "SVG output" section of the Inkscape Preferences dialog. For
each of the above cases, you can independently:
1. Print out warnings to the console (if running Inkscape from the
command line).
2. Delete the invalid or not useful items.
In the dialog, you can choose when Inkscape should test the SVG:
1. When reading files. (If this option is enabled at start-up,
files Inkscape uses internally like icons.svg will also be checked.)
2. When editing files. (Mostly useful for debugging Inkscape.)
3. When writing files.
This code has been test on a variety of SVG files but it will need much
broader testing. The default preferences are set to do nothing so as to
avoid the risk of damaging files. Please take your favorite SVG files
and compare the visual output when the "Remove" and "Writing" boxes are
checked in the Inkscape Preferences dialog. Also, compiling the code
under Windows and OSX needs to be checked.
Tav
[1] Only elements in the SVG name space are tested.
[2] The SVG specification explicitly allows styling properties such as
'font-family' on most SVG elements (e.g. <rect>) but there a many cases
where they are of no use.
[3] A property is useful if it changes an inherited or default value.
11 years, 3 months
