- Inkscape Users - Inkscape Mailman

Library post: Found it
by Kale Good 23 Jan '18

23 Jan '18

Hello all, Right after I sent that, I figured out a google search that returned a solution for me. Thanks! Kale -- ------------------------------------------------------------------------ Kale Good Good Music Academy <http://goodmusicacademy.com> ♫ 4705 Baltimore Ave, Phila, PA 19143 phone: (215)260-5383 Facebook <http://facebook.com/KaleGoodGuitarStudio> Google+ <https://plus.google.com/b/105422331794047992190/> Read my article "The Seven Secrets to Six String Success <http://www.guitarnoise.com/lesson/seven-secrets-to-six-string-success/>" at GuitarNoise.com <http://guitarnoise.com>

2 1

One metre interactive grid (long lat) superimposed on a map
by Philip Rhoades 20 Dec '17

20 Dec '17

People, I have done a bit of Googling but am a little overwhelmed about where to start but I thought Inkscape people might have a better idea. I want to add an interactive 1 sqm grid to the attached plan. I have the original as a SVG file but it is too large to attach - I imported it from a PDF file for use in Inkscape. I want the grid to be square with longitude and latitude (maybe the maybe should be rotated) such that people could click a rectangle of squares to indicate a proposed new building lot on the site. Is SVG the right tool to build such an interactive map for a web page? Thanks, Phil. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil@...2067...

2 1

Survey: Default beabiour on clones with path operations
by Jabier Arraiza 16 Dec '17

16 Dec '17

Hi all: I just commit a branch [1] that convert shapes and optinaly clones to paths previously any of this path operations: Booleans, Stroke to paths, Object to paths, Combine and Break Apart. The cuestion is simple: ¿Whats is your prefered option about symbols? This is done in preference section and can be change by the user, but we are speaking about the default behabiour. A: Convert to path clones and apply the operation B: Retain clones in this operatios ignoring the operation Thank for take time to reply. [1] https://gitlab.com/inkscape/inkscape/merge_requests/159

2 3

Spin slider widget, redux.
by Tavmjong Bah 15 Dec '17

15 Dec '17

Hi all, I've taken into account all the feedback and have developed a little test program that shows of a number of solutions to replacing the Gimp Spin Scale widget. A gzipped tar file of the source code is attached so that you can try out the solutions (should be trivial to compile on Linux if you have the Gtk3 libraries). Not all of the solutions fully work as I didn't take the time to make them... but you should be able to get a feel for them. If you run in debug mode (see README) you can interactively add CSS. I've include an example CSS file you can paste into the debug window (ignore the colors, they were just for experimenting). I've also attached PNGs of the widgets with and without the extra CSS. The five solutions, from top to bottom, are: * Custom Gtk::Range widget couple with Gtk::Spinbutton: This is my current favorite. It works quite well, methinks. Use the 'Alt' key to get into fine adjustment mode. It was rather simple to implement. Could be refined further (add styling properties, rounded corners, etc.). * Gtk::Scrollbar coupled with Gtk::Spinbutton: Works rather well, but doesn't show as well the current value. Using a narrow "slider" prevents it from covering up the text (text not implemented yet). I didn't know it before, but if one clicks on the slider and doesn't move for a second or two it enters into a fine- adjustment mode. * Gkt::ProgressBar coupled with Gtk::Spinbutton: CSS can get this looking pretty good but some extra work has to be done as the ProgressBar doesn't have an "adjustment", the class that actually handles tracking a value. The Gtk::Spinbutton actually contains a ProgressBar but while one can style it via CSS one can't directly access it and it overlaps the numerical entry part of the SpinButton (this is how the Gimp widget works). * Subclassed Gtk::Spinbutton: This is essentially a modified version of the Gimp widget but it has some major flaws as one cannot access the underlying widgets (ProgressBar, Buttons). In this example, the built in ProgressBar is disabled and new code that simulates a narrower ProgressBar has been added. I could not fine a good way to calculate how much narrower the new bar needs to be to not overlap the numerical entry part. Also, when dragging the bar it is easy to highlight the numerical text. The code to do all this is pretty messy. * Gtk::Scale coupled with Gtk::Spinbutton: CSS can make this look reasonable. Reducing the size of the circle will prevent it from covering text (text not implemented yet). Gtk::Scale also has a fine-adjustment mode accessed the same was as for a scrollbar. Tav

7 13

Display and User units, Scaling, Measuring Paths, Importing PDF
by Philip Rhoades 05 Dec '17

