- Inkscape Devel - Inkscape Mailman

Re: flowtext
by bulia byak 03 Aug '04

03 Aug '04

> - flowRegion makes flow-go.svg render "correctly" Actually from my reading of the spec, the old rendering was correct: each flowregion filled from top to bottom, even if it contains multiple shapes. > - fixed the lost word problem. note that you need to > put spaces at the beginning of a flowSpan (or the end > of the previous) otherwise the words at both ends will > be glued together Yes, that's reasonable > - a preliminary convert_to_text() verb is in sp-flowtext Excellent, I put it on Shift+Alt+W as "Unflow text", with the Alt+W reserved for "Flow text" (convert text + shape into a flowed text). There were a few problems: - compilation errors on char conversions again - fixed - the text style only worked if set on flowRoot, not flowDiv - fixed by adding SP_STYLE_FLAG_ALWAYS to sp_style_write_string (line 787), so that it writes the entire style of each chunk, including inherited style - space after flowSpan was lost - partially fixed by adding xml:space="preserve" to the created text, but the start positions of spans are still sometimes off (convert the attached one and watch the words "as well as" and "kinsoku" - they jump off a bit) Plus a few other small changes, so please take the files from CVS if you want to change something. I also thought about the best way to create flowed texts. I think using clones is indeed the best method, as it will let us avoid adding flowtext parsing code to a million places. So when you select a shape and a text, here's what happens: - the shape is cloned, clone placed exactly over the original - the clone gets inkscape:use-move="parallel" and inkscape:use-delete="unlink" attribs to ensure these behaviors regardless of user prefs (sp-use support required, but it's simple to add) - tspans with sodipodi:role="line" are merged together, separated by spaces - an empty tspan with sodipodi:role="line" (i.e. empty line) is converted into <flowLine/> - the flowRoot is constructed from the clone and the text thus prepared; original text is deleted The original shape thus remains and is editable as usual, and the text shape will be updated via the clone. This means the paths in "foreign" (non-Inkscape) flowed texts that do not use clones will not be editable at all, but this is OK (at least for now). This approach has the advantage of relative simplicity, and two more commands can be easily added based on the same mechanism - "Flow around" (adds exclusion shape to an existing flowed text) and "Chain flow" (adds a new region to an existing flowed text), with all these shapes remaining editable (i.e. only their clones are added into the flowtext).

2 4

Re: flowtext
by bulia byak 03 Aug '04

03 Aug '04

> - reintroduced the *_update() functions in > sp-flowdiv.cpp; apparently they're needed to have > flowRoot reflow when text is edited > - print uses the text-to-path method, that is you can > print any font in flowRoot > - better convert_to_text(), including partial dx/dy > support (need to figure a way to get the sum of the dy > shifts at the end of a tspan) Thanks, committed. The jumping flowspans bug on convert-to-text seem to be fixed. Please use the version from CVS! I now had to re-type several small fixes I had in sp-flowtext (such as _() for description). What remains to be done: - word-spacing CSS property must be supported as well as letter-spacing. This needs to be added to style.cpp and then to sp-text. - justification must be achieved, first, by squeezing/stretching spaces, and only if this is not possible, by modifying letterspacing. To this end, inkscape:layoutOptions must support 4 parameters: squeezability of space; stretchability of space; squeezability of letterspacing; stretchability of letterspacing (all four are in % relative to the normal value). Some sensible defaults can be found by playing with various texts.

1 0

GNOME HIG
by Lucas Vieites 03 Aug '04

03 Aug '04

Hi all, I just read about the new release of the GNOME HIG (Human interface guidelines) 2 and suddenly I asked myself if Inkscape was taking these into consideration. I browsed the mailing list a bit and found some postings mentioning them. Thinking a bit about the future and the possibility of Inkscape becoming part of GNOME, or even if this is not on the roadmap, I think these guidelines are a "good thing". So, are the developers using these guidelines as they design the user interface? What do you think about them? Greetings, -- Lucas Vieites Fariña Asix Informática <info@...212...> http://www.asixinformatica.com/ Tel/Fax: +34 986 54 26 98

8 13

Re: [Inkscape-user] Re: Crash on startup
by MenTaLguY 03 Aug '04

03 Aug '04

Sorry for taking so long to get back to you; emails about compilation problems will probably get answered quicker on the development mailing list... On Thu, 2004-07-22 at 16:05, Florent wrote: > But maybe, the problem come from the new libs version ? > Is there anyone who can run the last CVS on a Linux ? Yes, I've been running it since I did the library conversion. > And what is his lib versions ? gtk+-2.0 = 2.4.3 gobject-2.0 = 2.4.2 gmodule-2.0 = 2.4.2 glib-2.0 = 2.4.2 pango = 1.4.0 gtkmm-2.4 = 2.4.4 gdkmm-2.4 = 2.4.4 glibmm-2.4 = 2.4.3 pangomm-1.4 = 2.4.4 > I don't know if it can help but when I run the "ddd inkscape", it gives me : > > Program received signal SIGSEGV, Segmentation fault. > SPDesktop::_layer_hierarchy_changed(SPObject*, SPObject*, SPDesktop*) > (top=0x84023d0, bottom=0x84023d0, desktop=0x86bc208) at stl_list.h:397 > /usr/include/c++/3.2.3/bits/stl_list.h:397:10573:beg:0x815f4c4 void SPDesktop::_layer_hierarchy_changed(SPObject *top, SPObject *bottom, SPDesktop *desktop) { desktop->_layer_changed_signal.emit(bottom); } That place for the crash looks a little strange to me. Could you try compiling without optimization and see if it yields the same backtrace (and give me some more of the actual backtrace as well..). The only reason I can think of that it would crash here is if SPDesktop::_layer_changed_signal were not initialized properly for some reason. -mental

2 7

[Fwd: Fwd: mozilla svg meeting log 26.July 2004]
by Jon Phillips 03 Aug '04

03 Aug '04

Sorry for the long email, but this will be of interest to several of you about Mozilla + SVG involvments. This is from the Mozilla SVG team meeting log. -----Forwarded Message----- > From: jon phillips <phillipsjd@...400...> > To: jon@...235... > Subject: Fwd: mozilla svg meeting log 26.July 2004 > Date: Sun, 01 Aug 2004 00:36:09 -0700 > > ---------- Forwarded message ---------- > From: Alex Fritze <alex@...488...> > Date: Sun, 01 Aug 2004 08:34:18 +0100 > Subject: mozilla svg meeting log 26.July 2004 > To: phillipsjd@...400... > > Jul 26 18:39:50 <afri> anyway, shall we start with item 1) "Criteria > for switching on"? > Jul 26 18:39:55 <jwatt> is there any way to search for bugs that have > patches that modify a given file? > Jul 26 18:40:06 <jwatt> oops, never mind, later > Jul 26 18:40:17 <Scooter> 1 seems like a good beginning > Jul 26 18:40:19 <afri> Anybody got any thoughts? > Jul 26 18:40:36 <jwatt> don't we really need a brendan or someone > similar here for that? > Jul 26 18:40:42 <afri> tor: you had some contact with m.org about this? > Jul 26 18:40:45 <jwatt> since they will have a major say in that? > Jul 26 18:41:09 <tor> afri: just the normal moz2 meetings > Jul 26 18:41:51 <Scooter> Well, lets start with which profile we are > shooting for: Tiny or Basic? > Jul 26 18:42:01 <tor> turning it on will depend on the feature set > and size > Jul 26 18:42:11 <tor> 1.2 doesn't have basic, fwiw > Jul 26 18:42:11 <jwatt> or should we do Tiny > Basic > Full? > Jul 26 18:42:23 <tor> (not that we should be shooting for 1.2) > Jul 26 18:42:56 <Scooter> Agreed -- I'm a little uncertain about > 1.2. There seems to be a lot of debate surrounding it. > Jul 26 18:43:02 <afri> do you reckon that feature set is important? > Isn't stability and footprint the issue? > Jul 26 18:43:11 <tor> is anyone interested in working on animation or > svg fonts, which are a couple of the big points we're short of 1.1 tiny? > Jul 26 18:43:30 <tor> stability is definitely important > Jul 26 18:44:01 <tor> we need to be featureful enough so that people > can start do interesting things > Jul 26 18:44:05 <jwatt> I'd be interested in animation in the long > run, but feel I'm still finding my feet > Jul 26 18:44:28 <afri> who do we need to press for criteria? i guess > they are being decided by brendan et al? > Jul 26 18:44:52 <jwatt> yeah, an email to drivers would be a good idea > Jul 26 18:44:59 <tor> brendan was floating the idea of turning on svg > for 1.8, but that causes problems with platform prereqs > Jul 26 18:45:03 <jwatt> or should we /invite some folk now? > Jul 26 18:45:14 <tor> mail to drivers is likely not to get anywhere > Jul 26 18:45:22 <jwatt> oh > Jul 26 18:45:51 <Scooter> OK, so it sounds like there are some > platform issues that need to be on the list -- what are they? > Jul 26 18:46:14 <tor> requiring gdi+ on windows > Jul 26 18:46:27 <jwatt> as in for the installer? > Jul 26 18:46:30 <tor> (unless maybe we can try dynamically loading it?) > Jul 26 18:46:49 <jwatt> I was working on getting the installer script > to do the right thing for that > Jul 26 18:47:05 <Scooter> So, we have requirement #1 -- we need to > deal with gdi+ on windows, right? > Jul 26 18:47:11 <afri> IANAL, but i think technically we are allowed > to redist gdiplus.dll for older windows > Jul 26 18:47:32 <tor> we can't ship libart bits under trilicense > Jul 26 18:47:35 <jwatt> for win me, 98, nt and 2000 > Jul 26 18:47:44 <jwatt> all others aren't allowed > Jul 26 18:47:57 <afri> but we could use cairo for linux, right? > Jul 26 18:48:23 <tor> yes, but we'd have to link it in statically > given that they're still changing the api > Jul 26 18:48:29 <afri> ah > Jul 26 18:48:54 <afri> i guess the other problem is the mac > Jul 26 18:49:11 <Scooter> Perhaps we should focus on listing the > issues and postpone trying to solve them? > Jul 26 18:49:56 <afri> so is it fair to say then that the real first > hurdle for getting svg switched on is sorting out a backend on each > platform? > Jul 26 18:50:04 <tor> how about we ask the question another way - > ignoring distribution issues, would we be happy subjecting users to our > svg at this point? > Jul 26 18:51:00 <afri> i guess that comes down to stability... > Jul 26 18:51:04 <Scooter> I would really like to see us get closer to > *at least* Tiny before we roll this out. > Jul 26 18:51:31 <Scooter> Then we can focus on stability. Things are > clearly still changing pretty rapidly. > Jul 26 18:51:32 <afri> i think the current feature set looks pretty > ok for users > Jul 26 18:52:14 <tor> once gradients are in things are looking good > Jul 26 18:52:16 <Scooter> Even without animation and SVG Fonts? > Jul 26 18:52:21 <tor> <use> would be nice > Jul 26 18:52:45 <jwatt> yeah, gradients and use I think would be > necessary > Jul 26 18:53:16 <afri> yeah, gradients & <use> would be nice. > animation i think will take quite a long while and svg is pretty useful > even without it > Jul 26 18:53:35 <Scooter> Fair enough -- what about SVG Fonts? > Jul 26 18:54:25 <afri> hmm, it sounds tricky getting it right for > several backends... > Jul 26 18:55:03 <afri> do you think without fonts, SVG is not really > worth much to the end user? > Jul 26 18:55:45 <Scooter> Not at all -- I'm just sort of playing > devil's advocate here. I'm happy to see it turned on without that. > Jul 26 18:55:54 <tor> I think svg fonts were probably added to tiny > for platforms that didn't have native scalable/tranformable fonts > Jul 26 18:55:54 <Scooter> What about <switch>? > Jul 26 18:56:26 <afri> well we have your patch for that, so i guess > it will be going in soon > Jul 26 18:57:02 <Scooter> OK, so what we have is: Stability, Platform > issues, <use>, Gradients, and <switch>, right? > Jul 26 18:57:37 <afri> ...of which platform issues are probably the > most difficult > Jul 26 18:57:51 <afri> i don't have a clue how to go about this > Jul 26 18:58:08 <Scooter> Which this? The requirements list or the > platform issues? > Jul 26 18:58:10 <afri> will cairo work on windows/mac? > Jul 26 18:58:25 <afri> Scooter: the platform issues > Jul 26 18:58:52 <afri> can we even link to it statically on linux? > Jul 26 18:59:04 <afri> wouldn't that mean it needs to be checked into > the tree? > Jul 26 18:59:29 <tor> the software path of cairo should work on mac > Jul 26 18:59:51 <tor> if we're allowed to redistribute gdi+ then that > might not be a problem > Jul 26 19:00:06 <afri> fair enough > Jul 26 19:00:20 <afri> so let's assume windows is sorted for now... > Jul 26 19:00:30 <jwatt> as I said, we can only redistribute > gdiplus.dll on WinME, Win98, WinNT and Win2k > Jul 26 19:00:34 <afri> how do we go about linux/mac then? > Jul 26 19:00:43 <tor> jwatt: what else is there? > Jul 26 19:00:53 <afri> tor: XP > Jul 26 19:00:54 <jwatt> nothing that we need to cater for > Jul 26 19:00:57 <jwatt> XP has it > Jul 26 19:01:04 <tor> there's a quartz wip backend > Jul 26 19:01:18 <afri> wip? > Jul 26 19:01:27 <tor> work in progress > Jul 26 19:01:32 <afri> ah > Jul 26 19:01:57 <afri> i think we'd need to find a developer for that > Jul 26 19:02:06 * Lightkey cracks his wip > Jul 26 19:02:12 <afri> it seems to have stalled > Jul 26 19:02:42 <afri> Lightkey: you are a mac developer? > Jul 26 19:02:54 <Lightkey> I am the lowest > Jul 26 19:03:02 <Lightkey> internet reporter :D > Jul 26 19:03:14 <tor> we have a mac here > Jul 26 19:03:18 <Lightkey> no, I'm just a user > Jul 26 19:04:14 <afri> so if we have as a working assumption that > someone will fix the quartz backend, that still leaves linux... > Jul 26 19:04:42 <Scooter> And the issue with Linux is the license > restrictions on libart? > Jul 26 19:04:52 <afri> with libart not being an option, how would we > proceed with cairo? > Jul 26 19:04:57 <tor> statically linking cairo is just a build problem > Jul 26 19:05:10 <afri> what about the cairo license? > Jul 26 19:05:12 <tor> though cairo does feel slower than libart > Jul 26 19:05:28 <Lightkey> changing croczillas licenses to the one > libart uses? *scnr* > Jul 26 19:05:46 <tor> still MIT style, though they keep threatening > to change to LGPL (which would sink the static link solution) > Jul 26 19:06:35 <afri> is MIT compat with tri-license? > Jul 26 19:06:43 <tor> yes > Jul 26 19:07:06 <afri> so we could check this into the tree then? > Jul 26 19:07:10 <Lightkey> MIT is like FreeBSD > Jul 26 19:08:37 <tor> if it gets to that point, yes > Jul 26 19:08:51 <afri> to which point? > Jul 26 19:09:04 <afri> LGPL relicensing> > Jul 26 19:09:07 <afri> ? > Jul 26 19:09:15 <tor> where we're going to take the static link approach > Jul 26 19:09:23 <afri> ah yeah, ok > Jul 26 19:09:34 <afri> well, is there any other way? > Jul 26 19:09:44 <lsmith> afri: are those performance issues solved > that matthias found afri? > Jul 26 19:09:51 <lsmith> (iirc he send you a test case) > Jul 26 19:09:54 <tor> not that I can think of offhand > Jul 26 19:10:12 <lsmith> those might also be a little showstopper > Jul 26 19:10:26 <afri> lsmith: no, we'll get to that later > Jul 26 19:10:46 * lsmith nods > Jul 26 19:10:49 <afri> so shall we run this past brendan et al then? > Jul 26 19:11:23 <Scooter> Makes sense to me. > Jul 26 19:11:35 <jwatt> yeah, good to keep him informed if nothing else > Jul 26 19:11:50 <jwatt> But do we really have enough contributors to > deal with the development cycle that would be imposed on us if SVG was > turned on by default? > Jul 26 19:12:14 <tor> what development cycle? > Jul 26 19:12:43 <jwatt> having to stabalise, etc a1, a2, b, rc, > milestone > Jul 26 19:13:27 <jwatt> there are certain benefits to not being build > by default, and therefore not having to meet the same standards as the > rest of the code > Jul 26 19:14:41 <jwatt> or is it better that we should start to be > forced to those standards? > Jul 26 19:15:10 <afri> so is it fair to summarize then: stability, > backend are the major issues. course of action: gdi+ on win, quartz on > mac, statically-linked cairo on linux? run past brendan et al. find out > other criteria from them? > Jul 26 19:15:36 * lsmith notes while he doesnt have the know how to > contribute code we (my co-worker and I) will definately be willing to > help on the testing front > Jul 26 19:15:53 <jwatt> lsmith: cool > Jul 26 19:15:57 <jwatt> afri: seems right > Jul 26 19:16:12 <Scooter> afri: sounds right to me. We should also > mention <use>, which is an outstanding feature on the list. > Jul 26 19:16:45 <tor> afri: and getting the current features working > through reviews (gradient, switch) > Jul 26 19:17:11 <Scooter> afri: and font-size > Jul 26 19:17:21 <afri> ok > Jul 26 19:17:44 <afri> then there is the issue of getting the current > code sr'ed... > Jul 26 19:17:55 <jwatt> fun > Jul 26 19:18:39 <lsmith> may i ask what timeframe you are hoping for? > (slap me if i am intruding btw) > Jul 26 19:18:41 <afri> so is anyone volunteering to run these issues > past brendan et. al. ? > Jul 26 19:19:10 <tor> afri: sure, I send something to the moz2 list > and talk to brendan > Jul 26 19:19:34 <jwatt> where is the moz2 list? > Jul 26 19:19:37 <afri> tor: cool > Jul 26 19:19:39 <jwatt> is that public? > Jul 26 19:19:53 <tor> unfortunately no > Jul 26 19:19:57 <jwatt> shame > Jul 26 19:20:19 <afri> anybody got an idea what timeframe we are > aiming for? i don't... > Jul 26 19:20:43 <Scooter> I will volunteer to take on <use> as soon > as I can clear out some of the other patches. <use> looks a lot like > the some of the gradient reference stuff. > Jul 26 19:20:52 <afri> cool > Jul 26 19:21:14 <jwatt> afri: no, I'm in no rush, I just wanted to > clarify things to aim for in the long run > Jul 26 19:21:35 <afri> ok, i guess that's item 1 sorted then as well > as we can atm > Jul 26 19:21:55 <jwatt> scooter's only here for another 40 min > Jul 26 19:21:57 <tor> brendan was floating 1.8 - if we were serious > about that, of that list, we might be able to get everything except for > <use> > Jul 26 19:22:07 <jwatt> what do we need to discuss while he's here? > Jul 26 19:22:32 <afri> cool > Jul 26 19:22:59 <Scooter> Do you really think we could get the > stability and platform issues worked out for 1.8? > Jul 26 19:23:03 <afri> tor: how about if you run this past brendan > and we talk about it again next week? > Jul 26 19:23:26 <tor> afri: sure > Jul 26 19:23:36 <afri> if there's a commitment by mozilla.org to get > this in, i guess we could make it > Jul 26 19:23:47 <tor> Scooter: do we have serious stability problems? > Jul 26 19:24:26 <Scooter> Not sure -- there's a lot of work in > progress. Until its all in a single build, we really haven't done much > to shake things out. > Jul 26 19:24:28 <afri> AFAICS many stability problems on linux are > libart-specific > Jul 26 19:24:51 <afri> there are issues with very large SVGs > Jul 26 19:25:03 <afri> we don't do any culling or clipping... > Jul 26 19:25:28 <Scooter> Should clipping be on our requirements list? > Jul 26 19:25:37 <tor> oh, speaking of which cairo is in the midst of > redoing their trianglization algorithms, so some fills mess up now > Jul 26 19:25:39 <afri> so if the SVG viewport is larger than the > client area we still build all the paths > Jul 26 19:26:14 <afri> i guess visual glitches are one > thing...crashing/hanging is another > Jul 26 19:27:10 <afri> shall we move to the other items then? > Jul 26 19:27:12 <Scooter> I don't know...I guess I'd feel more > comfortable enabling SVG right *after* 1.8. That way we could get in at > the start of a cycle. > Jul 26 19:27:23 <Scooter> Sure, lets move on. > Jul 26 19:27:50 <afri> "currentColor" > Jul 26 19:28:07 <afri> Scooter: you had a question about the intent > of the specs? > Jul 26 19:28:35 <afri> isn't "current" just the value of the "color" > property? > Jul 26 19:29:14 --> shaver (~shaver@...489...) has joined #svg > Jul 26 19:29:28 <Scooter> Sort of. The question is, is it the value > of the color property of the surrounding elements (i.e. inherited) or > just the last set value? > Jul 26 19:30:27 <afri> is there a difference? > Jul 26 19:31:24 <Scooter> Internally, I think that there is. For > example, I could set the "color" property on an HTML element then not > set the property again and then use it inside of SVG as "currentColor". > Jul 26 19:31:48 <afri> ah, i see > Jul 26 19:31:58 <afri> i haven't got a clue > Jul 26 19:32:23 <afri> don't the specs say anything about this? > Jul 26 19:32:29 <afri> (the css specs) > Jul 26 19:32:38 <Scooter> I *believe* that that is the intent of the > spec -- a way to maintain color between different document elements. > Jul 26 19:33:12 <Scooter> The only example (in the test suite) just > sets the color inside of SVG and then references it using "currentColor" > Jul 26 19:33:43 <afri> hmm, i guess noone here knows... > Jul 26 19:34:09 <jwatt> maybe ask in www-svg, or mail chris/dean > directly > Jul 26 19:34:10 <Scooter> The css specs (2.1) don't talk about > "currentColor". That's supposed to be coming in CSS3 (I'm told). > Jul 26 19:34:19 <Scooter> OK, will do. > Jul 26 19:34:26 <afri> great > Jul 26 19:34:38 <afri> 3. ICC Color - do we do it? Should we? > Jul 26 19:34:50 <afri> i don't even know what ICC color is > Jul 26 19:35:00 <tor> color profiles for color correction > Jul 26 19:35:12 <afri> ah > Jul 26 19:35:14 <Scooter> And its part of the SVG spec > Jul 26 19:35:40 <afri> i guess we should then > Jul 26 19:35:44 <Scooter> My take is to wait for somebody to ask for it. > Jul 26 19:35:47 <afri> at some point > Jul 26 19:35:51 <tor> somewhat low priority, I woudl think > Jul 26 19:35:57 <afri> yeah > Jul 26 19:35:58 <jwatt> btw, I found their specs online some years > ago, I downloaded them if they can't be found now > Jul 26 19:36:19 <Scooter> They are still online. > Jul 26 19:36:39 <Scooter> OK, I agree that this should be low priority. > Jul 26 19:36:40 <jwatt> cool, anyway, low priority > Jul 26 19:36:44 <afri> cool - so ICC color=low priority. 4) patterns > Jul 26 19:36:56 <Scooter> Any takers? > Jul 26 19:37:00 <jwatt> ugh > Jul 26 19:37:17 <afri> i think we need to sort out clipping before > patterns > Jul 26 19:37:23 <Scooter> Agreed. > Jul 26 19:37:27 <afri> that's something i wanted to do next > Jul 26 19:38:19 <Scooter> Great! Getting clipping would be really good. > Jul 26 19:38:26 <afri> so I guess we wait until clipping is sorted > out then > Jul 26 19:38:35 <afri> 5. SVG text > Jul 26 19:39:09 <Scooter> What's missing besides textPath? > Jul 26 19:39:12 <tor> textPath seems hard > Jul 26 19:39:36 <afri> selection is only partially implemented atm (i > got bored) > Jul 26 19:40:23 <afri> i think before we ship in default builds, > selection either needs to be disabled or finished > Jul 26 19:40:32 <afri> it's kind-of screwy atm > Jul 26 19:41:04 <afri> font-size we have Scooter's patch for, so i > guess that will go in soon > Jul 26 19:41:51 <Scooter> That's sort of minor (although you wouldn't > know it by the number of comments). > Jul 26 19:41:56 <afri> All the other stuff (textPath, tref, glyphs) > would be nice, but does anybody want to work on that? > Jul 26 19:42:05 <Scooter> So, I guess we don't have any takers for > working on SVG Text? > Jul 26 19:42:27 <jwatt> why disable it? I'd prefer not to, even if it > doesn't get finished. > Jul 26 19:42:58 <afri> disable selection, not text > Jul 26 19:43:06 <jwatt> I know > Jul 26 19:43:10 <Scooter> So, should we submit a bug for the missing > stuff with helpwanted? > Jul 26 19:43:30 <afri> it doesn't work - some of the machinery is > there, that's all > Jul 26 19:43:39 <jwatt> but sometimes it works, and the worst thing > that can happen is that the user can't select what they want and files a > bug > Jul 26 19:43:54 <afri> fair enough > Jul 26 19:44:40 <Scooter> If I'm going to do <use> I'll take a look > at <tref> also. > Jul 26 19:44:45 <afri> cool > Jul 26 19:45:08 <afri> tor: text is working on cairo, right? > Jul 26 19:45:13 <Scooter> That still leaves textPath (and glyphs) > Jul 26 19:45:39 <jwatt> these things are out of my league at the mo > Jul 26 19:45:49 <tor> afri: yes, though i18n text doesn't work > Jul 26 19:46:17 <tor> afri: font size tends to be off > Jul 26 19:46:37 <afri> i guess that's stuff we can live with > Jul 26 19:47:29 <afri> so shall we move on to the next then? > Jul 26 19:47:30 <tor> probably fixable - I'm using the "wimp api" for > cairo fonts > Jul 26 19:47:38 <Scooter> So, file a bug for textPath and move on? > Jul 26 19:48:09 <afri> cool > Jul 26 19:48:17 <Scooter> What's next? > Jul 26 19:48:24 <jwatt> item 6 > Jul 26 19:48:29 <tor> <defs> > Jul 26 19:48:39 <afri> <defs>: why on earth are they stylable? > Jul 26 19:48:54 <afri> & transformable? > Jul 26 19:49:14 <tor> good batch of crack at the w3c? > Jul 26 19:49:24 <tor> I mean, I'm sure they had a good reason > Jul 26 19:49:43 <jwatt> another one for chris/dean? > Jul 26 19:50:01 <afri> it looks to me as if everything that goes into > a <defs> has its style and/or xforms applied whereever it's referenced from > Jul 26 19:50:10 <afri> yeah, i'll mail the list > Jul 26 19:50:25 <afri> although i usually don't get any answers > Jul 26 19:50:50 <Scooter> Maybe all of us can sort of push for > answers. I'm on the svg list also (mostly been lurking). > Jul 26 19:50:54 <tor> <use> is supposed to use a combined cascade, > which makes the style make a bit of sense > Jul 26 19:50:57 <jwatt> then follow it up with personal emails > Jul 26 19:51:42 <afri> ok, i guess i should take a look at the <use> > specs before i complain about anything > Jul 26 19:51:56 <Scooter> I've got to go get ready for my > presentation. I'll be back in a couple of hours (if you all are still > at it), but if not, will somebody summarize via E-Mail? > Jul 26 19:52:25 <jwatt> yeah, somebody will > Jul 26 19:52:29 <-- lsmith has quit (Read error: Connection reset by > peer) > Jul 26 19:52:33 <afri> Scooter: have fun > Jul 26 19:52:42 <Scooter> Thanks! Talk to you soon. > Jul 26 19:52:45 <-- Scooter (~chatzilla@...490...) has left > #svg > Jul 26 19:53:19 <afri> so shall we carry on ... or wait for scooter > to come back ... or leave it for another day? > Jul 26 19:53:53 <jwatt> I'm happy to carry on or wait 'til scooter > gets back > Jul 26 19:54:10 <tor> either is fine for me > Jul 26 19:54:17 <jwatt> I'd rather not leave it until another day though > Jul 26 19:54:37 <afri> ok > Jul 26 19:54:47 <afri> what's next? > Jul 26 19:54:48 <tor> no 7 - svg matrices > Jul 26 19:55:00 <afri> should they be live or not? > Jul 26 19:55:23 <afri> the specs say nothing > Jul 26 19:56:02 <afri> does anybody have any strong feelings on this? > Jul 26 19:56:18 <jwatt> but it seems that at least dean and the other > SVG WG members that work on batik say they aren't > Jul 26 19:56:30 <afri> if not, then i'd prefer to leave them as they > are now... > Jul 26 19:56:34 <jwatt> I would like to maintain compatibility with > batik > Jul 26 19:56:51 <jwatt> but to be honest I don't understand your > reasons in the bug > Jul 26 19:56:54 <afri> yeah but i think they just say that because > that's how they implemented them in batik > Jul 26 19:57:18 <jwatt> does dean work on batik? > Jul 26 19:57:24 <afri> i don't know > Jul 26 19:58:01 <jwatt> is there no other way of doing what you want > them to do? > Jul 26 19:58:52 <afri> do you think the compatiblity issue is a real > issue? > Jul 26 19:59:10 <afri> i mean in 'normal' svg usage this is unlikely > to come up > Jul 26 19:59:43 <jwatt> it's the kind of thing that I would be likely > to come up against > Jul 26 19:59:58 <jwatt> but then dom scripting is really what I like > to do most > Jul 26 20:00:06 <jwatt> I don't know about other users > Jul 26 20:00:31 <afri> the way i see it is, the specs don't say > anything, so anybody scripting in this area can't make any assumptions > about it being live or not > Jul 26 20:00:41 <jwatt> what I would be worried about is that people > would start to take advantage of the fact that one matrix could be > referenced by multiple transforms in mozilla > Jul 26 20:01:12 <jwatt> and then it becomes impossible to change it > without annoying a whole load of people > Jul 26 20:01:15 <jwatt> maybe not, but they will > Jul 26 20:01:43 <afri> the thing is I don't see why we should cripple > our api because batik implemented something that is outside the specs in > a particular way > Jul 26 20:01:52 <afri> batik should change > Jul 26 20:02:23 <jwatt> heh > Jul 26 20:02:32 <afri> also, i think it is really inconsistent with > other datastructures that have to be live > Jul 26 20:02:35 <afri> e.g. points > Jul 26 20:02:37 <tor> what does adobe do? > Jul 26 20:02:49 <jwatt> adobe doesn't do that part of the dom > Jul 26 20:02:51 <afri> why are points live and transforms aren't > Jul 26 20:03:03 <jwatt> afri: yeah, I agree with that bit > Jul 26 20:03:46 <jwatt> to be frank this is another WG mess that has > no good solution > Jul 26 20:03:58 <afri> i really think this is not a big > interoperability issue > Jul 26 20:04:24 <afri> live matrices are nearly a superset of > non-live matrices > Jul 26 20:04:46 <jwatt> well for the moment let's leave it as it is, > and perhaps come back to it in the future > Jul 26 20:04:56 <jwatt> I'll just get on with that bug and ignore the > liveness aspect > Jul 26 20:04:57 <afri> what i mean is, any code that is coded with > non-live matrices in mind is likely to work in Moz as well > Jul 26 20:05:06 <jwatt> brb > Jul 26 20:05:21 <afri> not vice versa of course > Jul 26 20:06:32 <jwatt> back > Jul 26 20:06:35 <jwatt> afri: right > Jul 26 20:06:37 <afri> so would you guys be ok with leaving it as it > is for now? > Jul 26 20:07:27 <tor> I'd be curious to hear what others thought > about <embed> content > Jul 26 20:07:28 <jwatt> for now yes, but I'd like to go over how much > of a problem this would be for crocodile-maths with you later > Jul 26 20:07:40 <jwatt> so <embed> > Jul 26 20:08:03 <tor> oh, thought you were talking about the end of > the meeting, not the item > Jul 26 20:08:27 <afri> i think we should do <embed> > Jul 26 20:08:37 <jwatt> I think we should allow the use of <embed> > for svg content in html, but not in xhtml > Jul 26 20:08:51 <afri> i don't agree with dbaron's objections > Jul 26 20:09:10 <jwatt> I do for xhmtl > Jul 26 20:09:10 <tor> is <embed> even in xhtml? > Jul 26 20:09:23 <jwatt> actually I don't know > Jul 26 20:09:36 <jwatt> come to think of it, probably not > Jul 26 20:10:11 <jwatt> In which case I would support implementing it > Jul 26 20:10:18 <jwatt> (your patch) > Jul 26 20:10:40 <tor> but should we always use the internal svg? > Jul 26 20:11:13 <tor> or should we <span class="quiet voice">add a > pref</span>? > Jul 26 20:11:23 <afri> heh > Jul 26 20:11:44 <afri> does the abobe stuff work with moz? > Jul 26 20:11:58 <afri> i've never tried it > Jul 26 20:12:22 <tor> it did last time I tried > Jul 26 20:12:23 <afri> from my point of view, always running native > svg would be just fine > Jul 26 20:12:57 <afri> it probably depends on how much people use asv > with moz > Jul 26 20:13:08 <tor> it would be a problem for a customer currently > happily using svg beyond the capablities of mozilla > Jul 26 20:13:21 <jwatt> does <embed> not have an attribute for > specifying the prefered plugin? > Jul 26 20:13:33 <afri> but are there customers like that? > Jul 26 20:13:49 <afri> in which case, yeah, we'd probably need a pref > Jul 26 20:14:30 <afri> sorry i got to go as well in a minute > Jul 26 20:14:52 <afri> tor: what do *you* think about embed? > Jul 26 20:14:59 <jwatt> afri: will you be back later when scooter > gets back? > Jul 26 20:15:14 <afri> if we had a pref would dbaron be ok with it? > Jul 26 20:15:23 <tor> afri: I think we should handle embed content > Jul 26 20:15:28 <afri> jwatt: hopefully > Jul 26 20:15:52 <tor> afri: maybe we should check if a plugin can > handle it first, then go to the browser? > Jul 26 20:16:09 <afri> sounds good > Jul 26 20:16:20 <afri> would that be easy to implement? > Jul 26 20:16:43 <tor> not sure offhand - have to check the code > Jul 26 20:17:27 <afri> ok, sorry gtg - talk to you later > Jul 26 20:17:33 --- You are now known as afri_away > Jul 26 20:19:49 <jwatt> tor: enumerate the gecko-content-viewers > category for supported mime types? > Jul 26 20:20:32 <jwatt> practically a quote > Jul 26 20:36:44 --> santamarta > (juanjo@...491...) has joined #svg > Jul 26 20:40:53 <-- shaver (~shaver@...489...) has left #svg > Jul 26 21:14:56 <tor> mailed the quartz guy to check the status of > that backend > Jul 26 21:23:18 <jwatt> cool > Jul 26 21:23:23 <jwatt> afri: ping > Jul 26 21:23:50 --> Hixie_ (~ianh@...492...) has > joined #svg > Jul 26 21:24:13 --> rocWork (roca@...493...) has > joined #svg > Jul 26 21:28:55 <jwatt> tor, we might come short of some aspects of > svg tiny, but aren't there things we do that are only in basic or full? > Jul 26 21:31:00 <tor> jwatt: yes, gradients are the big one > Jul 26 21:31:14 <rocWork> mmm, gradients > Jul 26 22:30:29 --> Scooter (~chatzilla@...490...) has > joined #svg > Jul 26 22:37:11 <-- DaaWk has quit (Ping timeout: 372 seconds) > Jul 26 22:37:15 <jwatt> hi scooter > Jul 26 22:37:35 <-- Daa has quit (Ping timeout: 372 seconds) > Jul 26 22:39:18 <tor> did my mail get through? I haven't gotten the > bounce back from drivers, but apparently gila is suffering from spammage > Jul 26 22:39:44 <jwatt> tor: that's what my previous comment was about > Jul 26 22:46:55 --> DaaWk (daa@...494...) has joined #svg > Jul 26 22:48:08 --> Daa (daa@...494...) has joined #svg > Jul 26 22:49:19 --- You are now known as afri > Jul 26 22:56:21 <jwatt> afri: can you expand on what you mean by: > 'Live' matrices that can be shared amongst several transforms come in > very handy for things like implementing dynamic canvases where part of > the objects should be transformation-invariant. > Jul 26 22:57:16 <jwatt> particularly the part about "part of the > objects should be transformation-invariant" > Jul 26 22:57:29 <-- Scooter has quit (Remote host closed the connection) > Jul 26 22:59:52 <afri> jwatt: well e.g. imagine a map where cities > are displayed by some icon > Jul 26 23:00:20 <afri> jwatt: as you zoom into the map you want the > icons to stay at the same size > Jul 26 23:01:14 <afri> ... but everything else should zoom > Jul 26 23:01:45 <afri> so you need a different xform for the city > icons and for everything else > Jul 26 23:02:41 <jwatt> afri: I see, that makes sense -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/)

