- Inkscape Devel - Inkscape Mailman

Glyphs that return no vertical extent information???
by mathog 08 Apr '13

08 Apr '13

In trying to clean up my libTERE text reassembler code so that it works properly with R->L languages like Hebrew I found that the Hebrew glyphs mostly contain no useful vertical extent information, even though this information is present for English language characters. Here is the code (in C, this is not strictly a part of Inksape, but is used by it): int TR_getadvance(FNT_SPECS *fsp, uint32_t wc, uint32_t pc, int load_flags, int kern_mode, int *ymin, int *ymax){ FT_Glyph glyph; int glyph_index; int advance=-1; FT_BBox bbox; glyph_index = FT_Get_Char_Index( fsp->face, wc); if (!FT_Load_Glyph( fsp->face, glyph_index, load_flags )){ printf("DEBUG TR_getadvance 1\n");fflush(stdout); if ( !FT_Get_Glyph( fsp->face->glyph, &glyph ) ) { printf("DEBUG TR_getadvance 2\n");fflush(stdout); advance = fsp->face->glyph->advance.x; FT_Glyph_Get_CBox( glyph, FT_GLYPH_BBOX_UNSCALED, &bbox ); printf("DEBUG TR_getadvance bbox.ymax/ymin %d,%d\n",bbox.yMax,bbox.yMin);fflush(stdout); printf("DEBUG TR_getadvance glyph metrics height %d vertbearing Y %d\n",fsp->face->glyph->metrics.height,fsp->face->glyph->metrics.vertBearingY);fflush(stdout); if(ymin && (bbox.yMin < *ymin))*ymin=bbox.yMin; if(ymax && (bbox.yMax > *ymax))*ymax=bbox.yMax; if(pc)advance += TR_getkern2(fsp, wc, pc, kern_mode); FT_Done_Glyph(glyph); } } return(advance); } When the font is "Century Schoolbook L", for instance all Hebrew strings trigger a series of these output lines: DEBUG TR_getadvance 1 DEBUG TR_getadvance 2 DEBUG TR_getadvance bbox.ymax/ymin 0,0 DEBUG TR_getadvance glyph metrics height 0 vertbearing Y 0 and ymin,ymax are returned as zero. So far only one tested font actually had this vertical extent information for these glyphs - Verdana. The glyph does eventually render OK in Cairo, but not being able to figure out the vertical extent of the bounding box really makes it difficult to reassemble complex text into <text><tspan> structures! Is there some trick for pulling these vertical extent values out when the font itself appears not to hold them? Perhaps a function that will calculate them from the glyph instead of reading them from the font? The only other approach I could think of was to fall back to looking up the vertical extents for some glyph that does have these values, like "A", and applying them for the missing Hebrew glyph. That would be a terrible approximation, but better than saying the vertical extent is zero! Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

GSoC 2013
by Josh Andler 08 Apr '13

08 Apr '13

Hey All, We've been accepted again this year as a mentoring organization. If you are interested in mentoring please apply at http://www.google-melange.com/gsoc/org/google/gsoc2013/inkscape and if you are a student interested in participating with our organization it is recommended to get in contact with us sooner rather than later. For more information on participating with our organization as a student please visit: http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code We're looking forward to another great summer and hope you will join us! Cheers, Josh

1 0

new .48 XAML output not compatible with silverlight, PathFigureCollection not supported in silverligth 5
by Damian Hallbauer 08 Apr '13

08 Apr '13

Hello, Thanks for your continued development on Inkscape. Due to all the format wars this the best and only tool i can use for my self-funded Silverlight game. But I'm having a problem. We have been stuck using version .47 and it was crashing allot randomly, but the xaml worked, in WPF and silverlight. finally got .48 to work, it is stable, but i get a problem, its now using PathFigureCollection for any simple path. here is the issue i am stuck with now. http://stackoverflow.com/questions/11331549/why-does-this-xaml-path-crash-s… . MSIE wont draw it. Could you please revert so that the XAML does without the Figures= ? Or set it as an option if you are taking it somewhere needed?. So far i see only one object in the collection anyways. I just downloaded the latest daily build from Skydrive and still see the Figures.. This may affect RT, phone 8 and other developers. Another smaller issues i have: -thinner line weight on paths do not show in xaml. ( this worked in inkscape .47) i work around it by scaling 10x more on my drawing, then import at 0.001 scale. -groups do not show in xaml( this is still broken but i just ungroup for now) we only use simple paths, layers, strokes, and sometimes groups. if my game makes any money after this 4+ years development i will donate. Yours, Damian Hallbauer

