- Inkscape Devel - Inkscape Mailman

No default units in dev build Inkscape0805062005.7z
by worms invasion 20 May '08

20 May '08

I have downloaded http://inkscape.modevia.com/win32/Inkscape0805062005.7z yesterday, and tested it. It has a weird problem : no default units are showing, and nothing is showing when I try to use the drop-down menus to select a unit. I am on Windows 2000 - which is known to have problems with drop-down boxes, but nothing can be done at OS level, I believe. Anyway... Has someone the same problem on other OSs? Also, when I enter 10.00 in the box to transform, it becomes 1000000.00, but I can't select "pix". Same in the document properties. Screenshot at : http://www.corpsmoderne.net/~eve97/vertex/default_units_missing.png ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

4 4

GSL dependency
by unknown＠example.com 19 May '08

19 May '08

Hi all, I just updated Inkscape's copy to the latest 2geom svn rev. I tried to add the GSL dependency to configure.ac but have no way to check whether it has gone wrong or not. I am very sorry if this breaks your build :-( -Johan

4 7

isFinite() problem again
by Maximilian Albert 19 May '08

19 May '08

Hi all, recently there was a discussion about name clashes involving is_finite(). The problem appeared to be solved but now I ran into it (or something similar?) again. Namely, adding the line #include "live_effects/effect.h" to object-edit.cpp yielded the following compile error: object-edit.cpp: In function ‘void sp_spiral_outer_set(SPItem*, const NR::Point&, const NR::Point&, guint)’: object-edit.cpp:1121: error: ‘isFinite’ was not declared in this scope When I additionally changed the line #include "isnan.h" to #include "2geom/isnan.h" and replaced isFinite() with IS_FINITE(), compilation worked fine again. Thus it seems that there is some kind of clashing between isnan.h and 2geom/isnan.h. Has anyone else seen this and what should be done to avoid further difficulties in the future? Max

3 3

NEW: Spiro splines LPE
by bulia byak 19 May '08

19 May '08

Spiro splines are a novel way of defining curvilinear paths developed by Raph Levien. Recently, Spiro support was added to the FontForge font editor, and now it is available in Inkscape too. It takes some getting used to, but for certain tasks Spiros have a clear advantage over Bezier curves. http://www.levien.com/spiro/ A Spiro path is defined by a sequence of points, but unlike a regular path with Bezier curves, all Spiro points lie on the path and there are no off-path handles. The curvature of the path is defined entirely by the positions of the points and their types. The path behaves very similar to a springy rod which is forced to pass through the given points and which uses the minimum possible curvature to satisfy the requirement. As such, it feels quite natural and the resulting path is very smooth - with the kind of smoothness you can achieve with Beziers only after much tweaking. To create a Spiro path, select any path and assign the "Spiro spline" path effect to it. There are no parameters. Each node of your path becomes a point of a Spiro path, depending on the type of node: * Smooth nodes (those with two collinear Bezier handles) become curve points of the Spiro path; such points bend the curve but must remain smooth. Note that the length or direction of the Bezier handles of the source path is ignored; the only thing that matters is that the node is smooth. * Cusp nodes of the source path become corner points of the Spiro path. Between two corner points, the path is always a straight line. * Half-smooth nodes - those with one Bezier handle collinear with a straight line segment on the other hand - become "left" or "right" points on the Spiro path which behave exactly the same: they sit between a straight line and a curve and enforce that these two segments join smoothly without a cusp. Note that what matters is the actual collinearity of a node's handles, regardless of the node type that the node has in the Node tool; for example, if a cusp (diamond-shaped) node has collinear handles, it will become a curve point of the Spiro path. For creating half-smooth nodes, use Ctrl+dragging of the node handle to make it snap to the direction of the straight line segment on the other side, or press Shift+S to lock it to that direction. Some configurations of points do not converge and produce wild loop and spirals instead of a smooth curve. According to Raph, "The spline solver in this release is _not_ numerically robust. When you start drawing random points, you'll quickly run into divergence. However, "sensible" plates based on real fonts usually converge." Avoid too sharp changes in direction between points to prevent divergence. Hopefully, the robustness of the algorithm will be improved in future releases. For now, to edit Spiro paths viewing the result in real time, you have to use the Node tool. The Pen tool does not yet allow you to preview a Spiro as you draw, although you can paste the Spiro effect on the path and see the result as soon as the path is finalized. You can always use the Node tool to continue a Spiro path by duplicating and dragging away its end nodes. Also, when you have a Spiro path selected, you can add a new subpath to it with Pen or Pencil if you start drawing with Shift. Raph: Thanks for your code, and let me know when you have a new version :) I have copied only spiro.c/h and bezctx.c/h to Inkscape tree, renaming .c to .cpp and removing debug output, but otherwise unchanged. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

