- Inkscape Devel - Inkscape Mailman

OSX native compile error
by Matt Peterson 27 Jun '08

27 Jun '08

Inkscape wants to use Bitstream Vera Sans as the default font, but I don't have that installed on my system so every character becomes ugly rectangles. I cannot figure out how to change the font to something else. I noticed that there is a Resources folder when embedding Inkscape inside a bundle, but it doesn't seem to work for the native version. Does anyone have any suggestions for putting inkscape native into an application bundle? -- Matthew Peterson Programmer Christa McAuliffe Space Education Center On Fri, Jun 20, 2008 at 3:39 PM, Matt Peterson <revcompgeek@...400...> wrote: > Looks like both were problems. I copied the definitions of IS_FINITE to > 2geom/isnan.h and switched to gcc-4.0 and it compiled fine in about 4 hours. > It seems to run fine, but I was having font problems. However, I recently > screwed up my system fonts and I need to restart, which should fix the > problems. If anyone wants it, I have terminal output of the assertion > failures that happened while running. > > -- > Matthew Peterson > Programmer > Christa McAuliffe Space Education Center > > On Mon, Jun 16, 2008 at 6:06 PM, Michael Wybrow < > michael.wybrow@...38...> wrote: > >> >> On 17/06/2008, at 3:08 AM, Matt Peterson wrote: >> >>> >>> I have been attempting to compile a native version of Inkscape for Mac OS >>> 10.4 on a PowerBook G4, and using the latest SVN I am getting the following >>> error: >>> >>> In file included from 2geom/sbasis.h:43, >>> from 2geom/concepts.h:34, >>> from 2geom/d2.h:39, >>> from libnr/nr-convert2geom.h:16, >>> from sp-item.h:27, >>> from sp-lpe-item.h:17, >>> from sp-shape.h:18, >>> from sp-ellipse.h:18, >>> from arc-context.cpp:27: >>> 2geom/linear.h: In member function `bool Geom::Linear::isFinite() const': >>> 2geom/linear.h:91: error: `__isfinite' undeclared (first use this >>> function) >>> 2geom/linear.h:91: error: (Each undeclared identifier is reported only >>> once for >>> each function it appears in.) >>> make[2]: *** [arc-context.o] Error 1 >>> make[1]: *** [all-recursive] Error 1 >>> make: *** [all] Error 2 >>> >> >> >> My guess would be that the isnan.h in 2geom does not have the fixes we >> have added to the inkscape isnan.h. >> >> Try copying the definitions of IS_FINITE from src/isnan.h over the ones in >> src/2geom/isnan.h. >> >> >> Also, Matt, maybe you are using gcc 3.3? We compile our 10.4 packages >> with gcc-4.0, so maybe we haven't noticed a problem with gcc-3.3 on Mac OS >> X. >> >> >> >> Cheers, >> Michael >> > >

3 4

quick note on "using"
by Jon A. Cruz 26 Jun '08

26 Jun '08

Hi, Just a quick little note on the use of "using namespace" and such in .h files. Please don't have "using" in .h files, since that ends up contaminating any .cpp files that include the .h. Also any that include .h's that in turn include .h's that do... ... but then we get into my personal preference to avoid #include inside of .h's when possible.

1 0

Hackontest
by unknown＠example.com 25 Jun '08

25 Jun '08

Hi all, For long time I've been too lazy apply Inkscape for Hackontest, but next week when I am back in the Netherlands (!!!), I will sign us up for it. But first I'd like to do a check to see whichs devs are interested in teaming up for it. Please let me know if you're interested :-) One of the possible projects we could be working on is getting the whiteboard working. (imho it fits very nicely with the spirit of a teamed effort to code it :) Cheers, Johan

5 7

Text toolbar and controlling available options
by Valerie 25 Jun '08

25 Jun '08

