- Inkscape Devel - Inkscape Mailman

eps / pdf export
by Michael Palmer 14 Feb '11

14 Feb '11

Hi, if I understand the issue correctly, the eps and pdf export was switched in the transition from version 0.46 to 0.47. In my experience, the new eps export doesn't work well, producing larger files and also converting some vector elements to raster in an unpredictable way. The new pdf export seems to produce less rasterization but produces very large files that take a long time to render in a pdf viewer. I suppose there was a reason for this transition, maybe gradients, transparency and such. However, where these features are not required, the old export routines seem to work better. Also, the old eps export could be used with LaTeX' psfrag mechanism, whereas the new export cannot do this. So, my question is, could we have the old eps export back - as an additional option, or maybe as a user-installable extension? Thanks for consideration, best. Michael PS I attach 3 examples. ec046.pdf was produced via eps export in version 0.46 and epstopdf. The two other files were produced from the same svg in version 0.47, either directly to pdf or via eps export and epstopdf.

1 0

Updated 2geom -- what changed?
by unknown＠example.com 14 Feb '11

14 Feb '11

Hi all, I just updated our copy of lib2geom to the latest trunk version (bzr 10025). This greatly helps in improving Inkscape and lib2geom together. What changed in lib2geom since the last time we updated? Quite an important name change has happened: Geom::Matrix is now called Geom::Affine (to be found in affine.h instead of matrix.h). Some bugs were fixed (but were backported to Inkscape often too), and there are some other name changes. See the list below. I have not done extensive tests, Inkscape seems to build fine, runs ok, and what I tested (spiro LPE) works fine too. If there are any troubles, let me know. Cheers, Johan _______________________________________________________________________ Relevant changes to lib2geom since last update: Geom::Matrix --> Geom::Affine <2geom/matrix.h> --> <2geom/affine.h> Geom::Interval::extendTo --> expandTo Geom::Line::setBy2Points --> setPoints Geom::Line::origin(Geom::Point) --> setOrigin Geom::Line::versor(Geom::Point) --> setVersor Geom::Matrix::without_translation --> Geom::Affine::withoutTranslation Geom::EllipticalArc::rotation_angle --> rotationAngle Geom::EllipticalArc::large_arc_flag --> largeArc Geom::EllipticalArc::sweep_flag --> sweep _______________________________________________________________________

6 19

Re: [Inkscape-devel] bzr rant... Was: Updated 2geom -- what changed?
by Krzysztof Kosiński 13 Feb '11

13 Feb '11

Oops, replying to the list. W dniu 13 lutego 2011 17:36 użytkownik Terry Brown <terry_n_brown@...36...> napisał: > Well, sure, but the point is 12 seconds is hardly a show stopper(*). I suspect that people sometimes forget to do their bzr work in a share repository directory, so that making a branch takes much much longer. 12s is also acceptable for me. I updated the Bazaar tutorial on the wiki a bit, it now recommends first doing a checkout and working like in SVN. I also added some information on Git-style branches. > (*) that said, if I know my change is a one liner that's going to take me only a couple of minutes, I'll often work right in the trunk branch, pull, change, commit, push. In this case I would just work in a checkout. $ bzr bind :push $ bzr update ... do work ... $ bzr commit > Usually the trunk hasn't changed in 3-4 minutes. If it has, then I can rename my trunk branch, pull a fresh trunk, merge my changes and push, but usually the initial attempt to push from the trunk works. If the trunk has changed, you can use the 'bzr rebase' command from the bzr-rewrite plugin, so that your changes come at the end. Regards, Krzysztof

1 0

Problems with program
by David Moreno da Costa, Duque 12 Feb '11

12 Feb '11

Greetings Inskcape present an error when I paste, duplicate or any option in my vectorial works. The message presented is: *"Glib-ERROR **: gmem.c:136: failed to allocate 6144 bytes * *Aborting…"* Please help me, because I cannot continue with my project. Thanks for all -- * * *David Moreno da Costa D Estudiante del Programa de Postgrado Doctorado en Química Laboratorio No. 2 Dpto. de Química Orgánica Facultad de Química Pontificia Universidad Católica de Chile Teléfonos* ***(Secretaria Sra. Rosalba Meza)**: (56-2)-686-44-26* *(Móvil-Personal): (56-09)-9-470-7909 * * *