10 17

I knew Bryce was talented, but...
by rygle 19 May '08

19 May '08

I hadn't seen this yet... http://www.youtube.com/watch?v=wKz7ZVZR2mE Rygle =^D -- View this message in context: http://www.nabble.com/I-knew-Bryce-was-talented%2C-but...-tp17316637p173166… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 0

envelope LPE
by bulia byak 19 May '08

19 May '08

Thanks to whoever added this, it's fantastic! I have one request though: can you please combine the four envelope paths into one four-sided envelope? It will be much easier to edit this way. I understand that this may introduce the ambiguity as to where one side of the envelope ends and another starts, because the envelope sides may be more than 2 nodes long. But I have a rough idea on how to handle this: Imagine a line that goes at 45 degrees from SW to NE, and imagine that that line moves from infinity in the SE direction. The first node of the envelope path that it touches will be considered the top of the left side and the left end of the top side. Same for finding the 3 other corners. I think it will be relatively easy to implement - and much easier to use than the four separate sides. Thanks again, and by the way please add a description of the new feature to http://wiki.inkscape.org/wiki/index.php/ReleaseNotes047 -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

LPEs/paths and knotholders
by Maximilian Albert 18 May '08

18 May '08

Hi, I was experimenting with additional knotholders for items carrying an LPE but I'm having problems. What I did was simply to add another case distinction to sp_item_knot_holder() in object-edit.cpp. It checks whether an object has an LPE applied to it, in which case it returns a different knotholder than the standard one. The handling methods for the new knotholder are minimal (a 'set' method which does nothing and a 'get' method wich just returns a constant point) but Inkscape keeps crashing when handles corresponding to the "ordinary" knotholder are moved. I suspect that the new knotholder somehow interferes with the one that is created for paths in nodepath.cpp but I can't seem to find the exact cause of the problem. The backtraces don't look very helpful to me either since the crash happens in different places and I haven't yet found the common cause (see below for 2 sample backtraces; note that the line numbers may slightly vary due to my changes to the code). I wonder if anyone has an idea what could be wrong. Really some kind of interference between the two knotholders? How do the knotholders for paths work anyway? Is object-edit.cpp the wrong place to alter them? Thanks in advance, Max Backtraces: #0 0xb7376c77 in g_str_hash () from /usr/lib/libglib-2.0.so.0 #1 0xb73484db in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0 #2 0xb7341271 in g_quark_from_string () from /usr/lib/libglib-2.0.so.0 #3 0x087b783e in Inkscape::XML::SimpleNode::attribute (this=0x9ef1600, name=0x40240000 <Address 0x40240000 out of bounds>) at xml/simple-node.cpp:222 #4 0x081eae1d in update_repr_internal (np=0xaee6c00) at nodepath.cpp:578 #5 0x081ee47c in sp_nodepath_update_repr (np=0xaee6c00, annotation=0x884685c "Move nodes") at nodepath.cpp:613 #6 0x081eeb4b in node_ungrabbed (data=0xb2a1c40) at nodepath.cpp:3363 #7 0xb741265a in g_cclosure_marshal_VOID () from /usr/lib/libgobject-2.0.so.0 #8 0xb74056f9 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #9 0xb7419c3d in ?? () from /usr/lib/libgobject-2.0.so.0 #10 0x09a99b00 in ?? () #11 0x00000000 in ?? () #0 0x081a122c in sp_document_maybe_done (doc=0xb08eb40, key=0x0, event_type=111, event_description=@0xbfbff160) at document-undo.cpp:173 #1 0x081a14f0 in sp_document_done (doc=0xb08eb40, event_type=111, event_description=@0xbfbff190) at document-undo.cpp:125 #2 0x081ee4c4 in sp_nodepath_update_repr (np=0xb08eb48, annotation=0x884685c "Move nodes") at nodepath.cpp:617 #3 0x081eeb4b in node_ungrabbed (data=0xb7f8ae0) at nodepath.cpp:3363 #4 0xb73c865a in g_cclosure_marshal_VOID () from /usr/lib/libgobject-2.0.so.0 #5 0xb73bb6f9 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #6 0xb73cfc3d in ?? () from /usr/lib/libgobject-2.0.so.0 #7 0x0b974be8 in ?? () #8 0x00000000 in ?? ()