If you recall, I proposed "flow into shape" on the toolbar for easier chart items, with border and alignment options, while many of you also want kerning commands in the text toolbar as well. (oh by the way, I'll have to decline on removing the "vertical layout" button from the toolbar: I'm half-Chinese, so it wouldn't surprise me if some took that removal rather badly ;) ) http://img57.imageshack.us/img57/475/textinterface3uc0.png (It's still messy for now) As you can see, even after resizing and removing unnecessary buttons, the resulting toolbar would still be ridiculously long. So basically, the ideal would be to first implement a way to control what appears in the toolbar. Options include: - ticking boxes or lists in text preferences - a button on the toolbar to add or remove buttons by ticking from a list - right click -> customize then drag and drop (like in Firefox 3) - alternatively, is it out of the question to have buttons appear on 2 rows? (with options to collapse parts)? So the big question is... which of the above is feasible and/or can be implemented most easily/fastest? This would be useful for other tools that are starting to have too many options, too. Once something like that is implemented, more options can be added, such as: - more text style elements (underline, strike-through, subscript, superscript, etc) - I was thinking offsets values for object aligns. - spellcheck options and custom layout options? - presets too On an unrelated note: text rendering happens to be pretty slow in Inkscape. This is probably due for its conversion into a deformable svg object? But some of us just want to do charts in Inkscape without fancy text effects, or do one of those tutorial picture files you see on Deviantart. When you reach a text file that size though, Inkscape starts to become Really slow. Is it possible to get a "plain text" option for all that? If I wanted to resize the text, I'd change the font size, not accidentally drag on the text box corners. There could be a toggle button between plain text and dynamic text, just like there's a toggle right now between bezier and spiro.

1 0

Tracking dependencies
by Jon A. Cruz 25 Jun '08

25 Jun '08

Hi guys, There's a side issue that's been kicking around for a while now. Inkscape doesn't really have it's dependencies explicitly listed. So things may or may not work for certain users trying to build on certain platforms, OS versions, etc. For example, I put in a patch recently that uses g_timeout_add_seconds (). In the documentation on it, the function is listed as "Since 2.14". So that bumps the requirement to have glib2 >= 2.14. However that would make things no longer work on Fedora 7 and instead bump Fedora 8 as the minimum there. Since that's only a year old, the might be a bit too soon to bump. Anyway, this highlights a need we have to be tracking what we bump and what impact it will have. This is something that even non- programmers can help with, so I've added a quick section and link to the Help Wanted wiki page: http://wiki.inkscape.org/wiki/index.php/ HelpWanted#Determining_Dependencies A first step would be if people skimmed through the glib and gtk+ docs looking for newer functions. Then adding those that are in our codebase to the "Functions Used" table on the wiki could really help: http://wiki.inkscape.org/wiki/index.php/ Tracking_Dependencies#Functions_Used Then if someone has a distro they care about, they can add it and/or fill out details for at at http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies#Distros Finally, the developers can get a handle on creeping dependencies, and perhaps add a few #ifdef's or alternate methods where needed in order to keep things sane.

1 0

okay, who did the green fish on-canvas?
by Andy Fitzsimon 25 Jun '08

25 Jun '08

I have no idea where in the code you added it . please remove it (or let me know where to add the duck code.) prions shall rise again! Andy

3 3

SPCanvasBuf cairoified
by bulia byak 24 Jun '08

24 Jun '08

