- Inkscape Devel - Inkscape Mailman

flowedText switch branch
by Martin Owens 28 Mar '14

28 Mar '14

Hi developers, I've been looking at merging the fix for bug lp:167335 in branch[1] The code looks reasonable, although light. I'm compiling the branch now although could find no mailing list discussion about it and the merge review thread is empty. Any issues with this code before I merge it in? Martin, [1] http://bazaar.launchpad.net/~novalis/inkscape/fix-167335

3 6

SpinachCon Results
by Martin Owens 27 Mar '14

27 Mar '14

Here are the results from the User UX testing yesterday. All testers/users were new to inkscape or had only used it briefly before. UX Problems Found: * 3 Users thought they could select a group by clicking on the whilespace between objects * View > Grid was found to be confusing, Perhaps change to "Show Grid" or "Grid Guides" or some such. * All users found Rows and Columns dialog hard or impossible to find. Once found, it was easy to use. All expected to find it under Align and Distribute dialog. * 1 user thought Export Bitmap would make a PDF and didn't expect PDF in "Save As" * 1 user had screen size issues where many elements were off the sides of the screen. * New users found it hard to locate rotate handles, slow clicking not expected. Some would use the transform dialog instead. * All users could not find document size settings. Expecting Edit > Crop to Selection or similar function. Bugs found: * 3D boxes don't align at all. Thanks to everyone who took part and helped test Inkscape. I think for v1.0 of inkscape we should focus on clearing up a lot of these user interface issues we have. More testing would be good too. Best Regards, Martin Owens

7 11

strange valgrind issues with style.cpp
by mathog 27 Mar '14

27 Mar '14