4 6

Re: [Inkscape-devel] [Clipart] tutorials in Galician
by Jon Phillips 18 May '08

18 May '08

Cool, that is so great! I'm fwd'ing this to the inkscape list which handles this type of inkscape specific tutorial. Any takers on this and/or for blogging it on inkscape site? Jon On Thu, 2008-05-15 at 10:12 +0200, alberte mendez lopez wrote: > Hi All! I hope I'm doing this allright, since is my first e-mail to a > list. > I'm a Secondary school teacher, and this is just to say that i've made > some tutorials about inkscape for my pupils, based on all the great > stuff that i've found on this community. Now I'm putting them on the > web here , they're all in Galician (my little country language), so i > suppose they won't be very useful for the most of you :( , and they > are all on inkscape 0.45. > Just wanted to thank (and so do my pupils) to everybody who keep this > alive. > _______________________________________________ > clipart mailing list > clipart@...626... > http://lists.freedesktop.org/mailman/listinfo/clipart -- Jon Phillips San Francisco, CA + Guangzhou + Beijing GLOBAL +1.415.830.3884 CHINA +86.1.360.282.8624 jon@...235... http://www.rejon.org IM/skype: kidproto Jabber: rejon@...896... IRC: rejon@...897...

1 0

Re: [Inkscape-devel] PDF import crash, but not in 0.46
by Bob Jamison 16 May '08

16 May '08

Yes, I believe that all of the patches made it into the trunk. However, I don't think that any of them applied to Poppler. This sounds like simply a typical common regression here. ^^ We haven't done a "debug" upload in a few weeks. Time to do another one, I guess. bob -----Original Message----- >From: J.B.C.Engelen@...1578... >Sent: May 14, 2008 8:10 AM >To: inkscape-devel(a)lists.sourceforge.net >Subject: [Inkscape-devel] PDF import crash, but not in 0.46 > >Hi all, > >PDF import crashes for me on Windows with current trunk. It does not crash in the Inkscape 0.46 binary that I just downloaded. > >Have all windows patches been applied to trunk? > >Thanks, >Johan > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Microsoft >Defy all challenges. Microsoft(R) Visual Studio 2008. >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 2

Program too big to fit in memory
by Marcin Floryan 16 May '08

16 May '08

Hello! On today's compile of Inkscape (XP, SVN 18630) I got an unpleasant surprise. My system complains: Program too big to fit in memory with inkscape.exe being 224,113,108 B Although I have 2G of RAM I might have starved my XP of it a bit running quite a few programs already but nevertheless... are we going towards a boundary (or is it just my compilation). Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]

3 4

Re: [Inkscape-devel] SVGFonts: lot's of questions
by Richard Hughes 15 May '08