I have just committed a change which turns SPCanvasBuf from 24bpp to 32bpp (since cairo cannot handle 24bpp buffers) and adds a cairo_t member (buf->ct) that canvas items can use to draw themselves using cairo. So far, canvas bpaths, ctrllines, and ctrlquadrs are drawn with cairo; the rest of items still use direct bitflipping although they are updated for 32bpp (and I think they should stay that way, as they don't need antialiasing and cairo would be much slower for them). Everything should work and behave exactly as before, except a little faster, and except the temporary regressions outlined below. Note that this only concerns canvas items; regular objects are still rendered as before. Total cairofication has become closer but we're not there yet. Here's what you need to remember to use cairo to render a canvasitem: - In the update method, you're given an affine matrix. Remember it. - In the render method, transform your points by the remembered affine, and then subtract from it the point (buf->rect.x0, buf->rect.y0). Use the resulting coords to draw into buf->ct, then everything will be where it must be. - When setting colors using cairo_set_source_rgba, give the components in the order B, G, R, A, not R G B A. Problems and regressions: 1 For some reason, drawing the canvasbuf onto the screen using cairo is very slow. So I had to keep the old method using gdk_draw_rgb_image_dithalign, which is faster even though it involves a 32bpp->24bpp conversion because gdk can only deal with 24bpp. This is controlled by the define CANVAS_OUTPUT_VIA_CAIRO in sp-canvas.cpp; uncomment it to use the cairo output. Can any cairo guru guess what is going wrong here? 2 Cairo cannot draw over the past content of the buffer with inversion. The XOR operator does not result in inversion, or at least I couldn't figure out how. So, the text selection (Shift+arrows over) had to become semitransparent blue instead of black with inversion. Hopefully this will be possible to fix with a future version of cairo. 3 With apologies to Mac users, I had to take out the code which reverts the byte order depending on endianness, which used to fix the problem caused by our using fixed byte order (RGBA) and cairo depending on the endianness of the hardware. Now that many things draw directly into the buffer using cairo, I can no longer easily separate what is drawn with cairo and what not, so there's no endianness fix anymore and as a result the colors of canvas items on a Mac will likely be wrong. This is a temporary regression; when rendering of regular objects is also cairoified, we can restore this fix, and when the problem 1 above is fixed, this endianness fix will be no longer needed because everything will be cairo throughout. Let me know if you find any problems. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 6

Re: [Inkscape-devel] Misc questions (dropdown menus, retrieving path info from files, LPE)
by Valerie 24 Jun '08

24 Jun '08

(Yay! :D ) Here's my take on 3) (alternatives are welcome): I can see 3 types of behavior people could want for LPE width: - absolute width: most useful for thin lines. Ex: 2 px. - % of original (%): big clipboard items. Chances are, when you copy an object you've just made for LPE, you want the object width to be more or less retained. - proportional resize: actually, isn't this what "bend path" more or less does? The object isn't stretched, it's just resized and bent. At first I was wondering how to call the last option in just two letters, but then I realized that it's best to make that a repeat option: http://img150.imageshack.us/img150/2599/lpekz5.png So, apart from the above, you have the following for units drop-down: % -- px mm etc. By the way, there should be an option for the resulting object to take on the color/fill properties of the original object instead of the current line properties. This in particular could be set as default for clipboard items: - if you copy a green leaf, you probably want it to stay green - also, if in the future you can copy complex objects with different fills and strokes for LPE, that'd allow you to retain those multiple settings Also, is it possible to implement a "skeleton" mode where all LPEs are disabled and only the skeletons are visible? The reasoning is simple: LPEs can consume a vast amount of memory. A skeleton mode would serve very much the same purpose here as the Outline mode (indeed, the outline mode itself could be made to only show skeletons and not rendered effects).

1 0

Startup slowdown caused by nr_arena_updates?
by Maximilian Albert 23 Jun '08

23 Jun '08

Hi all (and Johan in particular because it regards one of your commits), apparently rev #18921 introduced a significant slowdown in Inkscape's startup procedure (that's what git-bisect says). I'm not sure what the issue really is but after starting Inkscape, my CPU stays extremely busy for about 20 seconds or so. During that time, drawing operations and other actions respond considerably more slowly.[1] After about 20 seconds, everything seems to work as usual again, and all operations are reasonably fast. Anyone else seeing this? Here is a typical backtrace after interrupting Inkscape in gdb: #0 0x08241eb2 in Geom::D2<Geom::Bezier>::D2 () #1 0x08241ff6 in Geom::BezierCurve<1u>::BezierCurve () #2 0x082420b6 in Geom::Path::Path () #3 0x084d6ea8 in Geom::Path::operator* () #4 0x087fc9af in Geom::operator* () #5 0x084859e9 in nr_arena_shape_update () #6 0x0847cf70 in nr_arena_item_invoke_update () #7 0x0847ec8f in nr_arena_group_update () #8 0x0847cf70 in nr_arena_item_invoke_update () #9 0x0847ec8f in nr_arena_group_update () #10 0x0847cf70 in nr_arena_item_invoke_update () #11 0x0847ec8f in nr_arena_group_update () #12 0x0847cf70 in nr_arena_item_invoke_update () #13 0x0847ec8f in nr_arena_group_update () #14 0x0847cf70 in nr_arena_item_invoke_update () #15 0x084283c2 in sp_icon_doc_icon () #16 0x084291ee in load_svg_pixels () #17 0x084292f9 in prerender_icon () #18 0x08429d24 in icon_prerender_task () #19 0xb7340c91 in ?? () from /usr/lib/libglib-2.0.so.0 #20 0x00000000 in ?? () Note the several calls to nr_arena_group_update() and nr_arena_item_invoke_update(). The precise 2geom routines usually vary, but I see these two calls consistently during the slowed down phase. Hope this helps; it would be nice to have it fixed (I need to start Inkscape pretty often for testing, and this slowdown makes it quite annoying). Many thanks, Max [1] I first noticed this by drawing a star and converting it to a path (Shift+Ctrl+C) directly after startup, during which the cursor kept its hourglass state for about 15s. It doesn't seem to be related to path conversion, though.

3 4

VERSION and INKSCAPE_VERSION
by Bob Jamison 23 Jun '08

23 Jun '08

Hi, verbalshadow and I were looking at config.h and inkscape_version.h. Could we reduce our generated files by 1 and remove inkscape_version.h? It seems redundant. It only defines INKSCAPE_VERSION , rather than VERSION, and is used by aboutdialog.cpp. Can we move this to config.h like everyone else does? ^^ bob

2 1