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
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
Inkscape 0.49 Proposed Release Plan
by Josh Andler
Hey All,
The following is based on previous release plans. Let me know if
there's anything missing. One thing I want to do differently is the
bug hunt. No score for this release, only going for bugs milestoned
for 0.49 instead. This also means we need to hit the tracker to ensure
the milestoned ones are correct and to milestone and must fixes. The
number of bugs already fixed in trunk is huge, so getting the work out
for further testing "soon" is better. Dates are subject to change as
always, hopefully they could be moved up (with the exception of the
the time between Feature Freeze and Hard Freeze, for the sake of the
translators). Translators, I would recommend getting started sooner
rather than later.
1. Open development. (In Progress)
2. Chill. (September 21, 2012)
Development focuses on wrapping up.
No further refactoring.
Identify 'make distcheck' issues
Triage bug reports
Run an About Screen contest
First draft of Release Notes.
Update tutorials and other docs
3. Frost. (October 5, 2012)
Most development complete.
Release Notes should be >90% filled in.
Bug Hunt: Target those milestoned for 0.49.
Post alpha quality tarball.
4. Feature Freeze. (October 26, 2012)
No further development work.
Disable features that can't be finished in time.
Focus on critical bug fixing.
Finalize all tutorials, docs, etc.
Finalize all extensions.
Translators create/update translations.
Inkscape must pass 'make distcheck'
Post beta quality tarball.
5. Hard freeze. (November 23, 2012)
Only release wardens can commit to mainline.
No further string changes.
Focus on release-critical bug fixing.
Finalize translations, release notes, etc.
Post Release Candidate tarball.
Packagers test creating pkgs.
6. Branch. (December 7, 2012)
Establish the Stable Branch for release
Complete any late-late-late work.
Final verification of packaging, release notes,
docs, etc.
Publish more release candidates until ready for
release.
Plan 0.49.1+ release(s), as needed
7. Release. (December 21, 2012)
Post inkscape-0.49.tar.gz
Post packages
Post official announcements
8. Open development.
Yes, it seems like a ridiculously short timeframe given our history of
making releases happen and how much we've strayed in the past. I do
however feel it is doable given the change in the bug hunt requirement
for this cycle. That usually holds us up. Also, no platform specific
bugs will hold up this release. We will release for specific platforms
as issues are taken care of.
If anyone has objections or concerns, please speak up. As stated in
the past... this is doable. We're good, we're smart, we're competent,
and we have the resources... we just need to be focused to make this
happen. Let's do this!
Cheers,
Josh
10 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
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
Shared library
by Alex Valavanis
Hi All,
I'm not an expert on this kind of thing, but is there a reason why we
don't distribute libinkscape as a shared library? At the moment,
Inkscape and Inkview share a huge amount of code and they are both
pretty big executables. Presumably, we'd save a lot of installation
space with a shared lib.
AV
10 years, 6 months
Future releases
by Josh Andler
Hey All,
I'd like to proposed that after we get 0.49 out the door, we have
regular planned releases. No more "always open" trunk development. But
leverage merge windows instead... which also means needing to land
"more complete" features in trunk than we've historically allowed. I'd
love to see us have 6 month cycles to get features and fixes out to
users sooner. It's awesome to have flashy new stuff for every release,
but it's just not necessary.
What are people's thoughts on this tried and true strategy many other
projects use? Can we at least give it a shot?
Cheers,
Josh
10 years, 6 months