15 May '08

>> The difficulty we're having is that not enough of Inkscape's rendering >> has been converted to Cairo for it to be easy for us to use Cairo's >> user-fonts for output. Do you think it would be possible for us to >> create a fake Cairo user-font which only has a partially-implemented >> render_glyph_func (returns the extents but doesn't draw anything) and >> then we figure it all out later and send it to our own renderer? I'm >> just looking for a more incremental approach to this feature rather >> than having to bundle in a complete Cairo conversion at the same time. > How do you use Pango currently? You can do the same approach with > pangocairo. I assume you use pangoft2 to extract glyph outlines and > render them yourself. You can do the same with pangocairo. You don't > have to use cairo for everything... Yeah, something like that. I reckon the conversion for existing system fonts should be quite easy, but what about user-fonts? Do I understand that your design for Pango will not call the render_glyph_func at all, i.e. we can leave it as NULL until we've figured out how to do things properly? Richard.

2 1

Re: [Inkscape-devel] SVGFonts: lot's of questions
by Richard Hughes 14 May '08

14 May '08

> No. There's no way to implement a feature like this without help from > the backends, and I'm only going to do it in the cairo backend as that's > pretty much the only supported backend at this time. What other backend > do you have in mind? pangoft2? Inkscape really should just use the > cairo backend. Many cool new features (like vertical text support) are > only implemented in the cairo backend. OK, I was just trying to figure out what our options were. Of course Inkscape should be using the Cairo backend, we just don't at the moment. The difficulty we're having is that not enough of Inkscape's rendering has been converted to Cairo for it to be easy for us to use Cairo's user-fonts for output. Do you think it would be possible for us to create a fake Cairo user-font which only has a partially-implemented render_glyph_func (returns the extents but doesn't draw anything) and then we figure it all out later and send it to our own renderer? I'm just looking for a more incremental approach to this feature rather than having to bundle in a complete Cairo conversion at the same time. Changing the subject slightly, I can't see any mention of kerning in the current Cairo API. Is this something for later, or am I just ignoring things right in front of me again? Richard.

1 0

adaptiveThreshold.cpp:20: error: 'image' was not declared in this scope
by Jeff Kowalczyk 14 May '08

14 May '08