1 0

Re: [Inkscape-devel] Re : Update Cairo to 1.10.2 to fix bug]
by Uwe Schöler 12 Feb '11

12 Feb '11

Hi there, i've some hardware problems with my computer, so i can't build the windows versions of inkscape with the "old" devlibs to get rid of the GUI issue. Can someone build all (installer, 7z, debug, zip and portable) again with the old devlibs (without GUI error) for 0.48.1 to get it finally published? I hope to get a new computer at the end of next week. The 0.48.1 versions on sf.net are with the GUI error and IMHO we should weight the issues. It's more annoying for the people to "live" with the GUI error than have a problem with PDF export. Who can help here to build new files? Sincerely UweSch -------- Original Message -------- > Subject: Re: [Inkscape-devel] Re : Update Cairo to 1.10.2 to fix bug > Date: Tue, 8 Feb 2011 20:03:27 -0800 > From: Josh Andler<scislac@...400...> > To: ~suv<suv-sf@...58...> > CC: Nicolas Dufour<nicoduf@...48...>, > inkscape-devel(a)lists.sourceforge.net, > "J.B.C. Engelen"<J.B.C.Engelen@...1578...>, > uwesch@...859..., > Chris Morgan<chris.morganiser@...400...> > > On Mon, Feb 7, 2011 at 2:52 AM, ~suv<suv-sf@...58...> wrote: >> On 7/2/11 11:36, Nicolas Dufour wrote: >> >>>> De : ~suv<suv-sf@...58...> >>>> Any comments from Windows users (Johan, JazzyNico, Uwesch,...)? The >>>> issue is limited to the Windows builds afaict [1] and its impact on >>>> usability seems difficult to evaluate without actually using an affected >>>> build. >>> I'm afraid we're going to have the same kind of reaction we had with the >>> persistent markers with 0.48 on GNU/Linux. The problem with UI issues is that >>> even when they are not severe (here it's just flickering, and doesn't prevent >>> Inkscape from working), they are more visible than PDF export bugs. Frankly (if >>> it's not too late), I'd rather keep the old devlibs for 0.48.1 and start using >>> the new one (and try to find a fix or a workaround) in 0.48.2. >> As far as I know, the 0.48.1-1 packages already uploaded to sf.net >> (installer, archives, debug and portable) have been built with the >> current devlibs (cairo 1.10.2). >> >> Not sure, but it looks like we'll have to bear with the user reactions >> until the next bug-fix release is ready (0.48.2). Or replace the >> uploaded files with new packages (0.48.1-2), built with the old devlibs >> (cairo 1.8.8). The links to the new files have already been spread >> quickly via twitter et al. - replacing the files now could cause some >> confusion for users. OTOH the release wasn't yet officially announced. > I see minimal harm with what has spread via twitter that is not > official. :) If people file bug reports about it prior to official > announcement and say they found out via AwesomeSoftware2011 on > twitter, we just need to tell them to watch trusted people (myself, > joncruz, prokoudine, or any number of others) for *accurate* > information about releases. Confused users that trust third-party > sources instead of trusted/official sources are the least of my > worries and imho kinda deserve the pain they subject themselves to > (like people who get malware infected machines because they pirate via > P2P and such). > > Enough of that mini-rant. :) I think that we should see about > repackaging the win32 versions with the less "annoying" bug for now > until fixed libs are released. Uwe& Chris, do you think you'll be > able to do that? BTW, has anyone checked if it's a known issue > upstream? > > Cheers, > Josh > Ausgehende eMail ist virenfrei. Von AVG Free SB überprüft - www.avg.de Version: 9.0.872 / Virendatenbank: 271.1.1/3439 - Ausgabedatum: 02/12/11 08:34:00

1 0

C++ificiation and GTKMM
by Abhishek Sharma 10 Feb '11

10 Feb '11

