- Inkscape Devel - Inkscape Mailman

display scale factor
by unknown＠example.com 04 Nov '12

04 Nov '12

Recently, I wanted to use Inkscape to draw a floor plan for a large house. For this, I needed to use a grid specified in feet and inches. I found that in order to fit the whole drawing on the screen at once, I had to set the zoom factor to 3% or less, which was inconvenient. It seems that for some reason you cannot set a zoom factor of less than 1%, so if the building were even three times larger, there would be no way to view it all at once, if you used the correct units to draw it. It seems that I'm not the only person having this problem: http://inkscape-forum.andreas-s.net/topic/1209992 The suggested solution is to scale your drawing in "px" units, and then apply a mental scale factor to get the real dimensions. Of course you COULD do that, but why should you have to? Why can't Inkscape accommodate whatever units, dimensions, and scales are appropriate for the task at hand? My first solution was as follows. The inch and foot units are defined in the Inkscape config file "/usr/share/inkscape/ui/units.txt", or possibly "/usr/share/inkscape/ui/units.xml". I'm not sure which of these files is supposed to be normative; why are there two of them? # name plural abbr type factor PRI description inch inches in LINEAR 90.0 N Inches (90 px/in) foot feet ft LINEAR 1080 N Feet (12 in/ft) I added the following units, which are defined to be 1/360 of the usual ones: x-inch x-inches xin LINEAR 0.25 N X-Inches (0.25 px/xin) x-foot x-feet xft LINEAR 3 N X-Feet (12 xin/xft) Inkscape then recognizes these new units for the "Default units" and "Page Size" options, and for the "Transform" dialog. It DOES NOT recognize them for the object dimension boxes along the top of the canvas, and when the drawing's default unit is set to "xft", the rulers are graduated in "px" units. I then tried adding the same definitions to the "units.xml" file: <unit type="LINEAR" pri="n"> <name>x-inch</name> <plural>x-inches</plural> <abbr>xin</abbr> <factor>0.25</factor> <description>X-Inches (0.25 px/xin)</description> </unit> <unit type="LINEAR" pri="n"> <name>x-foot</name> <plural>x-feet</plural> <abbr>xft</abbr> <factor>3</factor> <description>X-Feet (12 xin/xft)</description> </unit> This did not appear to have any further effect. It seems rather silly that for some purposes, the unit definitions would be read at runtime from a config file, while for other purposes, they would be compiled into the program binary, but that appears to be how it currently works. I suppose I could fix this so that all the unit definitions were read from a single config file at runtime, and then define corresponding metric x-units as 1/100 of the usual ones, but that would be kind of pointless. People who want to draw cells, or integrated circuits, or molecules, would have to define y-micrometres, y-nanometres, and y-angstroms, as a million times bigger than the standard units, because it turns out that the maximum zoom factor you can apply is 25600%, or 256. (It's pretty silly to have to write 256 as "25600%", but apparently you do have to.) There is a much better solution, which is illustrated by the attached image "scale.png". This is intended as an addition to the current "Document Properties/Page" config window. It specifies the scale at which the drawing will be displayed on the physical screen, as a ratio between real dimensions on the screen, and the declared dimensions of the drawing. This does not replace the current "Zoom" option in the "View" menu or the box in the lower right corner of the main window. It is simply multiplied together with that setting, so if the zoom factor is set to "1:1" or "100%", the specified display scale factor is what you get. The intention is that the display scale factor will be set once, to an appropriate value for the drawing, while the zoom factor will be changed frequently while working. The display scale factor is specified as a ratio between two values, each of which consists of a decimal number and a unit chosen from a selection list. The available units are those read from the units.{txt,xml} file, with the addition of "width" and "height". These two units will refer to the physical screen dimensions, and the declared page size for the drawing. You can therefore specify that the normal display scale is such that the width of the drawing is the width of the screen (or half that, or twice that). This is likely to be useful, because often the X server does not have an accurate idea of the physical screen dimensions, but it always knows the size in pixels. It seems that this feature should be fairly simple to implement, for someone familiar with the Inkscape code. It only requires four additional widgets for the Document Properties window, for this setting to be saved and read from the SVG file, and for the resulting value to be multiplied with the existing zoom factor wherever that appears. Note the following related feature request, rated as "Priority: High": https://blueprints.launchpad.net/inkscape/+spec/real-units Bob wants to draw a house plan in feet and inches, but still print it on a letter-sized paper. (one idea: different layers can have different scales: e.g. border layer is actual size, house layer is 1 in. = 8 ft.) I would point out that the SVG specification does not prescribe any particular ratio between "px" drawing units and actual physical lengths. (It certainly DOES NOT specify that 90 px = 1 inch, as Inkscape currently assumes [units.txt]; this ratio is only mentioned as "for example".) http://www.w3.org/TR/SVG/coords.html#Units I suggest that for Inkscape, "px" be considered to be equivalent to the specified "Default unit" from the Document Properties window. If the default unit is metres, or whatever, then that's what "px" means, for that document, but no other. I don't see how this is inconsistent with the SVG specification. Another related proposal is here: http://sourceforge.net/mailarchive/message.php?msg_id=29861176 >> I think that if we are going to break compatibility, we go for one >> release to do it. Basically, all of the new-style stuff including >> custom doc coords would be a huge win to introduce all at once. I >> would love to see a rotatable canvas in Inkscape, but I have no idea >> how feasible it is with the current rendering/viewport stuff we have >> in place. > > In principle it should be possible to change doc2dt and dt2doc > matrices to any transform without any modifications to the display > subsystem, but it might expose bugs - mainly hidden assumptions that > doc2dt is always an Y flip + translation. If the canvas can be rotated by an arbitrary angle (or "any transform matrix" applied), then certainly another uniform scaling factor can be applied at the same time. Finally, I must comment on how strange it is that "units.txt" contains the following definition: # name plural abbr type factor PRI description % % % DIMENSIONLESS 1.00 Y Percentage It seems clear that since 100% = 100/100 = 1.0 , then 1% = 1/100 = 0.01 ; this is what the conversion factor should be. Only slightly less strange is this: degree degrees deg RADIAL 1.00 Y Degrees The natural base unit for rotations (if not radians) is one whole rotation, the identity operation, analogous to multiplication by one. These definitions necessarily imply that there must be inverse conversion factors of "100" and "360" hard-wired into the Inkscape code somewhere. But why should that be? The natural place for such conversion factors is this same "units.txt" definition file; that's what it's FOR. In this regard, it would be helpful if whatever piece of code is responsible for reading these definitions were (trivially) extended to handle ratios; then a degree could be defined as "1/360", rather than "0.002777777". Then, if someone wants to specify angles in milliradians, for some reason, they can define that as "1/6283.185", rather than "0.05729578", as is currently necessary. http://en.wikipedia.org/wiki/Angle#Units Similarly, if someone is working on some tiling problem and wants to scale things by multiples of 1/64, rather than 1/100, they can call that a "perfoo", and define it as "1/64", instead of "1.5625", as currently necessary. Another thing that would be useful for this file is to have some notation for "the n-th root of x"; for example, "2\4" could mean "the fourth root of two", which might otherwise be written as "2^(1/4)". Currently, the "+" and "-" keys zoom the display by a factor of 2^(1/2) (usually called "square root of two", 1.414214), while the up and down arrows next to the zoom factor box change it by almost, but not quite, 2^(1/10) ("tenth root of two", 1.071773). If there were some convenient notation for specifying geometric roots in the "units.txt" file, these zoom factors might be made configurable, and they could also be used in the "Transform" dialog for scaling objects. -- Ian Bruce

1 0

XQuartz no more!
by Andrew Pennebaker 03 Nov '12

03 Nov '12

As a Mac user, I'm happy that GIMP finally removed the XQuartz dependency. Would some GIMP developers like to do the same for other Mac Gtk projects such as Inkscape <http://inkscape.org/> or GnuCash <http://www.gnucash.org/>? The latter is in real need of an interface update. -- Cheers, Andrew Pennebaker www.yellosoft.us

1 0

Problem export to png in spanish version
by Benjamin Núñez 02 Nov '12

02 Nov '12

Hi everybody When I try export to png a file, and the name have spanish letters like "ñ" or accent like in this word "camión" the name change in other form. For example Cataluña change as CataluÃ±a. The other problem is, when I try import this file in the same folder nothing happens. If I want export the file I need put this file in other folder. I´m not sure if this problem is because I use Windows. I´m from Spain, sorry if my english not is good and I´m not engineer. V. 0.48 Spanish version Windows 7 -- Benjamín Núñez González

2 3

Color names shown when hovering a swatch color
by Lucas Vieites 02 Nov '12

02 Nov '12

Hi, I'm the translator for the Spanish version of Inkscape and I just got an email from a user asking why the names of the colours in the swatches weren't translated. I didn't know what he was talking about so I checked and found out that when hovering over a color in the swatch at the bottom of the Inkscape window a tooltip is shown in the status bar with the name of the colour that's in the .gpl file. Just out of curiosity: could it be a feature to add in the future, I mean the translation of the colours? Thanks in advance, -- Lucas Vieites lucas@...1852... http://blog.codexion.com http://www.linkedin.com/in/lucasvieites

2 1

Filter to background image, Is that a normal behaviour ?
by Ivan Louette 01 Nov '12

01 Nov '12

See the sample file : Import a bitmap Draw a shape and put it behind the bitmap Apply a filter to the bitmap with a Composite "In" connected to Background image Group bitmap and shape Add a new shape behind this group (separated from the group). At first time you see the filter applied to the group only. But if you refresh the screen (moving anything or panning) then the filter applies also to the last shape drawn behind the group. However if you make a bitmap copy or if you export to bitmap the shape behind isn't shown. (n.b. I added an outer shadow inside the filter in order to enhance the weirdiness.) To my sense the shape added after grouping should not inherit the filter effect. But I don't know how it is specified in SVG ivan

1 0

Packaging for OSX
by Gellule Xg 30 Oct '12

30 Oct '12

It looks like I may be able to package Inkscape in a dmg. The procedure is refreshed version of https://blueprints.launchpad.net/inkscape/+spec/inkscape-quartz It has been compiled on Moutain Lion (64 bits) from trunk. You should be able to give is a spin from: http://dl.dropbox.com/u/49834266/Inkscape.dmg Let me know if it works for you and/or if it is worth pushing this further. Regards, -Gellule

4 18

Re: [Inkscape-devel] Understand Code
by Arshdeep Singh 29 Oct '12

29 Oct '12

I am sorry, I know the question is vague. But, I am new to inkscape development and owing very little in-code commenting and guiding sections, the project seems to intimidating and big to understand by sheer hit-and-trial. Till now I have figured out this: 1.) src\dialog contains all dialog boxes' codes. I happen to have fixed a bug recently, Bug-773228. during the course to figure it out, I understood "dialog" contents. 2.) Your direction tells me, "display" is handling the rendering part. 3.) The "widget" directory happens to handle basic functionality types land tools. I really don't know what I need right now, but I was looking for a general understanding of how the code handles what to render on the canvas and then save it there and still enable editing. Maybe you mean, the code is abstracted onto Cairo's code, so we need not get behind the curtain. If that being the case, I would like to know, is there any general source for me understand these workings ? Sorry, if the questions are stupid, I am not that bad at understanding code in general, but without any kind of documentation and help it becomes a little obscure. -Arshdeep On Mon, Oct 29, 2012 at 8:51 PM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote: > On 29-10-12 10:57, Arshdeep Singh wrote: >> Can you shed some light on SP Classes ? > > Can you be more explicit about what you want to know? > >> Also, where can I get to know what inputs are passed on from Inkscape >> code to Cairo for various purposes like when I'm drawing a bezier or a >> rectangle ? > > I think you are probably more interested in the src/display directory, > as that's where the actual drawing is done (or Cairo is called at > least). But it would help if we knew a bit more about what you're trying > to do. > -- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614

2 1

Understand Code
by Arshdeep Singh 29 Oct '12

29 Oct '12

Hello All, Can someone help me with: 1. ) What does "SP-<anythiing>" do. For example, sp-named-view 2.) which is the actual class/cpp file which paints on the canvas ? -- Arshdeep Singh

2 1

Inkscape Board - election results
by Josh Andler 29 Oct '12

29 Oct '12

Hey All, I'm happy to announce that Tavmjong Bah & Johan Engelen have been elected and have accepted their positions on the board. A few people had voted off-lists, however, it does not affect the results in the end (they actually had more votes including those). So, to Johan & Tav, congratulations and welcome aboard! :) Cheers, Josh

5 6

Build broken (gtkm 2_24)...
by Johan Engelen 28 Oct '12

28 Oct '12

Hi all, I just fixed the windows build. With the current devlibs, we need "#define WITH_GTKMM_2_24". If this is not correct than please revert devlibs first. Verify the revert using the online launchpad tool, then fix build.xml. Ciao, Johan

3 5