1 0

flowing text support is in
by bulia byak 03 Aug '04

03 Aug '04

I just committed another exciting patch from Fred: support for flowing text! http://www.w3.org/TR/SVG12/#flow So far it's pretty much read-only, i.e. there's no UI yet for creating flow objects. But they are rendered already, and you can partially edit the envelope shape. Load share/examples/flowtext.svg from CVS, select the object, switch to node tool. and node-edit the envelope - the text will reflow into whatever shape you give it, preserving all the paragraph divisions and applied styles. Really exciting. There are two flow shapes in that example; when the text does not fit entirely in the first one, the rest will go to the second shape (to the right). There's also an "excluded" shape in the middle that the text flows around. You can only edit the first shape so far. You also cannot yet edit the flowed text by text tool - this is yet to be done. Note that this is a feature from SVG 1.2, which itself is not final yet and may change. This means that Batik or Adobe can't yet render that example. And yes, I know, we don't support all of 1.1 yet :) Now with Pango and this new patch, I hope to find time for rewriting the rest of the text system for the next version, to finally make it usable.

3 6

'No Preview' drawing
by Bob Jamison 02 Aug '04

02 Aug '04

Here is the file open dialog again, with a default preview SVG image, for when a preview cannot be displayed: http://troi.titan-aeu.com/~rjamison/inkscape/files/filedialog5.png That is what I meant by the "Preview not available" drawing. It would be nice if someone were to replace this (imho) unattractive placeholder I made, with something simple (small SVG code), elegant, and understated. Something like the Gimp dialog, only nicer. The only constraint is that the words are a single text string that can be localized. Any volunteers? Bob

