- Inkscape Devel - Inkscape Mailman

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