About knots selection
by Antonio Ospite
Hi,
I was looking into fixing
https://bugs.launchpad.net/inkscape/+bug/1707919 and, after compiling a
recent Inkscape version I noticed that the behavior of knot changed wrt.
selection and dragging compared to 0.92.x.
After some research on the mailing list I found the change mentioned
here:
https://inkscape.org/en/news/2017/07/12/what-happened-hackfest-2017/
I can see the benefit of keeping knots selected to be able to move
them with the keyboard but I still find the new behavior a little
unintuitive, at lest for shape editing:
1. The colors of the mouse-over and selected states are the same,
maybe the coloring scheme of node paths can be copied: where
mouse-over color is different from the selected and dragging colors
which are the same.
2. Previously selected knots look still selected when _another_ knot
is dragged without pressing Shift.
Steps to replicate:
1. Change size of a rect using one corner.
2. Then change the size using the opposite corner.
The firs corner looks still selected.
3. Shift-click does not really select arc knots for ellipses, or
rounding knots for rects, because this action is already used for
something else, e.g. to close the arc instead.
Would it be possible to use Ctrl-Shift-click for the current
function and leave Shift-click for the normal select behavior?
IMHO this would be more consistent.
4. Dragging with the mouse only affects the last selected knot, even
if multiple ones are selected, but this is not a big deal, the
behavior is different compared to path nodes, but both make sense
IMHO.
I'll resume working on https://bugs.launchpad.net/inkscape/+bug/1707919
after the details from above are sorted out, to avoid overlapping
problems.
Thanks,
Antonio
P.S.
When verifying 1. I also noticed that path nodes change their size when
clicked the _first_time_ but then get smaller again if the object
is unselected and re-selected; however this is unrelated to the message
above, I'll file a separate bug report for that if it can considered a
bug, what do you think?
--
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
4 years, 5 months
Problems building on Ubuntu 16.04
by mathog
Upgraded the Ubuntu 14.04 system which had endless build problems to
Ubuntu 16.04.
It doesn't seem to like 16.04 much better. Different problems, but
still problems.
Cleaned out the build directory and did:
cmake ..
which failed at
...
WITH_OPENMP: ON
WITH_PROFILING: OFF
WITH_YAML: OFF
------------------------------------------------------------------------
CMake Error: The following variables are used in this project, but they
are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the
CMake files:
POPPLER_INCLUDE_DIR
used as include directory in directory /usr/local/src/inkscape_trunk
used as include directory in directory /usr/local/src/inkscape_trunk
used as include directory in directory /usr/local/src/inkscape_trunk
used as include directory in directory /usr/local/src/inkscape_trunk
<SNIP many lines>
-- Configuring incomplete, errors occurred!
See also
"/usr/local/src/inkscape_trunk/build/CMakeFiles/CMakeOutput.log".
This is at revision 15617. These poppler pieces are present
ii gir1.2-poppler-0.18 0.41.0-0ubuntu1
ii libpoppler-dev:i386 0.41.0-0ubuntu1
ii libpoppler-glib-dev 0.41.0-0ubuntu1
rc libpoppler-glib4 0.12.4-0ubuntu5.2
ii libpoppler-glib8:i386 0.41.0-0ubuntu1
rc libpoppler19:i386 0.18.4-1ubuntu3.1
rc libpoppler44:i386 0.24.5-2ubuntu4.4
rc libpoppler5 0.12.4-0ubuntu5.2
ii libpoppler58:i386 0.41.0-0ubuntu1
ii poppler-utils 0.41.0-0ubuntu1
What needs to be tweaked to make this work?
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
4 years, 11 months
slow, sluggish drawing with pencil & calligraphy tool solved
by Yale Zhang
Hi, I've identified why drawing is lagging with GTK+3.
https://bugs.launchpad.net/inkscape/+bug/1723247
It's because of GTK3's motion event compression:
https://bugzilla.gnome.org/show_bug.cgi?id=702392
Adding a * gdk_window_set_event_compression (window, FALSE);* in
SPCanvas::handle_realize() makes things much smoother.
At 1st I thought it was because the events were sitting in the queue for
too long. So I added some timing code to measure the latency between when a
motion event was generated in GDK to when SPCanvas::paint() is called.
Actually, I detect bursts of mouse moves or redraws and only use the 1st
for latency measurements since there might not be a 1 to 1 relation between
motion events and redraws. I was seeing a 4 to 10ms latency for head (GTK3)
but only 0.5 ms for 0.92 (GTK2).
I thought I was on to something, but this mislead me for a while. Finally,
I saw that the # motion events and redraws were 10x higher for GTK2.
I haven't stayed up to date with the GitLab migration. I tried to push a
patch to my branch simdgenius_inkscape, migrated from Bazaar, but access is
denied. I just requested project access, so appreciate it if someone grants
it.
-Yale
4 years, 11 months
Roadmap 1.0
by Bryce Harrington
One of the items scheduled for today was a review of the roadmap,
looking both at the next development release, and the path to releasing
1.0.
With the change to gtk3, we anticipate there may be some behavioral or
functional changes that users may not find desireable, but that we may
not discover until the release gets into widespread use, so it has been
our plan to message this development release (which we have referred to
as 0.93) as more "experimental" than 0.92, and continue releases on the
0.92.x series for them.
Even with this messaging, though, we worry that distributors of our
software may push 0.93 as the latest release, and fail to adequately
provide the 0.92.x series to users that wish to maximize stability.
So, one idea discussed today would refer to this development
release not as "inkscape 0.93" but as either "inkscape 1.0~alpha" or
"inkscape 1.0~pre0", and treat it not as a regular release but as an
alpha release for 1.0. From there we could conduct multiple further
pre-releases building towards a 1.0 release in, say, a 1-year timeframe.
What do you think of this change in versioning nomenclature?
Regardless of how we version the releases, there was a concensus among
attendees to sharpen our focus towards achieving the 1.0 release
expediously, prioritizing stabilization, testing, and documentation
efforts. Apart from a limited set of development tasks targeted for
1.0, most development would be strongly encouraged to be done in
branches with merge deferred to post-1.0.
As requested at the hackfest, I'll take the action to itemize a listing
of tests needing written or ported from the old test system, and
divvying them out to currently active developers willing to take care of
them.
For development work that does target landing in 1.0, we would require
or at least urge the work be done in a manner that permits disabling or
reverting it if testing finds it to be insufficiently stable.
I am pretty open as to what we call the pre-1.0 releases, and would like
to gather more people's thoughts before deciding a path forward. So,
how does this plan sound to you?
Bryce
4 years, 11 months
Hackfest 2018: Actions and Toolbars
by Alex Valavanis
Hi All,
Here's a summary of my work at the Boston Hackfest.
Before I continue, I'd like to thank everyone who donated their money or
time to support this Hackfest. This has been a really useful event - it's
so much easier to deal with tricky design challenges and project management
stuff when we can meet face to face. It has also brought together people
with very diverse expertise across the project (UI, web, build, extensions,
project management etc). This week, we've figured out a path to deliver
long desired features (multipage support etc), roadmapped our final route
to deliver Inkscape 1.0, done some great website design work, and handled
some tricky code structure issues that I'll discuss in this message.
If you're able to donate some money to support Inkscape, and future
Hackfests, we really appreciate this. You can find the donation link on
our website: https://inkscape.org/en/support-us/hackfests/
It would also be great to get some more of the regular contributors from
our wider community to join us at future events (i.e., designers, bug-team,
experienced users... not just C++ developers!). The developers can learn
so much more about the project by discussing it with you.
So... what have I been doing this week?
== What are Actions? ==
Basically, an "action" is a thing that Inkscape can do (e.g., flip an
object horizontally), which we can identify using an ID code (e.g.,
"SP_VERB_OBJECT_FLIP_HORIZONTAL"). We can then hook up buttons, menu items
etc to activate these actions. In this example, we would set up our Flip
Horizontal button in the select-tool toolbar so that when the user clicks
it, it activates the required action.
My work this week has focused on improving the way we implement actions in
our code, which will
1. Allow Inkscape to run on machines with future versions of the Gtk+
library (Gtk 4+)
2. Provide much better separation between the behaviour and user
interface (i.e.,, separate pieces of the code will describe what Inkscape
"does", and what it "looks like")
3. Make it much easier to create new "flavours" of the Inkscape user
interface - for example, an "Inkscape for Kids" or "Inkscape CAD"
4. Make it easier for "non-programmers" to create and reorganise custom
toolbars and dialogs
5. Allow us to remove a lot of older "C" code that is very difficult for
current "C++" developers to maintain
== Where we are now? ==
In the Inkscape code, we have a mechanism called "verbs" that acts as a
kind of action mechanism... it provides a way of using an ID code to look
up the required commands to perform an action.
On top of this, we have another structure called SPAction that essentially
hooks up a couple of signals to the verb.
Finally(ish), we use objects called GtkActions from the Gtk+ library, which
let us create GUI elements (buttons etc) that we can add to our menus or
toolbars that activate the required action.
We have also got a few custom sub-classes of GtkAction that let us create
special kinds of tool-item that can activate actions... for example, one of
these creates a spin-button (a box with a number in it, and "up/down"
arrows) that can also handle units, basic arithmetic, and provides a label.
== What's the problem? ==
First, the GtkAction widget (and hence all our custom sub-classes) is
deprecated and has been removed from Gtk+ 4, so we need to change. Since
Inkscape 1.0 is intended as a "stable" release, we want to make it as
future-proof as possible.
The main reason for this deprecation is that the GtkAction widget is a
slightly weird mix of paradigms: it mixes information about how to display
a tool/menu item with information about behaviour. This causes some
problems... what if we wanted to run a "headless" Inkscape on a system that
has no display? What if we wanted to provide several different GUI options
for different kinds of user to trigger the same behaviour?
This is one of the reasons why we have the "verbs" system is in place, as
it separates behaviour from the GUI. However, there is still quite a lot
of code "overhead" needed if we want to hook up Inkscape's Verb behaviour
to a GUI element. Essentially, it's "programmers only" territory. What if
a designer wanted to add a new toolbar button to their Inkscape to handle a
useful feature that is currently buried deep in a menu? What if a teacher
wanted to strip out a lot of "advanced" behaviour from the interface to
make it easier to introduce Inkscape to their class? At the moment, they
have to edit the C++ code, and recompile it... a slow and complicated
process!
== Where are we going? ==
We need to move to using GActions (a feature in the Glib/GIO library).
This *only* describes the action's behaviour and provides an "activated"
signal that we can trigger by simply knowing the action's name. This is
completely separated from the GUI. These actions can be activated very
easily from a whole range of places, for example:
1. By attaching the action's name to a GUI element in the C++ code
(replacing our SPAction/GtkAction code)
2. By activating the action (using its name) from a command-line
interface (replacing some of our verbs code)
3. By attaching the action's name to elements in a customised GUI file
4. From external applications, using the DBus system
Number 3 in the list provides some very exciting opportunities for future
releases, as non-programmers will be able to make a customised user
interface by drawing one in the Glade application. You then just attach
the name of the required Inkscape action to each GUI element. Want a new
button? Just edit Inkscape's user-interface file in Glade and see the
changes immediately next time you start... no C++ knowledge needed!
== What have I done so far? ==
I've started working through Inkscape's toolbars, and have replaced the
deprecated GtkAction-based widgets with standard widgets (buttons etc).
Some of these now hook up to GAction descriptions of behaviour, while
others are just based on handling GUI signals (e.g., Button::clicked).
So far, I have migrated the toolbars for the Select, Dropper and Connector
toolbar, and have killed off a couple of the custom GtkAction-based widgets
that were only used in these.
In the process, I have also migrated the toolbar code to C++, which should
make it a little easier for the current core developers to maintain. Since
all the data is now stored as C++ member variables, rather than as GObject
data, we now benefit from better compile-time and run-time type-checking
that will help to safeguard against errors being introduced in the code in
future.
I have placed the updated toolbars in the Inkscape::UI::Toolbar namespace
and made them into proper sub-classes of the Gtk::Toolbar class.
== How can you help? ==
This important refactoring project must be done before Gtk+ 4 is widely
used, and represents a major change to the way that our toolbars are
implemented. It represents a couple of thousand lines of code changes and
will inevitably cause some regression bugs. I will need your help in
thoroughly testing that all the toolbars work correcly!
All of these changes are currently in a git branch
("gtk-actions-migration") and will not be merged into the master branch
until preliminary testing has been completed. In other words, this will
not "mess up" your stable version of Inkscape and will never be part of the
current 0.92.x release series! I intend to merge this work well in advance
of the Inkscape 1.0 release, so that we have plenty of time for very
thorough developer and user testing, and several preliminary bug-fix
"alpha" pre-releases before the final stable release.
For the very brave: please checkout the "gtk-actions-migration" branch in
git, rebuild and test. Please note that this is work-in progress. Do not
use this experimental branch for your regular Inkscape drawing work!!! The
Node toolbar will not work... the Select, Dropper and Connector toolbars
are highly experimental; all the other toolbars are "at risk"! If you
don't know how to do this, check out our developer guide.
For the quite brave: I'll merge this experimental branch into our master
development branch in a few weeks once (a) I've completed the basic work,
(b) I've had a good amount of feedback on the branch and know that it
"works" to some extent. I'll message you again at this stage and ask
everyone to help look for bugs. Again, this will only be visible to
developers and users of our experimental "trunk" PPA in Ubuntu.
For the intrepid: If you're interested in helping with the code migration -
message me and I'll help to divide up the tasks.
== The end ==
I hope this gives an insight into the work I've started doing this week,
and will continue over the coming weeks. Thanks once again to everyone who
has contributed time, money or even just attention and enthusiasm for the
Hackfest.
Best wishes,
Alex Valavanis (valavanisalex)
Inkscape developer
4 years, 12 months
Re: [Inkscape-devel] Hackfest 2018: Actions and Toolbars
by jelle
Hi all,
A lot of exiting things going on here. Separating the GUI from the
functionality of Inkscape and allowing to use it as a command line tool
sounds really cool.
Now the question that arises to me is whether that means Inkscape could be
used as a service and output could get rendered to a client browser? That
would allow for a wide variety of GUI's to be developed that could cater
to specific uses. I could envision a touch version and probably a VR
interface would be more of an option as well. Obviously the fast rendering
with Cairo would be lost that way, but for limited use cases (for instance
without filters) that should be fast enough I think.
Cheers,
Jelle
4 years, 12 months
Upcoming directory restructuring
by Tavmjong Bah
Hi all,
At the hackfest we discussed a revised directory structure to better
organize our code, This is a heads up that we plan on doing this
reorganization in a couple of week (to give time for existing patches,
etc. to land).
The purpose of the reorganization is to make it more obvious where to
find different pieces of code. At the moment our code tends to be
distributed over lots of different directories (especially the code
that manipulates SVG and the code for our 100+(!) GUI elements).
The proposed directory structure can be found at:
http://wiki.inkscape.org/wiki/index.php/Source_Directory_Structure
You can comment on the proposed change here or on the wiki page.
We also discussed a requirement that all files should have at least one
or two sentences to document what their contents does. This should
really help new developers (and prevent code duplication).
Tav
5 years
Hackfest 2018 Boston - day 1 update
by Bryce Harrington
A recap of some discussions that have been under way...
0. On the first day I gave a presentation on modularity, and identified
areas in both Inkscape the codebase and Inkscape the project, to
encapsulate complexity into more easily understood chunks, with well
defined and simple interfaces between them.
1. Gtk3 (and Gtk4) issues were brainstormed. We use several Gtk2
functionalities which are deprecated in Gtk3, and may be removed in
Gtk4. We scoped out ideas for transitioning, such as migrating from
GtkAction to GAction, and GtkMain to GtkApplication. The discussions
helped clear some blockers, and Alex is now digging into the code and
working out how we can do the change with minimum impact on UI
appearance or behavior.
Longer term, once these transitions are made, there are a number of more
impactful changes that could be attempted. One scheme we scoped out was
to separate the frontend and backend of Inkscape, using GActions as the
interface. The backend would present a lengthy list of all of its
internal operations (Actions). There would be separate sets of Document
Actions (like moving a node on a Bézier curve) and Window Actions (like
resizing the window). The frontend UI would translate its widget clicks
and menu picks into the corresponding actions and pass them down. Apart
from giving us better organized code, this could also make it easier to
have multiple kinds of UI's (e.g. a simplified "kidscape" interface) or
even no-UI (e.g. a headless version that processes commands through
command line args or a batch language).
2. Website strategy is under heavy discussion. It's been a while since
the website has had a design refresh, and whiteboard markers are
flowing. Improving mobile friendliness seems important, also better use
of graphics and videos is being explored, and better emphasis on using
some of the great user stories out there. There's also a recognition
that we have needs for something more user-facing (e.g. something
"brochure-like") and something more back-office-y (the contributor
community, aka "contributy"). A lot of this will need a lot more
hashing out and collecting wider ideas, but I'm looking forward to
seeing how this work proceeds in coming weeks and months.
3. Variable fonts. This new type of font permits e.g. sliding scale of
style aspects like bold between letter forms. Some implementation work
has already been done, but the hackfest has been used to hash out some
remaining questions and implementation details. There's still some
UX/UI questions on how it should be implemented in the interface.
4. Improved gradients using random dithering in pixman. Lots of
discussions in both IRL and IRC around Mc's code to add better
gradient rendering to pixman, that avoids banding by randomly dithering
the colors. The patch has been proposed to pixman and some feedback's
been received, but still mulling over how to actually get this feature
into use.
5. Color management / CMYK. We had an in-depth discussion between
coders and designers to hash out what we ought to be shooting for in
terms of requirements. We discussed a "print pre-flight dialog" concept
that had come up in some of the Vectors team discussions. What's needed
as a next step is to flesh out the concept - workflow use cases, a
mockup UI, and analysis of how data in/out flows need to work. There
are a lot of ideas and user stories, that need gelled into something
coherent that people can start throwing darts at.
6. SVG 2 working group, and future directions. A number of features we
wanted to see included in the SVG 2 spec sound like they will get
dropped. Further, this change of direction by the WG suggests it may
get tougher to include artistic-oriented features in future revisions of
the spec. We discussed some of the problems, but the path forward for
us is unclear.
---
I'm certain I've missed a number of the discussions here, and am not
capturing all the work under way. Hopefully other attendees can fill in
what I've missed or gotten wrong, and provide more details from my above
summary. Please ask questions, too.
Bryce
5 years
Future 0.92.x bugfix releases
by Bryce Harrington
Let's plan on a 0.92.4 in a few months, maybe in the May/June timeframe.
As we've talked about in the past, we'll be continuing to do bugfix
releases on the 0.92.x branch for the foreseeable future, and we'll be
treating it as an equivalent of a 'long term stable' series for Inkscape
in case changes. Some aggressive changes in 0.93 may lead to bad
breakages for some users, so we want to give them a reliable fallback.
So, please continue backporting good fixes from master into the 0.92.x
branch, and record the changes in release notes:
http://wiki.inkscape.org/wiki/index.php/Release_notes/0.92.4
If you don't have commit access to 0.92.x (or don't feel comfortable
pushing to it), you can mark bugs in Launchpad with the
'backport-proposed' tag, so committers can more easily spot them. (But
make sure the bug has a patch attached to it that will actually apply
and build against 0.92.x.)
A few release process todo's I'm aware of:
* Mac builds - need a volunteer
* 'make distcheck' - needs added to cmake
* PPA recipe updates - needs scripted [hackfest: bryce/alex]
* NEWS file update - change python script to use BeautifulSoup [bryce]
* packager announcements - set up a proper mailing list [bryce]
* Transition to new RSA 4096 GPG signing key [bryce]
* cleanup the release documentation [bryce]
* lp milestone, etc. updates - needs a LP script so its less manual
Let me know if you'd like to help on any of these tasks.
Bryce
On Fri, Mar 23, 2018 at 10:42:17PM -0700, Bryce Harrington wrote:
> Inkscape 0.92.3 is a maintenance release resolving numerous bugs and
> making this the most stable release of the series.
>
> To download the latest packaged version of Inkscape visit:
>
> https://inkscape.org/release/0.92.3/
>
> (Note: A build of 0.92.3 is not currently available for MacOS. The
> project welcomes additional contributors with MacOS expertise.)
>
> Among the most reported bugs addressed were:
>
> * Blank pages being output when printing multiple copies of a document
> * The inability to cancel during the export of large files
> * Application crashes caused by dragging a path at a cap or line join
> * Keyboard shortcut problems on non-Latin keyboard layouts
>
> Also a few performance improvements and usability enhancements of note:
>
> * New SVG export options from the command line
> * Support for right-to-left text
> * Improved ellipse controls
> * Multi-line text support for the PDF+LaTeX export
> * New render tile preferences for performance tuning
> * Better startup performance for many Windows users
>
> Find out more about the release at:
>
> https://inkscape.org/en/news/2018/03/22/announcing-0923-release-inkscape/
>
>
>
>
> Inkscape 0.92.3
>
> -~= Released 2018-03-11 =~-
>
> +----------------------------------------------------------------------+
> | Release Highlights |
> +----------------------------------------------------------------------+
>
> Inkscape 0.92.3 is mainly a stability and bugfix release, but it also
> brings some small new features, like being able to set an ellipses'
> radii numerically in the tool controls, or switching the writing
> direction from left-to-right to right-to-left. Windows users will be
> happy to learn that the long startup times many of them were seeing
> could greatly be reduced. A new rendering option with an adjusted
> default value can vastly improve performance when working with filters.
>
> Many of the bug fixes address important functionality, like printing
> issues, crashes with the node tool or problems with keyboard shortcuts.
>
>
> +----------------------------------------------------------------------+
> | Improvements |
> +----------------------------------------------------------------------+
>
> Command line usage
> ==================
>
> Three new command line options controlling page size are supported when
> exporting in SVG format:
>
> • --export-area-drawing (feature requests in bug #1597921 and bug #1722844)
> • --export-area-page while using --export-id
> • --export-margin
>
>
> Text tool
> =========
>
> Support for switching between RTL and LTR writing directions has been
> added (on narrow screens, find it by unfolding the overhang menu for the
> text tool's tool controls by clicking on the triangle at the far right).
>
>
> Circle/ellipse/arc tool
> =======================
>
> New fields for setting vertical/horizontal radius (Rx/Ry) were added to
> the tool controls bar. (Bug #1181127)
>
>
> PDF+LaTeX export
> ================
>
> Support for multi-line text with basic support for line-spacing
> attribute was added. (Bug #771959)
>
> Please note:
>
> • Currently only the line-spacing of the top level text element is
> considered, i.e. all lines in one text element share the same line
> spacing.
> • LaTeX is much more clever with respect to line spacing, so layout
> might not always be exactly the same as in Inkscape.
> • Make sure to use a continuously scalable font in LaTeX, otherwise
> results might be unexpected.
>
>
> Preferences
> ===========
>
> A new renderer option called "Rendering tile multiplier" was
> added. Making this value larger can speed up drawing, if you have large
> areas with complex filters in your drawing or work a lot with high zoom
> levels on filtered objects. Making the value smaller can make zooming
> and panning in relevant areas faster on low-end hardware (if there are
> no large filtered areas on the visible part of the canvas). The default
> value makes your screen consist of about four tiles that are rendered
> independently, if you're not using a hidpi screen (which requires more
> tiles). For a more detailed explanation, see:
>
> https://gitlab.com/inkscape/inkscape/merge_requests/211#note_62157385.
>
>
> Startup Performance
> ===================
>
> The first start of Inkscape on Windows is much faster now.
>
> This is the result of improvements in fontconfig 2.13.0, a third party
> library which handles font related tasks for Inkscape. One of the tasks
> is creating an index of all fonts available on the system which is much
> faster now. If the new indexing causes any issues (i.e. fonts or glyphs
> not available that could be used before) make sure to let us know or
> report the issue directly to the fontconfig project.
>
>
> Extensions
> ==========
>
> Extensions on Windows can now make use of Tkinter, without requiring
> users to install it themselves. Tkinter provides functionality for
> creating interactive graphical user interfaces. This is used, for
> example, by the TexText extension that renders mathematical LaTeX
> formulas to SVG (feature request at bug # 1735451).
>
>
> +----------------------------------------------------------------------+
> | Regression Fixes |
> +----------------------------------------------------------------------+
>
> • Potentially missing command line output in Inkscape 0.92.2 on Windows 7.
> (Bug #1714278)
> • Extensions in the 'Raster' submenu relying on ImageMagick were
> broken and caused crashes in Inkscape 0.92.2 on Windows.
> (Bug #1720330)
> • gcodetools were creating wrong orientation points since the dpi
> change had been made for Inkscape 0.92.
> (Bug #1680760)
> • Regression on 0.92.2 makes it impossible to fill a powerstroke shape
> (Bug #1715433)
> • The preferences dialog was tiny by default.
> (Bug #1360213)
> • Node handles no longer get too large when selected, and they also
> revert back to standard size when deselected.
> (Bug #1568644)
> • Export to .odg (Open Document Drawing) works again on Windows.
> (Bug #1654034)
> • Inkscape no longer freezes when trying to import clipart from
> OpenClipart when the openclipart.org server takes too long to
> respond to requests.
> (Bug #1745521)
> • Text that is written in vertical direction now has its marks
> (e.g. accents) on the correct side again.
> (gitlab commit 2abe0bb6)
> • The 'Clone original' path effect works again to fill a path with a
> PowerStroke applied to it (useful for drawing cartoons)
> (Bug #1715433)
>
>
> +----------------------------------------------------------------------+
> | Important bugfixes |
> +----------------------------------------------------------------------+
>
> • Fix crash when attempting to drag path at cap or line join.
> (Bug #1691406)
> • Inkscape process did not exit cleanly on Windows.
> (Bugs #1412365 and #1715339; also causing #1714278)
> • File extension was sometimes omitted when adding saved files to Windows'
> list of "recently used documents" resulting in unusable links.
> (git commit 4d599528)
> • Do not crash on systems with illegal fontconfig configurations.
> (Bug #1716516)
> • Resolve issues when attempting to save files to non-existing
> directories. Could happen for shortcuts.xml and when setting the
> autosave location manually.
> (Bug #1719629)
> • Allow cancellation of bitmap export.
> (Bug #1195929)
> • Fix issues with PDF+LaTeX export: wrong stacking of text/graphics, missing
> pages in PDF output.
> (Bugs #771957, #1417470)
> • Fix shortcuts not working as expected when a non-latin keyboard layout is
> the primary keyboard layout on a system.
> (Bugs #1226962, #1730246, #1734308)
> • Printing multiple copies of the document resulted in one copy and many
> blank pages.
> (Bug #490866, #1733424)
> • Fix export area when exporting single objects to SVG using the --export-id
> command line switch.
> (Bug #1306662, #1707368)
> • Fix DXF output and Windows vector print scaling for documents with a custom
> view box.
> (Bug #1672066)
> • Invalid output generated from extensions no longer makes Inkscape
> crash.
> (gitlab commit 608fa56e)
> • The Ruler Live Path Effect now shows correct measurements in the default
> template (and other non-px-based templates), too
> (Bug #1460858)
> • The Document Properties dialog now has a more compact layout, so all items
> should be accessible on smaller screens
> (Bug #1510831)
>
>
> +----------------------------------------------------------------------+
> | More bug fixes |
> +----------------------------------------------------------------------+
>
> There were even more issues fixed than those listed above, but these
> probably only affect a small portion of users, or are relevant for
> development and packaging only.
>
> For a complete list, visit our launchpad bug tracker and see the commit
> history on gitlab (all changes from August, 6th 2017 until release
> date).
>
>
> +----------------------------------------------------------------------+
> | Translations |
> +----------------------------------------------------------------------+
>
> The following UI translations received updates:
>
> • French
> • German
> • Icelandic
> • Italian
> • Korean
> • Spanish
> • Ukrainian
>
> The following installer translations received updates:
>
> • Korean
>
>
> Contributing to interface translations
> ======================================
>
> Want to help with translations? Learn how to help at:
>
> https://inkscape.org/contribute/translations/
>
>
> +----------------------------------------------------------------------+
> | Documentation |
> +----------------------------------------------------------------------+
>
>
> Documentation Relaunch
> ======================
>
> The Inkscape documentation repository, containing the man page, the
> keyboard shortcut list as well as the tutorials and their respective
> translation files, has been almost completely refactored (Java has been
> dropped in favor of Python), and was updated to work with git and
> gitlab.
>
>
> Documentation Updates
> =====================
>
> The man page and the keyboard shortcut list have been updated.
>
>
> Where to find recent documentation
> ==================================
>
> Continuously updated man page (for command line usage), keyboard and
> mouse shortcut list, tutorials and translation statistics for the
> various parts of the Inkscape project are available on the inkscape.org
> website:
>
> • Man page
> • Keyboard shortcuts
> • Tutorials
> • Translation statistics for Inkscape 0.92 series / development branch
>
> Tutorials, as always, are also included with your Inkscape installation.
>
>
> Contributing to documentation and documentation translation
> ===========================================================
>
> Contributions to the documentation translations, as well as improvements
> to its contents, are welcome at the inkscape-docs repository.
>
>
> +----------------------------------------------------------------------+
> | Known issues |
> +----------------------------------------------------------------------+
>
> • DPI Change: known issues with 'Scale elements' option
> (Bugs: 1653230,1653236,1654342,1654796,1654880,1654903,1655005,1655053,1660228)
> • DPI Change: Default grids in documents created with Inkscape 0.91 don't
> scale correctly.
> (Bug #1653893)
> • Line height: Changing "baseline spacing" stops working.
> (Bug #1707808)
> • Renderer: Artifacts in Gaussian blur effects with default quality settings.
> (Bug #1656383)
> • Node editor: Deselecting selected nodes of complex paths takes a long time.
> (Bug #1652100)
> • Performance: Using the objects dialog at least once in your Inkscape
> session slows down actions such as duplicate and delete for files
> with many objects.
> (Bug #1431274)
>
>
> ------------------------------------------------------------------------
> For information on prior releases, please see:
>
> http://wiki.inkscape.org/wiki/index.php/Inkscape
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iEYEARECAAYFAlq15TkACgkQEaMBVuDmdhFeGACffqDDMJ7PI1yYV8gVz8V1jekW
> vEgAn1jy67X42/mi4eX+ebQEvz9FUkpn
> =ITZ8
> -----END PGP SIGNATURE-----
> ------------------------------------------------------------------------------
> 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
5 years
Inkscape Hackfest 2018 (Boston) Almost here!
by Martin Owens
Dear Hackers,
Are we all looking forward to two weeks from now when we'll be dining
on lobsters and dunken donuts?
Well if you are coming, please do update the http://wiki.inkscape.org/w
iki/index.php/Hackfest2018_Attendees page (or let me know and I'll do
it for you)
This is the rough itinerary for the week:
* Sunday 25th, optional drink with local Free Software hackers at the
Grendel's Den in Harvard Square. 8:00pm to 11:00pm Some touristing
might be available if you like to see Harvard.
* Monday 26th - Friday 30th, Hacking at the Red Hat offices near south
station. Anyone lost can contact me +01 857 277 2117 (Signal App is
good for anyone from abroad)
* Wednesday 28th - User participation day, if we have some users
available, we'll be listening to normal Inkscape users.
* Thursday 29th - Tentative choice for Inkscape Dinner at Les
Zygomates (http://winebar129.com) (If no one objects in the next few
days, I'll book a table)
Let me know what you're looking forward to working on while your here,
I'd like to get a new article put together to kick things off.
If you can do photography, please let me know. We'll need a group photo
and someone with a nice camera and a good eye is needed sine CR isn't
here.
Anything else, please let me know.
Thanks everyone!
Best Regards, Martin Owens
5 years