2 1

preview in filter extension
by TimeWaster 08 Apr '13

08 Apr '13

hi list, i am trying to program a python filter extension and i need to know if the script is called for preview or for the live run. i already found out that the script is called when the preview checkbox is checked and when the apply button is pressed, but i found no differences in the data delivered to the script when called. in the c++ code both calls are different, but from the python side they seem to have the same effect. are there any differences? or is there any other way to determine what was clicked? thanks in advance, TimeWaster -- Save a printer manufacturer. Print this e-mail unless it's really necessary not to do so.

2 2

Re: [Inkscape-devel] C++ification of the SPObject tree
by Markus Engel 08 Apr '13

08 Apr '13

Okay, so here's my branch: https://code.launchpad.net/~engelmarkus/inkscape/cppify Markus

14 30

Extrangle [Y] coordinate in a Geom:Point generated with controlPontPosition::selectAll
by Jabiertxo Arraiza Cenoz 07 Apr '13

07 Apr '13

Hi to all. Posted in IRC, no rsolve. New attemt, maybe this is a better plaze for this type of cuestions. Im attemting to fit identical, the position of 2 Geom:Points, one generated by Inkscape::UI::controlPontPosition::allNodes() and a cast to Inkscape::UI::Node->position() and the other with first_segment()->initialPoint(). The values need to be the same but one return 154.13750999999999, 406.75175261718755 and the other 154.13750999999999, 645.61042999999995. Whith other node/segment the values are -74.927954, 664.71799261718752 and -74.927954, 387.64418999999998. The value with initialPont is similar -rouded- than in the SVG. I test to pass to the other desktop->w2d,desktop->d2w, and normaliza(), with no luke. What im doing bad? By, Jabier.

3 3

Compiling new files
by Arshdeep Singh 07 Apr '13

07 Apr '13

Hi people, If I want to add custom .cpp and .h files to the make list, how can I accomplish that ? -- demicoder

3 3

tablet input is laggy for Windows x64
by Yale Zhang 06 Apr '13

06 Apr '13

Inkscape developers, I'm using a custom Windows x64 Inkscape build and I'm getting huge lags (1/2 second or more) when drawing with my Wacom Intuos 5. Rather than submit a bug report and waiting, I want to debug and fix it, if possible, myself. Can someone give me a clue how to approach this? I was thinking of recording time stamps for input events in the event handler functions (e.g. sp_dyna_draw_context_root_handler() ) but if the input event handler isn't the bottleneck, I could measure time stamps of when the strokes show up on the screen, but in which function would I find that? Also, I don't think the processor is a bottleneck because I looked at the CPU usage when rapidly scribbling and it only uses 1/2 the throughput of 1 core. Also, is anyone out there interested in Inkscape for Windows x64? I know the extra memory available doesn't help much, but believe that there should be a speed boost from the extra 8 registers and SSE2. If there is demand, are there any build issues that I can help with? I think I read from previous posts that the main work was to switch to MingW64. I'm currently cross compiling Inkscape on a Linux host. Yale

1 0

Windows 16-bit colordepth memleak
by Johan Engelen 04 Apr '13

04 Apr '13

Hi all, A colleague today found Inkscape later than 0.48.2 unusable because of a huge memleak. He was using it in 16-bit (remote desktop). We found that on Windows 7, Inkscape 0.48.4 and trunk are unusable because of very rapidly increasing memory usage it quits because of no more available memory. Steps to reproduce: 1. set Windows color-depth to 16-bit 2. start Inkscape 3. zoom in and out repeatedly (mousewheel) 4. watch the used memory increase very rapidly in the task manager Might be easy to fix this, perhaps some of the blitting/display code assumes a 32-bit buffer? I've added it to the know issues for 0.48.4 and 0.49. (I remember that earlier versions of Inkscape would not even start when using 16-bit colordepth.) Thanks for looking into it! Cheers, Johan

2 2