Markus Engel tells me that all of the clang compiler warnings are now gone. That is good news. There was one clang warning about style.cpp in the list, and I was hoping that the clang fix would resolve an annoying valgrind issue with that file. Sadly, retested with all of these new patches in place and it is still there. When this test is run: valgrind -v --leak-check=yes --leak-resolution=high --num-callers=15 --show-reachable=yes --suppressions=./wcslen_sse2.supp --track-origins=yes src/inkscape --file /tmp/small.emf >/tmp/vgJ.log 2>&1 (The input file doesn't matter, I just use that one because it has some text, in fact, if memory serves, the first such error appears even if no input file is used. Each test takes about 5 minutes to get to the point where the window can be closed.) there are problems like this (sorry about the wrap): ==14247== Conditional jump or move depends on uninitialised value(s) ==14247== at 0x836DFC3: Inkscape::Text::Layout::Calculator::_computeFontLineHeight(font_instance*, double, SPStyle const*, Inkscape::Text::Layout::LineHeight*, double*) (Layout-TNG-Compute.cpp:1054) ==14247== by 0x8370F36: Inkscape::Text::Layout::Calculator::_buildSpansForPara(Inkscape::Text::Layout::Calculator::ParagraphInfo*) const (Layout-TNG-Compute.cpp:1268) ==14247== by 0x837146A: Inkscape::Text::Layout::Calculator::calculate() (Layout-TNG-Compute.cpp:1584) ==14247== by 0xA24A387: ??? ==14247== Uninitialised value was created by a stack allocation ==14247== at 0x821BA60: sp_style_read_ilengthornormal(SPILengthOrNormal*, char const*) (style.cpp:3576) This is line 1054 in Layout-TNG-Compute.cpp switch (style->line_height.unit) { and for some reason valgrind thinks the ".unit" part is either itself uninitialized or the result of something else being uninitialized. Try to print that value immediately before that line and valgrind warns on the output statement. Now here is where it gets weird. sp_style_read_ilengthornormal() is not a complicated function, and when debug print statements are placed in it that print that value valgrind does not complain about accessing that memory location. If memset is used to clear every bit in "val" in that function at the top it does not fix the problem. Running Inkscape in gdb and catching the first place where it goes wrong (from the valgrind output and the print statements, used to show the function parameters and the memory locations) and then setting a watch on that memory location (unit is a bit range, so the whole byte must be watched) shows that _nothing_ touched it before it got to the place where valgrind shows an error. So in location A in the program memory location "M" is initialized, and some time later in location B in the program memory location "M" is no longer initialized as far as valgrind is concerned. (The values stored there are the same in both locations in the program.) For the piece de resistance, if there are a bunch of print statements in sp_style_read_ilengthornormal(), and this std::cout << "DEBUG ssri final unit " << val->unit << " val " << val << std::endl; is placed just above the closing bracket, and valgrind run again, the problem goes away. But that output line _alone_ is not sufficient to clear up the problem, there have to be a bunch of other output lines present. Even though valgrind warns the values all seem to be good. But valgrind is already packed to the gills with warnings and the last thing it needs is many more. I have seen issues like this before, although usually in C, and they usually turned out to be erroneous memory accesses that by chance landed on valid memory. Anyway, I'm glad the scanner is coming up clean, but there is still something wrong with style.cpp. Or at least valgrind thinks so. Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Regression?
by Diederik van Lierop 26 Mar '14

26 Mar '14

Hi all, There's this annoying bug I've found in recent Inkscape builds, but I can't find any bug reports on it, so I figured I'd better ask here first: Every now and then I cannot select any object, except for text boxes. This happens only a few times per hour or so, and I cannot tell yet exactly how to reproduce it. Sometimes I can recover from this, but I cannot reproduce that either. Restarting Inkscape is one way to work around it. I think this only happens while translating or transforming objects. Is this just me, or has anyone else noticed this behavior too? If someone has any pointers as too what (recent) changes might have caused this, then I'll have a stab at fixing this. Thanks, Diederik PS: running a nightly PPA of Inkscape on Ubuntu 13.10

2 1

Fwd: Inkscape development
by Mohsena Akhtar 26 Mar '14

26 Mar '14

Dear concern(s), I am interested to work in inkscape development.I installed latest source code(0.48).But I can not run or compile the project of source code by terminal or editor .How can I do this?I am using ubuntu 12.04 and am trying with code blocks.But it shows error while running.Which will be the correct process?Please anybody help me.

2 1

Building with make
by Isobel Knowles 26 Mar '14

26 Mar '14

Dear Chaps, After much testing with different configurations on a couple of platforms, I think my Makefile is ready for you to try. As I said earlier, I have completely failed to get launchpad to work on my browser so I have worked on the only released version I could get my hands on - 0.48.4. Should you feel it is worthwhile continuing with this approach I am happy to port it to 0.48.5 and beyond. The purpose of my changes is to simplify the configuration and build process, to improve automation, and to do so in an easily-maintainable fashion. I recognise that the autotools and automake in particular, although superficially easy, perform a lot of heavy scripting to produce Makefiles which are far too complicated for most users to read. This in turn makes many developers wary of making anything but the simplest of changes. As a first step toward breaking down this barrier I have removed the need for automake and placed the make rules in plain sight. Although I am still using autoconf to configure the code, the configuration is now cleanly separated from the build itself, and is now simple enough that it can be done by hand without autoconf at all. The changes amount to this: - A bit of tweaking of the configure script to remove automake. - The removal of the myriad of automake files. - The creation of a Makefile which does pretty much everything automake did, but without the mystery. - Adding some convenient structures to aid debugging. - A small number of code fixes to deal with glaring bugs made evident by the above & to clean up the version number storage. (These have probably been fixed already.) I have tried to contain my changes to just autoconf/make-related matters so as to reduce the impact on those later versions of Inkscape which are currently unavailable to me. To keep my changes small I placed all the make stuff in one file. I appreciate this might rankle, but I felt it was best to concentrate on the overall problem for now and sort out the detail later. Please bear this in mind when you review the changes. I have tested the software on Linux with different libraries and compilers. One of the systems was a bang up-to-date Debian Wheezy. Therefore I suggest a developer with a Linux system be the first person to work with me. I have also tested (insofar as I can) a cross compilation with a Linux build machine. I feel confident this should work too, but there are bound to be a variety of problems which will come out of the woodwork. Builds on Windows/Mac should work, but are untested. In the process I couldn't help but notice the cxxtests directory appears to have bitrotted. Is this true of later versions? I have not addressed binary packaging yet because the documents I have seen seem inexplicably complex to me. If someone could tell me how it is actually done on the various platforms I can automate them as well. Source packaging is done. I have documented my changes to the build process in INSTALL and in the Makefile itself but am happy to improve them at your suggestion. This is a work-in-progress. Assuming broad agreement, I would like to: - port it to an up-to-date version, - iron-out the platform issues, - address packaging and distribution, - fix and automate testing, - address linking, libraries and source file grouping, and - attack the many compilation warnings. in the next few weeks. Without further ado, please find two attachments to this email. I have provided it this way to keep it small. You should: - Extract 0.48.4 into a directory and change into it. - Extract the two attachments to this email into that directory. - rm `cat delete-list` - patch -p1 -E -i diffs - rm delete-list diffs - Read INSTALL and the other files it points to. - autoconf configure.ac > configure - Configure, make, install and prepare tar files like so: sh ./configure make -j 6 make install DESTDIR=foo make dist adjusting to your taste. Also try sh ./configure --help to see the new options. Regards, Is.

4 7

Possible problem in Geom::Path
by Markus Engel 25 Mar '14

25 Mar '14

Hi, In 2geom/path.cpp, ll 338-340, the following can be found: // this approach depends on std::vector's behavior WRT iterator stability get_curves().erase(first_replaced, last_replaced); get_curves().insert(first_replaced, first, last); get_curves() returns a std::vector&, all parameters are iterators. Both the comment and a failed debug assertion (Expression: vector insert iterator outside range) made me look this case up and I'm quite sure that this is not allowed: std::vector::erase Iterator validity Iterators, pointers and references pointing to position (or first) and beyond are invalidated [.]. http://www.cplusplus.com/reference/vector/vector/erase/ So (at least) first_replaced is invalid in the second line. Can anyone confirm this? Is there an easy workaround? Regards, Markus

2 2

setAttribute std::string or Glib::ustring
by Johan Engelen 25 Mar '14

25 Mar '14

Hi all, To easier use repr->setAttribute, I want to add two extra (overloaded) functions virtual void setAttribute(gchar const *key, gchar const *value, bool is_interactive=false)=0; virtual void setAttribute(gchar const *key, Glib::ustring const &value, bool is_interactive=false)=0; virtual void setAttribute(Glib::ustring const &key, Glib::ustring const &value, bool is_interactive=false)=0; Should I use std::string or Glib::ustring for this? Thanks, Johan

3 7

clang static analysis report
by Markus Engel 25 Mar '14

25 Mar '14

Hi, here's the results of running scan-build on a part of the sources. I interrupted it, this takes quite a while. Anyway, you've got 263 possible bugs to check. Either there are many false positives or. inkscape shouldn't even start :) . Open index.html: https://db.tt/3Nj4vpmG Regards, Markus

2 3

Re: [Inkscape-devel] clang static analysis report
by Johan Engelen 24 Mar '14

24 Mar '14

(back to list) On 24-3-2014 23:58, mathog wrote: > 4. I don't understand what it is warning about at line 706 in > upmf.c. It doesn't like this: > > int U_DPO_free(U_DPSEUDO_OBJ **dpo){ > if(!dpo){ return(0); } > if(!*dpo){ return(1); } > U_DPSEUDO_OBJ *kpo = *dpo; > if(kpo->poPoints){ U_PO_free(&kpo->poPoints); } > if(kpo->poTypes){ U_PO_free(&kpo->poTypes); } // <------ > free(*dpo); > *dpo=NULL; > return(1); > } > > At the arrow it gives the warning: "Branch condition evaluates to a > garbage value" > > The U_DPSEUDO_OBJ struct looks like this > > typedef struct { > uint32_t Elements; /**< Element count, applies to both > PseudoObjects */ > U_PSEUDO_OBJ *poPoints; /**< Points in path */ > U_PSEUDO_OBJ *poTypes; /**< Types of points in path */ > } U_DPSEUDO_OBJ; > > and this is U_PO_free() > > int U_PO_free(U_PSEUDO_OBJ **po){ > if(!po)return(0); > if(!*po)return(1); > if((*po)->Data)free((*po)->Data); > free(*po); > *po=NULL; > return(1); > } As you can read on the webpage that scan-build generates, there are 18 steps involved. The reason that line 706 is bugged is because for some control flow "kpo->poTypes" has a garbage value. The cause is that for the control flow indicated, the U_DPSEUDO_OBJ *Path is never fully properly initialized, in particular kpo->poTypes isn't. -Johan

1 0

Where is clipping information stored relative to an sp object?
by mathog 24 Mar '14

24 Mar '14

Along with implementing more of the EMF clipping records I'm looking into implementing clipping output to that format, which at present is completely unsupported. All the EMF output code sees is a pointer to "style", but it can get back from there to the object. Can one of you enlighten me as to the "path" from the object back to the stored clipping paths and the logic that ties them together? The data that needs to be extracted by working back up the data tree is like this: pathvector1 (a simple clippath with one path, references nothing else) done pathvector1 AND pathvector2 (a clippath that is itself clipped by another clippath) done pathvector1 OR pathvector2 (a clippath that has two paths) done Ideally this would be as C++ variables and not as the corresponding SVG text, so it would not need to be parsed again. Also on a related point, EMF clipping has modes that support AND, OR, XOR, and DIFF. EMF input goes through a text SVG intermediate, so the first two can be done using <clippath> syntax that I'm already aware of. Does SVG have path combination syntax for XOR and DIFF (subtract)? I know Inkscape has code that will operate on pathvectors to do this, but what I'm asking is if there is a standard SVG syntax that Inkscape supports more or less along these lines: <path> id="XORofPath1AndPath2" operator="XOR" path1="(a path specification)" path2="(another path specification)" </path> Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 1

libcroco fix
by Johan Engelen 24 Mar '14

24 Mar '14

To the maintainer of our libcroco copy, Please have a look at rev. 13178, where I fixed errors in pointer type signed-ness (Glib functions like g_strdup want a gchar*, not a guchar*). I guess you'd want to upstream the small change. cheers, Johan

5 7

Windows builds: enable -Werror
by Johan Engelen 23 Mar '14

23 Mar '14

Hi all devs on Windows, Please consider enabling -Werror for your work. I added stuff to build.xml to make it easy for you to see the status of trunk. Just remove the space between "-" and "->" to enable -Werror on line 356. Currently, there are 3 warnings/errors left (tdm-gcc 4.6.1). They are very likely to be false positives. But I am not sure yet. Make sure you don't add any new ones! Thanks for your effort in improving the code quality and stability of Inkscape. cheers, Johan

1 0

Possibly unitialized used of variable
by Johan Engelen 23 Mar '14

23 Mar '14

Hi all, GCC 4.6.1 gives an uninit var warning in sp-canvas.cpp: src/2geom/generic-interval.h: In static member function 'static void SPCanvasGroup::update(SPCanvasItem*, const Geom::Affine&, unsigned int)': src/2geom/generic-interval.h:144:8: error: '*((void*)(& bounds)+24).Geom::GenericInterval<double>::_b[1]' may be used uninitialized in this function [-Werror=uninitialized] src/display/sp-canvas.cpp:1051:19: note: '*((void*)(& bounds)+24).Geom::GenericInterval<double>::_b[1]' was declared here ... I have been working on this warning for hours, but I cannot find the problem. Because I have already found a (serious) bug from another warning like this, I am very reluctant to conclude that it is a compiler mis-analysis. I would greatly appreciate someone else having a (thorough) look at this. Thanks, Johan

5 10

I want to help and I want help……
by MARK BUCHALTER 23 Mar '14

23 Mar '14

To the developers. (GREAT PROGRAM) I am a web developer and created an app using mostly inkscape…that works well… but unfortunately, no mater how great a program this is,…... it is still a work in progress…. I am getting many bugs when try to revise and want to share what I have done and get some feedback. AND Try to help solve some of this issues. I would be happy to discuss this with anyone who thinks they can assist…please look at the App…located here….. http://www.digitaldudes.com/1-visualizer/9-link-visualizer.svg this is a swim suit / active ware designer I created…. I have not seen anyone else doing this kind of stuff… maybe because it is hard to make money BUT…PLEASE LOOK THANKYOU MARK BUCHALTER captbuck@...2857... cell" 340-642-3740

2 1

make doing unneeded compilations?
by mathog 22 Mar '14

22 Mar '14

Lately I have noticed that when I come back to Inkscape on another day, modify a single cpp (today's was drawing-text.cpp) and "make" it starts rebuilding all sorts of things that would seem to be utterly unrelated. In fact, the build is so extensive it may well be a complete rebuild. Here is just a fraction of the things it compiled: ... CXX sp-mesh-gradient.o CXX sp-mesh-patch.o CXX sp-mesh-row.o CXX sp-object.o CXX sp-path.o CXX sp-pattern.o CXX sp-rect.o CXX sp-shape.o CXX sp-stop.o CXX sp-style-elem.o CXX sp-text.o CXX sp-tref.o CXX sp-tspan.o CXX sp-use.o CXX style.o ... If the same file is later modified again, "make" the next time does the expected thing and just compiles that one file and then links everything. Any idea why it is doing that? It almost seems like the Make files now have some concept of "old" object files and anything over a day old gets rebuilt. Trunk 13168, Ubuntu 12.04.4 LTS Configure was run with export CPPFLAGS="-DWITH_SVG2" ./configure --disable-strict-build Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

4 6

libuemf: upmf.c
by Johan Engelen 22 Mar '14

22 Mar '14

Hi David, In libuemf/upmf.c, what is this line of code supposed to do? line 3096: U_SERIAL_DESC *List = List; Thanks for fixing, Johan

1 0

filter2D_IIR problem
by Johan Engelen 22 Mar '14

22 Mar '14

Hi all, There may be a bug in nr-filter-gaussian.cpp. The following warning is emitted: src/display/nr-filter-gaussian.cpp: In function 'void Inkscape::Filters::filter2D_IIR(PT*, int, int, const PT*, int, int, int, int, const IIRValue*, const double*, IIRValue* const*, int) [with PT = unsigned char, unsigned int PC = 1u, bool PREMULTIPLIED_ALPHA = false, IIRValue = double]': src/display/nr-filter-gaussian.cpp:504:45: instantiated from here src/display/nr-filter-gaussian.cpp:342:13: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] src/display/nr-filter-gaussian.cpp:343:13: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] src/display/nr-filter-gaussian.cpp:504:45: instantiated from here src/display/nr-filter-gaussian.cpp:358:17: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] The warning is emitted because the (incredibly ugly!) #define PREMUL_ALPHA_LOOP for(unsigned int c=0; c<PC-1; ++c) will resolve to #define PREMUL_ALPHA_LOOP for(unsigned int c=0; c<0; ++c) for the template instantiated value for PC = 1. Meaning that the loop will never run. Is this intended? If so, please fix the code to not emit that warning. If it's a bug, please fix the bug! :) Thanks, Johan

