- Inkscape Devel - Inkscape Mailman

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