- Inkscape Devel - Inkscape Mailman

I'm here, I swear
by Ted Gould 01 Dec '03

01 Dec '03

Hey guys, I just wanted to say that I'm not MIA, I was just gone over the holiday weekend (in the US it was Thanksgiving). I'm now catching up on the ~120 devel messages and ~180 CVS messages... I've already seen a couple for me to look at - I'll hopefully get through all tonight. --Ted

1 0

Fonts problem with win32 build
by Mael 01 Dec '03

01 Dec '03

Hello, Concerning the fonts problem in the win32 build (fonts are rendered in italic), I think this is because of the function nr_type_calculate_position in nr-type-directory.c which uses the name of the font and string comparisons to test if it contains "italic" "bold", etc .. But for example on my french win32 fonts are named with "italique" instead of "italic" and "gras" instead of "bold" and so on, so this function gives wrong results. Sodipodi_0_33_1_Setup_Win2000_XP.exe seems to have the same problem excepted that it finds normal as default style instead of italic (so it's less visible :), when I try to set the style of the font to "gras" or "italique" it always goes back to "normal". M

1 0

select within group
by bulia byak 01 Dec '03

01 Dec '03

I want to enable ctrl-click to select within group, but I don't see how it can be done. I've delved deep into the arena code and found that if a group is "transparent" then its members can be selected one by one. But how can I do that on ctrl-click? In select-context.c, the handler that checks what button/key was pressed seems to already get a selected item as an argument from the arena code. Will I have to analyze this preselected item on my own, or is there a more elegant way? Please enlighten me! -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Re: [Inkscape-devel] button size
by bulia byak 01 Dec '03

01 Dec '03

For now I would vote for: #define TOOL_BUTTON_SIZE 28 #define AUX_BUTTON_SIZE 22 but I think we need to try to add more stuff to the secondary toolbar to see how it will look. > Well, as it is the toolbar size forces the window to a fairly large > minimum height. I'm a little uncomfortable forcing a much larger > minimum size. We have a lot of room to grow :) Currently the default window is very small - 400x400 if without the toolbar strut. BTW maybe we should increase this a bit, say to 640x480. But ultimately the size and maximized state of the document window should be remembered from previous session. > Do you think it would be okay to permit the button bar to be cut off if > the window is resized smaller? I think the main toolbar should not be cut (and it's not likely to be cut anyway), but the secondary toolbar must be permitted to be cut off if the window is small. > Well, perhaps I should use the GTK detachable toolbar widget there, > though the plain GTK one is kind of weak. :/ What is wrong with it? Is there an alternative? Maybe in Gtkmm? It would be nice to have this done without coding it from scratch :) -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Warnings for unimplemented SVG styles
by Bryce Harrington 01 Dec '03

01 Dec '03

I've put in a change to the codebase for some warning messages. Previously, if Inkscape encountered style properties that were not implemented, it would issue a generic warning such as: Unimplemented style property id: 1042 I've created specific warnings for each feature, so now it will report: Unimplemented style property id SP_PROP_FONT_SIZE_ADJUST: value: -4 This won't affect the quantity of warnings issued, just their specificity. I figured as we strive to gain better SVG compliance, we'll want to know more precisely what features we're missing. The warnings are all in style.c. If you're interested in trying your hand at adding a new SVG style property, have a look-see there at the sp_style_merge_property function. Bryce

1 0

Re: [Inkscape-devel] button size
by bulia byak 01 Dec '03

01 Dec '03

Also, I think it makes sense to establish a certain difference in style between the primary and secondary buttons. The primaries may be more 3Dish, with shades and highlights; the primaries should be much simpler, with less colors, without any highlights or gradients. This contrast need not be too drastic, but still it may be helpful. Thus, from this viewpoint, the current node editor secondaries are OK, while for the selector, only the three last buttons (rotate and flip) are OK, others must be made simpler, flatter and more laconic. The same goes for zoom secondaries which are currently "too beautifil". -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Re: [Inkscape-devel] button size
by Robert Crosbie 01 Dec '03

01 Dec '03

IMHO, I think the top bar could use the larger buttons too. Rob. http://members.rogers.com/rcrosbie >From: MenTaLguY <mental@...3...> >To: Inkscape ML <inkscape-devel(a)lists.sourceforge.net> >Subject: [Inkscape-devel] button size >Date: Sun, 30 Nov 2003 18:12:50 -0500 > >I made the tool selection buttons along the side larger than the buttons >for various commands up top. > >While I'd experimented with this a while back and abandoned it, it's >since been suggested a number of times (most recently by Jon), and Xara >appears to do so as well, I decided to try it again. > >See what y'all think... > >-mental ><< signature.asc >> _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

[Fwd: Re: [Sodipodi-list] Win32 0.33 prerelease beta2]
by MenTaLguY 30 Nov '03

30 Nov '03

For those of you working on the Inkscape Win32 stuff... (you might want to hit the sodipodi list archives and follow the whole thread though) -----Forwarded Message----- From: Mitsuru Oka <oka326@...90...> To: Lauris Kaplinski <lauris@...39...> Cc: sodipodi-list(a)lists.sourceforge.net Subject: Re: [Sodipodi-list] Win32 0.33 prerelease beta2 Date: Mon, 01 Dec 2003 04:20:09 +0900 Lauris Kaplinski <1070186315.8512.36.camel@...91...> wrote: >Hello! > >I wonder, if gtk+ is built with multibyte charset, and sodipodi >uses Unicode, is the result functional at all? >We can switch back to multibyte, if it is needed, although this makes >things much uglier and error-prone. Yeah, It's reasonable. I found that dirty hack also works on win98: Index: nr-type-w32.c =================================================================== RCS file: /cvs/gnome/sodipodi/src/libnrtype/nr-type-w32.c,v retrieving revision 1.18 diff -u -r1.18 nr-type-w32.c --- nr-type-w32.c 29 Nov 2003 23:50:52 -0000 1.18 +++ nr-type-w32.c 30 Nov 2003 19:15:43 -0000 @@ -15,6 +15,8 @@ #include <stdio.h> #include <tchar.h> +#include <glib.h> + #include <libarikkei/arikkei-dict.h> #include <libarikkei/arikkei-strlib.h> @@ -565,11 +567,16 @@ nr_type_w32_typefaces_enum_proc (LOGFONT *lfp, TEXTMETRIC *metrics, DWORD fontType, LPARAM lParam) { if (fontType == TRUETYPE_FONTTYPE) { - LOGFONT lf; + GSList *list; + LOGFONT *lf; + + lf = nr_new (LOGFONT, 1); + *lf = *lfp; - lf = *lfp; + list = g_slist_append (*(GSList **)lParam, lf); + *(GSList **)lParam = list; - EnumFontFamiliesEx (hdc, &lf, (FONTENUMPROC) nr_type_w32_inner_enum_proc, lParam, 0); +/* EnumFontFamiliesEx (hdc, &lf, (FONTENUMPROC) nr_type_w32_inner_enum_proc, lParam, 0); */ } return 1; @@ -578,12 +585,14 @@ static void nr_type_w32_init (void) { + GSList *font_que = NULL; LOGFONT logfont; int pos, i; /* g_print ("Loading W32 type directory...\n"); */ - hdc = CreateDC (L"DISPLAY", NULL, NULL, NULL); + /* hdc = CreateDC (L"DISPLAY", NULL, NULL, NULL); */ + hdc = CreateDCA ("DISPLAY", NULL, NULL, NULL); arikkei_dict_setup_string (&familydict, 131); arikkei_dict_setup_string (&namedict, 537); @@ -591,7 +600,14 @@ /* read system font directory */ memset (&logfont, 0, sizeof (LOGFONT)); logfont.lfCharSet = DEFAULT_CHARSET; - EnumFontFamiliesEx (hdc, &logfont, (FONTENUMPROC) nr_type_w32_typefaces_enum_proc, 0, 0); + EnumFontFamiliesEx (hdc, &logfont, (FONTENUMPROC) nr_type_w32_typefaces_enum_proc, (LPARAM)&font_que, 0); + + while (font_que) { + LOGFONT *lf; + lf = (LOGFONT*)font_que->data; + EnumFontFamiliesEx (hdc, lf, (FONTENUMPROC) nr_type_w32_inner_enum_proc, 0, 0); + font_que = g_slist_remove (font_que, (gpointer)lf); + } /* Fill in lists */ NRW32Families.length = families_len; Best regards,

1 0

Re: [Inkscape-devel] paste style
by bulia byak 30 Nov '03

30 Nov '03

> It seems like when copying to the clipboard, there needs to be a > mechanism to scan the selected objects for any referenced objects > and also copy the defs for those. The recipient of the paste > would then need to add those refs to its own set of defs. It's > possible that the receiving document could a) have a different def > by the same name, or b) have the same def by a different name; in > case (a) it would seem prudent to rename the incoming style, and > in case (b) perhaps it should normally merge by default but allow > the user an option to not merge when pasting. That sounds like a lot of code. Maybe we can simplify it a bit as follows: - a new clipboard is made for storing defs - whenever anything is cut or copied, the entire defs from the current document are placed on that defs clipboard - whenever clipboard objects (or style) are pasted, the contents of the defs clipboard are merged with the current document defs: -- same name, same content: disregard -- same name, different content: rename both defs and the pasted objects' references (this is the most tricky part) -- different name, same content: just add, no merge An advantage of this approach is that you don't need to scan your objects and select relevant defs when copying. However, you'll still have to scan and re-id what you are pasting in case of name conflicts (although these are likely to be rare). -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

paste style
by bulia byak 30 Nov '03

30 Nov '03

2003-11-29 bulia byak <bulia@...23...> * src/selection-ch emistry.c src/selection-chemistry.h src/verbs.c src/verbs.h src/shortcuts.c src/interface.c: new function, verb, shortcut (shift-ctrl-v), menu command: paste style (apply the style of copied object to selection). If more than one object is copied, the first one in the clipboard list is taken as the source of the style. One problem with both paste and the new paste style: gradients are not copied between documents. This is because the CSS refers to a gradient which is stored separately in <defs>, and it's not copied or pasted when you copy or paste an object using it. The same will apply to bitmap fills and masks when we implement them. Did anyone think about how to solve this in the most generic and elegant way? -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

3 2