Right to left language support, is this intended or a bug?
by mathog 02 Apr '13

02 Apr '13

Here is a test file: http://saf.bio.caltech.edu/pub/pickup/hebrew_decorations1.svg It starts with two Hebrew sentences (R->L) and ends with the English word "overline" (L->R). It is all overlined (text-decoration.) So the text is supposed to look like this: __________________ --3--><--2--<--1-- The first Hebrew sentence is longer and the second one has two words of three characters each. (No browser I tried rendered this correctly, hence the long verbal description.) Anyway, when an attempt was made to print this to an EMF file this is what was observed: 1. Each Hebrew character was sent as its own string. 2. In "style" both "direction" and "block_progression" computed values were set to 0. 3. The one English word was sent as a string (not character by character). Again, the direction and block_progression were set to 0. Naively for this sentence I expected to see two calls to PrintEmf::text(), the first with all of the Hebrew and text direction nonzero, and the second all English and direction zero. Only the second part of that was correct. Before I try to "fix" it - is the current character by character behavior for R->L text intentional? (Not having tried to fix it yet, it could well be that this is a side effect of some of my changes.) On a related note elsewhere, for instance, when rendering text to the screen, Inkscape leaves mixed L->R,R->L tspans in one piece - and then does some very strange things when one tries to navigate with the arrow keys within them to edit the text. Would it perhaps not be better to break up all mixed direction tspans that hit TNG compute into 2 or more tspans, each of which is either all R->L or all L->R characters, and for good measure, has the direction="rtl" and "ltr" tags set to match? Doing it the current way all sorts of other pieces of Inkscape have to know about bidirectional text. Without the tags being set other code cannot in general determine the tspan direction quickly - put 20 leading and trailing spaces around the core text, and the direction is not determined until something other than a space is encountered. Reduce all such tspans to homogeneous pieces in the TNG compute code and the rest of inkscape only needs to know how to handle the extra direction information for each tspan - which is much simpler to deal with than bidirectional text. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 2

Problem with scale/rotate as root
by Jabiertxo Arraiza Cenoz 01 Apr '13

01 Apr '13

Hi. In a debian testing box amd64, i have a problem running inkscape as root user, when select 2 or more nodes of a path, no handles to scale/rotate/skew show. Is the correct behabiour? By.

1 0

For prospective GSoC students
by Johan Engelen 31 Mar '13

31 Mar '13

Hi all, If you are thinking about applying for GSoC this year, but you do not have Inkscape-development experience, you are probably thinking: how to start? For this, we have created the "easy-fix" tag in our bug tracker. Have a look here for some (probably) easy to fix bugs, that do not require extensive knowledge of Inkscape's codebase. https://bugs.launchpad.net/inkscape/+bugs?field.tag=easy-fix Ciao, Johan

1 0

Re: [Inkscape-devel] Problem with the tarball source on website
by Jon Phillips 31 Mar '13

31 Mar '13

Yes let's push through a point release with a couple of back ported fixes. 6 months until release and 3 years after major release is too long guys! While everyone is enjoying their weekends, there are people who really need inks cape. Sciscla do you also do the packaging? Who handles that? Jon On Mar 31, 2013 2:13 AM, "Michael Lyons" <mdl0394@...400...> wrote: The tarball located here: http://inkscape.org/download/?lang=en (This is the direct download link: http://downloads.sourceforge.net/inkscape/inkscape-0.48.4.tar.gz) Has a syntax error in the file desktop-widget on line 252, there is an added comma before the semi-colon. This bug was not present in the bzr, so I assume it accidentally got added sometime before balling it up for release. Mike Lyons -- Michael Lyons - Sent from Computer ------------------------------------------------------------------------------ Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

Inkscape 0.49 Release? Is Inkscape Development Frozen?
by jon＠...235... 30 Mar '13

30 Mar '13

Hey dudez, long time no rejon ;) Over at my company http://fabricatorz.com we are pushing on new changes to Open Clip Art Library (OCAL). One thing that is really important is to get a new version of Inkscape out so that the most popular Inkscape downloaded Windows has working OCAL import working. How close is the release? How can we help and/or accelerate it? Who is in charge of releases now? Also, checking out http://inkscape.org I notice no news in about a year now on the main page of the site. Let's make some big news!!! I hope everyone is truly well! Don't forget about Open Clip Art Library! We even have some new code for an updated site over at github: http://github.com/openclipart Cheerz! Jon -- Jon Phillips 王✳ http://fabricatorz.com ✳ skype: kidproto ✳ irc: rejon +1.415.830.3884 (global) ✳ +86-187-1003-9974 (beijing)