3 6

Re : comments on fr.po
by Gazal, Geraud (MED) 02 Aug '04

02 Aug '04

>I"m not a native french speaker; can someone please check the following > comments and diff? Thanks. I'm :) > What"s the preference between normal space and non-breaking space before >e.g. `:" ? I"d have thought that it would be bad to have a line break >just before `:", which suggests that non-breaking space (  /   >/  ) is better. In French, the 'typographic" rule is to place a space before (and after) ":". But no line break. -> preference is "non-breaking space" I think I'll try to have a second look on the French translation. (I don't always agree with some translations, or would like to shorten some of them) But haven't had time enough recently to do so. Plus did not manage to synchronize with Frederic Rodrigo. (I think he has done a great job, and I don't want to break this) Regards, Matiphas

1 0

Inkscape Status 2004-08-01
by Bryce Harrington 02 Aug '04

02 Aug '04

Statistics Nov 15 May 15 Jun 15 Jul 15 Aug 1 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1028 928 845 844 (68.5%) (92.7%) (93.4%) (94.0%) (94.0%) Max Week's Rank on SourceForge: 62 36 41 33 17 (99.6%) (99.8%) (99.8%) (99.8%) (99.9%) Total SF Page Views * 475,000 616,263 741,681 838,154 Total SF Downloads * 27,400 34,015 39,359 44,068 Total Freshmeat URL Hits 746 * 7,333 7,946 9,034 Total Freshmeat Subscriptions 16 74 87 93 112 Lines of Code in src/: 115,901 189,116 280,263 264,418 273,381 Code lines 147,471 210,119 192,240 199,473 Comment line 16,757 40,620 41,926 42,411 Blank 25,886 34,677 35,422 36,717 Lines of Docs in doc/: 1,135 4,544 15,170 15,217 16,117 Lines of content in website: 1,173 6,008 6,372 6,784 6,953 Size of the Inkscape wiki: 3,700 18,638 17,176 17,854 19,096 Minutes since last ChangeLog mod: 360 * * 54 30 Bugs open/total: 9/15 57/365 63/401 73/496 103/548 Features open/total: 18/18 183/238 210/285 242/331 253/347 Patches open/total: 1/ 6 4/ 83 5/ 88 8/110 6/117 CVS Commits (as per inkscape-cvs): 481 3391 5549 6314 6,528 Inkscape-devel membership: 49 78 84 95 98 Inkscape-announce membership: 9 43 53 60 65 Inkscape-user membership: 71 76 90 98 Num Translations : 32 33 Ave Translation Ratio: 40.5% 43.8%

1 0

Boehm Garbage Collector
by Jon Phillips 02 Aug '04

02 Aug '04

Hello all, In my attempt at being able to build CVS once again and upgrading to Fedora Core 2 from FC1 (intermediate b4 gentoo), I found several errors which many users and developers have been complaining about not working. Upon some research and acting as JoeUser, it appears that this collector is not available as an RPM or common package!!! I'm reacting to this as JOE USER and this is probably not good for our next release. There are only old rpms for SUSE available and Bryce has tried (and they did not work). Also, Ted says that this garbage collector is avail. for debian. But, there are not packages available for Fedora Core as far as I can see and not many listings elsewhere. Thus, we really need this to be more widely available. There are three options I see: 1.) EASY: Drop Boehm Garbage Collector as a dependency (or replace with something more widely avail) 2.) MED: Push changes upstream and try and get packages for current version of this collector at common repositories. 3.) HARD: Supply our own along with Inkscape as a package or in our main build tree. Please voice your opinions, as our current dependencies are a little too bleeding edge it seems right now, and I totally understand why these are needed. However, if by the time we do a release these dependencies are not widely available on the dominant distros (fedora core, windows, etc), then there will be a problem (aka, loss of users). Thoughts and solutions? Jon -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/)

3 3