April 2013 - 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