Hello everyone, C++ification of inkscape has been a long term planned goal for inkscape. To the same accordance I would like to ask a few questions: 1. Does the dependency on GObject need to be removed?? The current code is huge and based on GObject as inheritance, increasing the complexity further. But if we wish to use the functionalities of GTK+ and remove GObject from the picture, wouldn't it be possible and feasible to instead use GTKMM to suffice for the same??? 2. While c++ifying what is going to be the fate of the inkscape's own implementation of garbage collection?? 3. What are your views regarding GTKMM to be introduced in the codebase for c++ification?? Expecting replies from the developers. Thank You. -- Abhishek Sharma

3 2

Easter eggs tutorial
by Nicolas Dufour 10 Feb '11

10 Feb '11

Hello, We've recently received new translations (Galician and Polish) for the Easter eggs tutorial. It was expected to be released with Inkscape 0.45 (see http://wiki.inkscape.org/wiki/index.php/ReleaseNotes045#Translations.2C_tut…) but I can't find it in versions from 0.45.1 to 0.48.1. And up to yesterday, there was no translation at all for that tutorial. Is there a reason why it exists in inkscape-docs but not in the released versions? Does anyone mind if I add it to the tutorials menu? Regards. -- Nicolas

3 2

Update Cairo to 1.10.2 to fix bug
by unknown＠example.com 09 Feb '11

09 Feb '11

Hi all, (best wishes for the new year!) Cairo 1.10.2 has been released, and a bug concerning Inkscape was fixed. https://bugs.launchpad.net/inkscape/+bug/665628 It is a pity it is just too late to include in 0.48.1 Krzystof, can you update Cairo in the Windows devlibs when 0.48.1 is done? Thanks, Johan

8 18

Re: [Inkscape-devel] [Fwd: bzr rant... Was: Updated 2geom -- what changed?]
by unknown＠example.com 07 Feb '11

07 Feb '11

> -----Original Message----- > From: martinpool@...400... [mailto:martinpool@...400...] On Behalf Of > Martin Pool > Sent: 07 February 2011 07:35 > > Thanks for the information. > > JBC, I suggest you uses bzr explorer and qbzr rather than tbzr as > they're much more active. TBZR == QBzr from a user perspective. All TBzr adds is the icon overlays in explorer and context menu's when rightclicking on files in explorer. If you choose something from those menus, it calls QBzr. So it is pretty hard to use tbzr, but not use qbzr :-) (Bzr explorer does not seem to provide any extra functionality for me, for simple everyday tasks) Cheers, Johan

1 0

Re: [Inkscape-devel] Regarding memory usage when embedding pictures
by Mahen 07 Feb '11

07 Feb '11

Thanks a lot for replying, Jon ! Well indeed I tried to embed the pictures in the SVG. Let's say they'are about 2560*1920 resolution (some less some more). So : 2560 * 1920 * 4 * 35 (number of pictures) / 1024 / 1024 = 656.25 MB and 70 MB (size on disk) * 4 / 3 = 93.3 MB Total = about 750 MB Which is indeed the memory amount taken by OO.org, but Inkscape quickly fills my 4 GB of ram (minus what is eaten by KDE of course) Well, this may be an expected behaviour actually, I just wanted to check if it had to be reported. Thanks again ! Mahen Le 07/02/2011 02:45, Jon Cruz a écrit : > On Feb 6, 2011, at 4:01 AM, Mahen wrote: > >> I tried to load my document again, and noticed Inscape was almost >> filling my 4 GB of ram. I tried to do the very same thing with >> OpenOffice draw and the memory usage was "only" of 0.7 GB. >> >> I definitely guess Inkscape is not meant for importing tons of pictures, >> but I was wondering whether there was some kind of memory leak or waste >> triggered by this particular scenario and if you think I should make >> another bugreport ? > > Yes, memory use was a major factor discussed when we were going over linked vs. embedded. If you were seeing this while linking in the images, we'll have a larger problem. On the other hand if the images were actually embedded, some such bloat was expected. This is part of why the consensus was to avoid switching to always embedding until we had such issues covered, but someone went ahead and flipped things in the code anyway. > > To get a rough idea of memory use, just multiple image width in pixels by height in pixels times four and you get the rough minimum buffer needs. Also add in on-disk image file size times four and divided by three. This gives the string size needed for the XML string embed itself. > > > So the first question is are they linked or are they embedded. Second question is if you calculate the rough memory needs for all of those 35 images do they start to hit the limits of your machine? > > >

1 1