- Inkscape Devel - Inkscape Mailman

apply and remove transform ?
by Bric 12 Apr '13

12 Apr '13

I am certain this question has been asked; i found discussions online but no viable solution. Is there a command to "solve" the transform derivation (or shift), store the derivation as constants, and remove the transform directive? This KIND OF happens with paths, when you "simplify path". But that's a big "kind of": "simplify path" actually removes nodes. I'd like to keep all my nodes but get rid of the "transform" attribute (after integrating and hard-coding its effect, in constant values). Possible? Please help! thanks!

1 0

Compile Errors
by Arshdeep Singh 12 Apr '13

12 Apr '13

Hi all, I added a new .cpp file in the ' ...\inkscape\src\ui\dialog ' directory. For reference I was using the fill-and-stroke.cpp for creating a GUI for my code. I named the tool say 'XYZ'. Upon compiling XYZ.cpp along with inkscape the following errors cropped up: Make error line 301: problem compiling: src/ui/dialog/xyz.cpp:31:1: error: 'XYZ' does not name a type. Can someone help me in understanding why this cropped up ? I am deriving a class of the name XYZ under the UI->Inkscape->Dialog namespace. Also, in fill-and-stroke.cpp: FillAndStroke::FillAndStroke() : UI::Widget::Panel ("", "/dialogs/fillstroke", SP_VERB_DIALOG_FILL_STROKE), _page_fill(Gtk::manage(new UI::Widget::NotebookPage(1, 1, true, true))), _page_stroke_paint(Gtk::manage(new UI::Widget::NotebookPage(1, 1, true, true))), _page_stroke_style(Gtk::manage(new UI::Widget::NotebookPage(1, 1, true, true))), _composite_settings(SP_VERB_DIALOG_FILL_STROKE, "fillstroke", UI::Widget::SimpleFilterModifier::BLUR), deskTrack(), targetDesktop(0), fillWdgt(0), strokeWdgt(0), desktopChangeConn() What do the highlighted text accomplish ? -- demicoder

2 2

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

12 Apr '13

Well, no, on linux, sorry. But I don't quite get the problem. There are lots of people who seem to have managed to make a recent version of gcc work on mac os. Of course you'd have to recompile all the necessary libraries from scratch when switching to a compiler with a different abi. As far as I understood that, Apple switched from gcc to clang because newer version of gcc are gplv3? Is Inkscape compilable with clang? -----Ursprüngliche Nachricht----- Von: suv@...2204... [mailto:suv@...2204...] Im Auftrag von ~suv Gesendet: Donnerstag, 11. April 2013 19:33 An: Markus Engel Cc: inkscape-devel(a)lists.sourceforge.net Betreff: Re: [Inkscape-devel] C++ification of the SPObject tree On 2013-04-11 19:25 +0100, Markus Engel wrote: > Yes, I just used this "polymorphic function pointer" > std::function<SPObject* ()> for the factory, this can be replaced by a normal function pointer. > Then there's one nested exception and some nullptrs. > Btw: > http://stackoverflow.com/questions/14153725/installing-gcc-4-7-1-on-os > -x I'm using gcc 4.7 for compiling Inkscape and it just works fine. On OS X? (Note: one main issue is with g++ and different versions of libstdc++, and incompatibilties with shared libraries/frameworks compiled with the system compiler. Ask the darktable team about details - myself I'm not an expert on this area) > -----Ursprüngliche Nachricht----- > Von: Alex Valavanis [mailto:valavanisalex@...400...] > Gesendet: Donnerstag, 11. April 2013 18:30 > An: Markus Engel > Cc: Inkscape Devel List > Betreff: Re: [Inkscape-devel] C++ification of the SPObject tree > > Sounds great! Is there any way to avoid C++11 for the moment though? > As I understand it, there isn't a suitable version of GCC available on > OS X yet. > > On 11 April 2013 16:57, Markus Engel <p637777@...1081...> wrote: >> Hi there, >> now I finally managed to get rid of the GObject type system and >> merged all the virtual pads with their classes. It should work quite >> well, although I still have to figure out what to do with those >> "rdf:RDF" and > "inkscape:grid" >> nodes. If you want to try it, please add a CXXFLAGS="-std=c++11" to >> your configure line ;). >> Who of you is currently working on the guides-improvement? Is there >> any special reason why you use "g_object_class_install_property" >> instead of "normal" properties? >> >> Markus >> >> >> --------------------------------------------------------------------- >> - >> -------- Precog is a next-generation analytics platform capable of >> advanced analytics on semi-structured data. The platform includes >> APIs for building apps and a phenomenal toolset for data science. >> Developers can use our toolset for easy data analysis & visualization. >> Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > ---------------------------------------------------------------------- > -------- Precog is a next-generation analytics platform capable of > advanced analytics on semi-structured data. The platform includes APIs > for building apps and a phenomenal toolset for data science. > Developers can use our toolset for easy data analysis & visualization. > Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

2 1

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

11 Apr '13

Hi there, now I finally managed to get rid of the GObject type system and merged all the virtual pads with their classes. It should work quite well, although I still have to figure out what to do with those "rdf:RDF" and "inkscape:grid" nodes. If you want to try it, please add a CXXFLAGS="-std=c++11" to your configure line ;). Who of you is currently working on the guides-improvement? Is there any special reason why you use "g_object_class_install_property" instead of "normal" properties? Markus

2 1

