- Inkscape Devel - Inkscape Mailman

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