2 1

Re: [Inkscape-devel] Warning on explicit cast in libuemf
by Johan Engelen 21 Mar '14

21 Mar '14

Back to on-list. On 21-3-2014 20:07, mathog wrote: > > 1. Why do we need libiconv in devlibs at all since it is already in > mingw? It is not in my copy of MinGW (TDM-GCC). > 2. Why is the version in devlibs 1.09 (from 2003 or 2004) when 1.14 > is current (and the version in mingw)? Don't know. How harmless is upgrading without upgrading our other dependencies? ciao, Johan

1 0

Warning on explicit cast in libuemf
by Johan Engelen 21 Mar '14

21 Mar '14

Hello David, in libuemf/uemf_utf.c, there is /** \cond */ /* iconv() has a funny cast on some older systems, on most recent ones it is just char **. This tries to work around the issue. If you build this on another funky system this code may need to be modified, or define ICONV_CAST on the compile line(but it may be tricky). */ #ifdef SOL8 #define ICONV_CAST (const char **) #endif //SOL8 #if !defined(ICONV_CAST) #define ICONV_CAST (char **) #endif //ICONV_CAST /** \endcond */ An example of the macro usage: ... status = iconv(conv, ICONV_CAST &src, &srclen, &dst, &dstlen); ... This generates a warning because, at least on Windows, iconv expects a (const char **) and gcc complains about an unsafe cast. This is not at all trivial, and is a very valid compiler warning. Please read this: http://stackoverflow.com/questions/14562845/why-does-passing-char-as-const-… I do not know how to fix this at the moment. Of course I could do an #ifdef for Windows to replace the cast with what iconv wants, but.... Thanks for having a look, Johan