05 Dec '17

People, If I produce a new drawing on an A4 page with Display and User units in mm with a scaling factor of 1.0, I can draw a rectangle of XxY and when I use the Visualise->Measure Path Extension with a Scale Factor of 100 and Length Unit in m - I get exactly the right dimensions for the rectangle for its perimeter length and area - all good! However, I have imported a surveyor's map from a PDF file into SVG and I need to be able to draw rectangles on it as above in mm (like my test) that will correspond to m in the real world but the drawing is on an A1 page and the Display and User Units are in px and I have tried everything I can think of and Googled a lot but I can't do what I was able to do with my little test case. So: How can I convert the drawing to be on an A4 page with mm units so the mm correspond to m and the Measure Path Extension will give me the correct result in m and sqm? The original PDF says the scale was 1:300. Thanks, Phil. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil@...2067...

2 1

Spin slider widget: Opinions needed!
by Tavmjong Bah 05 Dec '17

05 Dec '17

Hi, I've been looking into replacing the Gimp Spin Slider widget (e.g Blur/Opacity in the Fill and Stroke dialog). The widget is licensed under GPLv3 and is the only reason Inkscape as a whole is licensed under GPLv3 rather GPLv2.. The board sometime ago agree that being a GPLv2 program was desirable (I don't remember the exact reasoning). A normal Gtk Spin Slider (aka Gtk::SpinButton) has an option to show the "progress" of slider, that is the percentage (defined in some arbitrary way) between a minimum and maximum value. This in Gtk 2 is shown as a solid blue bar with width proportional to the value that covers the widget from top to bottom. In Gtk 3 the solid blue bar is replaced by a thin blue bar at the bottom of the widget. As far as I can tell, the Gimp version of the slider makes three changes: 1. It allows for a label inside the widget. This is a nice space saving feature. The widget handles changing the label text from black to white as the progress bar moves across the label. 2. It allows for a non-uniform scale by adding a "gamma" factor. 3. It adds the ability to drag the progress bar to change the value. If one drags from the top (down arrow cursor) the change follows the cursor directly. If one drags along the bottom half (double headed cursor) the change is finer and relative to the current value. I've always found that dragging the progress bar to be a bit awkward. One problem is that one can not start the drag at the far right of the widget as that area is reserved for typing a value directly in. Also, the different functionality of starting the drag in the top of the widget vs. the bottom of the widget is confusing. Since I am rewriting this widget, I can adjust it to what people want: * Do you want the progress bar? * If so, should it be the full height of the widget (quite a bit more complicated)? * Do you want to be able to drag the bar? With one/two methods? * Any other changes? Thanks, Tav

5 8

Re: [Inkscape-user] [Inkscape-devel] Spin slider widget: Opinions needed!
by Tavmjong Bah 04 Dec '17

04 Dec '17

