- Inkscape Devel - Inkscape Mailman

Fw: non-uniform text scaling
by vellum 02 Jan '05

02 Jan '05

Bulia wrote: >What was the change and what was the bug? Bulia, Peter will probably get back to you. The original bug was a record of non-uniform scaling of text causing incorrect pt size designation of font. Peter made changes to correct this and I tested a day or so later as reported below. The new bug was that transformed text could not be transformed again back to a known pt size. This was worse than the original. Hence Peter removed his changes. The original bug should be reinstated in the bug list. vellum ----- Original Message ----- From: "vellum" <kaver@...68...> To: "Peter Moulder" <Peter.Moulder@...38...> Sent: Saturday, January 01, 2005 3:51 PM Subject: non-uniform text scaling > Peter, > I have tested your changes using 0412311700. The changes you have made seem > to work to cure the original bug. However, I think they have created or > uncovered another one. That is: The transformed texts cannot be transformed > back to the original point size. > > In Xarax. Transform say a 10pt text non-uniformly to some other value say > 37.32pt. Select the transformed text and choose 10pt as the font size, > apply. The text will go back to 10pt. > > In Inkscape transform the 10pt text non-uniformly to 38.6pt. Select > transformed text, choose 10pt, apply. The text goes back to 14.3pt. Further > attempts to change it to 10pt are to no avail. > > When the text is transformed uniformly then there is no problem with > Inkscape. And that seems to be the case whether the width/height lock is on > or whether it is done with Ctrl drag. > > In your second comment on the bug sheet 041231 4:41. I think I understand > what you are saying regarding the translation and the other two columns of > the transformation matrix. However, I do not know what the other two columns > are called and each of the other programs tends to have these values hidden, > or if shown it is not clear what they are. When I change values in the > transformation matrix the text seems to go all over the place since I do not > know what I am changing. > > Can you tell me what Column 1 and Column 2 are called? Then I can get onto > your request. > > regards, vellum > >

1 0

[Fwd: Re: [Inkscape-devel] CFV: Inkscape Examples Webpages]
by Felix Rabe 01 Jan '05

01 Jan '05

I'm still not used to this strange kind of replying :/

2 2

elongating lines doesn't work anymore
by David Christian Berg 01 Jan '05

01 Jan '05

Hey guys, first of all let me wish you a wonderful year 2005! May it be rewarding not only concerned the Inkscape development. Now: I don't have latest CVS, so maybe this is fixed again. My RFE "[ 1036484 ] Elongating straight lines" that was fixed by Bulia seems to have to be reopened. At least I don't manage elongating lines using a modifier key anymore. Any clues? David

2 2

dividing the inch
by Aaron Spike 31 Dec '04

31 Dec '04

It is customary to divide inches in halves, fourths, eighths and sixteenths, right? In Inkscape dark grid lines (love that feature by the way) and ruler marks appear in halves, fifths and tenths. sp_ruler_metrics in sp-metrics.h has it all right. But sp_ruler_set_metric is only called in desktop.cpp and SP_PT is hardcoded as the metric. To make the divisions follow the document preferences the call to sp_ruler_set_metric would probably have to be moved farther down the line into sp_desktop_widget_update_rulers and some math would need to be changed. I don't know if Inkscape would want to do this. A really feature bloated app might even let you work in your prefered unit and configure you own arbitrary divisions. Then I could divide inches in thirds. I tried hacking out a change for this a while back and started to get the idea that messing with units probably wasn't appropriate for a newbie with now knowledge of C++. It seems messing with units actually means messing with the fundamental assumptions on how Inkscape should deal with units. So I don't have a question, as such, I would just like to see what others think. Aaron Spike

2 1

CFV: Gtkmm - Develop a Context Menu
by Bryce Harrington 31 Dec '04

31 Dec '04

Okay, last Call for Volunteers today, I promise! This one will be quite tricky and requires good knowledge of C++, Gtkmm, and the Inkscape codebase. The menu needs to be very dynamic and well tied in with Inkscape's internals, so if you don't already know Inkscape code thoroughly, you'll need to be prepared for a lot of digging and learning. Fortunately, you can start simple and build up as you go. :-) 7. Context Menu ================ The current context menu in Inkscape is not very powerful. We can do better. First skim through the tutorial on context menus on the gtkmm.org site: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch10s03.html In the Gtk+ codebase, the context menu is implemented in the function sp_ui_context_menu, in the file interface.cpp. Review that function to see how the context menu works currently. As a general rule, there should be no more than about ten items total on the context menu. The context menu, by definition, should customize the set of items it displays to the user based on what the user has right clicked on. It should tie in with the Actions system, and should display appropriate menu items for the selected context. The context menu must check the context item against the current selection. The context item is the thing directly under the mouse cursor when the right-click action occurs. The current selection is the item or items selected by the left-click menu. Note that it's definitely possible for these to be different - the user may left click to select a circle, then right click over a rectangle to change its properties. It is also possible to have no selection, or to select multiple items. Each of these implies a different type of context, and would be handled differently. If the context item is completely different from the selection, then display only actions which don't require the object to be selected. For instance, do not display the 'Delete' action, since that will cause the _selected_ item to be deleted rather than the context item. Same thing for cut, copy, etc. Note that context commands should *not* change the selection to get around this. If the context item is the same as the selected item, then detailed operations should be shown for that item, including actions that can be performed on selections. In this case, you'd display Delete, Cut, Paste, etc. If multiple items are selected, and the context item is one of the items in the selection, then present actions that can be performed on multiple selected items. Delete, cut, copy, duplicate should act on all selected items, for instance, and commands for group, Text-on-path, booleans (Union, Difference, etc.) should be presented. If the context item is part of the chrome (i.e., a toolbar button, the status bar, etc.) then display a context menu appropriate to that item, plus some commands specific to the inkscape application itself. For instance, it should allow all of the actions available through doubleclick, shift-click, alt-click, etc. with the button, and inkscape preferences, view/hide the chrome item, etc. Think about the context menu in three sections. The top third and bottom third should have the most commonly expected commands, and the middle should have the less common commands. The top (and sometimes the bottom) will be the closest to the mouse cursor when popped up so it will be most convenient for common actions to be located there. The middle is less accessible so rarer functions should be placed there. Strive to always place the same command in the same location in the context menu. The top portion of the menu should have actions which are common, frequently used commands needed for any shape or context. The bottom portion should consist of the commands that are common for the specific shape or context selected. The middle portion should consist of commands specific to the shape or context, but less commonly used. Any action available in the context menu should also be available through other means, but you can include actions that otherwise require several clicks. For instance, in the context of a font item, you could include actions for changing the font size; this is normally available only by first opening the text and font dialog, then selecting the font size from the font size widget. To get the Gtkmm codebase: $ cvs -d:pserver:anonymous@...54...:/cvsroot/inkscape login (hit enter for password) $ cvs -z3 -d:pserver:anonymous@...54...:/cvsroot/inkscape co experimental/bryce/inkscape_gtkmm $ cd experimental/bryce/inkscape_gtkmm $ make $ ./inkscape Bryce

