- Inkscape Devel - Inkscape Mailman

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