apply and remove transform ?
by Bric
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!
10 years, 1 month
Compile Errors
by Arshdeep Singh
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
10 years, 1 month
Re: [Inkscape-devel] C++ification of the SPObject tree
by Markus Engel
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
>
10 years, 1 month
Re: [Inkscape-devel] C++ification of the SPObject tree
by Markus Engel
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
10 years, 1 month
Inkscape helper apps.
by john Culleton
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
10 years, 1 month
Re: [Inkscape-devel] C++ification of the SPObject tree
by Markus Engel
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
10 years, 1 month
Re: [Inkscape-devel] C++ification of the SPObject tree
by Markus Engel
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
10 years, 1 month
GSoC 2013 student participation
by Damjan Velickovski
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!
10 years, 1 month
Glyphs that return no vertical extent information???
by mathog
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
10 years, 1 month