1 0

CFV: VDX and PDF extensions
by Bryce Harrington 31 Dec '04

31 Dec '04

For those interested in learning more about extensions, here are two that might be worth incorporating: http://vdxtosvg.sourceforge.net/ http://www.solidcode.net/pdf2svg/ Try them out - do they actually look useful and compatible with Inkscape? If so, add them to our extensions. You'll need to create a .inx file (see /usr/share/inkscape/extensions/ for examples), and test it out on a variety of files to make sure it's not too buggy. Then post a patch to the patch tracker (or report back if it looks like a no-go). Also, if you can find any other xxx2svg filter programs out there, go ahead and test out adding them too. Good places to look include svg.org and Freshmeat.net. You can also create your own filters pretty easily using packages such as perl's SVG.pm. I had good luck at hooking together SVG.pm and Perl's POD converter to create a pod2svg filter. ;-) Bryce

1 0

grid (and ruler) units
by Aaron Spike 31 Dec '04

31 Dec '04

I've seen it in my web logs a few times now. People are searching google to find out how to change the ruler units in Inkscape. I'm not surprised because that was one of my first questions. I ended up finding the answer in the release notes. If the "Document Preferences" dialog said "Grid and Ruler units" instead of just "Ruler units" the answer would be more apparent. If that isn't acceptable it could go in a FAQ. Aaron Spike

2 1

CFV: Performance measuring/testing
by Bryce Harrington 31 Dec '04

31 Dec '04

Here's a much more techie task we need done. Over the past several releases there's been some observations of slowness in the Inkscape renderer. We'd all like Inkscape to be nice and snappy, even for huge documents. However, we've not really had good, standardish ways of measuring performance. A good way of measuring it would be helpful in several ways: It'd help developers quickly see if a change improves or degrades performance; it'd enable us to track performance from release to release; and, it'd be a tool we could add new performance "Problem Cases" to as we go. The task is to create a collection of scripts that one can run on a copy of inkscape, that exercise it in some different ways and records the speed it did each thing. Right now, you can do some testing by just running Inkscape in cmdline mode on a large .svg file, and time how long it takes for Inkscape to startup, create the .png, and exit. (Later, maybe we can add some testing triggers inside the code so we can better measure performance of particular pieces (like just the startup time, just the gui init, etc.) Also, later hopefully we'll have some internal scripting or Atk support to allow further automated testing of the app. But static runs should be enough to give us some good info to start with.) It would be interesting to run this performance suite against older versions of the software, and measure how performance has changed over time. It'd be especially cool if this could produce an SVG graph. :-) Bryce

1 0

CFV: Update Roadmap
by Bryce Harrington 31 Dec '04

31 Dec '04

Here's another task... This one needs to be done fairly soon; I'm hoping to get to it later this weekend if nobody else can. We've decided to have an accelerated 0.41 release in mid to late January. This means that we need to shuffle the roadmap. Wiki skills are needed. Some knowledge of Inkscape's development activities would be helpful, but if you're good at asking questions you won't need much depth. http://inkscape.org/cgi-bin/wiki.pl?Roadmap * Tasks related to gtkmm need to be moved from Milestone 7 (0.41) to milestone 8 (0.42). * Most development tasks for 0.41 will also need to be bumped forward to 0.42 (speak with bulia, mental, etc. if you have questions - or ask them to update their tasks directly) * Most or all tasks listed for Milestone 8 (0.42) need to be bumped up one number, to Milestone 9 (0.43). Also bump all the subsequent tasks up one release number, too. * Also update the website copy of the roadmap: http://inkscape.org/roadmap.php Thanks, Bryce

1 0

Re: [Inkscape-user] proposed change to icons
by Ben Crowell 31 Dec '04

31 Dec '04

After posting on inkscape-user and increasing the sample size, it seems to me that there is a clear consensus in favor of the new style. Bulia wrote: >There's no need to argue. Ben, you can continue working on the new >icon set, and when you are ready we will ship your icons.svg alongside >the old one, so people can choose whichever they like. Trent, the same >for you: you are welcome to develop a set of icons that work best for >your black background, and we'll ship them also. When there's at least >one complete set besides the old one, we can make a preference with a >UI to choose one of them on load. The real issue is whose icons will be the defaults. Since most people seem to like mine better than yours, I think mine should be the defaults. I would like to request a clear decision on this from the core developers before I invest a lot more time on the icons.

3 3