Inkscape helper apps.
by john Culleton 11 Apr '13

11 Apr '13

I am asking this question on the devel list because those who know the answer are likely to hang out here. I know the helper applications like Scribus, Gimp, TeX and Java are needed to use the full power of Inkscape: Scribus for CMYK conversion, Gimp for extended manipulation of bitmap images, TeX for the Latex extension, and Java to support Jessylink. Am I missing any helper apps here? I would include both those called by Inkscape itself and those external to Inkscape but also considered very helpful. What about Imagemagick, Ghostview etc? Since I use Slackware linux I have a pretty complete set of helpers already. But what about the Windows and Mac users? -- John Culleton Wexford Press

1 0

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

11 Apr '13

Yes, I just used this "polymorphic function pointer" std::function<SPObject* ()> for the factory, this can be replaced by a normal function pointer. Then there's one nested exception and some nullptrs. Btw: http://stackoverflow.com/questions/14153725/installing-gcc-4-7-1-on-os-x I'm using gcc 4.7 for compiling Inkscape and it just works fine. -----Ursprüngliche Nachricht----- Von: Alex Valavanis [mailto:valavanisalex@...400...] Gesendet: Donnerstag, 11. April 2013 18:30 An: Markus Engel Cc: Inkscape Devel List Betreff: Re: [Inkscape-devel] C++ification of the SPObject tree Sounds great! Is there any way to avoid C++11 for the moment though? As I understand it, there isn't a suitable version of GCC available on OS X yet. On 11 April 2013 16:57, Markus Engel <p637777@...1081...> wrote: > Hi there, > now I finally managed to get rid of the GObject type system and merged > all the virtual pads with their classes. It should work quite well, > although I still have to figure out what to do with those "rdf:RDF" and "inkscape:grid" > nodes. If you want to try it, please add a CXXFLAGS="-std=c++11" to > your configure line ;). > Who of you is currently working on the guides-improvement? Is there > any special reason why you use "g_object_class_install_property" > instead of "normal" properties? > > Markus > > > ---------------------------------------------------------------------- > -------- Precog is a next-generation analytics platform capable of > advanced analytics on semi-structured data. The platform includes APIs > for building apps and a phenomenal toolset for data science. > Developers can use our toolset for easy data analysis & visualization. > Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 1

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

11 Apr '13

Hi there, now I finally managed to get rid of the GObject type system and merged all the virtual pads with their classes. It should work quite well, although I still have to figure out what to do with those "rdf:RDF" and "inkscape:grid" nodes. If you want to try it, please add a CXXFLAGS="-std=c++11" to your configure line ;). Who of you is currently working on the guides-improvement? Is there any special reason why you use "g_object_class_install_property" instead of "normal" properties? Markus

2 1

how do I get the original object's details from get_arenaitem(desktop->dkey)
by insaner 11 Apr '13

11 Apr '13

I'm working on https://bugs.launchpad.net/inkscape/+bug/816496 and I have managed to narrow down the offending lines (1113-1114) in sp-item.cpp arenaitem = SP_ITEM(l->data)->get_arenaitem(desktop->dkey); arenaitem->setOpacity(1.0); but I dont know how to go from the arenaitem to the original item to get the correct opacity it should be set to (instead of triggering a full redraw.. not that I would know how to do that either) any help would be greatly appreciated. -- View this message in context: http://inkscape.13.n6.nabble.com/how-do-I-get-the-original-object-s-details… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 3

GSoC 2013 student participation
by Damjan Velickovski 10 Apr '13

10 Apr '13

Hello, I'm Damjan Velickovski (dummyan) and I want to apply for this year GSoC on this project. I study Computer Architectures and Networking at St. Cyril and Methodius University. This year I became interested in computer graphics and that's the main reason why I choose Inkscape, also the fact that is a well established vector drawing program. Our faculty program emphasise programming in java, so my knowledge of C++ is intermediate. But I already started learning those things that I can do in java but not in C++ and I sure learned new things as well. My key objective with this participation is to sharpen up my programming skills, learn how to work in team and of course make a contribution to the open source community. I use linux about 6 or 7 years and I think it's finally time to pay back some of my moral debt :) I have read the blueprints and their comments and I haven't really decided for what to apply. These are some of them that seem interesting for me: - <https://blueprints.launchpad.net/inkscape/+spec/non-advanced-filters-ui> <https://blueprints.launchpad.net/inkscape/+spec/non-advanced-filters-ui>A filter effects dialog for non-advanced users with higher level abstraction of effects<https://blueprints.launchpad.net/inkscape/+spec/non-advanced-filters-ui> I see that this blueprint already have an assigner, but no work is done and seems to be halted. If you are Felipe "Juca" Sanches, please reply and tell me what are your opinions about handling this to student. If there is no reply I will contact him on the email address provided on launchpad. - Named color swatches dialog <https://blueprints.launchpad.net/inkscape/+spec/named-color-swatches> - Geometric & Tech Drawing<https://blueprints.launchpad.net/inkscape/+spec/tech-drawing> It seems to me that this one have great deal of coding and polishing. Can anyone explain briefly what has to be implemented in order to achieve this? So please post your thoughts. Share some previously GSoC experiences, where students fail most, what is essential to the job, in what way should I construct the application for GSoC. PS I have read the wiki page and I contributed my first patch and after my exams week is over I will try to solve more bugs. Thanks for reading, and best regards!

2 2

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