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.
8 years, 6 months
Mac OS X Mountain Lion x86_64 packaging of 0.48.4
by Valerio Aimale
Hello,
I am not an official packager, but I was eager to have an updated
version of Inkscape for Mac OS X and I noticed that nobody is packaging
the new version.
I've packaged it for Mountain Lion and x86_64. It should be considered a
beta packaging. I've packaged from version 0.48+devel r12005
You can download it at:
https://rapidshare.com/files/3885726044/Inkscape_MountainLion_x86_64.dmg
The Mac Os X packaging infrastructure in the source tree is a bit
ancient. Things I've noticed:
- configure.ac uses syntax that is not conforming anymore with
autoconf/automake/authohear 1.13. Going forward that should be updated.
- the scripts osx-build.sh os-app.sh needs update for the newest Xcode
versions. they don't work out of the box.
- the dylib base relocation infrastructure needed to be rewritten
- the Platypus-derived ScriptExec executable might not be needed anymore
- in this version, the app bundle executes the sh script directly.
Features:
- The version I packaged runs gtk-2.0+quartz. It does not need
X11/Xquartz anymore to run. This is the direction GIMP has gone to as well.
- It uses the same theme as GIMP. I think it's a good consistency
decision, and it's the theme that looks best on Mtn Lion.
If somebody want to try and report problems, I'd appreciate it
Valerio
9 years, 9 months
Mac OS X Build 0.48.4 RC1
by Valerio Aimale
This is a good build that is close to being a release:
For Mountain Lion
http://rapidshare.com/files/4204947016/Inkscape-r0.48.4-r9943-10.8%2B-x86...
For Lion:
http://rapidshare.com/files/3505176415/Inkscape-r0.48.4-r9943-10.7%2B-x86...
- the menu should be all working but the "Open Recent" submenu. No
matter which item is selected, the top open is always opened. This is a
bug between gtk/gtk_recent_menu_manager() and gtk-mac-integration. Needs
more analysis, not an easy fix.
- Quit, About and Preferences menu items moved under the app menu.
- python should be fully working now on Lion and Mountain Lion
- uniconvertor/sk1libs installed and fixed
The sk1libs/utilsfs.py line
return ['/']
really should be
return ['/System/Library/Fonts', '/Library/Fonts',
os.path.expanduser("~/Library/Fonts")]
- no more noise on the terminal stderr
- bunch of improvements and changes in the build system
10 years, 2 months
Re: [Inkscape-devel] Image resampling [PATCH 0/6]
by Krzysztof Kosiński
2012/11/24 Søren Sandmann <sandmann@...2931...>:
> Hi,
>
> Reviewing the supersampling patch here:
>
> http://cgit.freedesktop.org/~ajohnson/pixman/log/?h=supersampling
>
> I wasn't happy with either the performance and image quality, and I
> realized that the whole supersampling approach just isn't going to
> fly. Since I told people to do it that way, I apologize for that. The
> approach advocated by Bill Spitzak in the various downsampling threads
> of computing a convolution kernel up front, is the much better way to
> go. To make up for being misleading, the following patches implement
> comprehensive support for high-quality image scaling filters.
This is extremely awesome.
Regards, Krzysztof
10 years, 9 months
Android tablet as drawing input
by Jon Cruz
Hey Inkscapers, check this out
http://www.gimpusers.com/news/00462-use-android-tablet-as-graphics-tablet...
A simple use of an android tablet to feed as an extended X input device for drawing in Linux. Needs the X11 driver part to feed the data from the Android device to the X11 system, but from there it should end up working for all apps, including Inkscape.
This is overlapping an area I was working at from the other direction, but should be easy for me to hook up to from Inkscape directly. My talk at LCA 2013 is going to be on that input work (using wiimotes, guitars, gamepads, etc.) and once I get to the point of reading in drawing data (in addition to current use as keys and pressure modifiers) using that should be very simple and avoid the need for any X11 drivers.
Oh, and from what I see of the protocol, it should end up working cross-platform.
10 years, 9 months
LGM 2013
by Alexandre Prokoudine
Hello team,
As you probably already know, registration for LGM 2013 is open, and
talk proposals can be submitted.
The event is taking place on April 10-13 in Madrid. See
http://libregraphicsmeeting.org/2013/.
LGM used to have a nice attendance by Inkscape team in 2006-2010, but
then, AFAIK, things have changed.
Has anybody already made up their minds to participate this year? If
you did, I'd be happy to publish news and invite community to attend
the event, so that they could meet you in person.
Alexandre Prokoudine
http://libregraphicsworld.org
10 years, 9 months
Pointers -> references
by Johan Engelen
Hi all,
A code snippet from trunk:
void srgb_to_linear( double* c ) {
if( *c < 0.04045 ) {
*c /= 12.92;
} else {
*c = pow( (*c+0.055)/1.055, 2.4 );
}
}
Alright, this method should not do a NULL check for performance reasons
(I assume). But, shouldn't we use a reference in this case then? To
signal clearly that the method does not accept NULL pointers without
crashing:
void srgb_to_linear( double &c ) {
if( c < 0.04045 ) {
c /= 12.92;
} else {
c = pow( (c+0.055)/1.055, 2.4 );
}
}
I'm trying to reduce the number of crashes due to simple NULL pointer
crashes. I find such bugs satisfying to fix because it takes really only
1 minute to locate the bug and 1 minute to fix and commit it, but........
Ciao,
Johan
10 years, 10 months