5 7

Guides Improvement and GSoC 2013
by Michael Lyons 30 Mar '13

30 Mar '13

Hey guys, I would like to work on improving the guides system in inkscape, including adding a dialog listing current guides, and allowing for easier adding/removing/editing of guides. I have never worked with open source software before, but I have used inkscape from a user point of view for a number of years, and hope that gsoc will be an entry point for contributing to the project. I know that gsoc has not announced their accepted organizations yet, but I wanted to get started as soon as possible (to hopefully increase my chances of acceptance). I have a couple of questions real quick: The project seems to have been started by a user a while back ( https://code.launchpad.net/~john-glassmyer/inkscape/guides-improvement), but he didn't take ownership of the spec, so I assume that this project is still available to work on? Also I understand that inkscape has a "two patches" rule before a user is given commit rights. How big do these patches have to be, and should we try to relate these patches to the project we are looking into proposing or is it better to try to fix a bug that is listed as more important? Thanks! Mike Lyons mdl0394@...400... mdl7240@...2960...

2 1

Problem with the tarball source on website
by Michael Lyons 30 Mar '13

30 Mar '13

The tarball located here: http://inkscape.org/download/?lang=en (This is the direct download link: http://downloads.sourceforge.net/inkscape/inkscape-0.48.4.tar.gz) Has a syntax error in the file desktop-widget on line 252, there is an added comma before the semi-colon. This bug was not present in the bzr, so I assume it accidentally got added sometime before balling it up for release. Mike Lyons -- Michael Lyons - Sent from Computer

1 0

optional.hpp???
by mathog 29 Mar '13

29 Mar '13

Spent some time today using valgrind to squish some preexisting bugs that were affecting the experimental text-decoration draws. This is not a lot of fun, since under valgrind it takes almost 4 minutes before inkscape will accept input events well, and 20 seconds or so for it to shut down again. Anyway, so far, I found that sp_style_read_itextdecoration in style.cpp was broken several different ways and so rewrote it. That made text decoration turn on reliably. (Not render perfectly, that is another problem.) Will post the fix for style.cpp in bug 172133 later. I am currently stuck on another front. These two issues: ==4258== Conditional jump or move depends on uninitialised value(s) ==4258== at 0x810F401: SPClipPath::show(Inkscape::Drawing&, unsigned int) (optional.hpp:273) ==4258== Conditional jump or move depends on uninitialised value(s) ==4258== at 0x810F617: SPClipPath::setBBox(unsigned int, Geom::OptRect const&) (optional.hpp:273) are in "optional.hpp" which is apparently a file transiently created during the build and then deleted. Talk about a moving target! Which files are the basis for the creation of optional.hpp? Other than dropping print statements into the basis files, how does one go about debugging a transient file like this? Is there some way to get a listing of "optional.hpp"? Line 273 is not very helpful without the corresponding source code. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 1

AutoExport Script
by Xander Pirdy 29 Mar '13

29 Mar '13

Hi all. I wrote a small script to help me automatically export portions of an svg file as individual images. I posted about it on the [inkscape forum]( http://www.inkscapeforum.com/viewtopic.php?f=34&t=13682), and was recommended (by Jelle fwtw) to post it here. The script can be found at https://github.com/oxalic/AutoExport. Basically it takes an svg file, finds any groups that are named with a form of "prefix:name", and exports those as "name.png" "name.eps" and "name.svg". The script should be fairly well documented and very easy to extend. It is nice because it would be fairly simple to incorporate prefixes in the filenames, and it can export nested things (I use it to export both compound images, and scheme images in chemistry). It is a bit hackish (take a look at how I had to implement the export to plain svg's!), so if y'all have any suggestions or comments I'd love to hear them. Also more about my use case etc, the readme should cover most questions.

1 0

Re: [Inkscape-devel] C++ification of the SPObject tree
by Markus Engel 29 Mar '13

29 Mar '13

> In this case I think the third question is pretty clearly "it helps a lot". Getting answers on the first two takes a bit of end-to-end measurements in full use cases. If you happen to have some ideas on how to check this for the change, that would be helpful. If not, then it is something that we should look into overall anyway. > > One interesting point is that developer intuition is wrong 80% of the time when it comes to performance and optimization. So we need to get some actual measurements set up on the code. Well, currently I'd expect the time for creating new objects to have increased a bit as for every step down the inheritance hierarchy, one more new and delete have to be executed. Calling virtual functions on these objects shouldn't take longer, although I don't know what happens under the hood of these casting macros. So I think we should measure the time it takes to load a big document and construct the object tree. Actually, I have never been working on such a complex project and so profiling didn't matter to me, so I don't have no experience with that. If you have any further suggestions, please let me know... Markus

1 0

Re: [Inkscape-devel] C++ification of the SPObject tree
by Markus Engel 29 Mar '13

29 Mar '13

> As such, we should make sure that we don't break the expected behaviour of GObject objects. Well, what is the expected behavior? At the moment, the GObject type system is only needed for those casting macros that can easily be replaced by dynamic_casts and for object instantiation. Reference couting can be replaced by using shared_ptrs. Ive got some code here where I already replaced the factory and the macros and it works, but theres quite a lot left to do. As soon as the factory is replaced, the SP classes can simply be combined with the corresponding C classes, removing GObject from the derivations. This is not possible now because g_object_new doesnt fill in the vtable but its own type information. Markus Von: Alex Valavanis [mailto:valavanisalex@...400...] Gesendet: Donnerstag, 28. März 2013 18:15 An: Martin Owens Cc: Inkscape Devel List; Markus Engel Betreff: Re: [Inkscape-devel] C++ification of the SPObject tree My main concern about this kind of approach is that we're hovering between two different object systems. SPObject itself is actually derived from the GObject class structure. However, this patch switches to C++-style inheritance. As such, we should make sure that we don't break the expected behaviour of GObject objects. Really, I guess it would be good to derive SPObject from Glib::ObjectBase (I.e. use the c++ bindings from upstream) so that we can lose the need for GObject-style inheritance. AV On 28 Mar 2013 16:52, "Martin Owens" <doctormo@...400... <mailto:doctormo@...400...> > wrote: On Thu, 2013-03-28 at 16:59 +0100, Markus Engel wrote: > Okay, > so here's my branch: https://code.launchpad.net/~engelmarkus/inkscape/cppify Thanks Markus, Looking at the changes, the scope and breadth of files changed indicates that we should deal with merging this branch quickly. I'm tempted to merge it and deal with the fallout, but I'd like to hear from other devs. Martin, ---------------------------------------------------------------------------- -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

3 3

Re: [Inkscape-devel] C++ification of the SPObject tree
by Markus Engel 28 Mar '13

28 Mar '13

@Johan: > Just remove the "sp_classname_" part, but keep the rest untouched. I changed the names back to the original ones. @Martin: > Markus - Are you happy to wait with your cleaning branch for 0.49? Maybe we need some bug fixing help for 0.49 to get it out the door and speed that up? Well, It's not me to make that decision as I don't know exactly what you have planned. But I don't think there are too many changes to the SPObject tree so merging my branch afterwards shouldn't be a problem. What I did there was like tons of (ide-assisted) copy'n'paste... I'll have a look at the bugs registered and see whether I can be of any help. Markus

1 0

Win32 broken after r12251
by Nicolas Dufour 28 Mar '13

28 Mar '13

Hi, Compiling Inkscape r12251 (http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12251) on Windows XP returns the following error message. Alex, could you please take a look? ---- Make error line 301: problem compiling: src/registrytool.cpp: In member function 'bool RegistryTool::setStringValue(cons t Glib::ustring&, const Glib::ustring&, const Glib::ustring&)': src/registrytool.cpp:55:19: error: variable 'Glib::ustring keyName' has initializer but incomplete type src/registrytool.cpp:71:5: error: 'gunichar2' was not declared in this scope src/registrytool.cpp:71:16: error: 'keyw' was not declared in this scope src/registrytool.cpp:71:70: error: 'g_utf8_to_utf16' was not declared in this scope src/registrytool.cpp:72:16: error: 'valuenamew' was not declared in this scope src/registrytool.cpp:72:54: error: invalid use of incomplete type 'const struct Glib::ustring' src/registrytool.h:25:11: error: forward declaration of 'const struct Glib::ustring' src/registrytool.cpp:73:16: error: 'valuew' was not declared in this scope src/registrytool.cpp:73:50: error: invalid use of incomplete type 'const struct Glib::ustring' src/registrytool.h:25:11: error: forward declaration of 'const struct Glib::ustring' src/registrytool.cpp:86:56: error: invalid use of incomplete type 'const struct Glib::ustring' src/registrytool.h:25:11: error: forward declaration of 'const struct Glib::ustring' src/registrytool.cpp:88:77: error: invalid use of incomplete type 'const struct Glib::ustring' src/registrytool.h:25:11: error: forward declaration of 'const struct Glib::ustring' src/registrytool.cpp:98:16: error: 'g_free' was not declared in this scope ....

2 1

Re: [Inkscape-devel] C++ification of the SPObject tree
by Markus Engel 28 Mar '13

28 Mar '13

Oh I see it deleted my attachment... But when my patch is uncompressed it doesn't like it either, as it's too big... Here's a link then: http://dl.dropbox.com/u/37427492/virtual_pads.patch Markus

2 1

C++ification of the SPObject tree
by Markus Engel 28 Mar '13

28 Mar '13

Hi, I'm new here ;) . As I really like Inkscape I thought I'd help out programming. In order to gain some insight I started with a janitorial task, I put the virtual function calls in the SPObject tree into C++ classes. I found the procedure of porting the tree to C++ described in the wiki: http://wiki.inkscape.org/wiki/index.php/CPlusPlus This works quite well. In the attached patch you can find those "virtual pads". At the moment I'm turning all the other functions into real member functions and I'm playing around with a new factory that is independent of glib. Tell me what you think about it. Markus

1 0

Something special about Cairo glyph draws?
by mathog 27 Mar '13

27 Mar '13

There is something strange going on related to glyph draws through Cairo which I have not been able to figure out. Hopefully fresh eyes will spot the problem. In drawing-text.cpp this is the code that outputs the series of glyphs which put text on the screen, slightly modified to put a line over the glyphs (my changes all start at the first character on the line and end with "//"): Geom::Affine aff; // bool aff_set = false; // for (ChildrenList::iterator i = _children.begin(); i != _children.end(); ++i) { if(!aff_set){ // aff = g->_ctm; // aff_set=true; // } // DrawingGlyphs *g = dynamic_cast<DrawingGlyphs *>(&*i); if (!g) throw InvalidItemException(); Inkscape::DrawingContext::Save save(ct); if (g->_ctm.isSingular()) continue; ct.transform(g->_ctm); ct.path(*g->_font->PathVector(g->_glyph)); } // draw a rectangle over all of the glyphs, tsp_width_adj has the correct value if(aff_set){ // ct.transform(aff); // ct.rectangle( Geom::Rect(Geom::Point(0.0,0.0),Geom::Point(tsp_width_adj, 0.1)) ); // } // The strange thing is that the rectangle draw results in an XOR against the underlying glyphs. (Overlaps are not filled.) The reason this is bizarre is that when the code is modified so that the glyphs overlap each other (easy to do, just change the "g->_ctm" in ct.transform() to "aff") the glyphs do not XOR against each other. Use a string like "XO" to see this. Instead they just draw over each other, as one would expect for all of these draws. I thought the XOR might have something to do with the ct.rectangle() call, so made an alternate version where the rectangle is first converted to a (closed) PathVector "rectpath" and then this is done: ct.transform(aff); // ct.path(rectpath); // Unfortunately, this also had the XOR effect. I am puzzled. Where is the XOR effect coming from? More to the point, what is special about the glyph paths so that if they overlap there is no XOR, but a glyph and a rectangle or another path do XOR? By placing a DEBUG print statement at the top of _renderItem() one can see that this method is called twice for every string (actually <tspan>) in the document which is updated/changed. I suppose the XOR effect might have something to do with that, but it does not really make sense either, since the glyphs are drawn as many times as the overlapping line. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 2