- Inkscape Devel - Inkscape Mailman

RE: [Inkscape-devel] 0.39 Release?
by bulia byak 19 Jun '04

19 Jun '04

>done in a short enough amount of time. I have helped a bit with the >statusbar work; I completed as much as I knew to do and need input for >what to do next. Bug 945735 still stands, and this is what matters here. > > Also I'll need time to document the major new things in tutorials. This >also > > needs time. And I want to do more redrawing cursors and icons, which is > > cosmetics but also important. > >If there are people interested in / able to help with this work, would >it be something you could farm out to them? If someone comes up with something good, sure, I'll say thank you :) Otherwise I think it will just take me as much time to explain what I want to see as to actually do it. >We do have nightly autopackages posted at http://autopackage.org. If >people could use that it would kill two birds - first since then we >don't have to set up another nightly autobuild process yet, second so we >can get some additional testing of autopackage itself. I'll take the >task of encouraging people to use this approach. That's good if it works. I didn't know about it. I think it needs more advertising. >If I recall correctly, the issues that caused the need for the .1 >release were due to insufficient change control; non-trivial code >changes were being checked in at the last minute, and one or two of >these changes introduced serious bugs. So I agree we should announce >our unofficial betas earlier and wider, but I think to prevent the >causes of the .1 release last time what we really need is a firmer code >freeze especially in the last couple days prior to release. What do you >think? Tighter freeze would be good but difficult as you know :) And anyway wider testing could make these last-minute changes unnecessary by uncovering the problems eariler. _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

0.39 Release?
by Bryce Harrington 19 Jun '04

19 Jun '04

How do people feel about timeframes for doing a release? Also, looking at our current bug list, how much bug-fixing attention is needed? Bryce

1 0

RE: [ inkscape-Bugs-973768 ] letterspacing broken
by bulia byak 19 Jun '04

19 Jun '04

>- at some point, 'apply' a text style from the dialog; in the course of >action, the >Name() function is called on the font_instance instance that's going to be >used >for the text. this function was unsetting the size field so that it doesn't >appear in >the font descr Good catch. I did not guess that Name was the culprit so tried to work around it instead. Meanwhile, I have now used pango_font_description_better_match() in font selector where it matches the style of the text with the list of fonts it has in the dialog. I assume this is what Pango also uses internally when selecting a font that matches a description, and therefore we won't have any more bugs like the one where the actual font of the selected object and the font highlighted in the list are different. However this is only a beginning: we have Pango fully working, but the way it works does not satisfy me. The font_describe function in particular is buggy: for example it returns "italic" for an "oblique" font and seems to completely disregard condensedness. In fact this kind of problems is what I expected from it, and now I want to bring back my "manual" fuzzy match mechanism and embed it into the new system because it worked quite satisfactorily before. Below is an outline; any comments are welcome. The main idea of my fuzzy matcher is its reliance on font names to fugure out font features. Yeah, this is ugly, but it's really the only sensible way. For many features, there are no bits in the font itself that we can query, or they are not present in all formats, or they are simply not set (most common). So the way we'll do font matching is basically by doing a lot of string parsing and comparisons. Here's what we'll need: - A new font_description struct (or class) that will hold the family name, the standard weight/style/stretch/variant bits, and the exact face name. The bits are filled in by parsing the face name, but the face name may contain more style descriptions (e.g. "Outline" or "Alternate" or "Swash Caps") that we need to store too. - Each font_instance will have a member font_description that is filled in when it's created. - The data in font_description is filled in from PangoFontFace which in turn is got from PangoFontFamily in FontFactory. That's the only place where we can get this information about a font installed in the sysrtem, because here we can call get_face_name on the face and parse it - we can't do that with a PangoFont, and font_describe is useless. - A function that creates a font_description from CSS style. Fills in all the bits and, possibly, sets the face name too from the -inkscape-face: extension CSS property which we will need if we really want to support arbitrary fonts beyond the limitations of CSS. (This may wait, but the infrastructure to support -inkscape-face: will be in place.) - A function that returns the best match font_instance from a FontMap and font_description. Does this by searching through all famililes and faces in the map and finding the best one, using all of the information in font_description including the one that Pango ignores. (This is more or les how the old nr_type_directory worked.) The last two functions will be used everywhere to get from a CSS style to font_instance, instead of the current Face(descr). That's how I see it at the moment. Comments welcome. _________________________________________________________________ Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com

2 1

Re: [Inkscape-devel] Installing Inkscape on a Win machine
by bulia byak 19 Jun '04

19 Jun '04

>The bug is not present in builds up to and including 0406131800. >It is present in builds 0406140200 and beyond. Yeah, that's useful, but by backtrace I actually mean a GDB backtrace as described here: http://inkscape.org/report_bugs.php However for this to work you'll need a build compiled with debug info. If you don't compile your builds I wonder if we can provide unstripped auto builds for windows? (ishmal? mrchapp?) _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

3 2

ΦΤΗΝΑ ΤΣΙΓΑΡΑ ΚΑΙ ΠΟΤΑ ΣΤΗΝ ΕΛΛΑΔΑ - TAX FREE
by kapnos 19 Jun '04

19 Jun '04

Η ΜΕΓΑΛΥΤΕΡΗ ΕΥΚΑΙΡΙΑ ΣΤΗΝ ΙΣΤΟΡΙΑ ΤΟΥ ΜΑΡΚΕΤΙΝΓΚ ΔΙΚΤΥΩΝ & ΗΛΕΚΤΡΟΝΙΚΟΥ ΕΜΠΟΡΙΟΥ. Cigarette Store On Line - TAX FREE !!!!! Αγαπητέ Φίλε, Με μεγάλη ευχαρίστηση σας ενημερώνουμε ότι άρχισε και στην Ελλάδα η παράδοση Σιγαρέτων στο ΣΠΙΤΙ ή το ΓΡΑΦΕΙΟ ΣΑΣ σε τιμές ΦΑΝΤΑΣΤΙΚΕΣ !!!!! ΠΧ Malboro 1,2 euro to paketo Yespeedy Multi Level Marketing (MLM) program has been created for you to make money and share a social network community.Just click here <http://www.yespeedy.com:8080/referralprogramwebclient/entry.do?sponsorLogin…>@

1 0

versions of tutorial-basic
by Arpad Biro 18 Jun '04

18 Jun '04

Hi, Currently we have 2 different French translations of tutorial-basic.svg. I would like to ask those who speak French to compare them and tell us which one of those seems to be better. The versions are: Yves Guillou's version: http://cvs.sf.net/viewcvs.py/inkscape/inkscape/share/tutorials/tutorial-bas… Cedric Gemy's version: http://www.le-radar.com/mm/sodipodi/xml/tutorial-basic_fr.svg As you can see, currently Yves' version is in CVS. Cedric's letter on this subject: http://sf.net/mailarchive/forum.php?thread_id=4523725&forum_id=36054 Arpad Biro __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

1 0

Re: [Inkscape-devel] Installing Inkscape on a Win machine
by bulia byak 18 Jun '04

18 Jun '04

>Has anyone else experienced this crash? It has been present for several >days >now. I am using Win2000. I don't have a crash on this file in win98. If you could create a backtrace that would be really helpful. _________________________________________________________________ MSN Premium with Virus Guard and Firewall* from McAfee� Security : 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Sigc++ and GtkMM
by Bob Jamison 18 Jun '04

18 Jun '04

While trying to compile a test class with GtkMM2.4, I noticed that configure.in tests for GtkMM2.4, but not for SigC++2.0, which is its dependency. I modified the test to allow both or neither. However, after noticing a lot of Sigc1.2-dependent code in our source, I commented the tests out altogether. Since GtkMM is still "new development", should be not go with 2.4, and avoid a later upgrade? Swallow the pill now, rather than later? Just wondering. :) Bob

2 1

Re: [Inkscape-devel] Installing Inkscape on a Win machine
by bulia byak 18 Jun '04

18 Jun '04

>I just tried opening the help/keys file using the June 15 build on win200 >and got the crash. I've also had some semi-random crashes working on my >own files. The June 4 build doesn't seem to have any of these problems. The bug is here: http://sourceforge.net/tracker/index.php?func=detail&aid=973828&group_id=93… Please attach any relevant information there. _________________________________________________________________ Add photos to your messages with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Installing Inkscape on a Win machine
by David Christian Berg 18 Jun '04

18 Jun '04

Hi guys, since I'm working with Linux, I'll never have to personally, but inkscape has become my favorite graphics tool, and I need to share files with win users. Now since svg isn't supported that much, I thought, the easiest solution might be to just have the win users install inkscape... how hard is this? I mean including installing gtk. I hope this is real simple and you can point me at some howto. Also I wonder if there'll be work done on the ps export soon. Though I really am looking forward to pangoisation being finished, I really need a proper export of transparency for ps, to make pdfs for sharing, instead of pngs, since pngs are huge, for A3 or A4 posters since I need at least 300 dpi. Any chances, I will see something like that soon? David PS: The Scribus import filter isn't good enough for my posters... so using Scribus for export is ruled out. -- Otto von Bismarck once remarked: “A fool learns from his experience. A wise person learns from the experience of others.” If so, how to define President George W. Bush, who is not even able to learn from his own experience?

7 6

behaviour
by Néstor Díaz Valencia 18 Jun '04

18 Jun '04

Hello everyone, I am having big slowdowns when editing and zooming an svg I create from zero, using inkscape 0.38. Moving the canvas is slow. Zooming in or out is really slow. Selecting nodes is very very slow, and it takes time for inkscape to reflect the changes. It has gradients with more than two stops. In a last editing also some elements or atributes has disappeared, lucky I saved a copy before further editing. It happened when I delete a colour from a 4 colours gradient. The three version I had has grown in size dramatically though i didn't add many elements more: lives.svg=13k lives2.svg=28,8k (this is the version that lost stuff) lives3.svg=48k Should you follow my case for bughunting or do you think it's been solved in the cvs version? just to let you know: Néstor ps: I can send the svgs.

3 6

RE: [Inkscape-devel] Letterspacing
by bulia byak 18 Jun '04

18 Jun '04

>Just build the newest public cvs... letterspacing is 0 by default. That >sucks, since text is unusable this way... That just got fixed. _________________________________________________________________ Add photos to your messages with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

SVG and Typography: Bells and Whistles
by Bluefuture 17 Jun '04

17 Jun '04

Take a look to this article, coul be useful for passepartout and inkscape: http://www.xml.com/pub/a/2004/06/02/svgtype.html Cheers, Blue

2 1

Letterspacing
by David Christian Berg 17 Jun '04

17 Jun '04

Just build the newest public cvs... letterspacing is 0 by default. That sucks, since text is unusable this way... Guess that's a real tiny bug. David -- Otto von Bismarck once remarked: “A fool learns from his experience. A wise person learns from the experience of others.” If so, how to define President George W. Bush, who is not even able to learn from his own experience?

1 0

ANNOUNCE: SVG::Metadata
by Bryce Harrington 17 Jun '04

17 Jun '04

I've completed writing some code for processing collections of SVG files to validate their metadata (title, author, license). The code is packaged and released to CPAN: http://search.cpan.org/~bryce/SVG-Metadata-0.01/ It includes the following: SVG::Metadata - A module for parsing and accessing an SVG's metadata, including title, author, license, and keywords. svg_validate - A script for scanning through a collection of SVG files and extracting ones with valid metadata. It also automatically generates png's for each (using inkscape) and metadata text files. Bryce

1 4

Re: [Inkscape-devel] Double meaning for Ctrl+U
by bulia byak 16 Jun '04

16 Jun '04

>I dont quite understand how you would need to manually switch to Unicode >instead of the change happening automatically if the input is Unicode (or >even Inkscape being Unicode by default). You dont mean switching to a >differnt Input Method (Cyrillic/Asian Languages/etc) do you? No. If you can type your non-ascii chars direct from keyboard, that's fine, it will work. But if you cannnot, use the Unicode mode to type the codes of the characters you need. Usually it's used for special typographic chars such as em-dash. >It might be a problem if you later want to allow Underlined text which >normally uses Ctrl+U in text mode. Yes. When we get there we'll think of something :) >Back to the general Inkscape interface, I should also mention that many >users are familiar with Mozilla using Ctrl+U for View Source, so it might >be an improvement to bind Ctrl+U to the XML editor, so it might still be >worth changing ungroup to ctrl+shift+g Again, no need to change. Ctrl+Shift+G works for ungrouping already. _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Inkscape-devel] Double meaning for Ctrl+U
by bulia byak 16 Jun '04

16 Jun '04

>if you want an alternative then using >Ctrl+G Group >Ctrl+Shift+G Ungroup >would be more consistant with the Gnome HIG. > >still many new users might think that Ctrl+U was for Ungroup We have both Ctrl+U and Ctrl+Shift+G. And I don't see why a different meaning of Ctrl+U in text editing mode is a problem. Lots of other keys also have different meanings in this mode, such as arrow keys. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN Premium http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

bug and request tracking, give me more POWER! mwuhahaha
by Alan Horkan 16 Jun '04

16 Jun '04

bug and request tracking, give me more POWER! mwuhahaha! which is my way of asking if my sourceforge.net account (username:horkana) could be added as an official member of the project so that I can mark bug reports, feature requests as duplicates. http://sourceforge.net/project/memberlist.php?group_id=93438 Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/

2 1

SVG cards
by David Bellot 16 Jun '04

16 Jun '04

Hi, I made a complete set of playing cards in SVG (partly with Inkscape). It is released under LGPL and features all numbered cards, characters, jokers and a set of 14 backs of cards. URL: http://david.bellot.free.fr Cheers, David

3 2

RE: [Inkscape-devel] bug and request tracking, give me more POWER! mwuhahaha
by bulia byak 16 Jun '04

16 Jun '04

>which is my way of asking if my sourceforge.net account (username:horkana) >could be added as an official member of the project so that I can mark bug >reports, feature requests as duplicates. >http://sourceforge.net/project/memberlist.php?group_id=93438 done _________________________________________________________________ MSN Premium includes powerful parental controls and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Project Status May 31, 2004
by Bryce Harrington 16 Jun '04

16 Jun '04