Is anyone else seeing the following build error on inkscape trunk? depbase=`echo extension/internal/bitmap/adaptiveThreshold.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/lib/perl5/5.8.8/i686-linux/CORE -I/usr/include/freetype2 -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DRELAYTOOL_CRYPTO='static const int libcrypto_is_present = 1; static int __attribute__((unused)) libcrypto_symbol_is_present(char *m) { return 1; }' -DRELAYTOOL_SSL='static const int libssl_is_present = 1; static int __attribute__((unused)) libssl_symbol_is_present(char *m) { return 1; }' -DHAVE_SSL -I/usr/include/freetype2 -I/usr/include/poppler -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -DPOTRACE=\"potrace\" -pthread -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gtkspell-2.0 -I../cxxtest -Werror=format-security -Wall -Wformat -Wformat-security -W -D_FORTIFY_SOURCE=2 -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -O2 -march=i686 -pipe -MT extension/internal/bitmap/adaptiveThreshold.o -MD -MP -MF $depbase.Tpo -c -o extension/internal/bitmap/adaptiveThreshold.o extension/internal/bitmap/adaptiveThreshold.cpp &&\ mv -f $depbase.Tpo $depbase.Po In file included from extension/internal/bitmap/imagemagick.cpp:29: extension/internal/bitmap/imagemagick.h:14:22: error: Magick++.h: No such file or directory In file included from extension/internal/bitmap/adaptiveThreshold.h:9, from extension/internal/bitmap/adaptiveThreshold.cpp:12: extension/internal/bitmap/imagemagick.h:14:22: error: Magick++.h: No such file or directory In file included from extension/internal/bitmap/adaptiveThreshold.h:9, from extension/internal/bitmap/adaptiveThreshold.cpp:12: extension/internal/bitmap/imagemagick.h:24: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.h:24: error: expected ',' or '...' before '*' token In file included from extension/internal/bitmap/adaptiveThreshold.cpp:12: extension/internal/bitmap/adaptiveThreshold.h:23: error: 'Magick' has not been declared extension/internal/bitmap/adaptiveThreshold.h:23: error: expected ',' or '...' before '*' token extension/internal/bitmap/adaptiveThreshold.cpp:20: error: variable or field 'applyEffect' declared void extension/internal/bitmap/adaptiveThreshold.cpp:20: error: 'Magick' has not been declared extension/internal/bitmap/adaptiveThreshold.cpp:20: error: 'image' was not declared in this scope make[2]: *** [extension/internal/bitmap/adaptiveThreshold.o] Error 1 make[2]: *** Waiting for unfinished jobs.... In file included from extension/internal/bitmap/imagemagick.cpp:29: extension/internal/bitmap/imagemagick.h:24: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.h:24: error: expected ',' or '...' before '*' token extension/internal/bitmap/imagemagick.cpp:39: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:39: error: expected ',' or '...' before '*' token extension/internal/bitmap/imagemagick.cpp:43: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:43: error: ISO C++ forbids declaration of 'Image' with no type extension/internal/bitmap/imagemagick.cpp:43: error: expected ';' before '*' token extension/internal/bitmap/imagemagick.cpp: In constructor 'Inkscape::Extension::Internal::Bitmap::ImageMagickDocCache::ImageMagickDocCache(Inkscape::UI::View::View*)': extension/internal/bitmap/imagemagick.cpp:57: error: class 'Inkscape::Extension::Internal::Bitmap::ImageMagickDocCache' does not have any field named '_images' extension/internal/bitmap/imagemagick.cpp:72: error: '_images' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:72: error: expected type-specifier before 'Magick' extension/internal/bitmap/imagemagick.cpp:72: error: expected `;' before 'Magick' extension/internal/bitmap/imagemagick.cpp:85: warning: deprecated conversion from string constant to 'char*' extension/internal/bitmap/imagemagick.cpp:87: error: expected type-specifier before 'Magick' extension/internal/bitmap/imagemagick.cpp:87: error: expected `;' before 'Magick' extension/internal/bitmap/imagemagick.cpp: In destructor 'virtual Inkscape::Extension::Internal::Bitmap::ImageMagickDocCache::~ImageMagickDocCache()': extension/internal/bitmap/imagemagick.cpp:104: error: '_images' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:105: error: type '<type error>' argument given to 'delete', expected pointer extension/internal/bitmap/imagemagick.cpp: At global scope: extension/internal/bitmap/imagemagick.cpp:111: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:111: error: expected ',' or '...' before '*' token extension/internal/bitmap/imagemagick.cpp: In member function 'void Inkscape::Extension::Internal::Bitmap::ImageMagickDocCache::readImage(const char*, int)': extension/internal/bitmap/imagemagick.cpp:118: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:118: error: expected `;' before 'blob' extension/internal/bitmap/imagemagick.cpp:119: error: 'blob' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:120: error: 'image' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:123: error: 'image' was not declared in this scope extension/internal/bitmap/imagemagick.cpp: In member function 'virtual void Inkscape::Extension::Internal::Bitmap::ImageMagick::effect(Inkscape::Extension::Effect*, Inkscape::UI::View::View*, Inkscape::Extension::Implementation::ImplementationDocumentCache*)': extension/internal/bitmap/imagemagick.cpp:156: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:156: error: expected `;' before 'effectedImage' extension/internal/bitmap/imagemagick.cpp:157: error: 'effectedImage' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:159: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:159: error: 'blob' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:159: error: expected type-specifier before 'Magick' extension/internal/bitmap/imagemagick.cpp:159: error: expected `;' before 'Magick' extension/internal/bitmap/imagemagick.cpp:197: error: expected type-specifier before 'Magick' extension/internal/bitmap/imagemagick.cpp:197: error: expected `)' before '::' token extension/internal/bitmap/imagemagick.cpp:197: error: expected `{' before '::' token extension/internal/bitmap/imagemagick.cpp:197: error: '::Exception' has not been declared extension/internal/bitmap/imagemagick.cpp:197: error: 'error_' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:197: error: expected `;' before ')' token ./util/glib-list-iterators.h: In member function 'T* const& Inkscape::Util::GSListConstIterator<T*>::operator*() const [with T = SPItem]': extension/internal/bitmap/imagemagick.cpp:222: instantiated from here ./util/glib-list-iterators.h:47: warning: dereferencing type-punned pointer will break strict-aliasing rules

3 8

Re: [Inkscape-devel] adaptiveThreshold.cpp:20: error: 'image' was not declared in this scope
by Bob Jamison 14 May '08

14 May '08

Is this using the "prefix:" attribute in the .pc file correctly? bob >>>> /usr/include/ImageMagick/Magick++.h >>>> >>> This is non-standard. It can be correct, but I'm guessing this command >>> returns the same thing it does for me: >>> >>> $ pkg-config --libs --cflags ImageMagick++ >>> -lMagick++ -lWand -lMagick >>> $ >>> >>> Which basically means the ImageMagick++.pc file is incorrect on your >>> system. I think the more standard installation is to have Magick++.h >>> in /usr/include, but I can understand someone wanting to change it. But >>> that person needs to update the package config script too or compiles >>> will break :)

1 0

PDF import crash, but not in 0.46
by unknown＠example.com 14 May '08

14 May '08

Hi all, PDF import crashes for me on Windows with current trunk. It does not crash in the Inkscape 0.46 binary that I just downloaded. Have all windows patches been applied to trunk? Thanks, Johan

2 2

Request for translation SVN commit rights
by Domas Jokubauskis 14 May '08

14 May '08

Hello, I have been using Inkscape for a couple of years now and it have been a great experience. Thank you! I'm passionate about getting proper Lithuanian language user interfaces so I did a substantial update of Lithuanian Inkscape translation for version 0.45.1. I would like to continue my work on future releases but sending changes to the mailing list and asking others to commit them is counter-productive. Thus, I would be grateful if the project's admins granted me the permission to commit changes to lt.po file. My SF.net e-mail: domasj@...58... -- Domas Jokubauskis DomasJ@...1970...

2 1

unicode<->glyphid mapping
by Felipe Sanches 13 May '08

13 May '08

I am working on nr-arena-glyphs.cpp there, at line 468: NRArenaGlyphs *g = NR_ARENA_GLYPHS(child); g->glyph holds an integer (the glyph id). As I understand it, there must be a mapping between a unicode char and its respective glyph id. How can I retrieve it? Juca

2 1

Re: [Inkscape-devel] SVGFonts: lot's of questions
by Richard Hughes 13 May '08

13 May '08

> The font data can all be fed to cairo using the user-font support that I > committed to master last week. So you have some code to write already. > You need to provide the render_glyph(). If you don't have kerning, > providing unicode_to_glyph() would be enough, but for kerning, you need > to use the full text_to_glyphs() method. > The Pango bits to make pango use cairo user-fonts don't exist yet. This > is the bug tracking that: > http://bugzilla.gnome.org/show_bug.cgi?id=347237 > While I want to fix that bug this cycle, I don't have a estimate for it > yet, and it's not on my plate for the next few weeks... Reading through that bug I'm unclear whether the proposed pango_font_description_set_domain() function could be used to support a user-font which wasn't also a Cairo user-font. Could you clarify whether it intended to be able to use this feature without being required to use Cairo? Richard.

1 0

Re: [Inkscape-devel] SVGFonts: lot's of questions
by Gail Carmichael 13 May '08

13 May '08

Looks like that pango stuff would probably help what I was doing, too. I never got to worrying about rendering fonts, just representing them in the SVG file. On Tue, May 13, 2008 at 2:24 PM, Behdad Esfahbod <behdad@...1866...> wrote: > On Tue, 2008-05-13 at 14:54 -0300, Felipe Sanches wrote: > > > > What is needed to make inkscape render this? I suppose that I should > > provide the kerning info to cairo userfonts and then cairo-user-fonts > > would call my glyph-rendering functions providing me the proper x,y > > coordinates. But how do I enable this behaviour just for Super Sans > > font? I guess there must be a way of registering new fonts with pango. > > I just don't see exactly how these pieces fit together. > > The font data can all be fed to cairo using the user-font support that I > committed to master last week. So you have some code to write already. > You need to provide the render_glyph(). If you don't have kerning, > providing unicode_to_glyph() would be enough, but for kerning, you need > to use the full text_to_glyphs() method. > > The Pango bits to make pango use cairo user-fonts don't exist yet. This > is the bug tracking that: > > http://bugzilla.gnome.org/show_bug.cgi?id=347237 > > While I want to fix that bug this cycle, I don't have a estimate for it > yet, and it's not on my plate for the next few weeks... > > Hope that helps. > > -- > behdad > http://behdad.org/ > > "Those who would give up Essential Liberty to purchase a little > Temporary Safety, deserve neither Liberty nor Safety." > -- Benjamin Franklin, 1759 > >

1 0

buildtool again
by Bob Jamison 13 May '08

13 May '08

Hi again. I left something out of buildtool yesterday, that broke the cross-compiler build on a linux box. Buildtool was not handling recursive substitutions, like: a = "Hello, ${b}" b = "earth, the third ${c}" c = "planet" This is slightly more work to do at execution time than at read time. command="${archutil}windres" archutil="${arch}" arch="i686-pc-mingw-" ...was not working. But it's fixed now, and has that pleasant late-binding smell. Sorry if this broke any cron jobs out there. ALSO: Does anyone know what might be causing this warning? I was afraid to touch it: http://rafb.net/p/34eJBu54.html bob

1 0

Fwd: CSS fonts only?
by Gail Carmichael 13 May '08

13 May '08

Below are some excerpts from my conversation with the Pango folks. Not the whole conversation, but will hopefully help Juca out a bit with his project. Gail ---------- Forwarded message ---------- From: Gail Carmichael <gail.banaszkiewicz@...400...> Date: Fri, Mar 21, 2008 at 2:14 PM Subject: Re: CSS fonts only? To: cfynn@...240... Cc: gtk-i18n-list <gtk-i18n-list@...45...> Thanks for the responses, everyone. I just got into a busy spell at school again, but later on I will need to look into this more. It sounds to me that, basically, we shouldn't be using that PangoFontDescription structure in memory to represent our fonts? Unless that changes (either the options the structure can represent or the fact that Inkscape relies on it so much), we will be stuck with the fonts it can represent. I will probably be back more a bit later to ask questions :) Gail Christopher Fynn wrote: Gail Carmichael wrote: Hi Christopher (and others)! Basically what I am saying is that the enumerations defined here <http://library.gnome.org/devel/pango/unstable/pango-Fonts.html><http://library.gnome.org/devel/pango/unstable/pango-Fonts.html>, like the variant, for example, have a specific subset of values. I just happened to notice that the defined values are pretty much equivalent to allowable CSS text attributes. In Inkscape, we use the PangoFontDescription pretty extensively. It is how font information is stored in memory while the program is running, for example. The problem is that some fonts have, say, a swash variant, which cannot be described with CSS text attributes, and also cannot be described with any of these enumerations in Pango in terms of the PangoFontDescription. Instead, the regular face of a font family is used (as a default fall-back), and "fancy" fonts are thus not accessible in Inkscape. Gail My guess is the best way to handle this w Pango would be through OpenType features & lookups i.e. to include the swash variant glyphs in the base font and have those accessed through OpenType features and lookups - which could be either contextual or user selected. Having *separate* alternative "fancy" fonts with swash / small caps / etc. fonts is the old way of doing things - if you think about it that way, is much more limited. For user selected / discretionary OT features the application (Inkscape) would need some kind of interface /menu through which the user could apply the features she wanted to. WRT CSS - there has been some serious discussion off and on over several years (on the OpenType list, CSS related lists and other places) about specifying - or applying OpenType features through CSS. regards - Chris Hope that clarifies what I am trying to say. It would be cool to pretty much just add more values to the enumerations (and supporting code) so more varieties of fonts could be described. I wanted to know what you guys thought of that possibility - is there some technical or philosophical reason, as can sometimes happen, for not doing so? Thanks Gail ------------------------------ *** VIRUS SCANNED by FASTLINK ISP ***

1 0

Update to buildtool for win32
by Bob Jamison 13 May '08

13 May '08

Hi, all. Over the weekend, I noticed a big flaw in Buildtool. The property aliasing, such as: path="{$gtk}/lib" ...was done at file-read-time. This made it impossible for a Task to use the results of another task as input. So all of the Tasks were recoded to have late binding. Package-config now works. To query a package, just use ${pc.packageName} for the 'all' query, ${pcc.packageName} for the 'cflags' query, and ${pcl.packageName} for the 'libs' query. Note that this is processed internally, and does not call the pkg-config executable. It also grabs all dependent packages' queries, too. This is in addition to the existing: ${env.VARIABLE_NAME} to fetch an environment variable. I did a test build, and it seems to work ok. Please let me know if there are any problems. After you svn up, you will need to do: g++ buildtool.cpp -o btool.exe ...again, for btool to use build.xml properly. bob (ishmal)

2 1

CSS for SVGFonts
by Felipe Sanches 12 May '08

12 May '08

During this weekend I have spent some time coding parameter loading for the font-face tag. Then, after commiting (http://inkscape.svn.sourceforge.net/viewvc/inkscape?view=rev&revision=18594), I noticed that style.{cpp,h} contain code that partially implements the same thing. So, I supose that I will have to revert what I did and use face->style to access the content of those attributes (such as font-style, font-variant, font-stretch, etc). Although, I have also noticed that not every attributes described on CSS2 spec, section 15 (Fonts) are implemented. For example, none of the attributes on section 15.3.6 ('panose-1', 'stemv', 'stemh', 'slope', 'cap-height', 'x-height', 'ascent', and 'descent') seem to be implemented. What should I do? Should I implement them in SPStyle? Or should I implement it on SPFontFace ? Juca

3 2

feature request, XY lower-left vs center toggle
by qazxswedcvfrtgbnhyujmkiolp2000 qazxswedcvfrtgbnhyujmkiolp2000 12 May '08

12 May '08

Hi inkscape-devel, A very useful feature for me (and probably others) is to toggle the meaning of the X and Y boxes between object lower left coordinate and object center coordinate. For example, just as there is a padlock button to control whether W and H are locked, there could be an origin button to control whether X and Y are lower left or center coordinate. I want this e.g. for positioning centered text by center coordinate, not lower left. What do you think? qazxswedcvfrtgbnhyujmkiolp2000

2 1

eraser tool feedback
by MenTaLguY 12 May '08

12 May '08

After experimenting with the eraser tool a little bit, I think the best answer to my use case would be to expand the tool to three modes, something like: - Delete - Erase from selected - Erase from all [i.e. all on current layer] Additionally, the tool needs the ability to "reach into" groups when erase. Currently it just leaves the erasure path behind without doing anything if you try to erase a group with paths inside. Also, the dynamic stroke features aren't very useful for erasure, which benefits most from a uniform, controllable shape. -mental

1 0