3 3

Incomplete switch statement
by Johan Engelen 21 Mar '14

21 Mar '14

Hi all, Yesterday I changed the compiler flags to now error on incomplete switch statements (-Werror=switch). Because of this, a buildbot found a tiny bug with GTK3: CXX ui/dialog/input.o ../../src/ui/dialog/input.cpp: In member function 'bool Inkscape::UI::Dialog::InputDialogImpl::eventSnoop(GdkEvent*)': ../../src/ui/dialog/input.cpp:1917:16: error: enumeration value 'GDK_SOURCE_KEYBOARD' not handled in switch [-Werror=switch] ../../src/ui/dialog/input.cpp:1917:16: error: enumeration value 'GDK_SOURCE_TOUCHSCREEN' not handled in switch [-Werror=switch] ../../src/ui/dialog/input.cpp:1917:16: error: enumeration value 'GDK_SOURCE_TOUCHPAD' not handled in switch [-Werror=switch] First: jay! for buildbots! The actual error is not too bad, just needs someone to look over the new GDK_SOURCE_s and figure out how to handle them there, with an #ifdef for GTK3. Jon, can you have a look? Thanks for fixing this, Johan

1 0

CSS Merging Bug
by Martin Owens 21 Mar '14

21 Mar '14

Hi Devs, I need some help with the style bug #167937 I've created this patch which I've put into a branch which fixes the direct issue as it does not corrupt element styles with css values any more: http://bazaar.launchpad.net/~doctormo/inkscape/css-style/revision/13177 It's a fairly simple patch which redirects the stylesheet setter so it sets the computed value of each of the properties instead of the actual value. But it has bugs. Elements appear black until they have been nudged, then the style is applied. I can imagine the parent/inherited styles probably suffer the same bug but it's been under reported. I'd also be interested in hearing if this is the right approach to fix the bug. Would it be better to change it so it updated the styles value but kept the .set set to false to indicate no real value should be saved? Thanks for your help, Best Regards, Martin Owens [1] https://bugs.launchpad.net/inkscape/+bug/167937