Project Status Tuesday, June 15, 2004 The past two weeks have seen a great deal of progress on a number of important efforts, the most notable one, of course, is the Pango conversion. Several people have been hard at work researching, implementing, and testing this out, but the major thanks go to Fred for his patch that gets us much further along than we had expected for this release. Additionally, pattern fills were introduced, orphan collection was created to garbage collect leftover gradients/markers, and there was additional experimentation and changes to how inserted images are handled to make them more useful and usable. Mental has been working on C++-ifying a lot of code, most notably the sp_object_* to SPObject::*. Ted has introduced a number of improvement to the file dialog and file handling, adding better support for other file formats like EPS. Ishmal has introduced his EMCAScript code into the main codebase and is working on hooking it up for use with SVG files. Peter is working on fixing the units to be more sensible (px, pixel, etc. are proving to be rather confusing). More details on these changes are in the ReleaseNotes in Wiki and will all be included in the 0.39 release. There have also been a number of noteworthy non-coding events for Inkscape the past two weeks. An article by Bryce about Inkscape was published on OSNews earlier this month. It was picked up by Slashdot and other sites, and brought in a good bit of traffic. Several people are helping to move the nightly snapshots to less bandwidth-sensitive machines. The Open Clip Art Library has been picking up a lot of new contributions from artists, and is currently focusing on better capturing the metadata in the SVG files. Cedric has expressed an intent to develop an Inkscape Manual, based on the manual he had written for Sodipodi. This will nicely augment our tutorials, providing a more advanced reference for knowledgeable users. Rejon will be giving a presentation on Inkscape and OCAL at the SVGOpen. Whew! And there's probably a lot more that I forgot! As you can see, it's been a very actively busy couple of weeks and tons of stuff has been achieved. Now that the Pangoification work is looking like it will be done soon, it is time to think towards making a freeze and working towards packaging the 0.39 release. We probably need another week or two for further code settling and bug fixing, and probably a week-long freeze prior to the release. So that suggests a late-June/early-July timeframe for the release, but we'll see how things come together. Statistics Nov 15 Jan 15 Mar 15 Apr 15 May 15 May 31 Jun 15 ========== ====== ====== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1928 * 1164 1028 1035 928 (68.5%) (86.1%) * (91.7%) (92.7%) (92.7%) (93.4%) Max Week's Rank on SourceForge: 62 321 90 31 36 110 41 (99.6%) (97.5%) * (99.8%) (99.8%) (99.4%) (99.8%) Total SF Page Views * 126,500 * 330,000 475,000 521,500 616,263 Total SF Downloads * 5,735 * 17,250 27,400 29,600 34,015 Total Freshmeat URL Hits 746 2,958 4,670 6,000 * * 7,333 Total Freshmeat Subscriptions 16 33 50 70 74 77 87 Lines of Code in src/: 115,901 166,914 177,286 183,694 189,116 190,764 280,263 Code lines 133,150 138,457 143,662 147,471 148,770 210,119 Comment line 12,468 15,584 16,041 16,757 16,880 40,620 Blank 21,929 24,061 24,931 25,886 26,113 34,677 Lines of Docs in doc/: 1,135 3,000 4,434 4,540 4,544 4,571 15,170 Lines of content in website: 1,173 2,885 5,087 5,414 6,008 6,228 6,372 Size of the Inkscape wiki: 3,700 11,284 14,840 15,461 18,638 16,300 17,176 Minutes since last ChangeLog mod: 360 6 0 11 1 1889 2 Bugs open/total: 9/15 74/160 43/244 47/322 57/365 68/381 63/401 Features open/total: 18/18 104/120 151/184 173/213 183/238 195/256 210/285 Patches open/total: 1/ 6 4/32 6/ 45 5/ 72 4/ 83 5/ 85 5/ 88 CVS Commits (as per inkscape-cvs): 481 * 3070 3710 3391 5241 5549 Inkscape-devel membership: 49 64 75 77 78 82 84 Inkscape-announce membership: 9 22 35 41 43 47 53 Inkscape-user membership: 71 69 76 * - Statistics unavailable

1 0

Thoughts on units
by Peter Moulder 16 Jun '04

16 Jun '04

I'm going home now; here are some initial notes on choice of units and difficulties converting between inches and px. pjrm. Let us assume that in the produced SVG, there are no units other than px, except for the attributes of the <svg> element (width, height). This is inkscape's usual behaviour. Before an SVG agent looks at an SVG document, it calculates a px/in value from its environment, e.g. by consulting the X server or a printer profile for a dpi value, and choosing an appropriate px/in value that would have an integer number of device dots per px. The px/in value should vary according to expected viewing distance: around 120px/in for printers and around 90px/in for monitors. Because there should be an integral number of device dots per px, the px/in value may vary more than this for low-resolution devices, like 72px/in for a 72dpi monitor or printer, or 144px/in for a 144dpi printer. When Inkscape offers to convert between px and inches, it currently assumes a fixed 90px/in. We could make this configurable for purposes of rendering and conversions, which helps if you're drawing for your own printer or screen, but doesn't help much if the document is to be rendered on many different monitors and printers: inkscape's conversions between px and inches can be out by sqrt(2) or more if the document is to be rendered both at 72px/in and at 144px/in (to use the examples of the previous paragraph). If a document's <svg> element has a viewBox attribute and width & height attributes specified in real-world units (mm/in/pt/cm/pc), then we can say that the document's primary unit is real-world units. If the viewer has accurate dpi information, then the document can control lengths in real-world units (mm, inches), but cannot accurately control lengths in px. If a document's <svg> element lacks a viewBox attribute or its width & height attributes are missing or specified in px, then we can say that the document's primary unit is px: the document can control lengths in px, but cannot accurately control lengths in real-world units like mm or inches. An interesting possibility is to use em for the document's primary unit. Depending on how the initial size of an em is determined for svg, this might be good for people needing large fonts. Varying needs: Eyesight (need for large fonts); actual device resolution; actual viewing distance; X server dpi setting. Atypical viewing distances: - Bill-boards. - Wall projectors. - Casual display for crowds, e.g. in cinema entrance hall, airport lounge, train station. For people with poor eyesight that need larger fonts, neither real-world distances (mm) nor angular measures (reference px) are suitable. In the case of a wall projector used for a typical presentation, true real-world lengths (mm on wall) are irrelevant. However, in this case the X server is typically misinformed about the device resolution: it will probably assume about 100dpi. Documents designed for viewing on a normal desktop monitor that use mm as the primary document unit will look too small. This case is similar to the poor-eyesight case (see below). In some cases, it is practical for someone to apply custom scaling. In the wall-projected presentation case, the presenter may be able to import the SVG document into a presentation document and apply scaling. If the scaling is tweaked per presentation (differing projector or computer or X server settings) then any primary document unit can work fine. Similarly for the billboard case. [Proportion of "page" (screen) may be a meaningful measure for this case, but that's complicated by non-squareness of page dimensions. The user could set the page width to be 100 of an arbitrarily-chosen unit (whether mm or px) and consider them as percentages.] Users needing larger fonts (including the wall-projected presentation case) may configure their X server to assume a high dpi for normal X font rendering purposes, but this would be defeated by the integerization aspect of CSS px. I'd guess that most viewers would use 1 dot/px even if the X server claimed 180dpi. However, having mm as the primary document unit would result in scaling as desired. A "reference px" is 1/90" at 28" viewing distance (typical screen distance), or 1/120" at 21" viewing distance (typical printed page distance) (http://www.w3.org/TR/REC-CSS2/syndata.html#length-units). More generally, the reference px is 1/2520 of the viewing distance. (2520px/viewdist = 90px/in * 28in/viewdist = 120px/in * 21in/viewdist.) The actual length of a px for a given viewing distance should be an integer number of device dots. E.g. on a 72dpi monitor, a px is 1/72". If the viewing distance is still 28" then a px is 125% of the size of a reference px: 2016px/viewdist. A monitor from 1994 may be flickery at 1024x768, so one would usually use 800x600, giving about 60dpi. If 28" viewing distance then a mere 1700px/viewdist, but one might sometimes compensate for the small dpi by having a larger viewing distance, making the dots look smaller (more px/viewdist). If the target devices have little disadvantage in "fractional number of dots" (e.g. printer >= (300dpi * 20in viewing distance), or greyscale screen >= (100dpi * 26in viewing distance)), then ideally use a unit like px but without the integerization. Given that there is no such unit in SVG: If we can assume a fairly fixed viewing distance (e.g. consider just on-screen or just printed page or just billboard), then use mm. If the target output devices have fairly high dpi (so high dots per px), then the integerization doesn't have much effect, so px is a good choice. If there isn't much "body-sized" or small text, or other fine detail (such as in icons), then scaling doesn't matter much. Monitors with low dpi often also have a small viewing area, which suggests that mm is better than px. Otherwise, use px.

1 0

Arc in SVG exported by Dia makes wrong turn in Inkscape
by Colin Marquardt 15 Jun '04

15 Jun '04

Hi, I have a bubble diagram (circles connected with arcs basically) that I export as SVG with dia 0.93. When opening this drawing in Inkscape (CVS from May 27th), almost everything is fine, except for one arc which still has the same start and end node coordinates, but opens in the wrong direction and is huge. I guess the tangents at the end nodes are also correct, just the orientation of the arc is not. Is this a known problem, or should I submit a testcase for this? Cheers, Colin

3 4

off-topic, but maybe related: ghostricpt got broken after installing inkscape-20040610
by Peter Linnell 14 Jun '04

14 Jun '04

> Message: 13 > From: Artemio <theman@...283...> > To: inkscape-devel(a)lists.sourceforge.net > Date: Sun, 13 Jun 2004 13:00:46 +0300 > Subject: [Inkscape-devel] off-topic, but maybe related: ghostricpt got broken after installing inkscape-20040610 > > Hello everybody! > > This may be off-topic, but maybe not. I didn't do anything to my system except > for installing inkscape-20040610 yesterday. > > I have been using my system (Mandrake Linux 10.0) for three months: viewing > PS/PDF files, creating PS/PDF files - all with ESP Ghostcript 7.07 (that one > with CUPS). But yesterday, suddenly, GS became broken. > > So, everytime I try to view a PS or PDF file with KGhostView, Ghostview or any > other viewer, and everytime I try to print to PS or PDF, I get an error > message box from these applications, they show a gs command line and an error > message: "Unrecoverable error: syntaxerror in token Operand stack: > --nostringval-- --nostringval-- Zmachine sRB --nostringval--" > > I don't have any GS_* variables defined except fot GS_LIB=/home/artemio.fonts > > The weird thing is that when I say "gs" in the command line, I instantly get > this: > > ESP Ghostscript 7.07 (2003-11-19) > Copyright 2003 artofcode LLC and Easy Software Products, all rights reserved. > This software comes with NO WARRANTY: see the file PUBLIC for details. > Unrecoverable error: syntaxerror in token > Operand stack: > --nostringval-- --nostringval-- Zmachine sRB --nostringval-- > > On my system, /usr/bin/gs is symlinked to /usr/bin/gs-common, and gs-common is > an ELF executable, not a shell wrapper that adds some extra options. > > > Please excuse me if this is off-topic here, but I just don't know what to > do... > > > Artemio. --nostringval-- --nostringval-- Zmachine sRB --nostringval-- <<--- GS is complaining it can't find that font 1) something you are trying to print has that font embedded in the postscript stream or 2) your GS fontmaps are messed up. 3) your fontconfig cache is stale Possible fixes: 1) as root fc-cache -fv - this refreshes the fontconfig cache 2) remove any and all freefont* rpms - Some of the ones shipped by Mandrake have some really busted fonts which have caused issues for Scribus. 3. Reinstall all the Ghostscript packages so the default fontmaps are restored. Drop into #scribus if you need more help. Cheers, Peter

1 0

Re: [Inkscape-devel] valgrind complaint with the new text stuff
by bulia byak 14 Jun '04

14 Jun '04

>Perhaps this is because pango_font_description_set_size () is not being >called on the PangoFontDescription which is created at line 340? I need not to. That descr is passed further to Face(descr) which sets size in line 280. _________________________________________________________________ MSN Premium helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

valgrind complaint with the new text stuff
by Carl Hetherington 14 Jun '04

14 Jun '04

Hi, valgrind observes some problems, examples of which are: ==27369== Invalid read of size 2 ==27369== at 0x40AA72EF: pango_font_description_equal (in /usr/lib/libpango-1.0.so.0.200.1) ==27369== by 0x818C9F8: font_factory::Face(_PangoFontDescription*, bool) (libnrtype/FontFactory.h:37) ==27369== by 0x818CCB3: font_factory::Face(char const*, NRTypePosDef) (libnrtype/FontFactory.cpp:388) ==27369== by 0x80BD1ED: sp_string_calculate_dimensions(SPString*) (sp-text.cpp:831) ==27369== Address 0x45CE4F14 is not stack'd, malloc'd or free'd ==27369== ==27369== Invalid read of size 2 ==27369== at 0x40AA72EF: pango_font_description_equal (in /usr/lib/libpango-1.0.so.0.200.1) ==27369== by 0x818D443: __gnu_cxx::hashtable<std::pair<_PangoFontDescription* const, font_instance*>, _PangoFontDescription*, font_descr$==27369== by 0x818CAF8: font_factory::Face(_PangoFontDescription*, bool) (/usr/include/c++/3.2.2/bits/stl_pair.h:84) ==27369== by 0x818CCB3: font_factory::Face(char const*, NRTypePosDef) (libnrtype/FontFactory.cpp:388) ==27369== Address 0x45CE4F14 is not stack'd, malloc'd or free'd ==27369== ==27369== Invalid read of size 2 ==27369== at 0x40AA72EF: pango_font_description_equal (in /usr/lib/libpango-1.0.so.0.200.1) ==27369== by 0x818C9F8: font_factory::Face(_PangoFontDescription*, bool) (libnrtype/FontFactory.h:37) ==27369== by 0x818CCB3: font_factory::Face(char const*, NRTypePosDef) (libnrtype/FontFactory.cpp:388) ==27369== by 0x80BDA9A: sp_string_set_shape(SPString*, SPLayoutData*, NR::Point&, int*) (sp-text.cpp:968) ==27369== Address 0x45CE4F14 is not stack'd, malloc'd or free'd In case that's any use to anybody ... Cheers Carl

1 1

de.po update for inkscape upcoming
by Colin Marquardt 14 Jun '04

14 Jun '04

Hi, in order to avoid duplicated work... this is to announce that I will submit an update to the de.po that is in CVS in a few days - I have posted it on the gnome-de mailing list for review now. I did not have the time to translate everything, but it's an update nevertheless. I haven't checked (had a very poor connection, barely enough to the get the po file), but maybe it would be worth to msgmerge the po files from Sodipodi with the ones from Inkscape from time to time? Cheers, Colin

2 1

Fred / someone please check a commit
by Carl Hetherington 14 Jun '04

14 Jun '04