On Mon, 2017-12-04 at 14:43 +0100, Eduard Braun wrote: > Hi Tav, > > thanks for looking into this! > > One question to get on the same page: > > This is about sliders like "Blur" and "Opacity" (which are re- > used > in some other places, too), right? However the actual color > sliders in the Fill and Stroke dialog are not affected? Yes... > Some thoughts from my side: > > > The "top part" dragging is very useful, we should have that. > > The "bottom part" dragging never felt quite right for me and > was > actually very confusing when I first started using Inkscape, > so > personally I'd be fine with dropping that. OK. That should be easy to do. > Having text and the spinner inside the widget is nice as it > saves a lot of space and creates a clean UI control that is > immediately recognizable as such (in contrast to multiple > controls loosely packed into a box with each other). > > If it's implementable with reasonable effort it's probably > good > to keep it, especially for locations where there is not much > room for an additional label and spinner (e.g. in the toolbar > of > the various tools that use the widget). It's not too hard (already done in my toy implementation). > The previous bullet point is only true if it's done right - > thanks to gtk3's wasteful use of screen space I'd consider > most > spinners in the toolbar broken right now (the label is > usually > hidden behind an ellipsis; due to the two huge buttons which > are > now placed side-by-side the usable width decreases even more, > so > we either need a more economic solution or need to rethink > the > use of spin sliders in the toolbar fundamentally. One can narrow the +/- buttons via CSS ( ,up, .down { padding:0; } ). I'll probably check this in (actually I'll probably set it to 2px, default is 8px). > > One performance consideration that might be worth to > have in mind when doing the rewrite: > > For some reason the custom spinner widget has > a much worse redraw performance than other spinner > implementations (e.g. the ones in the color selector): > > If I change opacity of an object the widget > only updates a few times per second and is redrawn with a > delay (canvas reflects the current value properly though). > In > contrast if I change the fill opacity of the same object > this > spinner widget redraws without noticeable delay. > > (strike that part - it only seems to affect the gtk2 build > and I > assume you won't backport this to 0.92.x) No, I won't be touching 0.92.x with this. > > TLDR: I kind of like the spin sliders like they are now for > "Blur"/"Opacity" (and could do without the bottom part > sliding), > however they waste too much space to be useful in toolbars > right > now. > > > Best Regards, > > Eduard > > > > > Am 04.12.2017 um 13:42 schrieb Tavmjong > Bah: > > > > > Hi, > > > > I've been looking into replacing the Gimp Spin Slider widget (e.g > > Blur/Opacity in the Fill and Stroke dialog). The widget is licensed > > under GPLv3 and is the only reason Inkscape as a whole is licensed > > under GPLv3 rather GPLv2.. The board sometime ago agree that being > > a > > GPLv2 program was desirable (I don't remember the exact reasoning). > > > > A normal Gtk Spin Slider (aka Gtk::SpinButton) has an option to > > show > > the "progress" of slider, that is the percentage (defined in some > > arbitrary way) between a minimum and maximum value. This in Gtk 2 > > is > > shown as a solid blue bar with width proportional to the value that > > covers the widget from top to bottom. In Gtk 3 the solid blue bar > > is > > replaced by a thin blue bar at the bottom of the widget. > > > > As far as I can tell, the Gimp version of the slider makes three > > changes: > > > > 1. It allows for a label inside the widget. This is a nice space > > saving > > feature. The widget handles changing the label text from black to > > white > > as the progress bar moves across the label. > > > > 2. It allows for a non-uniform scale by adding a "gamma" factor. > > > > 3. It adds the ability to drag the progress bar to change the > > value. If > > one drags from the top (down arrow cursor) the change follows the > > cursor directly. If one drags along the bottom half (double headed > > cursor) the change is finer and relative to the current value. > > > > I've always found that dragging the progress bar to be a bit > > awkward. > > One problem is that one can not start the drag at the far right of > > the > > widget as that area is reserved for typing a value directly in. > > Also, > > the different functionality of starting the drag in the top of the > > widget vs. the bottom of the widget is confusing. > > > > Since I am rewriting this widget, I can adjust it to what people > > want: > > > > * Do you want the progress bar? > > > > * If so, should it be the full height of the widget (quite a bit > > more > > complicated)? > > > > * Do you want to be able to drag the bar? With one/two methods? > > > > * Any other changes? > > > > Thanks, > > > > Tav > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > > ------------- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > > > >

1 0

volunteer moderators needed
by brynn 28 Nov '17

28 Nov '17

Hi Friends, If anyone is interested, we still need more moderators for the website gallery. It doesn't usually take very much time. I'd estimate no more than a half an hour per week. (Preferably spread out 5 or 10 minutes each for 3 or 4 days per week. But at this point, once a week would help.) And Martin has built us a wonderful system where the burden of deleting an image or removing member doesn't fall all on one person. Typically it takes 2 moderators to decide the fate of a reported image or member. If interested, please visit this page, (https://inkscape.org/en/*moderators) and click the button which I think says something like "Join this team." After that, I'll contact you with details to get you started. All best, brynn

1 0

powerstroke on closed path bug?
by brynn 14 Nov '17

14 Nov '17

Hi Friends, I've seen a few times where applying Powerstroke LPE to a closed path not only doesn't work, but creates some strange results. This includes using the Triangle In/Out for Pencil and Pen, as well as applying it separately to a path. I thought it surely must be already reported as a bug, but I can't seem to find any reports. It could have a title with some technical words that I don't understand. I just want to make sure it's not going to be a duplicate if I report it. Is anyone aware of this being reported as a bug before, or knows which bug report it is? Or is this just such a known issue, that we don't expect it should work? Here's a test file: https://inkscapecommunity.com/jd/imgs/psclosed.svg Just add a powerstroke to that closed path. (Windows 7, 64-bit, Inkscape 0.92.2, 64-bit, 7z). Thanks, brynn

1 0

Inkscape.SNAP Snappy package do not export dxf files
by Luis Vasquez 08 Nov '17

08 Nov '17

Hi, i installed inkscape snap package and i can not export files to dxf. Some plugins are not installed numpy Failed to import the numpy or numpy.linalg modules. These modules are required by this extension. Please install them and try again.

2 2

Meeting - Inkscape Vectors
by Ryan Gorley 03 Nov '17

03 Nov '17

The Inkscape Vectors will be meeting a couple hours before the board meeting. Catch the agenda, time and location details here: https://gitlab.com/inkscape/inkscape-vectors/general/issues/21 (https://gitlab.com/inkscape/inkscape-vectors/general/issues/21) All are welcome. We hope you'll join us! -- Ryan Gorley Founder + Creative Director https://dijt.co (https://dijt.co)

1 1

Symbol edition and reuse
by Xaviju Julián 22 Oct '17

22 Oct '17

Hi, As suggested in the new features section I'd like to see the community opinion on a possible feature suggestion. As a heavy user of the symbols feature for web design I tend to save many UI portions of my design as symbols and reuse them across many different documents. Sometimes I need to edit one of those symbols and I'd like all documents that are referencing that symbol to update. Same behavior as when I update the original symbol SVG code, all references will keep using that symbol, but updated. Right now, the only way I found the inkscape UI has to edit a symbol is to `unplug` (sorry don't know the english word) it from its reference, but that does not allow me to reuse and update. Do this make sense to you? Am I missing something? Thanks, Xavi

3 2

misunderstood tiled clones issue
by brynn 08 Oct '17

08 Oct '17

Hi Friends, Someone recently has posted in a forum, asking why the first array created by Tiled Clones dialog is deleted, when the 2nd array is created (using the same parent object). http://www.inkscapeforum.com/viewtopic.php?f=5&t=33037 Because this is what I previously understood the Remove button is supposed to do, I thought it must be a bug. However searching LP has not turned up any existing bug report (not unless its title contains technical language that I don't understand, or that doesn't really describe the issue). I'm on Windows, but other operating systems are represented in the forum topic. I tested going back to version 0.47.3, and the same behavior is seen there. So since it seems to be long standing, and not reported, I have to think it's either intended behavior, or at least not a bug. Oh interesting! It seems the first array is deleted /whenever/ a 2nd array is created with the same parent (not just when the 2nd array immediately follows the first)! Because I did this (with all default settings): 1 - Object A: 2 x 2 array 2 - Move all the clones away from the array area (to easily notice that they are deleted when the 2nd array is created, and not just covered up by the 2nd array). 3 - Object B: 3 x 3 array 4 - Object A: 4 x 4 array -- This removes all the clones from the 2 x 2 array of object A; leaves the 3 x 3 array of object B alone, and creates the new 4 x 4 array of object A. If there's a reason for this, could someone explain, in a not too technical way? Thank you very much, brynn

1 0

Re: [Inkscape-user] [Inkscape-devel] the Scale setting and Display units
by brynn 27 Sep '17

27 Sep '17

Sorry I was unavailable for all this discussion the last couple of days. (just a bit out of sorts) I completely understand that everyone has different preferences for whatever project they use Inkscape to accomplish. I would say that as far as Inkscape is concerned, none should be considered better or more preferred than the other. I think it would be a mistake to force one or more user groups to always change their docs, or make their own special templates, just so that one or more other user groups can have convenience. Especially with this new system which is so confusing for many users. Inkscape should be made usable, equally as possible, for all user groups. The bottom line (at least for me) is that there is no way to satisfy everyones needs at the same time. What is needed is a simple way for users to choose and set their desired units, no matter which kind of document or template they want. Before 0.92, it was very, very simple, and easy to understand and easy to use. Now, it is not. If there is some reason related to Inkscape's being able to function at all, where mm Must be the default units, then please make Inkscape do all the work, so that the user only has to click once to change their units (as before). (Make Scaling silent.) However, I think it would be better to go back to the traditional system of px for the user units, where if a user wants to change their units, they just have to click once. > So it would be very nice to have px as the default template and let our users change units in the display as desired without any concerns regarding scale. Ditto! As a footnote, this is one of the many issues we are seeing with users not understanding the scale (it's an old topic where a new message was posted, starting here) http://www.inkscapeforum.com/viewtopic.php?f=5&t=17182#p101060 Here, it seems setting the wrong scale is exaggerating the expected deformations of paths when using offsets. All best, brynn PS - I made the wishlist report, for what it's worth: https://bugs.launchpad.net/inkscape/+bug/1719162 -----Original Message----- From: TylerDurden Sent: Saturday, September 23, 2017 9:46 PM To: inkscape-devel(a)lists.sourceforge.net Subject: Re: [Inkscape-devel] [Inkscape-user] the Scale setting and Display units >>[Luca] I ask again: is this just a template issue? << Yes, I also think so. I currently instruct all my Inkscape students at the local makerspace to create a custom default template with units=px and scale=1. Slide from the class: https://dl.dropbox.com/s/8ydap6q59dtne1i/Inkscape_Class_101-Default.png At the makerspace we regularly use px, imperial and metric; and output from Inkscape for print, CNC, laser, game design, web, CAD, and on, and on... So it would be very nice to have px as the default template and let our users change units in the display as desired without any concerns regarding scale. Thanks, TD -- Sent from: http://inkscape.13.x6.nabble.com/Inkscape-Dev-f2781808.html ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

3 5

Inkscape 0.92.2 not building
by Alice Wonder 26 Sep '17

26 Sep '17

I hope this isn't better suited for the devel list, but I'm not an Inkscape developer. Trying to build Inkscape 0.92.2 and it seems to not like ImageMagick 7.0.7 patch 4 (the current) The build error: make[2]: *** [src/CMakeFiles/inkscape_base.dir/extension/internal/bitmap/channel.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs.... /builddir/build/BUILD/inkscape-0.92.2/src/extension/internal/bitmap/crop.cpp: In member function 'virtual void Inkscape::Extension::Internal::Bitmap::Crop::applyEffect(Magick::Image*)': /builddir/build/BUILD/inkscape-0.92.2/src/extension/internal/bitmap/crop.cpp:27:78: error: no matching function for call to 'Magick::Geometry::Geometry(int&, int&, int&, int&, bool, bool)' image->crop(Magick::Geometry(width, height, _left, _top, false, false)); ^ /builddir/build/BUILD/inkscape-0.92.2/src/extension/internal/bitmap/crop.cpp:27:78: note: candidates are: In file included from /usr/include/ImageMagick-7/Magick++/Drawable.h:28:0, from /usr/include/ImageMagick-7/Magick++/Image.h:17, from /usr/include/ImageMagick-7/Magick++.h:12, from /builddir/build/BUILD/inkscape-0.92.2/src/extension/internal/bitmap/crop.cpp:15: /usr/include/ImageMagick-7/Magick++/Geometry.h:119:5: note: Magick::Geometry::Geometry(const RectangleInfo&) Geometry(const MagickCore::RectangleInfo &rectangle_); ^ /usr/include/ImageMagick-7/Magick++/Geometry.h:119:5: note: candidate expects 1 argument, 6 provided /usr/include/ImageMagick-7/Magick++/Geometry.h:52:5: note: Magick::Geometry::Geometry(size_t, size_t, ssize_t, ssize_t) Geometry(size_t width_,size_t height_,::ssize_t xOff_=0, ^ /usr/include/ImageMagick-7/Magick++/Geometry.h:52:5: note: candidate expects 4 arguments, 6 provided /usr/include/ImageMagick-7/Magick++/Geometry.h:49:5: note: Magick::Geometry::Geometry(const string&) Geometry(const std::string &geometry_); ^ /usr/include/ImageMagick-7/Magick++/Geometry.h:49:5: note: candidate expects 1 argument, 6 provided /usr/include/ImageMagick-7/Magick++/Geometry.h:46:5: note: Magick::Geometry::Geometry(const Magick::Geometry&) Geometry(const Geometry &geometry_); ^ /usr/include/ImageMagick-7/Magick++/Geometry.h:46:5: note: candidate expects 1 argument, 6 provided /usr/include/ImageMagick-7/Magick++/Geometry.h:43:5: note: Magick::Geometry::Geometry(const char*) Geometry(const char *geometry_); ^ /usr/include/ImageMagick-7/Magick++/Geometry.h:43:5: note: candidate expects 1 argument, 6 provided /usr/include/ImageMagick-7/Magick++/Geometry.h:40:5: note: Magick::Geometry::Geometry() Geometry(); ^ /usr/include/ImageMagick-7/Magick++/Geometry.h:40:5: note: candidate expects 0 arguments, 6 provided make[2]: *** [src/CMakeFiles/inkscape_base.dir/extension/internal/bitmap/crop.cpp.o] Error 1 make[2]: Leaving directory `/builddir/build/BUILD/inkscape-0.92.2' make[1]: *** [src/CMakeFiles/inkscape_base.dir/all] Error 2 make[1]: Leaving directory `/builddir/build/BUILD/inkscape-0.92.2' make: *** [all] Error 2 Any ideas?

2 2

the Scale setting and Display units
by brynn 26 Sep '17

26 Sep '17

Hi Friends, Sending up a signal flare from the not-so-technially-inclined user community. Please either explain the Scale setting and how users can easily change the Display units; or fix the UX so we can use it. Thank you so very much, brynn

5 14

Re: [Inkscape-user] [Inkscape-docs] UX team?
by brynn 24 Sep '17

24 Sep '17

Oh! (Copying over to dev and user lists.) There are so very many people interested in working on the UX (I seem to recall several people had been signed up -- it's hard to believe not one of them would volunteer for this simple task. If "the team's business" means writing the intro, Team Details and Charter, I can do that. What other business might there be? (Even though I'm leading the Moderators Team, I suspect the "business" is probably different.) If it requires a lot of work, let's put it up on the To-Do List page, to try to recruit someone. But what kind of business is it? Thanks, brynn -----Original Message----- From: Martin Owens Sent: Wednesday, September 20, 2017 7:25 AM To: brynn ; Inkscape-Docs Subject: Re: [Inkscape-docs] UX team? On Wed, 2017-09-20 at 06:42 -0600, brynn wrote: > Hi Friends, > I just noticed there is no UX team showing on the Teams page > (https://inkscape.org/en/teams/). I could have sworn I saw one > there, not too > long ago (couple of months maybe). I think it had several members. > > What happened with that? The UI team is currently hidden as it's TODO introduction and lack of leadership made it hard to justify keeping it visible. So what it needs is someone with a passion, preferably a UX person, who can say that even if it's just a team of one, that they will handle the team's business. Best Regards, Martin Owens

5 5

Fwd: open-draw-community.de
by Arlo Barnes 23 Sep '17

23 Sep '17

I had the notion of resurrecting it but was not able to invest as much attention as I had anticipated to get PHPbb up and running. The domain name will expire October 12*th*, so I can transfer to anyone willing to pay for hosting or at least just renewal to prevent it turning to spam. I am using Register4Less for both the domain and hosting and have a referral code that I think will reduce the cost of transfer. Of course if one wants to host with Gandi or wherever that is fine too (just not GoDaddy! :P). Thanks, —Arlo James Barnes

1 0

Re: [Inkscape-user] the Scale setting and Display units
by Tyler Durden 21 Sep '17

21 Sep '17

Greetings all, A universal default.svg with units px and scale=1 provides a simple single solution to a number of issues: - Resolves broken extensions and features like symbols and outset/inset, etc. - No need for users to consider scale, they just set the display units and work. - No need to tailor localizations with in/96, mm/3.77953. - Fewer bug reports for scale and localization issues. - Neophytes are less likely to abandon Inkscape as confusing or complicated. That's a lot of benefit, for what could be relatively little effort. Like with any graphics or CAD application, users should be familiar with setting document units when starting to work. This is the most basic of best-practices. Even making a template is not difficult, but a button/tool to save the current document as a template would be very handy. Regards, TD

1 0

Re: [Inkscape-user] [Inkscape-devel] the Scale setting and Display units
by Ryan Gorley 21 Sep '17

21 Sep '17

Since it's now America first maybe we should use 8.5 inches by 11 inches as the default. :P Sarcasm aside, I do find it mildly annoying to have to go into the Document Properties every time I load an instance of Inkscape to change it (almost always to pixels). I know this can be changed in the config directory, but being able to change the default page size and units in the GUI seems like a reasonable feature. Alternatively (or additionally) presenting the Document Properties dialog on startup is the way many graphics applications handle this. I doubt we'll find any size/unit combo that makes everyone happy. *Ryan Gorley* Managing Partner | Dijt <https://dijt.co> On Thu, Sep 21, 2017 at 9:59 AM, Eduard Braun <eduard.braun2@...26...> wrote: > Am 21.09.2017 um 13:14 schrieb LucaDC: > >> Eduard Braun wrote >> >>> Hehe, we're back to the question "what is one pixel" and as far as >>> Inkscape (since 0.92) is concerned 1 px is 1/96 inch, so it is a real >>> world size and this pixel size in fact *is* the standard pixel size >>> according to CSS2. Y'all should really read Mc's posts on units. ;-). >>> >> If this sentence was as strong as it tries to appear, the transition from >> 90 >> dpi to 96 dpi would have been a lot less painful. Oh, sorry, I was wrong: >> the transition wouldn't even had been necessary! >> >> "Pixel" is not listed in The International System of Units (SI), where mm >> is >> (well, m of which it's a power: >> http://www.bipm.org/en/measurement-units/base-units.html). So you can't >> say >> that the definitions of pixel and mm have comparable weights and scopes. >> 1 mm is 1 mm. Full stop. >> I agree that today a pixel can be related to a real world size unit (1/96 >> of >> an Inch), but yesterday it wasn't so who can guarantee that tomorrow it >> will >> still be? >> SI units are there not to suffer of this uncertainty so that's what I call >> _real_world_units_, not something that can be changed to fit the needs of >> a >> so quickly evolving technology. >> > I don't disagree with you, a meter (why are we using mm? ;-) ) is > certainly a better measure of length than the pixel. However - while I'm an > advocate of SI myself - it's certainly not the only measure and needs are > different. Just because *you* prefer the meter does not mean other people > work the same way. You only want to offer SI units? Great! Let's drop > inches and point, too! A user wants to design a screenshot for their full > HD screen? Let's tell them to make their document 1920x1080 mm² because "1 > mm will always be 1 mm" (no wait... because the px is flawed they're > probably out of luck anyway - or should they measure their screen with a > ruler... I'm confused ;-) ) > Maybe you're right and with high DPI screens becoming more and more > popular it's time to say goodbye to pixel units for most content. But for > now they still have their uses and it's not for us to decide! If an > application complicates certain usage scenarios on purpose it's bound to > upset some people and leaves a bad impression behind. I don't want that. > > At the very least I think we need a possibility to select the default > template via UI (I even opened a bug about that some time ago: > https://bugs.launchpad.net/inkscape/+bug/1673608) so users can make a > choice on their own without too much hassle. > > Eduard Braun wrote >> >>> personally I'd feeld a lot safer to use a px-based (unscaled) SVG as a >>> base for production than to rely on some SVG with millimeters as user >>> units that Inkscape currently implements via a viewBox scaling of the >>> whole SVG (which broke a lot of our export extensions and might just as >>> well confuse import filters in other software). >>> >> If I get this sentence right, it makes me feel you've not completely >> understood how a (current) mm document is made. What could be >> misunderstood >> in a document where mm is the unit, the page is 297x210 and you have an >> object with dimensions 10x10? Actually I can't see any "viewBox scaling of >> the whole SVG" here, unless that's how you call the viewBox function >> itself. >> Perhaps you're making a bit of confusion between px as 1/96 of an inch (as >> we've been talking up to now) and px as user-unit (as per SVG >> specifications): a user-unit is not (necessarily) 1/96 of an Inch, and >> that's what the viewBox is for: nothing strange or outside SVG >> specifications here so broken extensions or import filters are simply >> buggy. >> And as far as Inkscape (since 0.92) is concerned 1 px (in the SVG sense, >> i.e. user-unit) is not always 1/90 or 1/96 inch anymore. At last. >> > You don't have to lecture me, I'm quite familiar with what we do > internally. > > The problem is not so much the correctness of the SVG (I don't argue with > that) but what other software makes of it. And while you're absolutely > right that software not properly handling the viewBox attribute should be > considered broken, it does not help our users. Do you want to tell them > "hey, Inkscape is doing everything right, here, look in the cryptic > specification users should never have to care about and see for yourself > we're not to blame?" That won't help them at all... > > Also the length of this thread shows how "good a job" we're doing at > hiding all those internals from the user and giving them something they can > easily work with, regardless of their specific application. > > Regards, > Eduard > > > Luca >> >> >> >> >> -- >> Sent from: http://inkscape.13.x6.nabble.com/Inkscape-Dev-f2781808.html >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel >> > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

1 0

Re: [Inkscape-user] the Scale setting and Display units
by Tyler Durden 21 Sep '17

21 Sep '17

Greetings. A suggestion from the peanut gallery... 1) All future releases have default.svg with the display units set for px, scale= 1uu/px 2) Move the scale controls to another tab in the Document Properties panel, with language to describe function. 3) Expose the "Set page to drawing or selection" toolset (which is often overlooked by new and veteran users) on the Page tab of the Document properties panel. Mockup of modified Document properties panel: https://dl.dropbox.com/s/zfz9yetclfy1m21/mockup1.png (also attached in case this board allows) The above changes should alleviate most of the confusion and retain the controls for scale. Typical users needn't be concerned with scale and its complicated workings. Thank you for your time and consideration, TD

10 18

Re: [Inkscape-user] the Scale setting and Display units
by Jabier Arraiza 20 Sep '17

20 Sep '17

Hi. The display unit in mm is a good option for printing and anybody can change using a template or modifing the default one. Maybe a prompt when change display units to retain current scale could be a good option, I always need to change to previous scale (normaly 1.00) once change to display_units. Also I add a option to resize to content, what I retain collapsed by default, to make the same value in 4 inputs. Regards, Jabier.

1 0

Linebreacks: last and first word of lines are melting together
by Onsemeliot 10 Sep '17

10 Sep '17

I wonder if others experience the same behaviour: I created a folder layout where I put the front and the back pages on separate layers. I use text boxes with justified text and adapted the letter-space in some lines in order to get more or less uniform text blocks. This seems to work fine on first glance. Unfortunately after saving and opening the file again I end up with some lines where the last word of the previous line fuses with the first word of the next line. This of course messes up my line breaks. I can easily "repair" this by inserting a space between those two words again but I have to look very carefully to not miss any instance each time I open my file for editing. So far I couldn't figure out when exactly this happens. It could be random but I suspect it happens when two lines with letter spacing definitions follow after another. But it doesn't happen always to the same lines. I guess when saving and opening the XML code of the file gets interpreted slightly different resulting in losing the space between some words belonging to two different blocks of letter spacing. Maybe it only occurs if both blocks do have the same value. I imagine there is a clean-up that removes unnecessary tags losing spaces on the way. I use Inkscape 0.92.1 r15371 on Debian GNU/Linux 9 (stretch) 64-bit with standard GNOME 3 on a Technoethical T400s (which in fact is a refurbished Lenovo T400s with Libreboot). Thank you for any feedback, Onsemeliot

4 3

Convert textPath to rotated text
by Joel C. Salomon 07 Sep '17

07 Sep '17

Neighbors, I have in an e-book a title page formatted with SVG, using <textPath> to place text along a curve. To reduce the picture to a minimum example, consider curvetext.svg: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" viewBox="0 0 160 256" width="160" height="256"> <g style="text-align:center;text-anchor:middle;stroke:none;"> <path style="fill:none;" d="m 0,72 c 32,-16 52,-20 80,-20 28,0 48,4 80,20" id="path-upper" /> <text style="font-size:9px;" ><textPath xlink:href="#path-upper" startOffset="50%"><tspan >Text to be Placed Along a Curve</tspan></textPath></text> </g> </svg> Trouble is, Kindle (among other platforms) doesn’t support <textPath> in SVG. I can generate a raster image, but that’s no fun. But experimenting with various formats suggests this: $ inkscape -A curvetext.pdf --export-ignore-filters curvetext.svg $ inkscape -l curvetext2.svg curvetext.pdf And it works, generating lines like <text transform="matrix(0.94068351,0.33928532,0.33928532,-0.94068351,17.864857,145.9156)"><tspan y="0" x="0">T</tspan></text> <text transform="matrix(0.94997891,0.31231406,0.31231406,-0.94997891,20.665461,146.93493)"><tspan y="0" x="0">e</tspan></text> <text transform="matrix(0.96048875,0.27831882,0.27831882,-0.96048875,24.497618,148.19598)"><tspan y="0" x="0">x</tspan></text> <text transform="matrix(0.96875188,0.24803186,0.24803186,-0.96875188,28.337099,149.29823)"><tspan y="0" x="0">t</tspan></text> Well, the result actually includes a bunch of other boilerplate that Inkscape likes to add to SVGs (some of which I’ve removed for clarity in the example above), and also it adds a global transform matrix, <g transform="matrix(1.3333333,0,0,-1.3333333,0,256)"> around everything and the result is generally odd-looking code. And maybe I should just let Inkscape do its thing and not worry about this. But what I’d really like is to compile down ›just‹ the <textPath> code, and have it yield something anchored around where the text actually appears on the page (maybe the start of the <path> at (0,72), or the midpoint at (80,52), or something plausible). Is what I’m looking for at all reasonable, and is there some way to accomplish this with Inkscape? (I’m prepared to hear “no” to both parts of my question.) ––Joel C. Salomon

2 2

Re: [Inkscape-user] Pencil pressure
by Jabier Arraiza 29 Aug '17

29 Aug '17

> Wow ! This feature brings discoverable and quick access to Power > Strokes, really awesome enhancement, it will be very useful! > > Thanks Jabier for the really quick integration and Nate for the > suggestion. This is a great FLOSS collaboration example ! :) > > Victor Thanks so much for the feedback!

1 0