August 2004 - Inkscape Devel - Inkscape Mailman

Re: spalah + inkscape?
by bulia byak 04 Aug '04

04 Aug '04

I'm cc'ing my reply to inkscape-devel, where more people will be able to comment. On Sun, 25 Jul 2004 20:30:52 +0300, Anatoly Podlesnuk <beerubeer@...466...> wrote: > Hi > > It's good idea to join spalah and inkscape. > > There is some questions. > > 1. I'm not use in spalah "items tree" of SVG nodes from sodipodi. Spalah > items tree is much simple. So I will need some help with inkscape items > tree. We haven't yet departed too far from Sodipodi's system of SPObjects tree and repr tree that are synced periodically, though we did a lot of incremental changes to it (mostly in the direction C++fying it). I don't think anything simpler than that will actually work for interactive SVG editing. Of course we will be glad to help you with it. > 2. Spalah uses ming library (ming.sourceforge.net) for flash generation, > so inkscape will require this library. No problem. SWF export is a good thing to have, even if for static SVGs at first. > 3. What is role spalah code in inkscape? It will a part of ExportDialog > or inkscape will able to add animation to SVG objects? As I know > inkscape does not support some SVG nodes that responses for animation. Our goal is to be a complete SVG editor, and that includes animation. So we'll need to add support for all the corresponding elements and attributes. As for the UI, what I had in mind is a timeline control selecting one of the frames for editing, plus a separate preview window (based on inkview?) with actual animation. Of course, at this stage all this requires lots of thinking, planning, and experimenting. > 4. What about release planning, code formatting, > classes/functions/variables names? I guess the main development principle is that CVS must always remain compilable and workable, without bad regressions. Releases are done when there's enough stuff for a new release, usually every 2 to 3 months. There's a period of code freeze and bug hunt before a release, but at other times you're free to work on your stuff. For coding style, we have a few guidelines here: http://inkscape.sourceforge.net/doc/coding_style.php Let me know what you think.

5 9

new open dialog
by bulia byak 04 Aug '04

04 Aug '04

First off, I wanted to say thank you to Bob for this work. The preview on open is fabulous! It gives a whole new perspective on my files. A very important addition. Still there are problems. I know some of them may not be fixable due to GTK limitations, but still. 1 The dialog is modal but not transient. It's a very dangerous combination: it sinks under your document and you can't understand why the document is unresponsive. Please make it transient as it was before. 2 The dialog opens in some unpredictable place on the screen. Before, it opened centered over the document window. Can we restore that? (Maybe it's a consequence of its not being transient.) 3 BUG: when I press Ctrl+O for the first time, there are no files listed at all in the directory where it opens, only subdirectories. If I go e.g. to the parent dir and then back, the files appear. 4 After some thinking I'm convinced that (as suggested here) we must replace the "Autodetect" with two new options, "All images" and "All files". That makes much more sense and is more consistent with typical Windows/Mac programs. Both these options would do autodetect and differ in filtering the list: no filtering for "All files" and showing only Inkscape-supported images for "All images". The bad thing about "Autodetect" is that it speaks about what the program does, not about what the user needs. Autodetect is not something I ever want to be off; it must always work behind the scenes. What I want to control is what files are shown and what not, and this is what this menu must affect. 5 The menu should be reordered more logically so that the most frequently used options are at the top: All images <-- default All files SVG Compressed SVG ---------- (separator) AI EPS PS Dia Sketch WMF text rest of bitmap formats... 6 Also it would be nice to group the same formats with different extensions as proposed here: https://sourceforge.net/tracker/index.php?func=detail&aid=990674&group_id=9… 7 If I want to go e.g. to /home/me/inkscape and browse files here, I go to the filename field, type "/home/me/inkscape" and press Enter. Nothing happens. In other programs (and I believe in Inkscape with the old dialog) this caused the dialog to switch to that dir. 8 I get these warnings whenever I open it for the first time: (inkscape:7505): Gtk-WARNING **: Could not find the icon 'gnome-fs-home'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://freedesktop.org/Software/icon-theme/releases (inkscape:7505): Gtk-CRITICAL **: file gtksettings.c: line 447 (gtk_settings_get_for_screen): assertion `GDK_IS_SCREEN (screen)' failed (inkscape:7505): GLib-GObject-WARNING **: invalid (NULL) pointer instance (inkscape:7505): GLib-GObject-CRITICAL **: file gsignal.c: line 1726 (g_signal_handler_disconnect): assertion `G_TYPE_CHECK_INSTANCE (instance)' failed I installed http://freedesktop.org/Software/icon-theme/releases/hicolor-icon-theme-0.5.… but this did not help. Any ideas? Preview: 9 There's no way to turn the previews off. 10 The open/close dance of the preview pane as you go through image/non-image files is a bit disconcerting. Can't we always have the preview widget on (that is, unless you turn it off, see 8), even if inactive for the current file, with the same unchanging size? 11 Bob, you mentioned that you did preview for the bitmap files as well, but this does not work for me, only SVGs. That's it for now, perhaps I'll find more when I test it more thoroughly.

5 13

Adobe Illustrator 7/10, Photoshop CS and Postscript (probably eps)
by Tuukka Pasanen 04 Aug '04

04 Aug '04

hi, A long story short. AI7 files aren't in PDF format and AI10 uses PDF 1.4 as native saving format. I Have also heared that Photoshop CS uses PDF 1.4 as saving format. So i looked in pstoedit program and finded out (Author pointed out) there is GPL svg output plugin. So it would be neat to have this option in inkscape but is it too much to ask for http://www.gnu.org/software/plotutils/ and pstoedit be installed to have this input?? There is also one problem in SVG because it doesn't put fill:none in style inkscape just fills everything in black:P.. I still look how good plot-svg output is but seems good enouhg to me.. Then i just have to think how to find AI7 and AI10 in ill2svg.pl;) So should we use it or not? In Gnu/Linux and *BSD (*nix) world it's easy to install but windoze is biggest problem.. Tuukka.

3 4

convention for XML names
by MenTaLguY 04 Aug '04

04 Aug '04

Although it's not crucial, could we settle on using XML names that adhere to a specific convention? I'm a little worried that having: inkscape:one-thing inkscape:another_thing inkscape:YetAnotherThing as element/attribute names in the same SVG file, while permissible, looks unprofessional. I personally favor using lowercase words separated with dashes (-). -mental

4 3

[Fwd: Re: [gnome-core] gtkmm 2.4 + inkscape + YOU]
by Jon Phillips 03 Aug '04

03 Aug '04

bulia, et al. fyi...contact this person directly to encourage moving package to unstable and then stable fink... Jon -----Forwarded Message----- > From: Martin Costabel <costabel@...26...> > To: Jon Phillips <jon@...235...> > Cc: fink-gnome-core(a)lists.sourceforge.net > Subject: Re: [gnome-core] gtkmm 2.4 + inkscape + YOU > Date: Tue, 03 Aug 2004 12:20:08 +0200 > > Jon Phillips wrote: > [] > > I'm sending this to encourage the move up to gtkmm2 project's current > > stable version 2.4. > > There is a gtkmm24.info in > fink/experimental/gnome/2.6/main/finkinfo/gnome/ on CVS. Have you tried > it? It has been there since 2004/05/16. -- 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

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