Hi, I just committed the following patch: Index: src/libnrtype/TextWrapper.cpp =================================================================== RCS file: /cvsroot/inkscape/inkscape/src/libnrtype/TextWrapper.cpp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- src/libnrtype/TextWrapper.cpp 14 Jun 2004 14:44:04 -0000 1.2 +++ src/libnrtype/TextWrapper.cpp 14 Jun 2004 23:05:45 -0000 1.3 @@ -393,7 +393,7 @@ int last_w_st=-1; int last_s_st=-1; int last_p_st=0; - for (int i=0;i<=nAttr;i++) { + for (int i=0;i<nAttr;i++) { text_boundary nbs; text_boundary nbe; nbs.uni_pos=i; Could people just check that they agree with it? Thanks Carl

1 0

Re: Inkscape-devel digest, Vol 1 #444 - 14 msgs
by Peter Linnell 14 Jun '04

14 Jun '04

> 8. Installing Inkscape on a Win machine (David Christian Berg) > Message: 8 > From: David Christian Berg <david.berg@...240...> > Reply-To: david@...139... > To: inkscape-devel(a)lists.sourceforge.net > Organization: SIP Solutions > Date: Fri, 11 Jun 2004 15:37:17 +0200 > Subject: [Inkscape-devel] Installing Inkscape on a Win machine > > Hi guys, > > since I'm working with Linux, I'll never have to personally, but > inkscape has become my favorite graphics tool, and I need to share files > with win users. Now since svg isn't supported that much, I thought, the > easiest solution might be to just have the win users install inkscape... > how hard is this? I mean including installing gtk. I hope this is real > simple and you can point me at some howto. The current packaging works great IMO: a. download b. unzip > > Also I wonder if there'll be work done on the ps export soon. Though I > really am looking forward to pangoisation being finished, I really need > a proper export of transparency for ps, to make pdfs for sharing, > instead of pngs, since pngs are huge, for A3 or A4 posters since I need > at least 300 dpi. > > Any chances, I will see something like that soon? > > > David >PS: The Scribus import filter isn't good enough for my posters... so >using Scribus for export is ruled out. Have you updated to Scribus 1.1.7, which has a bunch of new gradient support ? The other variable is the version of Ghostscript installed. Using a 8.1x version has better results overall. Text handling on SVG import is the next issue to tackle, but IMO most text work can be done in Scribus more effectively - not a knock on Inkscape, it is just that SVG and PS/PDF text models are a bit different and easier to translate into reliable PDF via Scribus. I wrote a howto for installing parallel GS's, so you do not need to remove the existing patched GS which most distros supply: http://ahnews.music.salford.ac.uk/scribus/documentation/gsadv.html I hate to sound like a broken record, but exporting transparency in PS is not a trivial task. In pre-press, I would think it is safer and really much better to use PDF 1.4 for handling transparency downstream with printers etc. PDF 1.4 spec supports this capably. Moreover, even if Inkscape were to do this (export transparency) in PS, few printers or print setups on typical Linux distros can fully support advanced PS3 printing. I know - I've tested with Suse 9.x and Fedora with a Fiery PS3/PDF1.4 RIP. It took some tweaking to get this working properly. I basically rebuilt all the CUPS rpms to enable PS3, which is turned off by default. Otherwise, Inkscape would need to add a flattener to the exported PS - again not trivial. Peter

1 0

ill2svg.pl change
by Bryce Harrington 14 Jun '04

14 Jun '04

ill2svg.pl now auto-detects the file format (Unix, Mac, or DOS) and performs line ending conversion appropriately. This makes the -l cmdline option unnecessary, and thus it has been removed. Let me know if this causes any compatibility issues. Bryce

2 1

RE: [Inkscape-devel] Report on Bugs
by bulia byak 14 Jun '04

14 Jun '04

>Bug 852976 is reported a LOT, there's probably 3-4 other bug reports >that describe basically the same problem, that I left at lower priority. >We've looked at it before and it seems to be a Gtk-on-Windows issue so >there might not be much we can do about it. It would be nice if someone >could figure out if there's a work-around of some sort for Windows that >would stop the crashing, even if it required disabling a feature on >Windows (e.g. autoscrolling). Autoscrolling is irrelevant. GTK just drops events when mouse is outside a window. I've spent a lot of time on this and I honestly don't know what to do. Someone with fresh energy must attack it. The most annoying thing is that Sodi does not suffer this malaise (reportedly). _________________________________________________________________ STOP MORE SPAM with the MSN Premium and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Report on Bugs
by Bryce Harrington 14 Jun '04

14 Jun '04

I've gone through all the bug reports in the tracker on SF to update priorities. There were eight bugs that looked like critical bugs: 964635 CRASH (Win32) on insert special character in text w/ALT+Num 953771 Click on zoom spin control crashes inkscape 955020 assert when quitting with dialog and duplicated window 950610 SEGV with gradients 937347 symbol fonts not supported? 934209 Marker-related assertion failure. 852976 win32: mouse freeze when dragging outside canvas 925033 win32: non-ascii filenames still don't work For this release since it is development-focused I don't think we need to close all the critical bugs, but it'd be nice to close a few. Bug 852976 is reported a LOT, there's probably 3-4 other bug reports that describe basically the same problem, that I left at lower priority. We've looked at it before and it seems to be a Gtk-on-Windows issue so there might not be much we can do about it. It would be nice if someone could figure out if there's a work-around of some sort for Windows that would stop the crashing, even if it required disabling a feature on Windows (e.g. autoscrolling). Since the Pango patch was applied today, it would be wise for everyone to get a new development copy at this time and test the heck out of it, and report all recreatable crash bugs you can find, so we can address them prior to the upcoming release. Bryce

1 0

mucking with repr
by Kees Cook 14 Jun '04

14 Jun '04

So, I want to understand what I have to do to make the xml parser sane when it comes to reading RDF's. Currently it adds id='s and removes "xmlns"s. Where should I start looking for examples on how to search/change/update elements in the XML tree? -- Kees Cook @outflux.net

2 1

Re: [Clipart] ANNOUNCE: SVG::Metadata
by Glenn Randers-Pehrson 14 Jun '04

14 Jun '04

At 11:14 AM 6/13/2004 -0700, Bryce Harrington wrote: >On Sun, 13 Jun 2004, Glenn Randers-Pehrson wrote: >> At 10:04 PM 6/12/2004 -0700, Bryce Harrington wrote: >> >I've completed writing some code for processing collections of SVG files >> >to validate their metadata (title, author, license). The code is >> >packaged and released to CPAN: >> > >> > http://search.cpan.org/~bryce/SVG-Metadata-0.01/ >> > >> >It includes the following: >> > >> >SVG::Metadata - A module for parsing and accessing an SVG's metadata, >> > including title, author, license, and keywords. >> > >> >svg_validate - A script for scanning through a collection of SVG files >> > and extracting ones with valid metadata. It also automatically >> > generates png's for each (using inkscape) and metadata text files. >> >> For the past few weeks I have been attempting to get a "License" keyword >> approved by the PNG group, so far without success. The group seems to >> feel that licensing info should go in a textual chunk with the "Copyright" >> keyword, even if there is no copyright. I'll know more on June 23 >> when the group finishes voting. >> >> We could follow that recommendation, or we could of course use an >> un-registered "License" keyword or even "OCAP License" keyword. It >> would be good to use the same keywords in PNG and SVG metadata. > >Agreed. But if they end up using the Copyright keyword, that's probably >not an issue. > >Do you know of tools for editing the metadata in a PNG file? I could >modify the script to include a metadata insertion into the generated PNG >files as part of the process. pngcrush will do it. I wanted to resolve issues with the PNG group before writing it up. For example, pngcrush -text b "Copyright" \ "copyright 2000 svg-scribblers, Inc. Placed in Public Domain June 2004" \ -text b "Author" "J. F. Scribbler, www.svg-scribblers.com" \ in.png out.png The "b" means place the resulting tEXt chunk before the IDAT chunks. Otherwise use "a" to put it after the IDAT. Glenn

3 3

RE: [Inkscape-devel] Re: [Clipart] ANNOUNCE: SVG::Metadata
by bulia byak 13 Jun '04

13 Jun '04

>Do you know of tools for editing the metadata in a PNG file? I could >modify the script to include a metadata insertion into the generated PNG >files as part of the process. We probably also need to copy the SVG metadata into our exported PNG. Now our png-write.cpp has: /* Made by Inkscape comment */ text_ptr[0].key = "Software"; text_ptr[0].text = "www.inkscape.org"; but you can add arbitrary additional fields. Although I think this should be optional because not everyone wants their PNG bloated by metadata. _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Clipart] ANNOUNCE: SVG::Metadata
by Glenn Randers-Pehrson 13 Jun '04

13 Jun '04

At 10:04 PM 6/12/2004 -0700, Bryce Harrington wrote: >I've completed writing some code for processing collections of SVG files >to validate their metadata (title, author, license). The code is >packaged and released to CPAN: > > http://search.cpan.org/~bryce/SVG-Metadata-0.01/ > >It includes the following: > >SVG::Metadata - A module for parsing and accessing an SVG's metadata, > including title, author, license, and keywords. > >svg_validate - A script for scanning through a collection of SVG files > and extracting ones with valid metadata. It also automatically > generates png's for each (using inkscape) and metadata text files. For the past few weeks I have been attempting to get a "License" keyword approved by the PNG group, so far without success. The group seems to feel that licensing info should go in a textual chunk with the "Copyright" keyword, even if there is no copyright. I'll know more on June 23 when the group finishes voting. We could follow that recommendation, or we could of course use an un-registered "License" keyword or even "OCAP License" keyword. It would be good to use the same keywords in PNG and SVG metadata. Glenn

2 1

off-topic, but maybe related: ghostricpt got broken after installing inkscape-20040610
by Artemio 13 Jun '04

13 Jun '04

Hello everybody! This may be off-topic, but maybe not. I didn't do anything to my system except for installing inkscape-20040610 yesterday. I have been using my system (Mandrake Linux 10.0) for three months: viewing PS/PDF files, creating PS/PDF files - all with ESP Ghostcript 7.07 (that one with CUPS). But yesterday, suddenly, GS became broken. So, everytime I try to view a PS or PDF file with KGhostView, Ghostview or any other viewer, and everytime I try to print to PS or PDF, I get an error message box from these applications, they show a gs command line and an error message: "Unrecoverable error: syntaxerror in token Operand stack: --nostringval-- --nostringval-- Zmachine sRB --nostringval--" I don't have any GS_* variables defined except fot GS_LIB=/home/artemio.fonts The weird thing is that when I say "gs" in the command line, I instantly get this: ESP Ghostscript 7.07 (2003-11-19) Copyright 2003 artofcode LLC and Easy Software Products, all rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Unrecoverable error: syntaxerror in token Operand stack: --nostringval-- --nostringval-- Zmachine sRB --nostringval-- On my system, /usr/bin/gs is symlinked to /usr/bin/gs-common, and gs-common is an ELF executable, not a shell wrapper that adds some extra options. Please excuse me if this is off-topic here, but I just don't know what to do... Artemio. -- fOr ThE 1337 mEmBeRz OnLy -> http://elite.artemio.net [local time 12:56:51 (GMT +3) 13 June 2004] [system uptime 1 hr 49 min]

1 1

[Clipart] ANNOUNCE: First official release of Open Clip Art Library (fwd)
by Bryce Harrington 13 Jun '04

13 Jun '04

---------- Forwarded message ---------- Date: Sat, 12 Jun 2004 21:35:02 -0700 (PDT) From: Bryce Harrington <bryce@...260...> To: clipart@...330... Subject: [Clipart] ANNOUNCE: First official release of Open Clip Art Library The first official release package of the Open Clip Art Library is now available in the download section of the website: http://www.openclipart.org/downloads/ openclipart-0.03.tgz This is the "Father's Day, 2004" release. There aren't really any Father's Day type images, though; they're actually all UK road signs. ;-) Nineteen items passed a validation against the OCAL File Guidelines, and these are included in this release. The items that failed were missing RDF metadata sections and did not indicate title, author, and license. A listing of files scanned and a log of the testing results is included for review. A Makefile is included for installation on *nix platforms via the command `make install` as root. `make uninstall` also works. On Windows, users will need to manually install to their preferred directory. While not many items are included in this release, the focus has been to find and establish a process for accepting, checking, and packaging the files. With these in place, future releases will be quicker and easier to put out. :-) Bryce _______________________________________________ clipart mailing list clipart@...330... http://freedesktop.org/mailman/listinfo/clipart

1 0

sp_document_lookup_id deprecated
by MenTaLguY 13 Jun '04

13 Jun '04

Hmm, I seem to be more productive than usual tonight. I decided to go ahead and lay down some of the groundwork for decoupling SPObjects and ids. To begin with, I've replaced sp_document_lookup_id with two methods: * SPDocument::getObjectById() * SPDocument::getObjectByRepr() They do pretty much what you expect; I've already rewritten all the code in the codebase to getObjectById(), or getObjectByRepr() where it was simple and obvious to do so. (getObjectById() should stay at least for some things like Inkscape::URIReference) As before, I've left sp_document_lookup_id as a deprecated wrapper, but it will go away soon. -mental

1 0

SPObject update method C++ification
by MenTaLguY 13 Jun '04

13 Jun '04

I finally got fed up with confusing the sp_object_{request,invoke} methods, so I gave them more descriptive names, made them real C++ methods, cleaned up internal comments, and documented them somewhat. Quick overview of what became what: > sp_object_invoke_write -> SPObject::updateRepr > sp_object_request_update -> SPObject::requestDisplayUpdate > sp_object_invoke_update -> SPObject::updateDisplay > sp_object_request_modified -> SPObject::requestModified > sp_object_invoke_modified -> SPObject::emitModified There are now two versions of SPObject::updateRepr() -- the two-argument version lets you specify a repr; the single-argument version works on the repr attached to the object (and defaults to flags of SP_OBJECT_WRITE_EXT if you don't specify). This means that most of the time when you just want to push changes down to the SPObject's repr, you only need to call object->updateRepr() with no arguments and it'll do the right thing. Other than that, given the massive scale of the change (see the ChangeLog), I've tried to resist making any other major changes. Given that changes touch a very large portion of the tree you'll all probably find yourselves rebuilding quite a lot of files. Sorry about that. ^^; Also note that if you've written any new code using the old C methods, it should still work for now (I left wrappers in place), but you will get deprecation warnings. So rewrite that soon, I'll be pulling the wrappers in a day or two. -mental

1 0

SVG::Parser issue with top level comments
by Bryce Harrington 13 Jun '04

13 Jun '04

Hi Peter, In testing out use of SVG::Parser with SVG documents created by Inkscape I found an issue. Inkscape (as well as other SVG editors like Sodipodi) insert a comment at the top level indicating the app that made it, but SVG::Parser appears to not like top level comments. I.e., for a document like this: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">  <svg id="svg1" ...> ... </svg> I get the following from running it through SVG::Parser 0.97: Can't call method "comment" on an undefined value at /usr/lib/perl5/site_perl/5.8.0/SVG/Parser/Expat.pm line 225. When I change line 225 from this: $parent->comment($data); to this: if ($parent) { $parent->comment($data); } The problem goes away. For my purpose, dropping comments is fine; I imagine there is probably a better solution, and would love to hear it. (I'm writing a validator for checking presence and validity of RDF metadata within an SVG file, for the Open Clip Art Library project, http://www.openclipart.org.) Hope this helps! Bryce

2 1

node locking
by Kees Cook 12 Jun '04

12 Jun '04

This is in the RFE tracker, I think, but I thought of it again while reading the layer/group/selection thread. The quick summary: I hate the "dia" program. I want to use inkscape for all my diagrams, but it lacks the ability to link objects. One idea was to lock nodes together so that if one moves, so do the others linked to it. How difficult is this? - Defining a UI for locking/unlocking nodes. When in "node edit" mode, something needs to happen to change the view so a second node can be selected from another object. - I assume SVG doesn't have any concept of this, so another inkscape-named identifier would need to be added to describe locked nodes. - The preview renderer probably won't show the "true" result, since it would probably only work on the selected object? -- Kees Cook @outflux.net

2 1

RE: [Inkscape-devel] window focus confusions
by bulia byak 12 Jun '04

12 Jun '04

> 1. make it visually obvious (perhaps the selection could change colour) >which >window my dialog actions will affect, or Yes, that might be useful. I thought about that too. Please add a RFE. > 2. to lock the "active" window (maybe the last one actually edited?) to >consequent dialog actions. No, I don't think it's going to be intuitive. >Or maybe there's another, more obvious way to solve it. For example: 3. Turn off "focus follows mouse" :) 4. Use maximized document windows. I always use them, except I when need to compare two documents side by side (rarely). _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

4 3

Re: [Inkscape-devel] layers
by bulia byak 12 Jun '04

12 Jun '04

>When I'm doing comic projects in inkscape, the way I typically have it >organized is each panel is a set of: I'm not quite sure what is a "panel" but I think all this is covered by the "named selections" (or better cal them "sets") idea. Here are a few more UI tweaks for it: - When you happen to manually select exactly the objects that make up one of the sets, that set's name is displayed in the combo box - the same end result as if you selected the name from the list and thus caused it to be selected. - When one of the names is shown in that combo box, you can erase it, which results in removing this set from the list of defined sets. (Objects remain, they're just not in the set anymore.) Maybe a small button near the box can also be added for this purpose. - When you select something and then type the name of a set in the combo box (rather than select that name from the list), the current selection is added to that set, rather than replace it. - In the Object Properties dialog, add a Sets field next to Id, which would list (and allow you to edit) a comma-separated list of sets that the currently selected object belongs to. For multiple selections, list only those sets to which all selected objects belong. - In the same dialog, enable the visible/active checkboxes to be applicable to any number of selected objects. That will let you select one of the sets and hide/unhide it with a couple of clicks. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN Premium http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: pango again
by bulia byak 12 Jun '04

12 Jun '04

>what should fuzzy font matching do? (i admit i haven't >really looked into what it was doing) It has almost nothing to do with actual fonts, it only does a lot of string parsing - breaking CSS family specification into tokens, comparing them to the names of all available fonts, and selecting the best match based on various priorities and weights. I'll look at how Pango does its matching but I think we'll need to keep most of, if not all, of this fuzzy matching code (which even does some cashing to speed up matching - this turned out necessary for documents such as keys.svg). Likely we'll ask for a list of font names (families and styles) from Pango, do our fuzzy matching, and request the font with the best name we found. > > 5. Symbol fonts still don't work. When I select > > Symbol font in the list, I > > get > >argh. some error checking is needed. tho it's strange >that the symbol font doesn't have a charmap. how is >the unicode<->glyph conversion done? PfaEdit (a highly recommended font editor btw) reports that symbol.ttf (from a Windows installation) uses "Symbol" encoding, and it correctly shows all its characters. So perhaps it's just a special encoding that we need to support. >pango layout should do the trick, with one caveat: >since you can only specify one font for the layout, >for the dominant direction, all the text in the >opposite direction gets a default font from pango. if >you have idea on how to tell pango to choose one >specific font... Well, in this case one can put the opposite-direction fragments to be in <tspan>s in SVG, and set a font for them. Anyway, this is much better than not having RTL before. Unfortunately I can't compile the Windows build today - errors during linking: libinkscape.a(inkscape.o)(.text+0x1a6):inkscape.cpp: undefined reference to `sp_marshal_VOID__POINTER_UINT' libinkscape.a(document.o)(.text+0x194):document.cpp: undefined reference to `sp_marshal_VOID__DOUBLE_DOUBLE' libinkscape.a(view.o)(.text+0x136):view.cpp: undefined reference to `sp_marshal_BOOLEAN__VOID' libinkscape.a(view.o)(.text+0x1e7):view.cpp: undefined reference to `sp_marshal_VOID__DOUBLE_DOUBLE' etc. I used to get such errors before from time to time and I don't really know how to fix them. Any help is appreciated. _________________________________________________________________ Free yourself from those irritating pop-up ads with MSn Premium. Get 2months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

3 2

win build error
by bulia byak 11 Jun '04

11 Jun '04

Ted, here's the error I get when trying to crosscompile for windows: extension/implementation/script.cpp: In member function `gchar* Inkscape::Extension::Implementation::Script::solve_reldir(SPRepr*)': extension/implementation/script.cpp:90: error: `INKSCAPE_EXTENSIONDIR' undeclared (first use this function) Is this something you can fix? _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

window focus confusions
by Johan Forsberg 11 Jun '04

11 Jun '04

Hello, I've been using Inkscape fairly often lately and there's one thing in particular that has been annoying me a bit. If I keep more than one image-window open, and want to use e.g. the fill/stroke-dialog, there's always a chance that my wm changes focus to the wrong image-window while my pointer travels between the windows. This happens naturally if the windows overlap so that the wrong window is between the right window and the dialog. If this happens, whatever I do in the dialog will affect the wrong window/object. I realise that maybe I'm in the minority who swear by the "sun mouse" behaviour, but I'm not prepared to part with it on the account of one program :) So, I wonder if there could be an intuitive way to either 1. make it visually obvious (perhaps the selection could change colour) which window my dialog actions will affect, or 2. to lock the "active" window (maybe the last one actually edited?) to consequent dialog actions. Or maybe there's another, more obvious way to solve it. But I think as it works now, it's potentially confusing to new users. I can get around it by organizing my windows, but it's still easy to slip. Thanks! -- Johan Forsberg

1 0

RE: pango again
by bulia byak 11 Jun '04

11 Jun '04

Hi Fred, your patch is fantastic! Most everything works out of the box and the text looks really smooth with subpixel positioning. (No more autohinting, yay!) Even letterspacing works as before. I posted your patch to the tracker, please attach updated versions there. Here are the issues (all of the below is on Linux; I'll try to build it on Windows later today and report results in a separate message): 1. Convert to path distorts lettershapes. I attached a sample to the patch tracker. Compare the red "a" (path) with underlying black "a" (glyph). Looks like all bezier control points became closer to the nodes. 2. Some fonts are badly distorted. I attach (also in the tracker) one such font that is used in the same lettershape-distortions.svg. When converted to path, however, these distortions disappear, although the resulting path is still wrong as described in 1. above. 3. I see you disabled all the fuzzy font matching and name parsing code in nr-type-fontdirectory. Do you think it will be difficult to reenable it with your code? I have written a good deal of that file so I could now try to reenable it. Any hints you might give are welcome. 4. Kerning pairs in fonts still don't work. I thought Pango would provide that automatically - or is some additional support needed? 5. Symbol fonts still don't work. When I select Symbol font in the list, I get ** (inkscape:25358): WARNING **: Unable to load unicode charmap from font file /home/d/.fonts/SYMBOL.TTF ** (inkscape:25358): WARNING **: Unable to open font file /home/d/.fonts/SYMBOL.TTF for font Symbol 512, falling back to /usr/share/fonts/console8x8.pcf.gz ** (inkscape:25358): WARNING **: Error in FT_Set_Char_Size: 23 Haven't yet checked Hebrew or Arabic. Is right-to-left supposed to work now? If not what is needed to make it work? _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Inkscape-devel] layers
by bulia byak 11 Jun '04

11 Jun '04

> > * an object can be in zero or more layers > >Such concepts are better called groups or sets. >Can what you aim at be described as saved selections? Yes! I think it's exactly what it is - named selections. And from this viewpoint, the idea is useful, but it should NOT be coupled with visibility any more than it's coupled with z-order. It should be only concerned with saving and restoring selections (that possibly span layers or groups). And after you call it "named selection" and remove any attempts to tie it in with layer-like behavior, the idea of an object belonging to more than one named selection is perfectly legitimate. The UI might be simple: a "Name selection" command and an extra drop-down list in Find that lists all named selections in document. Or, even simpler, a single combo box on the selector top panel where you can type in the new name of your current selection, or select one of the defined names from a drop-down to reselect them. And the more I think about it, the more I like this idea. Saved selections can indeed be very useful. Mental, what do you think? _________________________________________________________________ MSN Premium helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: [Inkscape-devel] layers
by bulia byak 11 Jun '04

11 Jun '04

The idea is attractively simple, but I see some problems: > * layer visibility is an Inkscape-specific thing, separate from CSS >visibility of individual objects That's problem #1. Remember that our SVG must render the same anywhere. If I hide a layer and save, I must not see that layer in Batik either. I don't see how you can achieve this, other than by manually adding SVG invisibility to all objects that are in an invisible layer (messy). Also: - I disagree that layers should not be related to z-order. A very useful operation (in a traditional vector editor) is re-z-ordering layers, which is not possible with your scheme - except if you select all objects in a layer and group them and move them up or down... which brings us back to the original scheme. - The notion of current layer is possible (just add the name of the current layer to all newly created objects), but again this disregards z-order which may be very inconvenient. For example if I work in a layer which is on top of "background" layer but under the "shades" layer, I expect all new objects to be created in between these layers as well. In your scheme, they're still added on top of all objects, which makes the entire layer thing less than useful. - The idea of an object belonging to more than one layer is cool, but the more I think of it the less I like it. I think it's just unclean and will give users lots of headaches (such as "Why hasn't this object disappeared when I hide its layer? Why do some objects in X disappear when I delete everything in Y?" etc) without significant advantages (or at least I don't see such advantages). When I want object X to be visible both with layer Y and with layer Z, I just put it in a third layer and name it accordingly and manipulate it as needed. I think it's saner that way. Or am I missing something? _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

3 3

Re: [Inkscape-devel] layers
by Bob Jamison 10 Jun '04

10 Jun '04

Thorsten Wilms wrote: >Such concepts are better called groups or sets. >Can what you aim at be described as saved selections? > > > That might be a good model. The reason people keep saying "groups" is merely because the <g> tag is the mechanism that the SVG format gives us for things like this. Actually, z-layered groups was what I thought people were asking for when this idea was first mentioned. Just like Illustrator, Corel, even OpenOffice. Check out OO Draw, and see how they do it. A bit clumsy, but it works. It is definitely necessary at times in a drawing program to affix an image or other drawing in the background, sometimes ghosted, to provide a guide for drawing or tracing. This is something I could use myself, actually. Ok, back to my 4-day weekend. Bob

1 0

RE: [Inkscape-devel] layers
by bulia byak 10 Jun '04

10 Jun '04

>You're describing groups; this is something different. OK. But then I need our groups to be significantly expanded in functionality: I need a "current group" to which I can by default add newly created objects, and I need a dialog that would show me only these top-level groups so that I can get an idea of what I have in the document, and to set visibility/editability of such groups easily. See? You may call them "groups," but then we'll simply end up adding a lot of the standard layer functionality to these groups, because your "slices" do not support it. >I guess using the term "layers" sets up wrong expectations of behavior >for people coming from Illustrator/graphic design backgrounds (because >Illustrator calls its top-level groups "layers" and limits the >functionality of child groups), so we will need to find a better term. OK, let's call your idea "slices". Or "aspects". >What I'm describing is fundamentally different (we will still have >groups, so top-level groups will necessarily act like "Illustrator >layers") -- think of my "layers" being like search keywords, where one >can say "hide all objects not matching this set of keywords". We already have Find which is pretty close to what you describe. And we can make it behave almost exactly as you describe, by adding some sort of a combo box to Object properties that would allow you to set inkscape:keywords attribute by editing it or by selecting from a pool of other keywords in the document, and adding one more field to Find for searching by these keywords. It's not difficult, I just don't see much use in it if, as you say, we still need "traditional" groups as well. _________________________________________________________________ Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com >From MAILER-DAEMON Thu Jun 10 01:59:18 2004 Date: Thu, 10 Jun 2004 10:58:33 +0200 From: Thorsten Wilms <t_w_@...123...> To: inkscape-devel(a)lists.sourceforge.net Subject: Re: [Inkscape-devel] layers Message-ID: <20040610085833.GA5599@...124...> Reply-To: tw@...125... References: <1086842330.709.7207.camel@...4...> Mime-Version: 1.0 In-Reply-To: <1086842330.709.7207.camel@...4...> Priority: normal X-Mailer: Mutt User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 Sender: inkscape-devel-admin(a)lists.sourceforge.net Errors-To: inkscape-devel-admin(a)lists.sourceforge.net X-BeenThere: inkscape-devel(a)lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>, <mailto:inkscape-devel-request@lists.sourceforge.net?subject=unsubscribe> List-Id: <inkscape-devel.lists.sourceforge.net> List-Post: <mailto:inkscape-devel@lists.sourceforge.net> List-Help: <mailto:inkscape-devel-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>, <mailto:inkscape-devel-request@lists.sourceforge.net?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=inkscape-devel> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Content-Disposition: inline On Thu, Jun 10, 2004 at 12:38:51AM -0400, MenTaLguY wrote: > > In many tools, layers are entirely are decoupled from grouping and > z-ordering. They basically just let you take slices through "aspects" > of the document and work on them in isolation. > > For 2d apps, think of GIS databases or KiSS dolls. For 3d apps, Blender > or Unigraphics. > > I think that's the direction we should go with layers, too. It gives us > some really useful functionality we'd otherwise not have. But most the well known vector and bitmap apps all couple layers to z-order. And the whole metaphor doesn't make sense if you take that aspect away. So whatever you go for: don't call any concept that doesn't create z-order compartments layers And a z-order management facility just like illustrator/freehand layers is needed anyway. > * an object can be in zero or more layers Such concepts are better called groups or sets. Can what you aim at be described as saved selections? Going with the set name: Objects could be explicitly added to sets, or sets could be like live queries (allthough I wonder if that wouldn't be overkill). Just an idea: How about inheritance of properties from sets/groups to members? > * objects are visible in the editor iff: > > 1. their CSS visibility is "visible" > > 2. at least one layer they're in is visible, or they aren't in any > layers > > 3. their parents are visible by these criteria > > * there should be a {select,unselect}-by-layer feature > > * there should also be an {add,remove}-selected-objects-to-layer > feature Oh, saved selections wouldn't have visibility of their own, but allow to change all members state at once. --- Thorsten Wilms

1 0

layers
by MenTaLguY 10 Jun '04

10 Jun '04

Been thinking a bit about layers today, especially in light of the RFE that Jonathan put in, and Thorsten's comments earlier. I realized that I'm still wayy too stuck in the Illustrator mindset. They've got the right idea. Illustrator layers really are just glorified groups. We can do better, and different. It's helpful to look at other tools, and what layers look like in their generalized form. In many tools, layers are entirely are decoupled from grouping and z-ordering. They basically just let you take slices through "aspects" of the document and work on them in isolation. For 2d apps, think of GIS databases or KiSS dolls. For 3d apps, Blender or Unigraphics. I think that's the direction we should go with layers, too. It gives us some really useful functionality we'd otherwise not have. So, here's the deal, I think: * we keep the document tree dialog we had been planning, but we don't call it "layers" anymore, and don't try to shoehorn Illustrator-style pseudo-layers on top of it (we'll still have some easy facility for drawing/editing "inside" groups though) * inkscape:groupmode goes away (bulia has already rendered it obsolete anyway) * the "layers" dialog is just a list of layers with visibility toggles and buttons to add/remove layers * an object can be in zero or more layers * this is determined by the inkscape:layers attribute, which holds a whitespace-separated list of layer IDs (NMTOKENS) * we'll probably have <inkscape:layer> elements too, somewhere, to hang per-layer attributes (like descriptive names) on, but layers will fundamentally exist just by virtue of being referenced * in absence of this attribute, an object is considered to be in the same layer(s), if any, as its parent (this is the default for new objects) * layer visibility is an Inkscape-specific thing, separate from CSS visibility of individual objects * objects are visible in the editor iff: 1. their CSS visibility is "visible" 2. at least one layer they're in is visible, or they aren't in any layers 3. their parents are visible by these criteria * there should be a {select,unselect}-by-layer feature * there should also be an {add,remove}-selected-objects-to-layer feature I think that should cover all the bases, and shouldn't require much work to implement. Personal life allowing, I'll take a stab at getting this hammered out by next week. (no, I've not forgotten about pangoification ... my contribution to that this week will be getting the C++ification stuff documented, time permitting) -mental -----Forwarded Message----- From: SourceForge.net <noreply@...34...> To: noreply@...34... Subject: [ inkscape-Feature Requests-857357 ] LAYERS: Various ideas combined Date: Mon, 07 Jun 2004 22:17:17 -0700 Feature Requests item #857357, was opened at 2003-12-10 05:47 Message generated for change (Settings changed) made by bryce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=604309&aid=857357&group_i… Category: None Group: None Status: Open Priority: 9 Submitted By: Jonathan Phillips (kidproto) >Assigned to: MenTaLguY (mental) Summary: LAYERS: Various ideas combined Initial Comment: Something which I really missed in SVG is the ability to work with layers. Layers should allow to show and hide all objects in them and it should be possible to change some attribute in all objects of a layer (for example, the line color). Alternatively, it should be possible to select objects by layer - then this can be done manually. Note that layers are not groups: Objects from different groups can be in the same layer so they move with the other objects in the same group but whether they are visible or not depends on the setting of the layer. Layers can be used to depth-arrange objects (so when I move a layer in front of some other layer, the objects in the different groups must be reordered accordingly). When a group is in a layer, then all objects in that group are in the same layer. I'm not sure if it would be a good idea to allow one object to be in different groups (it's visible when at least one of them is visible). For the implementation: When I did this, I added a x:layer attribute to the elements plus a x:layer-style element to the SVG. Then my XSLT script would select drop all elements of invisible layers and sort the layers according to the depth attribute of the x:layer-style elements. ( NOTE: originally in sodipodi bug tracker as bug(s) # 616232 ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=604309&aid=857357&group_i…

1 0

Help needed setting up good Nightly Snapshot system
by Bryce Harrington 09 Jun '04

09 Jun '04

Hi all, As Bob mentioned, the visit from Slashdot cratered our nightly Win32 snapshot server, and we need some help coming up with a better solution. No Inkscape experience needed, just need to be familiar with SourceForge, scripting, and compiling apps. The snapshots have proven useful in letting users test out and report on recently implemented features without having to compile it themselves. So this is a pretty highly valued service for the community. What we need going forward is a script or set of scripts that: * Checks out from CVS once a day and compiles for Win/Lin/Mac both debug and optimized. (e.g. via SF compile farm?) * If compilation is successful, post the packages to mirrors (e.g. SourceForge). * Allows users a place on the web to go to to get the latest version * Creates and provides autopackage versions (the AP folks are doing this for us currently, so this may not be necessary but is worth considering if it's not hard to do.) * Doesn't place the administrative responsibility on a single specific person * Code is checked into a subdir of inkscape_project/ * Has a README and/or wiki page explaining install & usage If you'd like to work on this or a piece of it, let me know and we can work out the details. Bryce

10 20

Re: your patch
by bulia byak 09 Jun '04

09 Jun '04

>and be more concious of this sort of thing. (comes >from being self taught too, no one ever corrects you >:) ) One more comment: try to modularize more, instead of copy&paste. You may want to check out how I reworked your "copy gradients to gradients clipboard" code in selection-chemistry some time ago. >this was the plan, as i put pattern support in >get_stock when i wrote it. Again could do with a >"table of previews" type widget tho, should look into >if the GIMP or similar has something we can lift. Yes, and I think that widget will resolve the speed problem as well. Namely, it will need to generate previews on the fly when you open it, and show incrementally those that are already generated (the way images are shown as the are downloaded in a browser). This will remove the delay from fill&stroke. 2 remaining problems with patterns in fill&stroke: - it does not apply a pattern to multiple selected objects - I will need to create a function that, for any pattern, returns its visible ancestor, i.e. the first pattern up the chain of hrefs that has any children. Then we need to use this function everywhere you access a pattern, so that (1) auto-generated adjustment (childless) patterns linked to some other patterns are never shown in the menu and cannot be applied (you can only apply "root" patterns) and (2) for any selected object, you see its "root" pattern highlighted in the menu, instead of the real adjustment pattern it is assigned in SVG. This way it'll make much more sense. I will tackle the second problem later today. If you know how to easily fix the first one, that would be great. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Different idea for 'running' a file
by Bob Jamison 09 Jun '04

09 Jun '04

Hi all, I had this idea last night at the pub, and I think that it might be a cleaner and easier way to enable scripting interactivity than a "runmode". I'd like to toss this idea to the group and see what you all think. How about this: we consider "running" a file to be something like a "Preview" window. Instead of modifiying the behaviour of the Inkscape editor, we clone the repr tree, make an instance of an Inkview viewer, and display that. If we can just regard Inkscape as being "edit mode", and Inkview as "run mode", it might make for a cleaner separation, and obviate the need for things like if (runmode) { } in Inkscape source. Then, any of us working with interactivity need only hack on the player code, and can leave the editor stuff untouched. How does that sound? Anyone have an opinion? Bob

3 2

your patch
by bulia byak 09 Jun '04

09 Jun '04

I have applied and committed your patch after some cleanup. Comments: - Please get yourself an editor that can do auto indent. Now you seem to indent manually which is a pain both for you and for those who read your code :) - Always generate diffs ignoring whitespace differences (diff -b). That would make your patch much smaller and easier to read. - It's "Pattern fill", not just "Bitmap fill" - No need to set "sodipodi:fill-pattern". You seem to have copied it from "sodipodi:fill-cmyk" but that is entirely different story (and we plan to eliminate it btw). - Be more defensive in coding. You write e.g. pat = SP_PATTERN(g_object_get_data (G_OBJECT(gtk_menu_get_active (GTK_MENU(gtk_option_menu_get_menu (GTK_OPTION_MENU(patmnu))))), "pattern")); Not only is this ugly, but it's very easy to break. Instead, separate it into sequential assignments and do proper checks between them ("Did I get what I think I get?" "Is there an active item?" "Is this really a pattern?" etc). For example now your code will break if I add a separator to the menu (which is an item but has no pattern data). - Eventually it would be the best to treat patterns the same as markers. That is, add previews to the menu, and add a patterns.svg document that would contain some nice predefined patterns for users. That should be easy because we already have all the code in place. However this has to wait until we sort out the speed problem with marker previews first. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

WG: [Inkscape-devel] ecma -- my last spam for the day
by Taraben, Adib 09 Jun '04

09 Jun '04

Scipting is great, but this needs some kind of modeswitching in between runmode and editmode. Is it? Adib. ________________________________ Von: inkscape-devel-admin(a)lists.sourceforge.net im Auftrag von Bob Jamison Gesendet: Mo 07.06.2004 21:00 An: inkscape-devel(a)lists.sourceforge.net Betreff: [Inkscape-devel] ecma -- my last spam for the day Ok. I promise that this is my last post to the list today. I am finally caught up from last week, and now I can start adding the real code and not bother this list. I added one file: /src/ecma/script01.svg ...which is the example scripted svg file from the spec: http://www.w3.org/TR/SVG11/script.html#ScriptElement I would like to consider the current goal for scripting to be to make this file work correctly in Inkscape and/or Inkview. Does that sound reasonable? Bob ------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

3 3

question regarding use of inkscape for my own project
by Julien Keable 09 Jun '04

09 Jun '04

hello happy community, I'm new-to/mixed-up-with SVG, and I'm starting my own SVG-friendly application. I need to load SVG files, modify/generate objects and their properties via API calls and render it in a buffer. While looking at cairo and librsvg to render SVG graphics, I realized (correct me if I'm wrong) their API didn't provide calls to access individual objects or their properties. Then I figured out using some existant app would be much smarter, as open source is starting to kick some serious mellons. Then I saw inkscape and got very excited, because as a bonus, we get SVG extensions and automatic rendering technology updates and so on.. So my plan is to strip inkscape from its GUI part, or simply link the relevant CVS dirs to my own CVS, but this seems a bit harcodre to me and I'd like to hear your wisdom speak about this. (ex : which dirs/classes ? ) another thing I'd like is a table that looks like this : loads SVG renders SVG has API to modify objects ksvg cairo libart librsvg Just to make things as clear as possible, I need to : - load svg files - access/transform individual objects through API (not GUI, I don't have one) ex : rotate(MyCube, 123) - render it in some 32 bit pixel buffer (RGBA) BTW, why is everyone is moving away from libart (inkscape, sodipodi)? thanks, Julien Keable

5 8

ecma -- my last spam for the day
by Bob Jamison 09 Jun '04

09 Jun '04

Ok. I promise that this is my last post to the list today. I am finally caught up from last week, and now I can start adding the real code and not bother this list. I added one file: /src/ecma/script01.svg ...which is the example scripted svg file from the spec: http://www.w3.org/TR/SVG11/script.html#ScriptElement I would like to consider the current goal for scripting to be to make this file work correctly in Inkscape and/or Inkview. Does that sound reasonable? Bob

4 4

Pango
by Bryce Harrington 09 Jun '04

09 Jun '04

Hi all, Last weekend I read through the libnrtype code and put some comments to document what each of the routines do. Probably didn't get 100% correct though, and I wrote in a lot of questions. Could someone scan through the code for the 'Q:'s and see if they can fill in what I couldn't? Also, I reviewed the Pango API's last night and tried to sort out which groups of API calls would need to be implemented in each of the libnrtype files. I put these as steps in the Roadmap in Wiki. Again, I don't know how accurate I was so would appreciate it if someone could check it over and clarify what I missed. My goal was to drill down far into the details of each step. I feel like I came close, but not close enough, so any help specifying that more precisely would be appreciated. >From what I understand, most of libnrtype consists of functions to look up typeface names, font family names, metrics, attributes, etc. In effect, it implements a big 'dictionary' of this info, with various functions to get/set the data, initialize structs containing typeface info on the fly as needed (with reference counting), and so forth. For all this stuff, Pango has routines which do exactly the same thing. So these can be switched over pretty directly, I'd guess. It also has functions for getting outlines of fonts, which I don't totally grok yet, but it looks like there are similar routines in Pango. I can't tell if these would be as straightforward to switch over, since different kinds of structs are involved, so this may be the hard portion of the project. Beyond the above two things, the vast bulk of the rest of the code seems to be there to implement a class hierarchy. I.e., constructors, init, destructors, virtual functions, yada yada. Pretty straightforward and won't need to be fiddled with this go-around. I don't think C++-ifying it would buy us anything, since we'll probably want to majorly restructure all of this code anyway once we're fully converted over to Pango. By the way, Pango looks *very* cool - it handles a much wider degree of font styles, types, etc. than we do. Stuff like lower caps, strike-out, etc. I don't think we support these kinds of fonts at all, so we'll be gaining it all. Also, in Fred's pango_test we were able to get an arabic font to display, that didn't work for me at all in Inkscape. So potentially we may be picking up support for a much wider range of fonts, which would be quite cool. Bryce

2 2

pattern news
by bulia byak 09 Jun '04

09 Jun '04

- Now there's a Tile command (Alt+T) that creates a rect with pattern fill out of the selection. Lots of fun. - The Fill&Stroke dialog lets you select any of the patterns defined in the document for any object (done by Sim). - I changed the default back to import bitmaps as <image>s. Those who prefer it to be bitmaps however can change the setting in Preferences (Misc tab). Also you can select any <image> and Tile it for the same result. - Preferences>Transforms tab: there's now a setting to transform or not transform the pattern fill with the object. When it's off, you transform objects but their pattern stays unmoved; when on, they're transformed as a whole. Works the same in both Optimize and Preserve modes. Still todo: - The "transform pattern" switch will be moved to the selector top panel, alongside the "scale stroke" and "scale rounded corners in rects" switches. Also the same switch needs to be created for gradients. - An Untile command to convert a pattern fill to the original container object plus the object(s) that were in the pattern. - The pattern fills will get knots on the canvas that will let you arbitrarily transform patterns inside objects by dragging the knots (Sim is working on that). _________________________________________________________________ MSN Premium with Virus Guard and Firewall* from McAfee� Security : 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

change to Make for ecma
by Bob Jamison 08 Jun '04

08 Jun '04

I worked libjs.a and /ecma into the Mingw build files. It all builds/links with the new stuff. I will look into adding them to the Unix files later, when I am back from the office. I will try to get on jabber://inkscape@...132... later. Bob

1 0

RE: [Inkscape-devel] L10n questions
by bulia byak 08 Jun '04

08 Jun '04

>>#: src/verbs.cpp:962 >>"Ru_lers" >> >>#: src/verbs.cpp:962 >>"Show or hide rulers" >> >>#: src/verbs.cpp:963 >>"Show or hide scrollbars" > >Not used now, replaced by texts in interface.cpp. But it would be better to >rework sp_ui_menu_append_check_item_from_verb so that when verb is >non-null, it takes the label and tooltip from it as well (now it only takes >shortcut). And I just did this. _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

5 5

Revisiting ECMA. Seriously, folks. :)
by Bob Jamison 07 Jun '04

07 Jun '04

By the way, I am finally starting again to work on the ECMAScript/SVG binding (not Inkscape scripting). I checked in a cleaned-up directory of Mozilla's Javascript C engine. It is in /src/extension/script/js so that it can be convenient to both the SVG binding and IS scripting guys. I also started checking in a few files in /src/ecma for testing. Hopefully in a few days we can start seeing some progress. Bryce shamed me out of my lethargy with his article. ;-) Off topic: You might be interested in this mail list thread from another OS project (probably -the- OS project), gcc: http://gcc.gnu.org/ml/gcc/2004-06/msg00014.html This shows the kind of interaction among the members of a very large project. Some of the threads in that list can be fascinating. Bob

3 5

Re: [Inkscape-devel] Re: Inkscape Layers
by Bob Jamison 07 Jun '04

07 Jun '04

Yes, the intent -is- to provide layers just like in other applications. When we talk about using <g> nodes to group them, what we are talking about is merely how to store layer information in the SVG format. Thorsten Wilms wrote: >I didn't catch the whole discussion about layers, I just hope I'm not >totaly off here. >However, layers can be seen as serialized selections and are in this aspect >just like groups. But in vector graphics apps layers usualy establish >z-order 'compartments'. There is z order inside each layer, but the general >z-order of each member of a layer is higher than those of members of layers >below and lower than those of members of layers above. > >Grouping is used to lock relative position of items and for scaling them >all together. Layers are about organizing z-order, toggling visibility >and locking. Visibilty and locking can of course work the same way for >groups, it's just they are usualy not listed in vector apps. > >It would be interesting to implement/express layers as special case of >groups, but I have no idea how to go about toggable z-order compartment >behaviour. > > >--- >Thorsten Wilms > > >------------------------------------------------------- >This SF.Net email is sponsored by the new InstallShield X. >>From Windows to Linux, servers to mobile, InstallShield X is the one >installation-authoring solution that does it all. Learn more and >evaluate today! http://www.installshield.com/Dev2Dev/0504 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > >

1 0

Article followup
by Bryce Harrington 07 Jun '04

07 Jun '04

Hi all, I wanted to follow up with a few comments on the reception of the article. I was mortified when I saw that the Slashdot blurb said Inkscape was my "brainchild" and that I was _the_ founder of Inkscape rather than _a_ founder. I hope no-one took offense at that. I suppose its unusual for open source projects to be true team efforts, but that is really one of Inkscape's strengths and one of the things that makes it so fun. I also want to apologize to Bob for cratering his server! Hope that didn't cause problems beyond just the loss of the machine. Hopefully with Artemio's help, that problem will be stimulating us to gain a better solution in general for the future. Despite the problems, I think it went quite well. The main goal had been to raise awareness of Inkscape and what we got exceeded what I'd been hoping for. Also, I noticed that a number of the points I wanted to make were conveyed and received by the audience. A couple of the points sparked some interesting discussions; I think our "patch first, ask questions later" policy got people thinking. Big thank-you to mental or whomever suggested emphasizing we don't _blindly_ accept patches, but do check licenses, etc. I again want to thank everyone that helped with editing the article and rejon for giving me a deadline to get it done by; as much as I grumble about deadlines, it was useful motivation. Nathan - it turned out we missed one of the erroneous "it's", as several readers pointed out to me. :-) I'd also like to return the favor. I think with this general "What's Inkscape" piece out of the way, there is an audience for more focused articles, and if anyone is interested in writing one I would be more than happy to lend a hand. For example, I'd bet an article giving advice about usability would be well received. An article about Inkscape internals as they relate to SVG rendering would as well. I also think a usage-oriented "secrets of Inkscape" article would be appropriate. So if anyone is interested in authoring an article on any of those subjects, I would be happy to help in any capacity. Bryce

4 4

orphan collection
by MenTaLguY 07 Jun '04

07 Jun '04

Just a quick heads-up: I've comitted my orphan collection code to CVS. Among other things, this means that leftover gradients/markers/patterns will get automatically cleaned up when the objects that use them are deleted. Caveats: * this only applies to such objects created with a build of Inkscape which post-dates this commit * not all automatically-created objects will necessarily be collected; the code that creates them needs to be updated to set the correct collection policy * paint objects won't get collected until another editing operation takes place, since NRArenaShape currently holds onto an SPStyle for too long Technical details: Assuming its collection policy permits it, an object will be collected if neither it nor its descendants have any outstanding inter-document URI references (nonzero SPObject::hrefcount). There are two "policies" for collecting orphans: * "with-parent" - the object will only be collected if one of its ancestors is collected * "always" - the object is always collected if unused (a third policy might be "never", which would necessarily also prevent that object's ancestors from ever being collected; I do not plan on implementing it) The policy in effect is determined by the inkscape:collect attribute. Be careful with the "always" policy; it really only makes sense for "private" objects that are indirectly created behind the scenes (e.g. by selecting a fill or marker option in the GUI). -mental

1 0

Proposal for scoping the Pango work for 0.39
by Bryce Harrington 07 Jun '04

07 Jun '04

We've been discussing what needs to be done for the Pangoification work that we identified as required for 0.39, and what scope of work we should pursue for this release. One of the key factors driving the consideration is that we've got a lot of (cool but non-Pango) things implemented in the codebase right now that we'd like to get released to users soon. Unfortunately, the quantity of work to do the full conversion over to Pango 100% is daunting, especially considering the wide number of platform bugs we're certain will crop up. Thus, we are floating this idea for how to scope the Pango work for this release: 0. Document all of the routines in libnrtype 1. Create a copy of libnrtype in the codebase called libnrtype_pango 2. Go through all of the nr-*.cpp routines in libnrtype_pango and rewrite them to use Pango calls. This is the bulk of the work, but I figure this could be done by a couple developers in a week or so. 3. Cleanup and remove whatever files and code become obsolete from libnrtype_pango in the process. 4. Create a compile-time option --with-libnrtype-pango that controls whether inkscape is built with the existing type renderer, or our new Pango-based one. 5. Get Inkscape able to compile and run with the new libnrtype_pango code; if it misses a lot of existing features or has a lot of new quirks, that's perfectly fine - we'll fix them later. 6. Finish up all the non-Pango development work and finalize the release. 7. Generate two sets of packages for Windows, Linux, and Mac: One compiled with libnrtype_pango for testing, the other compiled with the existing type renderer for regular usage. We then will adjust the Roadmap by moving the 0.40 milestone and all subsequent ones forward one release and introducing a new 0.40 milestone that focuses on the second phase of the Pango conversion. The advantage of this change to the Roadmap is that it buys us additional development and testing time for Pango but still gets the current work out and available for users to start taking advantage of and testing out. Another advantage is that it will enable us (including users) to test out the feasibility of switching to Pango without having to take the full plunge all at once. Previously, we had not scoped out precisely what would be done for this release for Pango, so had assumed we'd try to get 100% finished with it; this may be doable but appears to be unrealistic to achieve within an acceptable amount of time. Please let us know if this plan sounds suitable, or if not, what adjustments to it that you would suggest. Thanks, Bryce

3 3

Fill and Stroke Dialog
by Michael Wheeler 07 Jun '04

07 Jun '04

Hi Everyone, I was playing around with the June 4th Win32 build and I noticed that the Fill and Stroke dialog is slow to come up. I haven't been using all of the daily builds, so I don't know where the problem started, but the dialog is snappy for me in 0.38. Also, changing the colors in the dialog is less smooth. The other dialogs seem just fine. By the way, the working eyedropper is great. I like that it keeps things real simple. How would people feel if it used a crosshair rather than the white arrow. Maybe this is silly, but I am always feel a little unsure what specific point I am aiming at with the arrow. Thanks, Michael Wheeler http://www.planet-zero.net

6 14

Re: [Inkscape-devel] Re: Inkscape Layers
by MenTaLguY 07 Jun '04

07 Jun '04

On Sun, 2004-06-06 at 05:44, Thorsten Wilms wrote: > However, layers can be seen as serialized selections and are in this aspect > just like groups. But in vector graphics apps layers usualy establish > z-order 'compartments'. There is z order inside each layer, but the general > z-order of each member of a layer is higher than those of members of layers > below and lower than those of members of layers above. In SVG, groups establish "compartments" as well. Because our model is based on SVG, to us layers and groups are essentially the same thing. -mental

1 0

RE: [Inkscape-devel] L10n questions
by bulia byak 06 Jun '04

06 Jun '04

>#: src/dialogs/find.cpp:541 >"Search paths, lines, polylines" > >What are "polylines"? http://www.w3.org/TR/SVG11/shapes.html#PolylineElement >#: src/sp-typeset.cpp:387 >"typeset object" > >Where does this string appear? Is "typeset" a verb here? It's a text that flows inside a shape. It's not enabled yet, no visible UI. >#: src/splivarot.cpp:536 >"Select some paths to outline." > >#: src/splivarot.cpp:733 >"No stroked paths to outline in the selection." Actually it means "convert stroke to path". Perhaps these strings should be changed. >#: src/verbs.cpp:962 >"Ru_lers" > >#: src/verbs.cpp:962 >"Show or hide rulers" > >#: src/verbs.cpp:963 >"Show or hide scrollbars" Not used now, replaced by texts in interface.cpp. But it would be better to rework sp_ui_menu_append_check_item_from_verb so that when verb is non-null, it takes the label and tooltip from it as well (now it only takes shortcut). > >#: src/verbs.cpp:982 >"_New View Preview" > >#: src/verbs.cpp:983 >"New View Preview" I think it's not used now. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN Premium http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

RE: [Inkscape-devel] Re: Article followup
by bulia byak 06 Jun '04

06 Jun '04

>As far as I know, the toolbar improvements are done in 2.4, the thing they >want to merge for 2.6 is the toolbar editing system currently in libegg. >Epiphany uses it and it's extremely sweet. Thanks for the pointer. I think we'll want editable toolbars eventually, but at least for 0.39 we can do without. It's more work at the moment to edit most icons so they look decent on the toolbar. If anyone feels like plugging in libegg, if course, they're welcome. _________________________________________________________________ Add photos to your messages with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

L10n questions
by Arpad Biro 06 Jun '04

06 Jun '04

Hi, I have a few questions as to what certain UI strings mean: #: src/dialogs/find.cpp:541 "Search paths, lines, polylines" What are "polylines"? -------------------------------- #: src/sp-typeset.cpp:387 "typeset object" Where does this string appear? Is "typeset" a verb here? -------------------------------- #: src/splivarot.cpp:536 "Select some paths to outline." #: src/splivarot.cpp:733 "No stroked paths to outline in the selection." What does "to outline" mean here? -------------------------------- #: src/verbs.cpp:962 "Ru_lers" #: src/verbs.cpp:962 "Show or hide rulers" #: src/verbs.cpp:963 "Show or hide scrollbars" #: src/verbs.cpp:982 "_New View Preview" #: src/verbs.cpp:983 "New View Preview" Where are these 5 strings used? Arpad Biro __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

Re: [Inkscape-devel] Fill and Stroke Dialog
by bulia byak 06 Jun '04

06 Jun '04

>I'd suggest to just go and use the system eye-dropper cursor! We have many different cursors, and need even more. Most of them are not available from the system. So I would prefer all our cursors to be consistent across application, instead of some of them being system (which may be a wildly different style) and some custom. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Re: [Inkscape-devel] Re: Inkscape Layers
by bulia byak 06 Jun '04

06 Jun '04

>Grouping is used to lock relative position of items and for scaling them >all together. We're not speaking about using user-visible groups as layers. We just want to use the <g> element with a certain extension attribute to work as a layer. This approach deals with the z-order and other layer issues quite straightforwardly, and will be consistent with the UI of most other vector apps (maybe even richer, because we can have hierarchical layers). _________________________________________________________________ Add photos to your messages with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Inkscape-devel] Article followup
by bulia byak 06 Jun '04

06 Jun '04

>* Resizing objects resizes their line width. For the online comic, I'm >aiming to use a constant style, which includes a fixed line-width for >all of the shapes. Adjusting line-widths on every resize is very >frustrating - if this were modal (modified with a keypress, or via a >setting), it would be a great improvement. Done in CVS, although needs a bit more work >* Copy/paste between Inkscape instances seems broken. I had planned to >use one Inkscape document like a clipboard of comic bits (similar to >Visio's stencils), but I couldn't get cut/paste to work. Yes, we don't use system clipboard, although we really should. Needs work. By the way, does anyone know of any library functions that would make this possible? I've searched through glib and gtk but found nothing. >* There is no 'application' toobar. I have a habit of clicking on save >from time to time (even though I also use ctrl-s). I haven't found a >standard toolbar. Planned. Actually it's an easy thing to do, but I heard about improvements in toolbar handling in gtk 2.6 and wanted to wait until we support it. But now that full customizability of window interface is in place (in CVS), I think I'll go on and assemble a "commands" toolbar for 0.39. >* Snap-to is a bit too snappy. Some applications have a snap-to that >allows both fine-positioning /and/ snap-to at the same time. One such >application uses a modifier key while dragging objects (shift iirc), and >another is just nice about its snappyness. We now have in CVS a temporary no-snap mode when dragging with Alt. Needs to be made to use Shift and improved (should affect nodes in node tool as well). Carl, are you working on that? >* The text properties are not applied in real-time. Nearly every time I >modify the text properties of a chunk of text, I forget to click apply. >Other similar applications apply these changes in real-time. I'm sure >there's a performance (or other) reason why this isn't the case, but it >results in many "D'Oh!"s. That's going to be fixed when we have a top panel for text tool with most of the controls, all of which will be instant-apply. The dialog will be rarely needed then. >* A user-defined palette. The colour wheels and sliders are great for >picking colours, but I'm usually working with a very particular set of >colours (and I'll work with those colours for many weeks). I've worked >around this by drawing my own palette on the diagram, which I use >instead. Right now in CVS it's slightly improved in that you can use the dropper tool always, and apply its picked color to either fill or stroke (with shift). So you can have a "palette" in your document and easily pick all your colors from it without ever opening fill&stroke dialog. But of course we need a real palette. The good news is that I now have a complete plan of how to achieve that, and working on that (the dropper is the first step). >* Persisted document properties. For every document I create, I find I >have to make the same set of tweaks to the document settings. It would >be really handy if this were persisted by Inkscape, and applied to each >document created. I.e. you want document templates for File->New. Also in our plans. It's a relatively easy project so if anyone feels like doing it, that would be great. >* A stencil-mechanism. I'd like to be able to save bits of drawings >that I could reuse later (cartoon bubbles/balloons, strip outlines, >etc.) I.e. defining symbols. It's not difficult from the SVG perspective, but the difficult part is that we need a new table-like widget for previewing and choosing the symbols. The same widget would be good to use for markers, instead of the bulky menus. Any ideas welcome. (For example, what does Nautilus use when it displays files as icons? Is this a standard widget?) >* A way to import bitmaps easily. One useful tool for an illustrator is >to be able to trace over a sketch loaded in the background (or in a >box). I've never really liked auto-trace tools, so just the ability to >load a bitmap into a box would be incredibly useful. There are some improvements in this area in CVS (imported bitmaps are now rects that can be node-edited, etc.). I'm now working on that. Summary: it's a bit early to boast about our usability I think. We made (barely) usable the stuff we have, but there are still too many functionality and usability gaps that are complained about again and again. We need more enthusiastic coders! :) _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/

4 4

[Fwd: [Sodipodi-list] Python extensions for Sodipodi]
by Jon Phillips 06 Jun '04

06 Jun '04

from sodi list: -----Forwarded Message----- > From: John Stracke <francis+keyword+sodipodi.6389c0@...99...> > To: Sodipodi <sodipodi-list(a)lists.sourceforge.net> > Subject: [Sodipodi-list] Python extensions for Sodipodi > Date: Sat, 05 Jun 2004 21:28:12 -0400 > > I've been wanting a scripting language for Sodipodi for some time (like > the Scheme scripting for the GIMP), so I started work on some extensions > to support Python scripting. I've attached the patch (against the > current CVS tip), which basically does a proof-of-concept: it adds a > "Py" menu to the main menubar, with some commands written in Python. > Obviously, if we decide to go down this path, we'll need some better > integration--at the moment, those commands are all hard-coded in > src/sodipodi.py; we need some way to have the user write their own > Python without having to reinstall Sodipodi. > > At the moment, not all of the subclasses of SPItem are exposed; only > SPText is. One of the example commands makes use of SPText to do word > wrapping (although, at the moment, the width to wrap to is hard-coded). > > To apply the patch, first update to the CVS tip. Then extract the > tarfile in the top-level sodipodi directory; this will give you a bunch > of new source files, plus python.patch, which you can apply with: > > patch -p1 <python.patch > > Now you need to rerun autogen.sh (because there are some changes to > configure.in): > > ./autogen.sh --with-python > > (Unless you specify --with-python, to autogen.sh or configure, it will > default to not including the Python extensions, for safety's sake.) Now > just make and run. > > You will need to cd to src in order to run, unless you install; it > expects to find sodipodi.py either in the current directory or in the > place where it gets installed. If you've got a version configured > --with-python, and you want to run without Python, you can pass > --without-python on the sodipodi command line. > > So. What do you guys think? Shall we work on this? > > /=================================================================\ > |John Stracke | http://www.thibault.org |HTML OK | > |Francois Thibault |============================================| > |East Kingdom |If we don't believe in freedom of expression| > |francis@...99...|for people we despise, we don't believe in | > | |it at all. -- Noam Chomsky | > \=================================================================/ > My medieval art for sale: http://www.thibault.org/store/ -- Jon Phillips Graduate Researcher Visual Arts Department PO BOX 948667 LA JOLLA, CA 92037 USA cell.858.361.2811 jon@...235... http://www.rejon.org

1 0

Re: bitmap fill patch
by bulia byak 06 Jun '04

06 Jun '04

Finally had time to look at it... but it seems incomplete: ends in the middle of paint-selector, and the patched source does not compile (sp_paint_selector_system_color_set undeclared etc.) Please rediff. (I promise to review it quickly this time :) Also, the patch has many regressions in that variable declarations are moved from first-use up to the top of the function. Why did you do that, or is it because you diffed against a newer version? Please do not include such changes in the diff. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN Premium http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

RE: [Inkscape-devel] Fill and Stroke Dialog
by bulia byak 06 Jun '04

06 Jun '04

>I was playing around with the June 4th Win32 build and I noticed that the >Fill and Stroke dialog is slow to come up. I haven't been using all of the >daily builds, so I don't know where the problem started, but the dialog is >snappy for me in 0.38. Also, changing the colors in the dialog is less >smooth. The other dialogs seem just fine. It's because the marker menus need time to generate the marker previews. >By the way, the working eyedropper is great. I like that it keeps things >real simple. How would people feel if it used a crosshair rather than the >white arrow. Sure, we need a new complete set of mouse cursors for all tools. The current set is ugly and incomplete. Jon was planning to do this; any other volunteers are welcome too, of course. _________________________________________________________________ MSN Premium with Virus Guard and Firewall* from McAfee� Security : 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Pango Discussion
by Bryce Harrington 06 Jun '04

06 Jun '04

Pangoification Discussion ------------------------- This is a summary of a discussion between mental, bulia and fred on Jabber regarding adoption of Pango and the issues involved. The principle issue we are facing at this time is that while many of the Pango issues we've identified seem to have doable work-arounds, it's become a little unclear what our eventual goal design-wise is with it in the long term. Specifically, Pango likes to grid-fit its layouts, which makes it a bit inflexible for things like getting undistorted outlines and layouts. Vertical Text ============= Pango does well with horizontal text but Fred had a question about how multi-byte characters are handled. E.g., an A with an umlaut requires two bytes. Would this render as a single character entity or as two? Certainly we wouldn't want the system to resort to putting the A and umlaut on separate lines. Mental explained that Pango provides routines for determining how many "codepoints" makes up a particular character. When you pass this routine a UTF-8 string pointer, it will return the pointer advanced by the next full character. A codepoint can consist of one or more bytes. one or more codepoints define a 'glyph'. One or more glyphs define a character. A glyph like an umlauts is an example of a "composing character". Fonts combine these composing characters with other base characters to form the various characters particular to a given language. It looks like pango_layout_move_cursor_visually() would be used to determine the positioning of vertical text. This won't be simple if we don't use the Pango glyph positioning. For more info see: http://developer.gnome.org/doc/API/2.0/pango/pango-Layout-Objects.html#pang… For our own work this suggests we may need to create PangoLayouts to do our own specialized layout. Kerning Abilities ================= Control over font kerning is important for Inkscape yet it is uncertain if Pango provides this control. For letter spacing we need to be able to: * Measure strings * Count characters * Handle pairwise kerning * Glyph width (for things like text-on-path) Currently, sp-chars creates a NRArenaGlyphGroup for each string, tied to one NRRasterFont, but for things like text-on-path we'll want to have unique transforms for each character. We do not want to have to create a separate GlyphGroup for each glyph though, so need a better solution to this. The question came up about whether we can eliminate NRRasterFont. This appears to be a necessary step in the pipline, because it is where the transform is taken into account and where glyph caching occurs. There is a question about whether glyph caching is really necessary, or if we could do direct rendering and use performance analysis to determine where such optimizations are really necessary, but since text always has such massive redundancy, caching is likely to prove quite necessary. Win32 Testing ============= We've very concerned that bugs in font handling are going to reproduce quickly on different platforms unless they're closely tracked by developers on those platforms. Is adopting Pango worth enduring those platform issues?

1 0

new illustrator screenshots
by Jon Phillips 05 Jun '04

05 Jun '04

Hello all, I finally got some these illustrator screenshots off my parents laptop I took in December. I posted to the wiki and they are available here: http://cabbage.ucsd.edu/~phillipsjd/media/adobeIllustrator10-win32/ I hope these help in comparing our user interface and in planning out new additions. Jon -- Jon Phillips Graduate Researcher Visual Arts Department PO BOX 948667 LA JOLLA, CA 92037 USA cell.858.361.2811 jon@...235... http://www.rejon.org

3 4

Re: Inkscape Layers
by MenTaLguY 05 Jun '04

05 Jun '04

On Fri, 2004-06-04 at 17:17, Alan Horkan wrote: > if the underlying infrastructure is already there then I would encourage > you to add Menu items first which is relatively easy compared to adding a > proper layers dialog. Well, we won't have "layers" per se -- the "layers" dialog would just display a tree of SPItems. Layers are groups are layers, the only difference being maybe the flag I mentioned in the article which determines some details of selection behavior (layer-like versus group-like). > I would suggest it would look roughly like this > > Layer > New Layer Ctrl+Shift+N > Duplicate Layer > Delete Layer > --- > Arrange > Bring to Front Ctrl+Shift+] > Bring Forwards Ctrl+ > Send to Back Ctrl+Shift+[ > Send Backwars Ctrl+[ > --- > View (this one you might leave out) > Current Only > All > None > Hide > --- > Merge Down > Merge Visible > Flatten > --- > Layer Properties * We already have nearly all of these operations (which apply to anything, not just layers). "merge down" and friends, however, might be useful to have for groups in general somehow. > * (at the very least this would put up a dialog allowing you to rename the > layer/group id) That's already part of the object properties dialog. We are missing a couple things, though, aside from the dialog: * SPDesktop needs to keep track of one SPObject as the current "edit root" (in which its tools create shapes) -- it would of course default to the top-level SPRoot. * the various drawing tools need to be modified so they create their objects under their associated SPDesktop's "edit root" ("edit root" of course roughly corresponding to the traditional notion of "current layer") -mental

3 2

Intro to Inkscape Hacking
by Bryce Harrington 05 Jun '04

05 Jun '04

For those of you just joining us, or who have been with us but are just now getting the itch to work on Inkscape, I thought I'd give some tips for how to get started working in the codebase based on our own experiences. One of the first things most people wonder is "what should I work on". As you may have already noticed, we generally don't "assign" projects. We figure there's plenty more work to do than people to do it, so you may as well work on something that you're either interested in or that adds something of benefit to you; that's extra motivation to get your own itches scratched. If you're really stumped though, we keep a detailed roadmap in wiki that you're welcome to browse through to look for ideas of things to work on. Tasks that do not have names beside them are open for anyone to take; if you want to take ownership of a task, just put your name beside it. Feel free to add or reword tasks as needed, although try not to load up the current milestone with tasks that aren't critical for the release. Feel free to work on stuff that is several milestones down the road; there's rarely any problem with getting stuff done sooner than planned. ;-) We have a process for gaining CVS commit access. The reason is that while it is important that we keep access to the codebase open, we don't want to be crazy and leave it wide open to any random passer-by. The process is that we require that the person make two contributions (patches, documentation, web collateral, etc.) and then make a request to get account access. In general you won't need CVS commit access in order to start doing development, because you can work from an anonymous checkout and create patches. If you've not done this before, you'll need to learn this skill first (basically see docs for `cvs diff`). When you first start hacking on Inkscape code, I wouldn't recommend taking an objective of implementing a specific feature, because you will need some time to familiarize yourself with the codebase, and because you won't really know what features are going to be straightforward to implement and which will be highly challenging. Of course, if you have the time and love adventures, this might be fun way to go. There are four approaches that I've seen people effectively use in getting into the codebase: 1. Write code documentation. Some people who don't mind adding comments to code or writing docs find it useful to just go through code they're interested in working on and writing up what it does. The codebase is in dire need of better docs, so this approach pays dividends well into the future. 2. Fix bugs. Tracing down the cause of reported bugs is an effective way to gain understanding of the codebase in small chunks. Many common bugs can be traced down and fixed in a matter of hours, and often will identify some bit of code in need of refactoring or extension. Note that some of our older bugs are in the system because they're hard to fix, so you'll want to work on the more recent ones. 3. Chip in on a group effort. Occasionally we identify a major refactoring effort (such as when we converted from C to C++), that we encourage lots of people to help on, in the philosophy that many hands makes short work. This work tends to be pretty rote so is not hard for new folks to get involved with; just takes time. We generally have one of these kinds of efforts per release. It usually isn't glamorous work, but in aggregate moves the codebase forward in a major way. 4. Subsystem/module work. Some people want to get their hands in the details quick, so take the approach of developing new code separate from the codebase, to be integrated in later. This generally tends to take a larger time commitment than the other approaches, but can an effective approach in some circumstances. We have a CVS module called 'experimental' that you're welcome to house your work until it's ready for prime time. Beyond that, you're going to find the documentation for the Inkscape code is pretty scarce. We've worked on bits and pieces but unfortunately the vast majority of the code is undocumented. On the plus side, often you can implement the stuff you care about after learning only a limited portion of the codebase. I think you'd find Inkscape an enjoyable Open Source project to work on. There's a huge range of interesting and useful skills that can be learned from it, plus the developers are great guys to participate with. The project itself runs smoothly and puts a premium on keeping things friendly and low-stress, so heated arguments are rare. The users have been great to work with and very appreciative of even small new features and fixes. Plus, since Inkscape is so visual in nature, it's very cool to see how your little changes make noticeable improvements to the app overall. Bryce

1 0

Re: [Clipart] file/magic/mime types for SVG and suggested viewers?
by Bryce Harrington 05 Jun '04

05 Jun '04

On Fri, 4 Jun 2004, Jeremy C. Reed wrote: > On Fri, 4 Jun 2004, Bryce Harrington wrote: > > > On Fri, 4 Jun 2004, Jeremy C. Reed wrote: > > > Is there a MIME type for SVG data? > > > > Yes, it's either image/x-svg or image/svg+xml > > > > > Is there any file(1) magic(5) for SVG images? > > > > Dunno, but if not would you like to help send the file/magic maintainers > > a patch to add it? > > I can submit it. But I don't know if it is possible to create a magic(5) > for SVG since they can start so many different ways. Hmm, good point, though isn't XML by definition supposed to contain indicators of what *type* of XML it is? Perhaps there's a mailing list we could ask on for direction? > Does anyone know how to configure magic so the offset is not forced? (For > example "<!DOCTYPE svg" could be at 141 position or could be at some other > position. Or the "<svg" marker may be at some random place. I'm also CCing to the Inkscape mailing list in case someone there can answer it. > > Thanks, I can add these to the faq, unless you'd like to? I don't know > > the answer for the third, though, so if you run across the answer let me > > know. > > I added the questions. But I don't have the answers. (That is why I posted > to list.) Okay, well for the first two questions I can provide some answers: Viewers - the de facto standard viewer for SVG is Batik. The Adobe SVG viewer plugin is also used, although I think it may only work under Windows. There is also a SVG renderer in library form, called librsvg. There are a number of tools and applications that provide SVG viewing support via that. I understand there is also a svg2png tool, although I've not used it myself. Editing - I put in my plug for Inkscape as a good SVG editor, but there are a lot of other ones out there. In the proprietary world, Adobe Illustrator is very good, although SVG is not its native format as it is with Inkscape. In the open source world, Inkscape, Sodipodi, Sketch (aka Skencil), and Karbon14 are worth looking at. Some additional tools (some SVG, some not) are listed here: http://inkscape.org/cgi-bin/wiki.pl?OtherProjects Also, for programmatic generation of SVG there's a wide variety of libraries available nowdays. For instance, Perl has a number of different SVG modules available via http://www.cpan.org/ Bryce

3 2

problem with using patterns for images
by MenTaLguY 05 Jun '04

05 Jun '04

I finally got around to using the new images-as-patterns feature. Unsurprisingly, Inkscape is subject to the same problem as most renderers -- due to roundoff error, opposite edges of the tile pattern will "peek around". That is almost impossible to avoid when dealing with an exactly-fitted tiled pattern. See the attached image for a visual demonstration of this. I have imported the same image twice; once as a pattern (left), and once as a straight image (right). Note that there is no stroke on the former. Unless we can find a workaround for this that will work in all SVG renderers (i.e. we can't just add a hack to our renderer to account for this case), we CANNOT import images as patterns (certainly not by default). One possible workaround would be to add an amount of empty "padding" around the image in the pattern. That does have its own disadvantages, however: * the tiling behavior is sometimes desirable (once users have the ability to manipulate pattern transforms) * the same roundoff errors could produce gaps between the image in the patterned fill and the stroke (if any) Any other ideas? -mental

1 0

[Announce] Scribus Team Releases Scribus 1.1.7 - "Alyssa"
by Peter Linnell 05 Jun '04

05 Jun '04

Hi all, The Scribus Team is pleased to announce the release of Scribus 1.1.7. The 1.1.7 release is the most stable, feature complete version to date. This release is mostly a bug fix release intended to allow more extensive testing of the new features recently added for the upcoming release of a stable 1.2 Scribus. Although, marked a developer's release, the Scribus team urges all users and distros to use this latest release. The Scribus Team is also pleased to be chosen by Trolltech as one of their "Cool Applications". We on the Scribus Team are honored to be recognized as such and appreciate the recognition. Also, Franz has provided bzip2 tarballs which shrink the download size by about 30%. Expect to see Fedora/RH and Suse RPMs soon, as well as debs provided by our Debian maintainer extraordinare: Alex Moskalenko At the usual place: www.scribus.net Enjoy!

1 0

Statistics
by Bryce Harrington 05 Jun '04

05 Jun '04

http://sourceforge.net/project/stats/?group_id=93438 Date Page Views D/L 3-june 13,131 603 2-june 29,206 1,185 1-june 3,808 163 31-may 3,032 167 30-may 2,034 87 29-may 1,896 89 28-may 2,764 167 The D/L numbers don't count the 800 or so from Bob's nightly snapshots, nor people who got it through apt-get, emerge, etc. Bryce

2 1

Re: [Inkscape-devel] Article followup
by bulia byak 04 Jun '04

04 Jun '04

> > We need more enthusiastic coders! :) > >I'm a coder, and can be enthusiastic from time to time. Great! :) If you want to help, join the jabber chat and discuss what you could do and where to start. _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: pangoification (never dies)
by MenTaLguY 04 Jun '04

04 Jun '04

On Thu, 2004-06-03 at 14:07, fred wrote: > since you mentioned it, i did a bit of testing with > IBM's ICU. it's quite good, in fact... it does kerning > and deals with opentype seamlessly. might be worth > considering We were actually originally going to use ICU, until I talked us out of it to try pango first (since it wouldn't add any library dependencies). Looks like JonCruz was right, though; I think ICU probably is the way to go. Something we need to look at though is how this will work with Win32 fonts; fontconfig is not an option there. -mental

1 0

RE: [Inkscape-devel] Article followup
by bulia byak 04 Jun '04

04 Jun '04

>than happy to lend a hand. For example, I'd bet an article giving >advice about usability would be well received. An article about >Inkscape internals as they relate to SVG rendering would as well. I >also think a usage-oriented "secrets of Inkscape" article would be >appropriate. So if anyone is interested in authoring an article on any >of those subjects, I would be happy to help in any capacity. I think I might be interested. But not right now, not before 0.39 at least. _________________________________________________________________ MSN Premium helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

simple idea to hack around hinting for pango and W32
by Nathan Hurst 04 Jun '04

04 Jun '04

Simply ask pango or whatever to layout text that is say 256* larger font size. Scale the glyphlist back to the correct size. njh

1 0

Re: [Inkscape-devel] Revisiting ECMA. Seriously, folks. :)
by Bob Jamison 04 Jun '04

04 Jun '04

I will look at this. However, spec compliance is one of the things we need: http://www.w3.org/TR/SVG11/escript.html Bob Charles Goodwin wrote: >For Vexi (www.vexi.org) we have a very small, efficient JS library that >is far more lightweight than Mozilla Rhino. It's in Java, though, >although GCJ compiles native binaries these days. > >If you were looking for something with less cruft then it could be an >option, but there are caveats. > >Here's what Brian Alliet, the guy who wrote it, had to say: > >(19:23:17) charlieg: balliet: how suitable would the JS engine be for >anything other than ibex/vexi? >(19:23:41) charlieg: specifically, the Inkscape guys want to integrate >an ECMAscript engine to enhance their SVG compliance >(19:24:02) balliet: very suitable. i've always kept ibex specific stuff >out of org.ibex.js >(19:24:48) balliet: does SVG compliance specificly require ECMA-262? >(19:25:07) balliet: that could be a problem since org.ibex.js isn't (and >doesn't intend to be) fully emca-262 compliant >(19:25:53) balliet: however, if they're just looking for something to >get 90% of the way there then org.ibex.js would be fine >(19:26:14) balliet: if they really need full ecma-262 though they'll >have to go with rhino >(19:26:35) charlieg: what are the major compliance obstacles? >(19:27:32) balliet: classes is the biggest one >(19:27:57) charlieg: simply because we don't need them, right? >(19:28:09) balliet: yeah, and they complicate things significantly >(19:28:22) balliet: it would take major changes to org.ibex.js to suport >them >(19:28:36) balliet: then there are lots of other little things that >would require major changes too. like in ecma-262 null isn't the same as >undefined >(19:29:04) charlieg: does rhino do that according to ecma-262, though? >(19:29:17) balliet: yup >(19:29:32) balliet: and its ridiculously complicated as a result of >it :) > >

2 1

Link to my server
by Bob Jamison 03 Jun '04

03 Jun '04

Can someone please remove the link from the "download" page to my server? Since Inkscape was mentioned on /. , my server has been /.-ed. It is a development server at the office, and these 800+ downloads since yesterday are rendering it useless. I have hidden the pages for now, until this is fixed. Maybe someone can upload a recent build to SF.net, and point to that instead? Thanks, Bob

2 1

[Fwd: svgx.org-Open Source Graphics for the Masses]
by JonPhillips 03 Jun '04

03 Jun '04

-----Forwarded Message----- > From: michael bolger <michael@...20...> > To: JonPhillips <jon@...15...> > Subject: svgx.org-Open Source Graphics for the Masses > Date: Wed, 02 Jun 2004 18:47:41 -0700 > > Hi Jon, new post at http://www.svgx.org > > Scalable Vector Graphics > and the Open Source Community > -from osnews.com, Bryce Harrington > see; Inkscape SVG Editor and Inkscape Wiki > also; Open Clip Art Library item section; project and tools > "Open Source community is now adopting the SVG format" > > > -also will add additional "permanent" main page link in next several days. > > Cheers > Michael > -- Jon Phillips Graduate Researcher Visual Arts Department PO BOX 948667 LA JOLLA, CA 92037 USA cell.858.361.2811 jon@...235... http://www.rejon.org

1 0

Inkscape Article
by Bryce Harrington 02 Jun '04

02 Jun '04

Here's the article about Inkscape on OS News: http://osnews.com/story.php?news_id=7241 Bryce

2 1

Keep up the good work!
by Alan Horkan 02 Jun '04

02 Jun '04

I tried out one of Bob Jamisons windows builds a few days ago and Inkscape 0.39 is looking really sweet, and I'm enjoying playing around with some of the new features. It is great now that the secondary toolbar/tool options palette (whatever ya call it) is now working for all the tools. The new picture in the about dialog is nice for a change. Although I'm very pleased and Inkscape is getting so good I'm fast running out of things to complain about ;) I cannot resist making a few comments: generally an about dialog provides information such as versioning and build options so that users reporting problems can let developers know exactly what they are using. It is a very minor point but the inkscape about dialog doesn't provide a convenient way (select and or) copy the text from the dialog. although there is a permanent zoom entry box on the status bar i still kind of expected to have one in the secondary/tool options palette when I was using the Zoom tool. Until you have learnt them icons can be slow to decipher, some sort of text labels on the Zoom toolbar might be an improvement. Thanks again for the software! Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/

1 0

Test of autopackaged Inkscape on Mdk 9.0
by Bryce Harrington 01 Jun '04

01 Jun '04

I had a spare Mandrake 9.0 box and had a shot at using autopackage on it, since I'd not run autopackage on it before, and that only has Inkscape 0.35 installed on it: .... 00%[=========================================>] 370,830 129.66K/s ETA 00:00 12:53:11 (129.66 KB/s) - `autopackage-0.5.1.tar.bz2' saved [370830/370830] Download completed. .......................... autopackage/libexec/autosu-gtk: relocation error: autopackage/libexec/autosu-gtk: undefined symbol: g_str_has_prefix /home/bryce/tmp121441735/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 437: return: : numeric argument required The autopackage support code could not be installed. It can be manually downloaded and installed by running the installation script located in the downloaded archive. {brimstone} ~ (10): umask 77 {brimstone} ~ (12): rpm -qa | grep gtk libgtkmm1.2-1.2.9-3mdk libgtk+1.2-devel-1.2.10-29mdk libgtk+-x11-2.0_0-2.0.6-8mdk libgtk+2.0_0-2.0.6-8mdk libgtk+2.0_0-devel-2.0.6-8mdk gtk-engines-0.12-3mdk gtk+mdk-0.1.6-12mdk gtkhtml-1.0.4-4mdk nautilus-gtkhtml-0.3.2-4mdk gtk-themes-1.0-9mdk libgtk+1.2-1.2.10-29mdk libgtkhtml20-1.0.4-4mdk libgtkhtml2_0-2.0.1-1mdk libgtk+-x11-2.0_0-devel-2.0.6-8mdk libgtkmm1.2-devel-1.2.9-3mdk libgtk+mdk0.1_6-0.1.6-12mdk libgtkglarea5-devel-1.2.3-4mdk gtk+2.0-2.0.6-8mdk libgtk+mdk0.1_6-devel-0.1.6-12mdk gtk-engines2-1.9.0-13mdk gtkdialogs-1.2-3mdk libgtkxmhtml1-1.4.2-1mdk pygtk-0.6.9-3mdk libgtkglarea5-1.2.3-4mdk {brimstone} ~ (14): rpm -qa | grep inkscape inkscape-0.35-0 {brimstone} ~ (15): xhost access control enabled, only authorized clients can connect

2 2

new autopackage patch available
by Mike Hearn 01 Jun '04

01 Jun '04

Hi, I've added a new patch with misc fixes/improvements to the relocatable build in the patch tracker. Apply at your leisure. By the way, autopackage 0.5 is now out. If you could link to these URLs from the website that would be great: The package: http://navi.cx/~mike/inkscape/inkscape-0.39cvs.package A page explaining what to do in friendly terms: http://autopackage.org/docs/howto-install/ Linking to both would be fantastic. If any users wish to follow the progress of Inkscape but not have to compile every day, this is a great way to track the project (it's what I've been doing). thanks -mike

3 21

Project Status May 31, 2004
by Bryce Harrington 01 Jun '04

01 Jun '04

Project Status Sunday, May 31, 2004 Statistics Nov 15 Jan 15 Mar 15 Apr 15 May 15 May 31 ========== ====== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1928 * 1164 1028 1035 (68.5%) (86.1%) * (91.7%) (92.7%) (92.7%) Max Week's Rank on SourceForge: 62 321 90 31 36 110 (99.6%) (97.5%) * (99.8%) (99.8%) (99.4%) Total SF Page Views * 126,500 * 330,000 475,000 521,500 Total SF Downloads * 5,735 * 17,250 27,400 29,600 Total Freshmeat URL Hits 746 2,958 4,670 6,000 7,500 7,750 Total Freshmeat Subscriptions 16 33 50 70 74 77 Lines of Code in src/: 115,901 166,914 177,286 183,694 189,116 190,764 Code lines 133,150 138,457 143,662 147,471 148,770 Comment line 12,468 15,584 16,041 16,757 16,880 Blank 21,929 24,061 24,931 25,886 26,113 Lines of Docs in doc/: 1,135 3,000 4,434 4,540 4,544 4,571 Lines of content in website: 1,173 2,885 5,087 5,414 6,008 6,228 Size of the Inkscape wiki: 3,700 11,284 14,840 15,461 18,638 16,300 Minutes since last ChangeLog mod: 360 6 0 11 1 1889 Bugs open/total: 9/15 74/160 43/244 47/322 57/365 68/381 Features open/total: 18/18 104/120 151/184 173/213 183/238 195/256 Patches open/total: 1/ 6 4/32 6/ 45 5/ 72 4/ 83 5/ 85 CVS Commits (as per inkscape-cvs): 481 * 3070 3710 3391 5241 Inkscape-devel membership: 49 64 75 77 78 82 Inkscape-announce membership: 9 22 35 41 43 47 Inkscape-user membership: 71 69 * - Statistics unavailable

1 0