2 2

Warnings: compiler flags
by Johan Engelen 20 Mar '14

20 Mar '14

Hi all, Can someone tell me where to add compiler warning/error flags for Makefile users? (On Windows, I know) Am going to slowly activate erroring on specific warnings. Thanks, Johan

3 4

Re: [Inkscape-devel] Warning on explicit cast in libuemf
by mathog 20 Mar '14

20 Mar '14

On 20-Mar-2014 16:10, Jon Cruz wrote: > > The more "big picture" solution is to just get rid of uemf_utf.c > altogether. ... > So a rough idea would be to delete uemf_utf.c and uemf_utc.h and > replace the conversion use in other files with the standard Glibmm > calls. libUEMF has no glib dependencies. It happens that when libUEMF is used in Inkscape glib is available, but that is not the case in other situations. Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Status of Inkscape 0.91 Release
by Bryce Harrington 20 Mar '14

20 Mar '14

2. Chill. DONE Development focuses on wrapping up DONE Disable features that aren't finished Identify 'make distcheck' issues Identify any critical OSX/Win32 packaging issues Identify remaining writing needed for Release Notes. DONE Regressions Bug Hunt: 500 points Update tutorials and other docs Can you help me identify where we are with the remaining items in the above list? 1. I ran 'make distcheck' and hit an error: CXX event-log.o ../../src/event-log.cpp:11:33: fatal error: util/signal-blocker.h: No such file or directory compilation terminated. There were also a bunch of errors in libcroco, that'll all need cleaned up. 2. I have zero insights into OSX or Win32 packaging. Can someone give me a low-down on what the current state is with these? Do we have all the dependency changes covered? Do the packaging scripts still work and produce a viable binary? Any other issues folks are worried about? (I do not want to find ourselves blocked from releasing due to Win32/OSX packaging problems, so if there are any I want to get them on the radar now, so we don't move forward from chill or freeze until they're sufficiently taken care of.) 3. I reviewed the ReleaseNotes a few months back and they looked really solid. Are there any areas you see where we need more attention? 4. Which features from this release need to have documentation and/or tutorials made? Is there any other tutorial or documentation work that will require tracking with the release? Bryce

12 29