https://wiki.inkscape.org/wiki/api.php?action=feedcontributions&user=Steren&feedformat=atomInkscape Wiki - User contributions [en]2024-03-29T12:16:59ZUser contributionsMediaWiki 1.36.1https://wiki.inkscape.org/wiki/index.php?title=Image_properties_dialog_enhancements&diff=63007Image properties dialog enhancements2010-06-18T18:17:06Z<p>Steren: /* Relative links */</p>
<hr />
<div>= Image properties dialog enhancements =<br />
<br />
==Current Status==<br />
<br />
This blueprint is no more in a blueprint state.<br />
<br />
Work has been done by students from [http://www.ec-lyon.fr Ecole Centrale Lyon]. You can read their report [[File:Centrale_Lyon_2010.pdf]]. Contact [[User:Steren]] for more information.<br />
<br />
The code is currently in a [https://code.launchpad.net/~centralelyon2010/inkscape/imagelinks2 branch]. The main features were added, but finishing, testing, reviewing and polishing are needed to merge it into trunk.<br />
<br />
===Relative links===<br />
'''scenario''':<br />
* 1 - Save your document, drop an image from a subdirectory on the canvas, select "link", see that the link should now be relative.<br />
* 2 - do not save the document, import an image on the canvas, the link is absolute, save the document near the image, the image link should be updated with a relative link.<br />
'''status''': to test<br />
<br />
'''bugs''':<br />
*<br />
<br />
===Relink tool===<br />
'''status''': features are here, need to polish the UI<br />
<br />
'''scenario''': create a document with linked images, save this svg. Move the svg to another folder. reopen it, the relinking tool appears and help you relink the broken images. <br />
<br />
'''TODO''':<br />
* do not show an alert dialog when relinking is finished, prefer the status bar ?<br />
<br />
'''bugs''':<br />
* when opening a file with a broken link, the alert dialog doesn't show well the names of missing files.<br />
<br />
===Image propriety window===<br />
'''scenario''' : right click on an image of the canvas, select image properties. A new window should allow you to see the image thumbnail and infos, choose another image, embed the image, reset ratio.<br />
<br />
'''status''': code started, not finished<br />
<br />
'''TODO''': (refering to the mockup on this page)<br />
* thumbnail<br />
* ...<br />
<br />
==Summary==<br />
<br />
Organizing linked bitmap images is quite a hassle at the moment. When a bitmap file is renamed or moved to a different location, the corresponding bitmap links need to be changed manually one by one in Inkscape, involving a tedious copy and paste process for the filenames. This can be improved.<br />
This is an alternative to the method proposed in the article [[Linked bitmap manager]].<br />
<br />
==Proposal==<br />
<br />
The proposal is to add some minor enhancements to the existing image properties dialog, in order to improve its usability and solve broken links in an easy and automated way.<br />
<br />
The first thing that has to be solved is the inconsistency in absolute/relative linking. At the moment all the images are linked with absolute paths, and that can be very inconvenient when working on the same file over a network.<br />
The images in the same directory than the SVG file should be linked with relative paths, and so the images in children directories. This condition can be extended to folders contained by the same parent folder that contains the SVG.<br />
<br />
That would solve common problems like broken links if the file was created or is retrieved from a remote machine over a samba mount in linux, for instance.<br />
<br />
Another common situation where absolute links are useless is a project retrieved from a backup. Again, all files have to be re-linked.<br />
So in the first place, fixing the absolute/relative linking will solve a lot of broken links.<br />
<br />
However, that wouldn't fix all the broken links, and there are several situations where moving or renaming a linked file will result in a broken link, so another strategy should be prepared for that.<br />
<br />
As it would discussed in the mailing list and related bug reports, the lack of a browse button in the image properties dialog makes it too tedious to re-link missing images, so adding that button would make things easier.<br />
<br />
But having dozens of broken links would be still a hassle even having that button, so a "smart re-linking" strategy would be handy.<br />
<br />
Adding a modal warning about broken links would be excessive since we already have a pretty visible way to display that there are missing bitmaps, so the focus should be put on providing an automated way to resolve broken links using a single manual replacement. As it was expressed earlier, a proper management of absolute and relative links would help with this task.<br />
<br />
==Image Properties Dialog Re-design==<br />
<br />
One of the most annoying things about the Image Properties dialog is that one window is opened for each image. That window should be re-utilized and be dockable. When the user selects another image, its information should fill the same properties window, not a new one.<br />
This dialog should be also accessible from the Object menu (like the object properties dialog), not only from the context menu of a selected image.<br />
<br />
[[File:new-image-properties-dialog.png]]<br />
<br />
At the top there's an area that shows general information about the image, along with a thumbnail. This will give a glimpse about the image we're working on.<br />
<br />
The URL field willbe accompained by a browse button for easy image re-linking.<br />
The URL text can be rendered red if the link is broken, giving a visual hint to the user that the path isn't correct. <br />
<br />
I added radio buttons for selecting if the image is linked or embedded, since that is part of the image properties and it would make sense to put it in that dialog instead of a separate extension.<br />
<br />
The fields for the dimensions of the image were preserved, adding a units selector and a proportional transformation lock.<br />
<br />
The position fields were removed, since they are not (from the user point of view) part of the image properties, but an attribute of the object on the document. It isn't likely that a user will set the position of the image object on the document from a window that covers it, He will probably use the tool controls bar selectors instead.<br />
<br />
An "advanced options" area was added. It lets the user enter the object ID, change the resolution of the image and use the original image's aspect ratio.<br />
<br />
:'''Comment:''' What about adding a checkbox in the section ''image source'', just below the edit control ''URL'' named ''Relative'' and to display the (on-the-fly-calculated) commun URL prefix (between the linked image and the Inkscape file) in a grey font? Best regards --[[User:Uncopy|Uncopy]] 10:52, 27 October 2009 (UTC)<br />
<br />
:'''Comment:''' The radio buttons should be for absolute/relative, and for embedded/linked there should be a push button that says "embed" or "extract..." based on the state of the image. Embedded/linked cannot be a radio button, because switching to "linked" needs to bring up a file browser. Doing so in response to radio button change breaks all the interface guidelines I know. --[[User:Tweenk|Tweenk]] 19:31, 5 March 2010 (UTC)<br />
<br />
:'''Comment:''' I'm ok with adding the relative/absolute switch. My original proposal was to do it kind of automatically, but I can see that it can be really problematic.<br />
Regarding the Embedded/linked thing, the original proposal considers "linked" as the default importing strategy. This has been changed recently in inkscape but I think it's plain wrong. Embedding always and then extracting contributes to having duplicates of the original images everywhere. I think that embedding should be the default for the "make bitmap copy" command, and in that case the extract command should make sense.<br />
The original proposal doesn't go against that practice either: if the image is already embedded, the file browser is hidden. If you click on the "linked" radio button, then the extract dialog would pop up.<br />
We must, however, find a way to make all the situations co-exist nicely: linked to embeded / embedded to linked (extracted) / Re-link linked image / Re-link embedded image. --[[User:Gez|Gez]] 19:31, 3 May 2010 (UTC)<br />
<br />
==Smart image re-linking==<br />
<br />
If there are several images with broken links and we choose the right path for one of those images (and they share the same location) Inkscape should compare the common location of the broken links and fix the remaining images with the new location automatically.<br />
<br />
'''Example:'''<br />
there are 3 images with broken absolute links:<br />
<br />
# /media/disk/inkscape-works/images/cat.png<br />
# /media/disk/inkscape-works/images/dog.png<br />
# /media/disk/inkscape-works/images/bird.png<br />
<br />
when the user sets a relative link for the first image to images/cat.png the other images should be automatically relinked, since they had:<br />
* broken links<br />
* the same orignal path<br />
* they exist in the new location.<br />
<br />
This operation could be silent, but when there are several images the re-linking process can take some time, so a confirmation window would provide a clear warning about the operation is going to be performed, with the possibility of choosing "yes" to perform the re-link process with the images found, or skipping it choosing "no"<br />
This window would appear right after a single re-link.<br />
<br />
[[File:relink-confirmation.png]]<br />
<br />
[[File:relink-confirmation-details.png]]<br />
<br />
The confirmation window can optionally show details about the images that are going to be re-linked, with the ability to untick the items that the user doesn't want to automatically re-link.<br />
<br />
: '''Comment:''' It is possible to uncheck all images and then click "yes", which doesn't make much sense. The text should be worded in a different way. For example, the prompt could be something like "Additional missing images were found. Select the image links you want to fix", choices would be "ok" and "cancel", and the list would always be visible. --[[User:Tweenk|Tweenk]] 19:24, 5 March 2010 (UTC)<br />
<br />
==Manual selection of relative or absolute paths==<br />
Steren pointed me out that there are some situations where selecting manually if the image will be linked using an absolute or a relative path.<br />
In that case, the file selector window that opens with the "browse" button of the Image Properties dialog could have radio buttons for selecting absolute or relative. The default value would be proposed by inkscape according the guidelines discussed earlier, but the user would have the ability to force the path to be relative or absolute, according his needs.<br />
However, that feature imposes a potential problem: How the smart re-linking feature should act in that case? The automatically re-linked images would use the same path type than the manually selected?<br />
<br />
==Linked vs. Embedded==<br />
The new image properties dialog would have radio buttons for choosing if the image is linked or embedded.<br />
<br />
The behavior of those buttons would be the following:<br />
* If the image is linked (default for the imported bitmaps) the behavior would be the described earlier in this blueprint<br />
* if the user chooses "embedded", the url input and its browse button will be grayed out, and the image will be embedded into the SVG document<br />
* if the user chooses "linked" on an image that was previously embedded, a file dialog will be opened, prompting the user to enter a location and a file name (by default the id and the path of the SVG file will be used) to extract and save the image.<br />
* if the link is broken, the "embedded" option will be grayed out until a valid path is set.<br />
<br />
: '''Comment:''' Embedded / Linked cannot be a radio button, because when we open a file with an embedded image, it has no path assigned. The button should say "extract..." when the image is embedded and bring up a file browser that allows the user to choose the location, and it should say "embed" when the image is linked. There should be a different radio button though: one that allows the user to choose between an absolute and a relative link. --[[User:Tweenk|Tweenk]] 19:29, 5 March 2010 (UTC)<br />
<br />
==Image Resolution==<br />
At the moment inkscape doesn't use the imported image's resolution value and use 90 dpi instead. There is a whishlist item in Launchpad about that and it should be fixed in order to implement this feature, otherwise the resolution value wouldn't make sense in this dialog.<br />
Notice that resolution value would change the "real world units" size of the image in the document, so changing that value would have impact in the dimensions selectors if they're set to real world units.<br />
The original file's resolution is important because it would tell inkscape what dimensions use for the imported image on the document.<br />
In my oppinion, if the default document's units are real world units, the resolution value should be used; if pixels are used as default units, the resolution should be disregarded, and grayed out in the dialog.<br />
<br />
<br />
==General Benefits of this change==<br />
<br />
These enhancements would tackle several usability issues in the current image properties dialog and provide an easy and straightforward solution for broken image links.<br />
The image properties would be unified in a single window, adding features that are currently available only via extensions, in locations that may not be so obvious for the new users.<br />
<br />
==TODO== <br />
There are a couple of interesting suggestions that can be added to this dialog but I hadn't the time to develop:<br />
* The thumbnail could be used for external editing (double clicking on it, or using a button)<br />
* Add a new option for embedded images: re-link to the original file. <br />
<br />
[[Category:Proposals]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_properties_dialog_enhancements&diff=63001Image properties dialog enhancements2010-06-18T18:15:23Z<p>Steren: /* Current Status */</p>
<hr />
<div>= Image properties dialog enhancements =<br />
<br />
==Current Status==<br />
<br />
This blueprint is no more in a blueprint state.<br />
<br />
Work has been done by students from [http://www.ec-lyon.fr Ecole Centrale Lyon]. You can read their report [[File:Centrale_Lyon_2010.pdf]]. Contact [[User:Steren]] for more information.<br />
<br />
The code is currently in a [https://code.launchpad.net/~centralelyon2010/inkscape/imagelinks2 branch]. The main features were added, but finishing, testing, reviewing and polishing are needed to merge it into trunk.<br />
<br />
===Relative links===<br />
'''scenario''':<br />
* 1 - Save your document, drop an image from a subdirectory on the canvas, select "link", see that the link should now be relative.<br />
* 2 - do not save the document, import an image on the canvas, save the document near the image, the image link should beupdated with a relative link.<br />
'''status''': to test<br />
<br />
'''bugs''':<br />
*<br />
<br />
===Relink tool===<br />
'''status''': features are here, need to polish the UI<br />
<br />
'''scenario''': create a document with linked images, save this svg. Move the svg to another folder. reopen it, the relinking tool appears and help you relink the broken images. <br />
<br />
'''TODO''':<br />
* do not show an alert dialog when relinking is finished, prefer the status bar ?<br />
<br />
'''bugs''':<br />
* when opening a file with a broken link, the alert dialog doesn't show well the names of missing files.<br />
<br />
===Image propriety window===<br />
'''scenario''' : right click on an image of the canvas, select image properties. A new window should allow you to see the image thumbnail and infos, choose another image, embed the image, reset ratio.<br />
<br />
'''status''': code started, not finished<br />
<br />
'''TODO''': (refering to the mockup on this page)<br />
* thumbnail<br />
* ...<br />
<br />
==Summary==<br />
<br />
Organizing linked bitmap images is quite a hassle at the moment. When a bitmap file is renamed or moved to a different location, the corresponding bitmap links need to be changed manually one by one in Inkscape, involving a tedious copy and paste process for the filenames. This can be improved.<br />
This is an alternative to the method proposed in the article [[Linked bitmap manager]].<br />
<br />
==Proposal==<br />
<br />
The proposal is to add some minor enhancements to the existing image properties dialog, in order to improve its usability and solve broken links in an easy and automated way.<br />
<br />
The first thing that has to be solved is the inconsistency in absolute/relative linking. At the moment all the images are linked with absolute paths, and that can be very inconvenient when working on the same file over a network.<br />
The images in the same directory than the SVG file should be linked with relative paths, and so the images in children directories. This condition can be extended to folders contained by the same parent folder that contains the SVG.<br />
<br />
That would solve common problems like broken links if the file was created or is retrieved from a remote machine over a samba mount in linux, for instance.<br />
<br />
Another common situation where absolute links are useless is a project retrieved from a backup. Again, all files have to be re-linked.<br />
So in the first place, fixing the absolute/relative linking will solve a lot of broken links.<br />
<br />
However, that wouldn't fix all the broken links, and there are several situations where moving or renaming a linked file will result in a broken link, so another strategy should be prepared for that.<br />
<br />
As it would discussed in the mailing list and related bug reports, the lack of a browse button in the image properties dialog makes it too tedious to re-link missing images, so adding that button would make things easier.<br />
<br />
But having dozens of broken links would be still a hassle even having that button, so a "smart re-linking" strategy would be handy.<br />
<br />
Adding a modal warning about broken links would be excessive since we already have a pretty visible way to display that there are missing bitmaps, so the focus should be put on providing an automated way to resolve broken links using a single manual replacement. As it was expressed earlier, a proper management of absolute and relative links would help with this task.<br />
<br />
==Image Properties Dialog Re-design==<br />
<br />
One of the most annoying things about the Image Properties dialog is that one window is opened for each image. That window should be re-utilized and be dockable. When the user selects another image, its information should fill the same properties window, not a new one.<br />
This dialog should be also accessible from the Object menu (like the object properties dialog), not only from the context menu of a selected image.<br />
<br />
[[File:new-image-properties-dialog.png]]<br />
<br />
At the top there's an area that shows general information about the image, along with a thumbnail. This will give a glimpse about the image we're working on.<br />
<br />
The URL field willbe accompained by a browse button for easy image re-linking.<br />
The URL text can be rendered red if the link is broken, giving a visual hint to the user that the path isn't correct. <br />
<br />
I added radio buttons for selecting if the image is linked or embedded, since that is part of the image properties and it would make sense to put it in that dialog instead of a separate extension.<br />
<br />
The fields for the dimensions of the image were preserved, adding a units selector and a proportional transformation lock.<br />
<br />
The position fields were removed, since they are not (from the user point of view) part of the image properties, but an attribute of the object on the document. It isn't likely that a user will set the position of the image object on the document from a window that covers it, He will probably use the tool controls bar selectors instead.<br />
<br />
An "advanced options" area was added. It lets the user enter the object ID, change the resolution of the image and use the original image's aspect ratio.<br />
<br />
:'''Comment:''' What about adding a checkbox in the section ''image source'', just below the edit control ''URL'' named ''Relative'' and to display the (on-the-fly-calculated) commun URL prefix (between the linked image and the Inkscape file) in a grey font? Best regards --[[User:Uncopy|Uncopy]] 10:52, 27 October 2009 (UTC)<br />
<br />
:'''Comment:''' The radio buttons should be for absolute/relative, and for embedded/linked there should be a push button that says "embed" or "extract..." based on the state of the image. Embedded/linked cannot be a radio button, because switching to "linked" needs to bring up a file browser. Doing so in response to radio button change breaks all the interface guidelines I know. --[[User:Tweenk|Tweenk]] 19:31, 5 March 2010 (UTC)<br />
<br />
:'''Comment:''' I'm ok with adding the relative/absolute switch. My original proposal was to do it kind of automatically, but I can see that it can be really problematic.<br />
Regarding the Embedded/linked thing, the original proposal considers "linked" as the default importing strategy. This has been changed recently in inkscape but I think it's plain wrong. Embedding always and then extracting contributes to having duplicates of the original images everywhere. I think that embedding should be the default for the "make bitmap copy" command, and in that case the extract command should make sense.<br />
The original proposal doesn't go against that practice either: if the image is already embedded, the file browser is hidden. If you click on the "linked" radio button, then the extract dialog would pop up.<br />
We must, however, find a way to make all the situations co-exist nicely: linked to embeded / embedded to linked (extracted) / Re-link linked image / Re-link embedded image. --[[User:Gez|Gez]] 19:31, 3 May 2010 (UTC)<br />
<br />
==Smart image re-linking==<br />
<br />
If there are several images with broken links and we choose the right path for one of those images (and they share the same location) Inkscape should compare the common location of the broken links and fix the remaining images with the new location automatically.<br />
<br />
'''Example:'''<br />
there are 3 images with broken absolute links:<br />
<br />
# /media/disk/inkscape-works/images/cat.png<br />
# /media/disk/inkscape-works/images/dog.png<br />
# /media/disk/inkscape-works/images/bird.png<br />
<br />
when the user sets a relative link for the first image to images/cat.png the other images should be automatically relinked, since they had:<br />
* broken links<br />
* the same orignal path<br />
* they exist in the new location.<br />
<br />
This operation could be silent, but when there are several images the re-linking process can take some time, so a confirmation window would provide a clear warning about the operation is going to be performed, with the possibility of choosing "yes" to perform the re-link process with the images found, or skipping it choosing "no"<br />
This window would appear right after a single re-link.<br />
<br />
[[File:relink-confirmation.png]]<br />
<br />
[[File:relink-confirmation-details.png]]<br />
<br />
The confirmation window can optionally show details about the images that are going to be re-linked, with the ability to untick the items that the user doesn't want to automatically re-link.<br />
<br />
: '''Comment:''' It is possible to uncheck all images and then click "yes", which doesn't make much sense. The text should be worded in a different way. For example, the prompt could be something like "Additional missing images were found. Select the image links you want to fix", choices would be "ok" and "cancel", and the list would always be visible. --[[User:Tweenk|Tweenk]] 19:24, 5 March 2010 (UTC)<br />
<br />
==Manual selection of relative or absolute paths==<br />
Steren pointed me out that there are some situations where selecting manually if the image will be linked using an absolute or a relative path.<br />
In that case, the file selector window that opens with the "browse" button of the Image Properties dialog could have radio buttons for selecting absolute or relative. The default value would be proposed by inkscape according the guidelines discussed earlier, but the user would have the ability to force the path to be relative or absolute, according his needs.<br />
However, that feature imposes a potential problem: How the smart re-linking feature should act in that case? The automatically re-linked images would use the same path type than the manually selected?<br />
<br />
==Linked vs. Embedded==<br />
The new image properties dialog would have radio buttons for choosing if the image is linked or embedded.<br />
<br />
The behavior of those buttons would be the following:<br />
* If the image is linked (default for the imported bitmaps) the behavior would be the described earlier in this blueprint<br />
* if the user chooses "embedded", the url input and its browse button will be grayed out, and the image will be embedded into the SVG document<br />
* if the user chooses "linked" on an image that was previously embedded, a file dialog will be opened, prompting the user to enter a location and a file name (by default the id and the path of the SVG file will be used) to extract and save the image.<br />
* if the link is broken, the "embedded" option will be grayed out until a valid path is set.<br />
<br />
: '''Comment:''' Embedded / Linked cannot be a radio button, because when we open a file with an embedded image, it has no path assigned. The button should say "extract..." when the image is embedded and bring up a file browser that allows the user to choose the location, and it should say "embed" when the image is linked. There should be a different radio button though: one that allows the user to choose between an absolute and a relative link. --[[User:Tweenk|Tweenk]] 19:29, 5 March 2010 (UTC)<br />
<br />
==Image Resolution==<br />
At the moment inkscape doesn't use the imported image's resolution value and use 90 dpi instead. There is a whishlist item in Launchpad about that and it should be fixed in order to implement this feature, otherwise the resolution value wouldn't make sense in this dialog.<br />
Notice that resolution value would change the "real world units" size of the image in the document, so changing that value would have impact in the dimensions selectors if they're set to real world units.<br />
The original file's resolution is important because it would tell inkscape what dimensions use for the imported image on the document.<br />
In my oppinion, if the default document's units are real world units, the resolution value should be used; if pixels are used as default units, the resolution should be disregarded, and grayed out in the dialog.<br />
<br />
<br />
==General Benefits of this change==<br />
<br />
These enhancements would tackle several usability issues in the current image properties dialog and provide an easy and straightforward solution for broken image links.<br />
The image properties would be unified in a single window, adding features that are currently available only via extensions, in locations that may not be so obvious for the new users.<br />
<br />
==TODO== <br />
There are a couple of interesting suggestions that can be added to this dialog but I hadn't the time to develop:<br />
* The thumbnail could be used for external editing (double clicking on it, or using a button)<br />
* Add a new option for embedded images: re-link to the original file. <br />
<br />
[[Category:Proposals]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_properties_dialog_enhancements&diff=62995Image properties dialog enhancements2010-06-18T18:11:56Z<p>Steren: /* Relink tool */</p>
<hr />
<div>= Image properties dialog enhancements =<br />
<br />
==Current Status==<br />
<br />
This blueprint is no more in a blueprint state.<br />
<br />
Work has been done by students from [http://www.ec-lyon.fr Ecole Centrale Lyon]. You can read their report [[File:Centrale_Lyon_2010.pdf]]. Contact [[User:Steren]] for more information.<br />
<br />
The code is currently in a [https://code.launchpad.net/~centralelyon2010/inkscape/imagelinks2 branch]. The main features were added, but finishing, testing, reviewing and polishing are needed to merge it into trunk.<br />
<br />
===Relative links===<br />
'''status''': to test<br />
<br />
'''bugs''':<br />
*<br />
<br />
===Relink tool===<br />
'''status''': features are here, need to polish the UI<br />
<br />
'''scenario''': create a document with linked images, save this svg. Move the svg to another folder. reopen it, the relinking tool appears and help you relink the broken images. <br />
<br />
'''TODO''':<br />
* do not show an alert dialog when relinking is finished, prefer the status bar ?<br />
<br />
'''bugs''':<br />
* when opening a file with a broken link, the alert dialog doesn't show well the names of missing files.<br />
<br />
===Image propriety window===<br />
'''status''': code started, not finished<br />
<br />
'''TODO''': (refering to the mockup on this page)<br />
* thumbnail<br />
* ...<br />
<br />
==Summary==<br />
<br />
Organizing linked bitmap images is quite a hassle at the moment. When a bitmap file is renamed or moved to a different location, the corresponding bitmap links need to be changed manually one by one in Inkscape, involving a tedious copy and paste process for the filenames. This can be improved.<br />
This is an alternative to the method proposed in the article [[Linked bitmap manager]].<br />
<br />
==Proposal==<br />
<br />
The proposal is to add some minor enhancements to the existing image properties dialog, in order to improve its usability and solve broken links in an easy and automated way.<br />
<br />
The first thing that has to be solved is the inconsistency in absolute/relative linking. At the moment all the images are linked with absolute paths, and that can be very inconvenient when working on the same file over a network.<br />
The images in the same directory than the SVG file should be linked with relative paths, and so the images in children directories. This condition can be extended to folders contained by the same parent folder that contains the SVG.<br />
<br />
That would solve common problems like broken links if the file was created or is retrieved from a remote machine over a samba mount in linux, for instance.<br />
<br />
Another common situation where absolute links are useless is a project retrieved from a backup. Again, all files have to be re-linked.<br />
So in the first place, fixing the absolute/relative linking will solve a lot of broken links.<br />
<br />
However, that wouldn't fix all the broken links, and there are several situations where moving or renaming a linked file will result in a broken link, so another strategy should be prepared for that.<br />
<br />
As it would discussed in the mailing list and related bug reports, the lack of a browse button in the image properties dialog makes it too tedious to re-link missing images, so adding that button would make things easier.<br />
<br />
But having dozens of broken links would be still a hassle even having that button, so a "smart re-linking" strategy would be handy.<br />
<br />
Adding a modal warning about broken links would be excessive since we already have a pretty visible way to display that there are missing bitmaps, so the focus should be put on providing an automated way to resolve broken links using a single manual replacement. As it was expressed earlier, a proper management of absolute and relative links would help with this task.<br />
<br />
==Image Properties Dialog Re-design==<br />
<br />
One of the most annoying things about the Image Properties dialog is that one window is opened for each image. That window should be re-utilized and be dockable. When the user selects another image, its information should fill the same properties window, not a new one.<br />
This dialog should be also accessible from the Object menu (like the object properties dialog), not only from the context menu of a selected image.<br />
<br />
[[File:new-image-properties-dialog.png]]<br />
<br />
At the top there's an area that shows general information about the image, along with a thumbnail. This will give a glimpse about the image we're working on.<br />
<br />
The URL field willbe accompained by a browse button for easy image re-linking.<br />
The URL text can be rendered red if the link is broken, giving a visual hint to the user that the path isn't correct. <br />
<br />
I added radio buttons for selecting if the image is linked or embedded, since that is part of the image properties and it would make sense to put it in that dialog instead of a separate extension.<br />
<br />
The fields for the dimensions of the image were preserved, adding a units selector and a proportional transformation lock.<br />
<br />
The position fields were removed, since they are not (from the user point of view) part of the image properties, but an attribute of the object on the document. It isn't likely that a user will set the position of the image object on the document from a window that covers it, He will probably use the tool controls bar selectors instead.<br />
<br />
An "advanced options" area was added. It lets the user enter the object ID, change the resolution of the image and use the original image's aspect ratio.<br />
<br />
:'''Comment:''' What about adding a checkbox in the section ''image source'', just below the edit control ''URL'' named ''Relative'' and to display the (on-the-fly-calculated) commun URL prefix (between the linked image and the Inkscape file) in a grey font? Best regards --[[User:Uncopy|Uncopy]] 10:52, 27 October 2009 (UTC)<br />
<br />
:'''Comment:''' The radio buttons should be for absolute/relative, and for embedded/linked there should be a push button that says "embed" or "extract..." based on the state of the image. Embedded/linked cannot be a radio button, because switching to "linked" needs to bring up a file browser. Doing so in response to radio button change breaks all the interface guidelines I know. --[[User:Tweenk|Tweenk]] 19:31, 5 March 2010 (UTC)<br />
<br />
:'''Comment:''' I'm ok with adding the relative/absolute switch. My original proposal was to do it kind of automatically, but I can see that it can be really problematic.<br />
Regarding the Embedded/linked thing, the original proposal considers "linked" as the default importing strategy. This has been changed recently in inkscape but I think it's plain wrong. Embedding always and then extracting contributes to having duplicates of the original images everywhere. I think that embedding should be the default for the "make bitmap copy" command, and in that case the extract command should make sense.<br />
The original proposal doesn't go against that practice either: if the image is already embedded, the file browser is hidden. If you click on the "linked" radio button, then the extract dialog would pop up.<br />
We must, however, find a way to make all the situations co-exist nicely: linked to embeded / embedded to linked (extracted) / Re-link linked image / Re-link embedded image. --[[User:Gez|Gez]] 19:31, 3 May 2010 (UTC)<br />
<br />
==Smart image re-linking==<br />
<br />
If there are several images with broken links and we choose the right path for one of those images (and they share the same location) Inkscape should compare the common location of the broken links and fix the remaining images with the new location automatically.<br />
<br />
'''Example:'''<br />
there are 3 images with broken absolute links:<br />
<br />
# /media/disk/inkscape-works/images/cat.png<br />
# /media/disk/inkscape-works/images/dog.png<br />
# /media/disk/inkscape-works/images/bird.png<br />
<br />
when the user sets a relative link for the first image to images/cat.png the other images should be automatically relinked, since they had:<br />
* broken links<br />
* the same orignal path<br />
* they exist in the new location.<br />
<br />
This operation could be silent, but when there are several images the re-linking process can take some time, so a confirmation window would provide a clear warning about the operation is going to be performed, with the possibility of choosing "yes" to perform the re-link process with the images found, or skipping it choosing "no"<br />
This window would appear right after a single re-link.<br />
<br />
[[File:relink-confirmation.png]]<br />
<br />
[[File:relink-confirmation-details.png]]<br />
<br />
The confirmation window can optionally show details about the images that are going to be re-linked, with the ability to untick the items that the user doesn't want to automatically re-link.<br />
<br />
: '''Comment:''' It is possible to uncheck all images and then click "yes", which doesn't make much sense. The text should be worded in a different way. For example, the prompt could be something like "Additional missing images were found. Select the image links you want to fix", choices would be "ok" and "cancel", and the list would always be visible. --[[User:Tweenk|Tweenk]] 19:24, 5 March 2010 (UTC)<br />
<br />
==Manual selection of relative or absolute paths==<br />
Steren pointed me out that there are some situations where selecting manually if the image will be linked using an absolute or a relative path.<br />
In that case, the file selector window that opens with the "browse" button of the Image Properties dialog could have radio buttons for selecting absolute or relative. The default value would be proposed by inkscape according the guidelines discussed earlier, but the user would have the ability to force the path to be relative or absolute, according his needs.<br />
However, that feature imposes a potential problem: How the smart re-linking feature should act in that case? The automatically re-linked images would use the same path type than the manually selected?<br />
<br />
==Linked vs. Embedded==<br />
The new image properties dialog would have radio buttons for choosing if the image is linked or embedded.<br />
<br />
The behavior of those buttons would be the following:<br />
* If the image is linked (default for the imported bitmaps) the behavior would be the described earlier in this blueprint<br />
* if the user chooses "embedded", the url input and its browse button will be grayed out, and the image will be embedded into the SVG document<br />
* if the user chooses "linked" on an image that was previously embedded, a file dialog will be opened, prompting the user to enter a location and a file name (by default the id and the path of the SVG file will be used) to extract and save the image.<br />
* if the link is broken, the "embedded" option will be grayed out until a valid path is set.<br />
<br />
: '''Comment:''' Embedded / Linked cannot be a radio button, because when we open a file with an embedded image, it has no path assigned. The button should say "extract..." when the image is embedded and bring up a file browser that allows the user to choose the location, and it should say "embed" when the image is linked. There should be a different radio button though: one that allows the user to choose between an absolute and a relative link. --[[User:Tweenk|Tweenk]] 19:29, 5 March 2010 (UTC)<br />
<br />
==Image Resolution==<br />
At the moment inkscape doesn't use the imported image's resolution value and use 90 dpi instead. There is a whishlist item in Launchpad about that and it should be fixed in order to implement this feature, otherwise the resolution value wouldn't make sense in this dialog.<br />
Notice that resolution value would change the "real world units" size of the image in the document, so changing that value would have impact in the dimensions selectors if they're set to real world units.<br />
The original file's resolution is important because it would tell inkscape what dimensions use for the imported image on the document.<br />
In my oppinion, if the default document's units are real world units, the resolution value should be used; if pixels are used as default units, the resolution should be disregarded, and grayed out in the dialog.<br />
<br />
<br />
==General Benefits of this change==<br />
<br />
These enhancements would tackle several usability issues in the current image properties dialog and provide an easy and straightforward solution for broken image links.<br />
The image properties would be unified in a single window, adding features that are currently available only via extensions, in locations that may not be so obvious for the new users.<br />
<br />
==TODO== <br />
There are a couple of interesting suggestions that can be added to this dialog but I hadn't the time to develop:<br />
* The thumbnail could be used for external editing (double clicking on it, or using a button)<br />
* Add a new option for embedded images: re-link to the original file. <br />
<br />
[[Category:Proposals]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=User:Steren&diff=62725User:Steren2010-06-07T20:48:55Z<p>Steren: </p>
<hr />
<div>I've participated in one student project and mentored two : (projects from [http://www.ec-lyon.fr Ecole Centrale Lyon])<br />
* LPE for groups + stacking + envelope (2008): see report [[File:Report_PI_Inkscape_2008.pdf]], added into trunk<br />
* Spray Tool (2009): added into trunk (mentored by Cedric Gémy and me)<br />
* Image Links (2010): see report [[File:Centrale_Lyon_2010.pdf]], currently in a [https://code.launchpad.net/~centralelyon2010/inkscape/imagelinks2 branch], please report bugs and TODOs [[Image_properties_dialog_enhancements|here]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_properties_dialog_enhancements&diff=62719Image properties dialog enhancements2010-06-07T20:47:35Z<p>Steren: /* Relink tool */</p>
<hr />
<div>= Image properties dialog enhancements =<br />
<br />
==Current Status==<br />
<br />
This blueprint is no more in a blueprint state.<br />
<br />
Work has been done by students from [http://www.ec-lyon.fr Ecole Centrale Lyon]. You can read their report [[File:Centrale_Lyon_2010.pdf]]. Contact [[User:Steren]] for more information.<br />
<br />
The code is currently in a [https://code.launchpad.net/~centralelyon2010/inkscape/imagelinks2 branch]. The main features were added, but finishing, testing, reviewing and polishing are needed to merge it into trunk.<br />
<br />
===Relative links===<br />
'''status''': to test<br />
<br />
'''bugs''':<br />
*<br />
<br />
===Relink tool===<br />
'''status''': features are here, need to polish the UI<br />
<br />
'''TODO''':<br />
* do not show an alert dialog when relinking is finished, prefer the status bar ?<br />
<br />
'''bugs''':<br />
* when opening a file with a broken link, the alert dialog doesn't show well the names of missing files.<br />
<br />
===Image propriety window===<br />
'''status''': code started, not finished<br />
<br />
'''TODO''': (refering to the mockup on this page)<br />
* thumbnail<br />
* ...<br />
<br />
==Summary==<br />
<br />
Organizing linked bitmap images is quite a hassle at the moment. When a bitmap file is renamed or moved to a different location, the corresponding bitmap links need to be changed manually one by one in Inkscape, involving a tedious copy and paste process for the filenames. This can be improved.<br />
This is an alternative to the method proposed in the article [[Linked bitmap manager]].<br />
<br />
==Proposal==<br />
<br />
The proposal is to add some minor enhancements to the existing image properties dialog, in order to improve its usability and solve broken links in an easy and automated way.<br />
<br />
The first thing that has to be solved is the inconsistency in absolute/relative linking. At the moment all the images are linked with absolute paths, and that can be very inconvenient when working on the same file over a network.<br />
The images in the same directory than the SVG file should be linked with relative paths, and so the images in children directories. This condition can be extended to folders contained by the same parent folder that contains the SVG.<br />
<br />
That would solve common problems like broken links if the file was created or is retrieved from a remote machine over a samba mount in linux, for instance.<br />
<br />
Another common situation where absolute links are useless is a project retrieved from a backup. Again, all files have to be re-linked.<br />
So in the first place, fixing the absolute/relative linking will solve a lot of broken links.<br />
<br />
However, that wouldn't fix all the broken links, and there are several situations where moving or renaming a linked file will result in a broken link, so another strategy should be prepared for that.<br />
<br />
As it would discussed in the mailing list and related bug reports, the lack of a browse button in the image properties dialog makes it too tedious to re-link missing images, so adding that button would make things easier.<br />
<br />
But having dozens of broken links would be still a hassle even having that button, so a "smart re-linking" strategy would be handy.<br />
<br />
Adding a modal warning about broken links would be excessive since we already have a pretty visible way to display that there are missing bitmaps, so the focus should be put on providing an automated way to resolve broken links using a single manual replacement. As it was expressed earlier, a proper management of absolute and relative links would help with this task.<br />
<br />
==Image Properties Dialog Re-design==<br />
<br />
One of the most annoying things about the Image Properties dialog is that one window is opened for each image. That window should be re-utilized and be dockable. When the user selects another image, its information should fill the same properties window, not a new one.<br />
This dialog should be also accessible from the Object menu (like the object properties dialog), not only from the context menu of a selected image.<br />
<br />
[[File:new-image-properties-dialog.png]]<br />
<br />
At the top there's an area that shows general information about the image, along with a thumbnail. This will give a glimpse about the image we're working on.<br />
<br />
The URL field willbe accompained by a browse button for easy image re-linking.<br />
The URL text can be rendered red if the link is broken, giving a visual hint to the user that the path isn't correct. <br />
<br />
I added radio buttons for selecting if the image is linked or embedded, since that is part of the image properties and it would make sense to put it in that dialog instead of a separate extension.<br />
<br />
The fields for the dimensions of the image were preserved, adding a units selector and a proportional transformation lock.<br />
<br />
The position fields were removed, since they are not (from the user point of view) part of the image properties, but an attribute of the object on the document. It isn't likely that a user will set the position of the image object on the document from a window that covers it, He will probably use the tool controls bar selectors instead.<br />
<br />
An "advanced options" area was added. It lets the user enter the object ID, change the resolution of the image and use the original image's aspect ratio.<br />
<br />
:'''Comment:''' What about adding a checkbox in the section ''image source'', just below the edit control ''URL'' named ''Relative'' and to display the (on-the-fly-calculated) commun URL prefix (between the linked image and the Inkscape file) in a grey font? Best regards --[[User:Uncopy|Uncopy]] 10:52, 27 October 2009 (UTC)<br />
<br />
:'''Comment:''' The radio buttons should be for absolute/relative, and for embedded/linked there should be a push button that says "embed" or "extract..." based on the state of the image. Embedded/linked cannot be a radio button, because switching to "linked" needs to bring up a file browser. Doing so in response to radio button change breaks all the interface guidelines I know. --[[User:Tweenk|Tweenk]] 19:31, 5 March 2010 (UTC)<br />
<br />
:'''Comment:''' I'm ok with adding the relative/absolute switch. My original proposal was to do it kind of automatically, but I can see that it can be really problematic.<br />
Regarding the Embedded/linked thing, the original proposal considers "linked" as the default importing strategy. This has been changed recently in inkscape but I think it's plain wrong. Embedding always and then extracting contributes to having duplicates of the original images everywhere. I think that embedding should be the default for the "make bitmap copy" command, and in that case the extract command should make sense.<br />
The original proposal doesn't go against that practice either: if the image is already embedded, the file browser is hidden. If you click on the "linked" radio button, then the extract dialog would pop up.<br />
We must, however, find a way to make all the situations co-exist nicely: linked to embeded / embedded to linked (extracted) / Re-link linked image / Re-link embedded image. --[[User:Gez|Gez]] 19:31, 3 May 2010 (UTC)<br />
<br />
==Smart image re-linking==<br />
<br />
If there are several images with broken links and we choose the right path for one of those images (and they share the same location) Inkscape should compare the common location of the broken links and fix the remaining images with the new location automatically.<br />
<br />
'''Example:'''<br />
there are 3 images with broken absolute links:<br />
<br />
# /media/disk/inkscape-works/images/cat.png<br />
# /media/disk/inkscape-works/images/dog.png<br />
# /media/disk/inkscape-works/images/bird.png<br />
<br />
when the user sets a relative link for the first image to images/cat.png the other images should be automatically relinked, since they had:<br />
* broken links<br />
* the same orignal path<br />
* they exist in the new location.<br />
<br />
This operation could be silent, but when there are several images the re-linking process can take some time, so a confirmation window would provide a clear warning about the operation is going to be performed, with the possibility of choosing "yes" to perform the re-link process with the images found, or skipping it choosing "no"<br />
This window would appear right after a single re-link.<br />
<br />
[[File:relink-confirmation.png]]<br />
<br />
[[File:relink-confirmation-details.png]]<br />
<br />
The confirmation window can optionally show details about the images that are going to be re-linked, with the ability to untick the items that the user doesn't want to automatically re-link.<br />
<br />
: '''Comment:''' It is possible to uncheck all images and then click "yes", which doesn't make much sense. The text should be worded in a different way. For example, the prompt could be something like "Additional missing images were found. Select the image links you want to fix", choices would be "ok" and "cancel", and the list would always be visible. --[[User:Tweenk|Tweenk]] 19:24, 5 March 2010 (UTC)<br />
<br />
==Manual selection of relative or absolute paths==<br />
Steren pointed me out that there are some situations where selecting manually if the image will be linked using an absolute or a relative path.<br />
In that case, the file selector window that opens with the "browse" button of the Image Properties dialog could have radio buttons for selecting absolute or relative. The default value would be proposed by inkscape according the guidelines discussed earlier, but the user would have the ability to force the path to be relative or absolute, according his needs.<br />
However, that feature imposes a potential problem: How the smart re-linking feature should act in that case? The automatically re-linked images would use the same path type than the manually selected?<br />
<br />
==Linked vs. Embedded==<br />
The new image properties dialog would have radio buttons for choosing if the image is linked or embedded.<br />
<br />
The behavior of those buttons would be the following:<br />
* If the image is linked (default for the imported bitmaps) the behavior would be the described earlier in this blueprint<br />
* if the user chooses "embedded", the url input and its browse button will be grayed out, and the image will be embedded into the SVG document<br />
* if the user chooses "linked" on an image that was previously embedded, a file dialog will be opened, prompting the user to enter a location and a file name (by default the id and the path of the SVG file will be used) to extract and save the image.<br />
* if the link is broken, the "embedded" option will be grayed out until a valid path is set.<br />
<br />
: '''Comment:''' Embedded / Linked cannot be a radio button, because when we open a file with an embedded image, it has no path assigned. The button should say "extract..." when the image is embedded and bring up a file browser that allows the user to choose the location, and it should say "embed" when the image is linked. There should be a different radio button though: one that allows the user to choose between an absolute and a relative link. --[[User:Tweenk|Tweenk]] 19:29, 5 March 2010 (UTC)<br />
<br />
==Image Resolution==<br />
At the moment inkscape doesn't use the imported image's resolution value and use 90 dpi instead. There is a whishlist item in Launchpad about that and it should be fixed in order to implement this feature, otherwise the resolution value wouldn't make sense in this dialog.<br />
Notice that resolution value would change the "real world units" size of the image in the document, so changing that value would have impact in the dimensions selectors if they're set to real world units.<br />
The original file's resolution is important because it would tell inkscape what dimensions use for the imported image on the document.<br />
In my oppinion, if the default document's units are real world units, the resolution value should be used; if pixels are used as default units, the resolution should be disregarded, and grayed out in the dialog.<br />
<br />
<br />
==General Benefits of this change==<br />
<br />
These enhancements would tackle several usability issues in the current image properties dialog and provide an easy and straightforward solution for broken image links.<br />
The image properties would be unified in a single window, adding features that are currently available only via extensions, in locations that may not be so obvious for the new users.<br />
<br />
==TODO== <br />
There are a couple of interesting suggestions that can be added to this dialog but I hadn't the time to develop:<br />
* The thumbnail could be used for external editing (double clicking on it, or using a button)<br />
* Add a new option for embedded images: re-link to the original file. <br />
<br />
[[Category:Proposals]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_properties_dialog_enhancements&diff=62713Image properties dialog enhancements2010-06-07T20:39:10Z<p>Steren: </p>
<hr />
<div>= Image properties dialog enhancements =<br />
<br />
==Current Status==<br />
<br />
This blueprint is no more in a blueprint state.<br />
<br />
Work has been done by students from [http://www.ec-lyon.fr Ecole Centrale Lyon]. You can read their report [[File:Centrale_Lyon_2010.pdf]]. Contact [[User:Steren]] for more information.<br />
<br />
The code is currently in a [https://code.launchpad.net/~centralelyon2010/inkscape/imagelinks2 branch]. The main features were added, but finishing, testing, reviewing and polishing are needed to merge it into trunk.<br />
<br />
===Relative links===<br />
'''status''': to test<br />
<br />
'''bugs''':<br />
*<br />
<br />
===Relink tool===<br />
'''status''': features are here, need to polish the UI<br />
<br />
'''TODO''':<br />
* do not show an alert dialog when relinking is finished, prefer the <br />
<br />
'''bugs''':<br />
* when opening a file with a broken link, the alert dialog doesn't show well the names of missing files.<br />
<br />
===Image propriety window===<br />
'''status''': code started, not finished<br />
<br />
'''TODO''': (refering to the mockup on this page)<br />
* thumbnail<br />
* ...<br />
<br />
==Summary==<br />
<br />
Organizing linked bitmap images is quite a hassle at the moment. When a bitmap file is renamed or moved to a different location, the corresponding bitmap links need to be changed manually one by one in Inkscape, involving a tedious copy and paste process for the filenames. This can be improved.<br />
This is an alternative to the method proposed in the article [[Linked bitmap manager]].<br />
<br />
==Proposal==<br />
<br />
The proposal is to add some minor enhancements to the existing image properties dialog, in order to improve its usability and solve broken links in an easy and automated way.<br />
<br />
The first thing that has to be solved is the inconsistency in absolute/relative linking. At the moment all the images are linked with absolute paths, and that can be very inconvenient when working on the same file over a network.<br />
The images in the same directory than the SVG file should be linked with relative paths, and so the images in children directories. This condition can be extended to folders contained by the same parent folder that contains the SVG.<br />
<br />
That would solve common problems like broken links if the file was created or is retrieved from a remote machine over a samba mount in linux, for instance.<br />
<br />
Another common situation where absolute links are useless is a project retrieved from a backup. Again, all files have to be re-linked.<br />
So in the first place, fixing the absolute/relative linking will solve a lot of broken links.<br />
<br />
However, that wouldn't fix all the broken links, and there are several situations where moving or renaming a linked file will result in a broken link, so another strategy should be prepared for that.<br />
<br />
As it would discussed in the mailing list and related bug reports, the lack of a browse button in the image properties dialog makes it too tedious to re-link missing images, so adding that button would make things easier.<br />
<br />
But having dozens of broken links would be still a hassle even having that button, so a "smart re-linking" strategy would be handy.<br />
<br />
Adding a modal warning about broken links would be excessive since we already have a pretty visible way to display that there are missing bitmaps, so the focus should be put on providing an automated way to resolve broken links using a single manual replacement. As it was expressed earlier, a proper management of absolute and relative links would help with this task.<br />
<br />
==Image Properties Dialog Re-design==<br />
<br />
One of the most annoying things about the Image Properties dialog is that one window is opened for each image. That window should be re-utilized and be dockable. When the user selects another image, its information should fill the same properties window, not a new one.<br />
This dialog should be also accessible from the Object menu (like the object properties dialog), not only from the context menu of a selected image.<br />
<br />
[[File:new-image-properties-dialog.png]]<br />
<br />
At the top there's an area that shows general information about the image, along with a thumbnail. This will give a glimpse about the image we're working on.<br />
<br />
The URL field willbe accompained by a browse button for easy image re-linking.<br />
The URL text can be rendered red if the link is broken, giving a visual hint to the user that the path isn't correct. <br />
<br />
I added radio buttons for selecting if the image is linked or embedded, since that is part of the image properties and it would make sense to put it in that dialog instead of a separate extension.<br />
<br />
The fields for the dimensions of the image were preserved, adding a units selector and a proportional transformation lock.<br />
<br />
The position fields were removed, since they are not (from the user point of view) part of the image properties, but an attribute of the object on the document. It isn't likely that a user will set the position of the image object on the document from a window that covers it, He will probably use the tool controls bar selectors instead.<br />
<br />
An "advanced options" area was added. It lets the user enter the object ID, change the resolution of the image and use the original image's aspect ratio.<br />
<br />
:'''Comment:''' What about adding a checkbox in the section ''image source'', just below the edit control ''URL'' named ''Relative'' and to display the (on-the-fly-calculated) commun URL prefix (between the linked image and the Inkscape file) in a grey font? Best regards --[[User:Uncopy|Uncopy]] 10:52, 27 October 2009 (UTC)<br />
<br />
:'''Comment:''' The radio buttons should be for absolute/relative, and for embedded/linked there should be a push button that says "embed" or "extract..." based on the state of the image. Embedded/linked cannot be a radio button, because switching to "linked" needs to bring up a file browser. Doing so in response to radio button change breaks all the interface guidelines I know. --[[User:Tweenk|Tweenk]] 19:31, 5 March 2010 (UTC)<br />
<br />
:'''Comment:''' I'm ok with adding the relative/absolute switch. My original proposal was to do it kind of automatically, but I can see that it can be really problematic.<br />
Regarding the Embedded/linked thing, the original proposal considers "linked" as the default importing strategy. This has been changed recently in inkscape but I think it's plain wrong. Embedding always and then extracting contributes to having duplicates of the original images everywhere. I think that embedding should be the default for the "make bitmap copy" command, and in that case the extract command should make sense.<br />
The original proposal doesn't go against that practice either: if the image is already embedded, the file browser is hidden. If you click on the "linked" radio button, then the extract dialog would pop up.<br />
We must, however, find a way to make all the situations co-exist nicely: linked to embeded / embedded to linked (extracted) / Re-link linked image / Re-link embedded image. --[[User:Gez|Gez]] 19:31, 3 May 2010 (UTC)<br />
<br />
==Smart image re-linking==<br />
<br />
If there are several images with broken links and we choose the right path for one of those images (and they share the same location) Inkscape should compare the common location of the broken links and fix the remaining images with the new location automatically.<br />
<br />
'''Example:'''<br />
there are 3 images with broken absolute links:<br />
<br />
# /media/disk/inkscape-works/images/cat.png<br />
# /media/disk/inkscape-works/images/dog.png<br />
# /media/disk/inkscape-works/images/bird.png<br />
<br />
when the user sets a relative link for the first image to images/cat.png the other images should be automatically relinked, since they had:<br />
* broken links<br />
* the same orignal path<br />
* they exist in the new location.<br />
<br />
This operation could be silent, but when there are several images the re-linking process can take some time, so a confirmation window would provide a clear warning about the operation is going to be performed, with the possibility of choosing "yes" to perform the re-link process with the images found, or skipping it choosing "no"<br />
This window would appear right after a single re-link.<br />
<br />
[[File:relink-confirmation.png]]<br />
<br />
[[File:relink-confirmation-details.png]]<br />
<br />
The confirmation window can optionally show details about the images that are going to be re-linked, with the ability to untick the items that the user doesn't want to automatically re-link.<br />
<br />
: '''Comment:''' It is possible to uncheck all images and then click "yes", which doesn't make much sense. The text should be worded in a different way. For example, the prompt could be something like "Additional missing images were found. Select the image links you want to fix", choices would be "ok" and "cancel", and the list would always be visible. --[[User:Tweenk|Tweenk]] 19:24, 5 March 2010 (UTC)<br />
<br />
==Manual selection of relative or absolute paths==<br />
Steren pointed me out that there are some situations where selecting manually if the image will be linked using an absolute or a relative path.<br />
In that case, the file selector window that opens with the "browse" button of the Image Properties dialog could have radio buttons for selecting absolute or relative. The default value would be proposed by inkscape according the guidelines discussed earlier, but the user would have the ability to force the path to be relative or absolute, according his needs.<br />
However, that feature imposes a potential problem: How the smart re-linking feature should act in that case? The automatically re-linked images would use the same path type than the manually selected?<br />
<br />
==Linked vs. Embedded==<br />
The new image properties dialog would have radio buttons for choosing if the image is linked or embedded.<br />
<br />
The behavior of those buttons would be the following:<br />
* If the image is linked (default for the imported bitmaps) the behavior would be the described earlier in this blueprint<br />
* if the user chooses "embedded", the url input and its browse button will be grayed out, and the image will be embedded into the SVG document<br />
* if the user chooses "linked" on an image that was previously embedded, a file dialog will be opened, prompting the user to enter a location and a file name (by default the id and the path of the SVG file will be used) to extract and save the image.<br />
* if the link is broken, the "embedded" option will be grayed out until a valid path is set.<br />
<br />
: '''Comment:''' Embedded / Linked cannot be a radio button, because when we open a file with an embedded image, it has no path assigned. The button should say "extract..." when the image is embedded and bring up a file browser that allows the user to choose the location, and it should say "embed" when the image is linked. There should be a different radio button though: one that allows the user to choose between an absolute and a relative link. --[[User:Tweenk|Tweenk]] 19:29, 5 March 2010 (UTC)<br />
<br />
==Image Resolution==<br />
At the moment inkscape doesn't use the imported image's resolution value and use 90 dpi instead. There is a whishlist item in Launchpad about that and it should be fixed in order to implement this feature, otherwise the resolution value wouldn't make sense in this dialog.<br />
Notice that resolution value would change the "real world units" size of the image in the document, so changing that value would have impact in the dimensions selectors if they're set to real world units.<br />
The original file's resolution is important because it would tell inkscape what dimensions use for the imported image on the document.<br />
In my oppinion, if the default document's units are real world units, the resolution value should be used; if pixels are used as default units, the resolution should be disregarded, and grayed out in the dialog.<br />
<br />
<br />
==General Benefits of this change==<br />
<br />
These enhancements would tackle several usability issues in the current image properties dialog and provide an easy and straightforward solution for broken image links.<br />
The image properties would be unified in a single window, adding features that are currently available only via extensions, in locations that may not be so obvious for the new users.<br />
<br />
==TODO== <br />
There are a couple of interesting suggestions that can be added to this dialog but I hadn't the time to develop:<br />
* The thumbnail could be used for external editing (double clicking on it, or using a button)<br />
* Add a new option for embedded images: re-link to the original file. <br />
<br />
[[Category:Proposals]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=User:Steren&diff=62683User:Steren2010-06-07T14:33:08Z<p>Steren: </p>
<hr />
<div>I've participated in one student project and mentored two : (projects from [http://www.ec-lyon.fr Ecole Centrale Lyon])<br />
* LPE for groups + stacking + envelope (2008): see report [[File:Report_PI_Inkscape_2008.pdf]], added into trunk<br />
* Spray Tool (2009): added into trunk (mentored by Cedric Gémy and me)<br />
* Image Links (2010): see report [[File:Centrale_Lyon_2010.pdf]], currently in a [https://code.launchpad.net/~centralelyon2010/inkscape/imagelinks2 branch]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=User:Steren&diff=62311User:Steren2010-05-24T22:54:13Z<p>Steren: </p>
<hr />
<div>I've participated in one student project and mentored two : (projects from [http://www.ec-lyon.fr Ecole Centrale Lyon])<br />
* LPE for groups + stacking + envelope (2008): see report [[File:Report_PI_Inkscape_2008.pdf]], added into trunk<br />
* Spray Tool (2009): added into trunk<br />
* Image Links (2010): see report [[File:Centrale_Lyon_2010.pdf]], currently in a [https://code.launchpad.net/~centralelyon2010/inkscape/imagelinks2 branch]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=User:Steren&diff=62305User:Steren2010-05-24T22:53:15Z<p>Steren: </p>
<hr />
<div>I've participated in one student project and mentored two :<br />
* LPE for groups + stacking + envelope (2008): see report [[File:Report_PI_Inkscape_2008.pdf]], added into trunk<br />
* Spray Tool (2009): added into trunk<br />
* Image Links (2010): see report [[File:Centrale_Lyon_2010.pdf]], currently in a [https://code.launchpad.net/~centralelyon2010/inkscape/imagelinks2 branch]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=File:Report_PI_Inkscape_2008.pdf&diff=62299File:Report PI Inkscape 2008.pdf2010-05-24T22:52:30Z<p>Steren: student project from Ecole Centrale Lyon 2008 : LPE for groups, stacking and envelope</p>
<hr />
<div>student project from Ecole Centrale Lyon 2008 : LPE for groups, stacking and envelope</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=User:Steren&diff=62293User:Steren2010-05-24T22:45:49Z<p>Steren: </p>
<hr />
<div>I've participated in one student project and mentored two :<br />
* LPE for groups + stacking + envelope (2008): added into trunk<br />
* Spray Tool (2009): added into trunk<br />
* Image Links (2010): see report [[File:Centrale_Lyon_2010.pdf]], currently in a [https://code.launchpad.net/~centralelyon2010/inkscape/imagelinks2 branch]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=User:Steren&diff=62287User:Steren2010-05-24T22:44:49Z<p>Steren: Created page with 'I've participated in one student project and mentored two : * LPE for groups + stacking + envelope (2008): added into trunk * Spray Tool (2009): added into trunk * Image Links (2...'</p>
<hr />
<div>I've participated in one student project and mentored two :<br />
* LPE for groups + stacking + envelope (2008): added into trunk<br />
* Spray Tool (2009): added into trunk<br />
* Image Links (2010): see report [[File:Centrale_Lyon_2010.pdf|here]], currently in a [https://code.launchpad.net/~centralelyon2010/inkscape/imagelinks2 branch]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=File:Centrale_Lyon_2010.pdf&diff=62281File:Centrale Lyon 2010.pdf2010-05-24T22:41:33Z<p>Steren: Report of a student project from Ecole Centrale Lyon in 2010</p>
<hr />
<div>Report of a student project from Ecole Centrale Lyon in 2010</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Release_notes/0.48&diff=60487Release notes/0.482010-03-28T17:30:43Z<p>Steren: /* Spray Tool */</p>
<hr />
<div>==Inkscape 0.48==<br />
'''(not released yet - [[AnnouncePlanning048]])'''<br />
<br />
==Release highlights==<br />
<br />
(TODO)<br />
<br />
==Tools==<br />
<br />
===Node Tool===<br />
<br />
During Google Summer of Code 2009, the node tool underwent an extensive rewrite. Along with more maintainable code, it brings several new features.<br />
<br />
; '''Multi-path editing'''<br />
: Any number of paths can be selected for node editing at once.<br />
; '''Improved clippath / mask editing'''<br />
: The clipping path or mask of an object can be edited at the same time as the object. The clip / mask editing buttons in the node tool are now toggle buttons, rather than mode switch buttons. If the object is transformed after applying a clipping path, the clipping path is no longer offset when editing it in the node tool. If the clipping path is a group, all paths in the group can be edited simultaneously.<br />
; '''Improved node join'''<br />
: It is now possible to join nodes from different paths. More than two endnodes can be joined at once—the distances between nodes will be used to determine which nodes to join, with the closest pairs being joined first. When nothing can be joined (less than 2 endnodes in selecion), each selected stretch of nodes will be joined into one node.<br />
; '''Improved segment join'''<br />
: It is now possible to create a segment between endnodes from different paths. More than one segment can be created at once—the distances between nodes will be used to determine which nodes to join with a segment, with the closest pairs being joined first. When nothing can be joined (less than 2 endnodes in selection), each selected stretch of nodes will have its middle nodes removed, leaving only one segment.<br />
; '''Node transforms'''<br />
: It is now possible to transform the nodes using the mouse and transformation handles similar to those in the selector tool. They can be turned on and off using the button in the node toolbar. When the handles are visible, clicking on a selected node will switch between scaling and rotation mode, instead of selecting only that node. You can also use Shift+H to switch the mode. All other operations work normally when transform handles are shown.<br />
; '''Path direction tools'''<br />
: Little harpoons are optionally shown in the middle of each segment, visualizing the direction of the path. This is useful when preparing a guide path for text, setting markers, and debugging extensions and Inkscape itself. The "Reverse" command (Shift+R) reverses the direction of subpaths that have some selected nodes, or all subpaths if the node selection is empty.<br />
; '''Customizable path update'''<br />
: Two new preferences allow you to specify when the path and its outline should be updated. Turning off live update of paths will improve performance for complex drawings.<br />
; '''Improved tips'''<br />
: The tips displayed for nodes and handles are more concise and affected by what modifier keys are pressed.<br />
<br />
For a detailed feature comparison between the old and new tool, see [[GSoC2009 Node Tool Rewrite]].<br />
<br />
===Spray Tool===<br />
You first need to select one or several items, then select the Spray Tool. To spray, click on the canvas, then move the mouse or scroll the mouse wheel.<br />
<br />
Three modes are available.<br />
<br />
*''Spray Copy mode :'' each sprayed item is independent from the others.<br />
*''Spray Clone mode :'' each sprayed item is a clone of the selected item. Changing the properties of the original item will affect the clones.<br />
*''Spray Single Path Mode :'' everything you spray is in a single path. You may need to convert your item into a path to make it work properly.<br />
<br />
'''Spray options'''<br />
<br />
*Amount : spray more or less items.<br />
<br />
*Rotation : randomly rotates items around the original rotation value. <br />
*Scale : randomly scales items around the original scale value. <br />
<br />
*Scatter : low values to spray items under the cursor, high values for a more uniform repartition over the spray zone.<br />
*Focus : items are sprayed following a ring. This parameters modifies the radius of the circle. Default at 0 to spray a spot. <br />
<br />
Use keys ↑ and ↓ to control the size of of sprayed items. Use ← and → to set the width of the cursor.<br />
<br />
<br />
The Spray tool is a perfect match for the transforming, duplicating, and deleting modes of the Tweak tool.<br />
<br />
<!--<br />
==Live Path Effects (LPE)==<br />
<br />
===Node tool changes===<br />
The new node tool means slightly different LPE editing too. Such as ...<br />
<br />
===New effects===<br />
<br />
* '''Extrude''' Similar to the Python extension <br />
--><br />
<br />
==Import/Export==<br />
===Improved bitmap image import===<br />
<br />
Bitmaps are now always embedded when pixel data is pasted or dragged into Inkscape's window (for example when copying parts of an image from GIMP). Files with automatically generated names like "inkscape_pasted_image_..." are no longer created in the document directory. When importing or opening bitmap images, a dialog is displayed that asks whether you want to link the image or embed it.<br />
<br />
===New LaTeX export for PDF/EPS/PS===<br />
<br />
Similar to GNUPlot's `epslatex' output terminal and Xfig's combined PDF/LaTeX output, Inkscape can now export graphics to PDF with an accompanying LaTeX file that overlays the text over the PDF when inputted in LaTeX. The image's text is typeset by LaTeX, so for example mathematical expressions are rendered correctly, and all text will be in the font and style of the LaTeX document (even when changing the document's font afterwards).<br />
<br />
''(the following description assumes export to PDF, but will work the same for EPS and PS)''<br />
Two files will be created: a PDF file containing all graphics, without text; and a LaTeX file with the same name, containing all text, and code to include the PDF and overlay the text. To include the exported image in LaTeX, one writes<br />
<br />
\begin{figure} <br />
\centering<br />
\def\svgwidth{\columnwidth} % sets the image width, this is optional<br />
\input{image.tex}<br />
\end{figure}<br />
<br />
A more thorough description of how to use the new feature (and automate the exporting/inclusion of the image in LaTeX) is given in this PDF: [http://wiki.inkscape.org/wiki/images/SVG_in_LaTeX.pdf SVG in LaTeX].<br />
<br />
====From the GUI====<br />
When exporting to PDF/EPS/PS from Inkscape's GUI, the usual dialog pops up after selecting to which PDF/EPS/PS file to export to. In this dialog, you can find the PDF/EPS/PS+LaTeX option.<br />
<br />
====Command line option====<br />
When exporting to PDF/EPS/PS from the command line, adding --export-latex will turn the LaTeX export on. For example<br />
<br />
inkscape image.svg -z -D --export-pdf=image.pdf --export-latex<br />
<br />
==Extensions==<br />
===New and improved extensions===<br />
<br />
* The new '''Generate from Path > Voronoi Pattern''' extension creates a random pattern of Voronoi cells. The pattern will be accessible from the Fill and Stroke dialog. The pattern can be made to be smooth at the edges by choosing a positive border, or sparse at the edges by using a negative border.<br />
* The new '''Render > Wireframe Sphere''' extension draws the globe as a collection of ellipses representing a sphere's latitude and longitude lines. The number of lines is adjustable, as well as the tilt and rotation. There is an option to hide the lines at the back of the sphere.<br />
* The new '''Render > Barcode - Datamatrix''' extension renders a DataMatrix 2D barcode, as specified in BS ISO/IEC 16022:2006. The number of rows and columns of the DataMatrix is adjustable. If more data is given than can be contained in one DataMatrix, more than one DataMatrix will be produced.<br />
* The new '''Modify Path > Pixelsnap''' extension aligns rectangles and paths to pixel boundaries, to create sharp web and digital graphics.<br />
* The new '''Color > Black and White''' extension turns the selection colors into black and white.<br />
<br />
<!-- ==Filters==<br />
<br />
==SVG Support==<br />
<br />
==Editing Aids== --><br />
<br />
==Other features==<br />
<br />
* Arch paper sizes are added in the Document Properties dialog<br />
* Displaying the '''font samples''' in the drop-down list of the Text tool is now optional. In Inkscape Preferences, go to Tools, Text, and uncheck "Show font samples in the drop-down list" if you don't want to see the samples. This will speed up displaying the list the first time you open it<br />
* Items in the File > Open Recent menu, when mouseovered, show tooltips with the full URI of each file in the list. Also, files that are in the list but are missing or unaccessible are automatically hidden<br />
* When a flowed text is truncated (i.e. the frame is too small for the entire text), the frame is shown red, and the statusbar hint includes '''[truncated]'''. You need to resize the frame to see the truncated end of the text. Analogously, if the path of a text-on-path object is too short to display the entire text, the statusbar will report it as '''[truncated]'''<br />
* Clicking the text alignment buttons (Left, Center, Right) on the Text tool's controls bar now does not let the text jump: it stays within the same bounding box as before, only changing the alignment<br />
* The position of text's baseline anchor (the small square) is now dependent of the alignment: for left-aligned text it is, as before, at the left end, for centered text in the middle, and for the right-aligned text it is at the right end of the text's first line (this is for horizontal text; for vertical, it is correspondingly at top, middle, or bottom of the first column). This allows snapping, aligning and distributing of text relative the side to which it's aligned<br />
* Snapping of gradient handles has been improved and now behaves similar to the snapping of all other handles and objects<br />
* When snapping to a bounding box, that bounding box will be shown for a moment (tied to the snap indicator)<br />
* If a new object is being created on the canvas with snapping enabled, then a snap indicator will also be shown for the first point<br />
* There are now options for Margins when resizing a document to a selection or the drawing in Document Properties<br />
* Preferences have been added to allow automatic grouping when setting a Clippath or Mask<br />
* Bitmap copies created using the Make a Bitmap Copy command (Alt+B) are now embedded. Previously they were saved in an automatically generated file and linked<br />
* The file preview size limit (in the File > Open and File > Import dialog box) is now 10 MB (1.3 MB in 0.47)<br />
<br />
===Extended input device configuration===<br />
<br />
The stock Input Devices dialog has been replaced with a completely redone version that provides a more useful representation of settings. It also contains a simple area for testing different inputs of different devices.<br />
<br />
Additionally hardware setup itself has been separated from general settings to allow for easier dynamic switching of settings appropriate to the task at hand.<br />
<br />
==User interface==<br />
<br />
===Adaptive UI===<br />
(In progress [[User:JonCruz|JonCruz]])<br />
<br />
===Custom Swatches===<br />
<br />
Custom swatches can be created and used on a per-document basis. An "Auto" color palette will track swatches in the current document and allow them to be set and used. The use is "live" with changes to the swatch being applied automatically to all objects set to it. The swatches can also be gradients and not just simple colors.<br />
<br />
===New cursors in Selector===<br />
<br />
Selector tool has a new mouse cursor (arrow with an open hand) for when your mouse is over a selectable object, and another (arrow with clinched hand) for when you're dragging an object. This improves precision of selection and UI consistency (previously, the mouse cursor over a selectable object was different across platforms, e.g. hand icon on Linux or four-way arrow on Windows).<br />
<br />
===Translations===<br />
<br />
New Farsi translation (in progress).<br />
<br />
==Tutorials==<br />
<br />
* SVG files are now optimized with Scour (filesize reduced by 40%).<br />
* Bitstream Vera fonts replaced with generic sans and serif fonts (solves many font substitution issues).<br />
* New Interpolate tutorial (Help > Tutorials > Inkscape: Interpolate).<br />
* New translations in Farsi, Belarussian and Dutch.<br />
<br />
==Notable bug fixes==<br />
<br />
* The 3D tool no longer inserts an inkscape:perspective element into SVG when it is not needed (i.e. when the document has no 3D box objects).<br />
* Wrong clippaths and masks with cyclic recursion (i.e. clippaths or masks that refer to themselves via other clippaths or masks) no longer crash Inkscape.<br />
* Default unit setting for the XY grid is now respected when creating a new grid.<br />
* Pasting Live Path Effect stacks now works. It adds the stack of the copied object to the end of the LPE stack (if present) of the object it is pasted to.<br />
<br />
==Known issues==<br />
<br />
==Previous releases==<br />
<br />
* [[ReleaseNotes047]]<br />
* [[ReleaseNotes046]]<br />
* [[ReleaseNotes045]]<br />
* [[ReleaseNotes044]]<br />
* [[ReleaseNotes043]]<br />
* [[ReleaseNotes042]]<br />
* [[ReleaseNotes041]]<br />
* [[ReleaseNotes040]]<br />
* [[ReleaseNotes039]]<br />
* [[ReleaseNotes038]]<br />
* [[ReleaseNotes037]]<br />
* [[ReleaseNotes036]]<br />
* [[ReleaseNotes035]]<br />
<br />
[[Category:Marketing]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Release_notes/0.48&diff=60481Release notes/0.482010-03-28T17:30:03Z<p>Steren: /* Spray Tool */</p>
<hr />
<div>==Inkscape 0.48==<br />
'''(not released yet - [[AnnouncePlanning048]])'''<br />
<br />
==Release highlights==<br />
<br />
(TODO)<br />
<br />
==Tools==<br />
<br />
===Node Tool===<br />
<br />
During Google Summer of Code 2009, the node tool underwent an extensive rewrite. Along with more maintainable code, it brings several new features.<br />
<br />
; '''Multi-path editing'''<br />
: Any number of paths can be selected for node editing at once.<br />
; '''Improved clippath / mask editing'''<br />
: The clipping path or mask of an object can be edited at the same time as the object. The clip / mask editing buttons in the node tool are now toggle buttons, rather than mode switch buttons. If the object is transformed after applying a clipping path, the clipping path is no longer offset when editing it in the node tool. If the clipping path is a group, all paths in the group can be edited simultaneously.<br />
; '''Improved node join'''<br />
: It is now possible to join nodes from different paths. More than two endnodes can be joined at once—the distances between nodes will be used to determine which nodes to join, with the closest pairs being joined first. When nothing can be joined (less than 2 endnodes in selecion), each selected stretch of nodes will be joined into one node.<br />
; '''Improved segment join'''<br />
: It is now possible to create a segment between endnodes from different paths. More than one segment can be created at once—the distances between nodes will be used to determine which nodes to join with a segment, with the closest pairs being joined first. When nothing can be joined (less than 2 endnodes in selection), each selected stretch of nodes will have its middle nodes removed, leaving only one segment.<br />
; '''Node transforms'''<br />
: It is now possible to transform the nodes using the mouse and transformation handles similar to those in the selector tool. They can be turned on and off using the button in the node toolbar. When the handles are visible, clicking on a selected node will switch between scaling and rotation mode, instead of selecting only that node. You can also use Shift+H to switch the mode. All other operations work normally when transform handles are shown.<br />
; '''Path direction tools'''<br />
: Little harpoons are optionally shown in the middle of each segment, visualizing the direction of the path. This is useful when preparing a guide path for text, setting markers, and debugging extensions and Inkscape itself. The "Reverse" command (Shift+R) reverses the direction of subpaths that have some selected nodes, or all subpaths if the node selection is empty.<br />
; '''Customizable path update'''<br />
: Two new preferences allow you to specify when the path and its outline should be updated. Turning off live update of paths will improve performance for complex drawings.<br />
; '''Improved tips'''<br />
: The tips displayed for nodes and handles are more concise and affected by what modifier keys are pressed.<br />
<br />
For a detailed feature comparison between the old and new tool, see [[GSoC2009 Node Tool Rewrite]].<br />
<br />
===Spray Tool===<br />
You first need to select one or several items, then select the Spray Tool. To spray, click on the canvas, then move the mouse or scroll the mouse wheel.<br />
<br />
Three modes are available.<br />
<br />
*''Spray Copy mode :'' each sprayed item is independent from the others.<br />
*''Spray Clone mode :'' each sprayed item is a clone of the selected item. Changing the properties of the original item will affect the clones.<br />
*''Spray Single Path Mode :'' everything you spray is in a single path. You may need to convert your item into a path to make it work properly.<br />
<br />
'''Spray options'''<br />
<br />
*Amount : spray more or less object.<br />
<br />
*Rotation : randomly rotates items around the original rotation value. <br />
*Scale : randomly scales items around the original scale value. <br />
<br />
*Scatter : low values to spray items under the cursor, high values for a more uniform repartition over the spray zone.<br />
*Focus : items are sprayed following a ring. This parameters modifies the radius of the circle. Default at 0 to spray a spot. <br />
<br />
Use keys ↑ and ↓ to control the size of of sprayed items. Use ← and → to set the width of the cursor.<br />
<br />
<br />
The Spray tool is a perfect match for the transforming, duplicating, and deleting modes of the Tweak tool.<br />
<br />
<!--<br />
==Live Path Effects (LPE)==<br />
<br />
===Node tool changes===<br />
The new node tool means slightly different LPE editing too. Such as ...<br />
<br />
===New effects===<br />
<br />
* '''Extrude''' Similar to the Python extension <br />
--><br />
<br />
==Import/Export==<br />
===Improved bitmap image import===<br />
<br />
Bitmaps are now always embedded when pixel data is pasted or dragged into Inkscape's window (for example when copying parts of an image from GIMP). Files with automatically generated names like "inkscape_pasted_image_..." are no longer created in the document directory. When importing or opening bitmap images, a dialog is displayed that asks whether you want to link the image or embed it.<br />
<br />
===New LaTeX export for PDF/EPS/PS===<br />
<br />
Similar to GNUPlot's `epslatex' output terminal and Xfig's combined PDF/LaTeX output, Inkscape can now export graphics to PDF with an accompanying LaTeX file that overlays the text over the PDF when inputted in LaTeX. The image's text is typeset by LaTeX, so for example mathematical expressions are rendered correctly, and all text will be in the font and style of the LaTeX document (even when changing the document's font afterwards).<br />
<br />
''(the following description assumes export to PDF, but will work the same for EPS and PS)''<br />
Two files will be created: a PDF file containing all graphics, without text; and a LaTeX file with the same name, containing all text, and code to include the PDF and overlay the text. To include the exported image in LaTeX, one writes<br />
<br />
\begin{figure} <br />
\centering<br />
\def\svgwidth{\columnwidth} % sets the image width, this is optional<br />
\input{image.tex}<br />
\end{figure}<br />
<br />
A more thorough description of how to use the new feature (and automate the exporting/inclusion of the image in LaTeX) is given in this PDF: [http://wiki.inkscape.org/wiki/images/SVG_in_LaTeX.pdf SVG in LaTeX].<br />
<br />
====From the GUI====<br />
When exporting to PDF/EPS/PS from Inkscape's GUI, the usual dialog pops up after selecting to which PDF/EPS/PS file to export to. In this dialog, you can find the PDF/EPS/PS+LaTeX option.<br />
<br />
====Command line option====<br />
When exporting to PDF/EPS/PS from the command line, adding --export-latex will turn the LaTeX export on. For example<br />
<br />
inkscape image.svg -z -D --export-pdf=image.pdf --export-latex<br />
<br />
==Extensions==<br />
===New and improved extensions===<br />
<br />
* The new '''Generate from Path > Voronoi Pattern''' extension creates a random pattern of Voronoi cells. The pattern will be accessible from the Fill and Stroke dialog. The pattern can be made to be smooth at the edges by choosing a positive border, or sparse at the edges by using a negative border.<br />
* The new '''Render > Wireframe Sphere''' extension draws the globe as a collection of ellipses representing a sphere's latitude and longitude lines. The number of lines is adjustable, as well as the tilt and rotation. There is an option to hide the lines at the back of the sphere.<br />
* The new '''Render > Barcode - Datamatrix''' extension renders a DataMatrix 2D barcode, as specified in BS ISO/IEC 16022:2006. The number of rows and columns of the DataMatrix is adjustable. If more data is given than can be contained in one DataMatrix, more than one DataMatrix will be produced.<br />
* The new '''Modify Path > Pixelsnap''' extension aligns rectangles and paths to pixel boundaries, to create sharp web and digital graphics.<br />
* The new '''Color > Black and White''' extension turns the selection colors into black and white.<br />
<br />
<!-- ==Filters==<br />
<br />
==SVG Support==<br />
<br />
==Editing Aids== --><br />
<br />
==Other features==<br />
<br />
* Arch paper sizes are added in the Document Properties dialog<br />
* Displaying the '''font samples''' in the drop-down list of the Text tool is now optional. In Inkscape Preferences, go to Tools, Text, and uncheck "Show font samples in the drop-down list" if you don't want to see the samples. This will speed up displaying the list the first time you open it<br />
* Items in the File > Open Recent menu, when mouseovered, show tooltips with the full URI of each file in the list. Also, files that are in the list but are missing or unaccessible are automatically hidden<br />
* When a flowed text is truncated (i.e. the frame is too small for the entire text), the frame is shown red, and the statusbar hint includes '''[truncated]'''. You need to resize the frame to see the truncated end of the text. Analogously, if the path of a text-on-path object is too short to display the entire text, the statusbar will report it as '''[truncated]'''<br />
* Clicking the text alignment buttons (Left, Center, Right) on the Text tool's controls bar now does not let the text jump: it stays within the same bounding box as before, only changing the alignment<br />
* The position of text's baseline anchor (the small square) is now dependent of the alignment: for left-aligned text it is, as before, at the left end, for centered text in the middle, and for the right-aligned text it is at the right end of the text's first line (this is for horizontal text; for vertical, it is correspondingly at top, middle, or bottom of the first column). This allows snapping, aligning and distributing of text relative the side to which it's aligned<br />
* Snapping of gradient handles has been improved and now behaves similar to the snapping of all other handles and objects<br />
* When snapping to a bounding box, that bounding box will be shown for a moment (tied to the snap indicator)<br />
* If a new object is being created on the canvas with snapping enabled, then a snap indicator will also be shown for the first point<br />
* There are now options for Margins when resizing a document to a selection or the drawing in Document Properties<br />
* Preferences have been added to allow automatic grouping when setting a Clippath or Mask<br />
* Bitmap copies created using the Make a Bitmap Copy command (Alt+B) are now embedded. Previously they were saved in an automatically generated file and linked<br />
* The file preview size limit (in the File > Open and File > Import dialog box) is now 10 MB (1.3 MB in 0.47)<br />
<br />
===Extended input device configuration===<br />
<br />
The stock Input Devices dialog has been replaced with a completely redone version that provides a more useful representation of settings. It also contains a simple area for testing different inputs of different devices.<br />
<br />
Additionally hardware setup itself has been separated from general settings to allow for easier dynamic switching of settings appropriate to the task at hand.<br />
<br />
==User interface==<br />
<br />
===Adaptive UI===<br />
(In progress [[User:JonCruz|JonCruz]])<br />
<br />
===Custom Swatches===<br />
<br />
Custom swatches can be created and used on a per-document basis. An "Auto" color palette will track swatches in the current document and allow them to be set and used. The use is "live" with changes to the swatch being applied automatically to all objects set to it. The swatches can also be gradients and not just simple colors.<br />
<br />
===New cursors in Selector===<br />
<br />
Selector tool has a new mouse cursor (arrow with an open hand) for when your mouse is over a selectable object, and another (arrow with clinched hand) for when you're dragging an object. This improves precision of selection and UI consistency (previously, the mouse cursor over a selectable object was different across platforms, e.g. hand icon on Linux or four-way arrow on Windows).<br />
<br />
===Translations===<br />
<br />
New Farsi translation (in progress).<br />
<br />
==Tutorials==<br />
<br />
* SVG files are now optimized with Scour (filesize reduced by 40%).<br />
* Bitstream Vera fonts replaced with generic sans and serif fonts (solves many font substitution issues).<br />
* New Interpolate tutorial (Help > Tutorials > Inkscape: Interpolate).<br />
* New translations in Farsi, Belarussian and Dutch.<br />
<br />
==Notable bug fixes==<br />
<br />
* The 3D tool no longer inserts an inkscape:perspective element into SVG when it is not needed (i.e. when the document has no 3D box objects).<br />
* Wrong clippaths and masks with cyclic recursion (i.e. clippaths or masks that refer to themselves via other clippaths or masks) no longer crash Inkscape.<br />
* Default unit setting for the XY grid is now respected when creating a new grid.<br />
* Pasting Live Path Effect stacks now works. It adds the stack of the copied object to the end of the LPE stack (if present) of the object it is pasted to.<br />
<br />
==Known issues==<br />
<br />
==Previous releases==<br />
<br />
* [[ReleaseNotes047]]<br />
* [[ReleaseNotes046]]<br />
* [[ReleaseNotes045]]<br />
* [[ReleaseNotes044]]<br />
* [[ReleaseNotes043]]<br />
* [[ReleaseNotes042]]<br />
* [[ReleaseNotes041]]<br />
* [[ReleaseNotes040]]<br />
* [[ReleaseNotes039]]<br />
* [[ReleaseNotes038]]<br />
* [[ReleaseNotes037]]<br />
* [[ReleaseNotes036]]<br />
* [[ReleaseNotes035]]<br />
<br />
[[Category:Marketing]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Release_notes/0.48&diff=60475Release notes/0.482010-03-28T17:28:02Z<p>Steren: /* Spray Tool */ better explanations</p>
<hr />
<div>==Inkscape 0.48==<br />
'''(not released yet - [[AnnouncePlanning048]])'''<br />
<br />
==Release highlights==<br />
<br />
(TODO)<br />
<br />
==Tools==<br />
<br />
===Node Tool===<br />
<br />
During Google Summer of Code 2009, the node tool underwent an extensive rewrite. Along with more maintainable code, it brings several new features.<br />
<br />
; '''Multi-path editing'''<br />
: Any number of paths can be selected for node editing at once.<br />
; '''Improved clippath / mask editing'''<br />
: The clipping path or mask of an object can be edited at the same time as the object. The clip / mask editing buttons in the node tool are now toggle buttons, rather than mode switch buttons. If the object is transformed after applying a clipping path, the clipping path is no longer offset when editing it in the node tool. If the clipping path is a group, all paths in the group can be edited simultaneously.<br />
; '''Improved node join'''<br />
: It is now possible to join nodes from different paths. More than two endnodes can be joined at once—the distances between nodes will be used to determine which nodes to join, with the closest pairs being joined first. When nothing can be joined (less than 2 endnodes in selecion), each selected stretch of nodes will be joined into one node.<br />
; '''Improved segment join'''<br />
: It is now possible to create a segment between endnodes from different paths. More than one segment can be created at once—the distances between nodes will be used to determine which nodes to join with a segment, with the closest pairs being joined first. When nothing can be joined (less than 2 endnodes in selection), each selected stretch of nodes will have its middle nodes removed, leaving only one segment.<br />
; '''Node transforms'''<br />
: It is now possible to transform the nodes using the mouse and transformation handles similar to those in the selector tool. They can be turned on and off using the button in the node toolbar. When the handles are visible, clicking on a selected node will switch between scaling and rotation mode, instead of selecting only that node. You can also use Shift+H to switch the mode. All other operations work normally when transform handles are shown.<br />
; '''Path direction tools'''<br />
: Little harpoons are optionally shown in the middle of each segment, visualizing the direction of the path. This is useful when preparing a guide path for text, setting markers, and debugging extensions and Inkscape itself. The "Reverse" command (Shift+R) reverses the direction of subpaths that have some selected nodes, or all subpaths if the node selection is empty.<br />
; '''Customizable path update'''<br />
: Two new preferences allow you to specify when the path and its outline should be updated. Turning off live update of paths will improve performance for complex drawings.<br />
; '''Improved tips'''<br />
: The tips displayed for nodes and handles are more concise and affected by what modifier keys are pressed.<br />
<br />
For a detailed feature comparison between the old and new tool, see [[GSoC2009 Node Tool Rewrite]].<br />
<br />
===Spray Tool===<br />
You first need to select one or several items, then select the spray tool. To spray, click on the canvas, then move the mouse or scroll the mouse wheel.<br />
<br />
Three modes are available.<br />
<br />
*''Spray Copy mode :'' each sprayed item is independent from the others.<br />
*''Spray Clone mode :'' each sprayed item is a clone of the selected item. Changing the properties of the original item will affect the clones.<br />
*''Spray Single Path Mode :'' everything you spray is in a single path. You may need to convert your item into a path to make it work properly.<br />
<br />
'''Spray options'''<br />
<br />
*Amount : spray more or less object.<br />
<br />
*Rotation : randomly rotates items around the original rotation value. <br />
*Scale : randomly scales items around the original scale value. <br />
<br />
*Scatter : low values to spray items under the cursor, high values for a more uniform repartition over the spray zone.<br />
*Focus : items are sprayed following a ring. This parameters modifies the radius of the circle. Default at 0 to spray a spot. <br />
<br />
Use keys ↑ and ↓ to control the size of of sprayed items. Use ← and → to set the width of the cursor.<br />
<br />
<br />
The Spray tool is a perfect match for the transforming, duplicating, and deleting modes of the Tweak tool.<br />
<br />
<!--<br />
==Live Path Effects (LPE)==<br />
<br />
===Node tool changes===<br />
The new node tool means slightly different LPE editing too. Such as ...<br />
<br />
===New effects===<br />
<br />
* '''Extrude''' Similar to the Python extension <br />
--><br />
<br />
==Import/Export==<br />
===Improved bitmap image import===<br />
<br />
Bitmaps are now always embedded when pixel data is pasted or dragged into Inkscape's window (for example when copying parts of an image from GIMP). Files with automatically generated names like "inkscape_pasted_image_..." are no longer created in the document directory. When importing or opening bitmap images, a dialog is displayed that asks whether you want to link the image or embed it.<br />
<br />
===New LaTeX export for PDF/EPS/PS===<br />
<br />
Similar to GNUPlot's `epslatex' output terminal and Xfig's combined PDF/LaTeX output, Inkscape can now export graphics to PDF with an accompanying LaTeX file that overlays the text over the PDF when inputted in LaTeX. The image's text is typeset by LaTeX, so for example mathematical expressions are rendered correctly, and all text will be in the font and style of the LaTeX document (even when changing the document's font afterwards).<br />
<br />
''(the following description assumes export to PDF, but will work the same for EPS and PS)''<br />
Two files will be created: a PDF file containing all graphics, without text; and a LaTeX file with the same name, containing all text, and code to include the PDF and overlay the text. To include the exported image in LaTeX, one writes<br />
<br />
\begin{figure} <br />
\centering<br />
\def\svgwidth{\columnwidth} % sets the image width, this is optional<br />
\input{image.tex}<br />
\end{figure}<br />
<br />
A more thorough description of how to use the new feature (and automate the exporting/inclusion of the image in LaTeX) is given in this PDF: [http://wiki.inkscape.org/wiki/images/SVG_in_LaTeX.pdf SVG in LaTeX].<br />
<br />
====From the GUI====<br />
When exporting to PDF/EPS/PS from Inkscape's GUI, the usual dialog pops up after selecting to which PDF/EPS/PS file to export to. In this dialog, you can find the PDF/EPS/PS+LaTeX option.<br />
<br />
====Command line option====<br />
When exporting to PDF/EPS/PS from the command line, adding --export-latex will turn the LaTeX export on. For example<br />
<br />
inkscape image.svg -z -D --export-pdf=image.pdf --export-latex<br />
<br />
==Extensions==<br />
===New and improved extensions===<br />
<br />
* The new '''Generate from Path > Voronoi Pattern''' extension creates a random pattern of Voronoi cells. The pattern will be accessible from the Fill and Stroke dialog. The pattern can be made to be smooth at the edges by choosing a positive border, or sparse at the edges by using a negative border.<br />
* The new '''Render > Wireframe Sphere''' extension draws the globe as a collection of ellipses representing a sphere's latitude and longitude lines. The number of lines is adjustable, as well as the tilt and rotation. There is an option to hide the lines at the back of the sphere.<br />
* The new '''Render > Barcode - Datamatrix''' extension renders a DataMatrix 2D barcode, as specified in BS ISO/IEC 16022:2006. The number of rows and columns of the DataMatrix is adjustable. If more data is given than can be contained in one DataMatrix, more than one DataMatrix will be produced.<br />
* The new '''Modify Path > Pixelsnap''' extension aligns rectangles and paths to pixel boundaries, to create sharp web and digital graphics.<br />
* The new '''Color > Black and White''' extension turns the selection colors into black and white.<br />
<br />
<!-- ==Filters==<br />
<br />
==SVG Support==<br />
<br />
==Editing Aids== --><br />
<br />
==Other features==<br />
<br />
* Arch paper sizes are added in the Document Properties dialog<br />
* Displaying the '''font samples''' in the drop-down list of the Text tool is now optional. In Inkscape Preferences, go to Tools, Text, and uncheck "Show font samples in the drop-down list" if you don't want to see the samples. This will speed up displaying the list the first time you open it<br />
* Items in the File > Open Recent menu, when mouseovered, show tooltips with the full URI of each file in the list. Also, files that are in the list but are missing or unaccessible are automatically hidden<br />
* When a flowed text is truncated (i.e. the frame is too small for the entire text), the frame is shown red, and the statusbar hint includes '''[truncated]'''. You need to resize the frame to see the truncated end of the text. Analogously, if the path of a text-on-path object is too short to display the entire text, the statusbar will report it as '''[truncated]'''<br />
* Clicking the text alignment buttons (Left, Center, Right) on the Text tool's controls bar now does not let the text jump: it stays within the same bounding box as before, only changing the alignment<br />
* The position of text's baseline anchor (the small square) is now dependent of the alignment: for left-aligned text it is, as before, at the left end, for centered text in the middle, and for the right-aligned text it is at the right end of the text's first line (this is for horizontal text; for vertical, it is correspondingly at top, middle, or bottom of the first column). This allows snapping, aligning and distributing of text relative the side to which it's aligned<br />
* Snapping of gradient handles has been improved and now behaves similar to the snapping of all other handles and objects<br />
* When snapping to a bounding box, that bounding box will be shown for a moment (tied to the snap indicator)<br />
* If a new object is being created on the canvas with snapping enabled, then a snap indicator will also be shown for the first point<br />
* There are now options for Margins when resizing a document to a selection or the drawing in Document Properties<br />
* Preferences have been added to allow automatic grouping when setting a Clippath or Mask<br />
* Bitmap copies created using the Make a Bitmap Copy command (Alt+B) are now embedded. Previously they were saved in an automatically generated file and linked<br />
* The file preview size limit (in the File > Open and File > Import dialog box) is now 10 MB (1.3 MB in 0.47)<br />
<br />
===Extended input device configuration===<br />
<br />
The stock Input Devices dialog has been replaced with a completely redone version that provides a more useful representation of settings. It also contains a simple area for testing different inputs of different devices.<br />
<br />
Additionally hardware setup itself has been separated from general settings to allow for easier dynamic switching of settings appropriate to the task at hand.<br />
<br />
==User interface==<br />
<br />
===Adaptive UI===<br />
(In progress [[User:JonCruz|JonCruz]])<br />
<br />
===Custom Swatches===<br />
<br />
Custom swatches can be created and used on a per-document basis. An "Auto" color palette will track swatches in the current document and allow them to be set and used. The use is "live" with changes to the swatch being applied automatically to all objects set to it. The swatches can also be gradients and not just simple colors.<br />
<br />
===New cursors in Selector===<br />
<br />
Selector tool has a new mouse cursor (arrow with an open hand) for when your mouse is over a selectable object, and another (arrow with clinched hand) for when you're dragging an object. This improves precision of selection and UI consistency (previously, the mouse cursor over a selectable object was different across platforms, e.g. hand icon on Linux or four-way arrow on Windows).<br />
<br />
===Translations===<br />
<br />
New Farsi translation (in progress).<br />
<br />
==Tutorials==<br />
<br />
* SVG files are now optimized with Scour (filesize reduced by 40%).<br />
* Bitstream Vera fonts replaced with generic sans and serif fonts (solves many font substitution issues).<br />
* New Interpolate tutorial (Help > Tutorials > Inkscape: Interpolate).<br />
* New translations in Farsi, Belarussian and Dutch.<br />
<br />
==Notable bug fixes==<br />
<br />
* The 3D tool no longer inserts an inkscape:perspective element into SVG when it is not needed (i.e. when the document has no 3D box objects).<br />
* Wrong clippaths and masks with cyclic recursion (i.e. clippaths or masks that refer to themselves via other clippaths or masks) no longer crash Inkscape.<br />
* Default unit setting for the XY grid is now respected when creating a new grid.<br />
* Pasting Live Path Effect stacks now works. It adds the stack of the copied object to the end of the LPE stack (if present) of the object it is pasted to.<br />
<br />
==Known issues==<br />
<br />
==Previous releases==<br />
<br />
* [[ReleaseNotes047]]<br />
* [[ReleaseNotes046]]<br />
* [[ReleaseNotes045]]<br />
* [[ReleaseNotes044]]<br />
* [[ReleaseNotes043]]<br />
* [[ReleaseNotes042]]<br />
* [[ReleaseNotes041]]<br />
* [[ReleaseNotes040]]<br />
* [[ReleaseNotes039]]<br />
* [[ReleaseNotes038]]<br />
* [[ReleaseNotes037]]<br />
* [[ReleaseNotes036]]<br />
* [[ReleaseNotes035]]<br />
<br />
[[Category:Marketing]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=CompilingUbuntu&diff=55591CompilingUbuntu2010-01-10T22:03:16Z<p>Steren: /* Getting source from Bazaar */</p>
<hr />
<div>== Hardy, Intrepid and Jaunty ==<br />
=== Consider using stable (recommended for production) ===<br />
This is a short how to build the latest svn version. Please note that SVN version may be buggy and crash often. This is released for people who want to help testing or need the very latest features. If you are not of developer kind, you are suggested to install the stable version from the repositories using Synaptic or from command line:<br />
<br />
<pre><br />
sudo apt-get install inkscape<br />
</pre><br />
<br />
=== Using prebuilt packages (recommended) ===<br />
For Ubuntu there are nightly builds available. <br />
<br />
Get your appropriate repository lines from launchpad (read about [https://help.ubuntu.com/community/Repositories/Ubuntu adding repositories]):<br />
<br />
https://launchpad.net/~inkscape-nightly/+archive/ppa<br />
<br />
<br />
Run following command to update the repository information and install inkscape:<br />
<pre> sudo apt-get update<br />
sudo apt-get install inkscape<br />
</pre><br />
<br />
=== Compiling unstable developement version ===<br />
==== Installing dependencies ====<br />
If you are sure you can face Inkscape being unstable, then please continue reading. First you should install all the dependencies. This can be done by:<br />
<br />
<pre><br />
sudo apt-get install build-essential autoconf automake intltool \<br />
libglib2.0-dev libpng12-dev libgc-dev libfreetype6-dev liblcms1-dev \<br />
libgtkmm-2.4-dev libxslt1-dev libboost-dev libpopt-dev libgsl0-dev libaspell-dev<br />
</pre><br />
<br />
Now you should have every dependency you need to build Inkscape.<br />
<br />
===== Additional dependencies =====<br />
If you want to have pdf support you need to install poppler:<br />
<br />
<pre><br />
sudo apt-get install libpoppler-dev libpoppler-glib-dev<br />
</pre><br />
<br />
If you want to have optional features you may need to install some more packages:<br />
<br />
<pre><br />
sudo apt-get install libgnome-vfsmm-2.6-dev libssl-dev libmagick++9-dev libwpg-dev<br />
</pre><br />
<br />
==== Getting source from Bazaar ====<br />
Inkscape now uses Bazaar, please refer to the [[Working with Bazaar]] page for details on how to get the Inkscape source code.<br />
<br />
==== Configuring and Compiling ====<br />
Enter the newly created inkscape directory.<br />
<br />
<pre><br />
cd inkscape<br />
</pre><br />
<br />
As you may have already noticed this folder contains some files with all CAPITAL letters like README, INSTALL, HACKING, COPYING and probably others. These contain the latest information about how to build the program. The README file says that if you have no configure script in the current directory you should run autogen script to create it:<br />
<br />
<pre><br />
./autogen.sh<br />
</pre><br />
<br />
Now run configure script which detects your system variables, installed software etc.:<br />
<br />
<pre><br />
./configure<br />
</pre><br />
<br />
or, if you want to make it install to an alternate location so that you can keep the standard version installed and untouched<br />
<br />
<code><br />
./configure --prefix=/home/''yourname''/opt/local<br />
</code><br />
(replacing "yourname" with your actual directory user name, of course)<br />
''All bug reporting testers may find it useful to install to use --prefix=/home/''yourname''/opt/inkscape-revision-19900 or --prefix=/opt/inkscape-19900 or something similar, replacing the revision number with correct one (this is shown when svn fetching finishes, also can be found in file .svn/entries). This way you can have several versions of inkscape installed at once.''<br />
<br />
or, if you want to have inkboard enabled,<br />
<br />
<pre><br />
./configure --enable-inkboard<br />
</pre><br />
<br />
If the configure script ends with no error messages, you are the lucky one, all system requirements are met. Run make to compile.<br />
<br />
<pre><br />
make<br />
</pre><br />
<br />
This may take some time, probably hours, depending on your machine's speed. On 1,4Ghz P3M with 512Mb clean build took 100 minutes.<br />
<br />
==== Installing ====<br />
<br />
If you used some --prefix=/... other than /usr, then you may install using usual 'make install' or 'sudo make install', depending on the location.<br />
If the the location prefix was /usr, then "sudo make install" is not recommended, as debian package manager would know nothing about new package. The better alternative is using checkinstall. If checkinstall is not installed, you can install it the usual way "sudo apt-get install checkinstall".<br />
<br />
<pre><br />
sudo checkinstall<br />
</pre><br />
<br />
Happy inkscapeing.<br />
<br />
===== Fix no icons problem =====<br />
<br />
If you run this and you find that you have no tool icons it's because it's looking in the wrong place for them. To fix that you need to make a symbolic link to the correct location. Here is an example:<br />
<br />
<pre><br />
sudo ln -s /usr/share/inkscape /usr/local/share/inkscape<br />
</pre><br />
<br />
==== Update your version ====<br />
<br />
If you want to update your already built inkscape to the very latest version, you need to run following commands in inkscape source directory. Please correct the configure line and use the same installation method as on first install.<br />
<br />
<pre><br />
svn update<br />
./configure --prefix=/home/''yourname''/opt/local<br />
make<br />
make install<br />
</pre><br />
<br />
== Dapper and Edgy ==<br />
If you're going to build Inkscape, you'll need to have a full complement of build requirements. This is very easy to do in Ubuntu Dapper and Edgy:<br />
<br />
Note: the libgc-6.7 that is available in Edgy removes the need for the following:<br />
<br />
<pre><br />
sudo apt-get build-dep inkscape<br />
sudo apt-get install liblcms-dev build-essential<br />
echo "deb-src http://ftp.us.debian.org/debian/ unstable main" >> /etc/apt/sources.list<br />
sudo apt-get update<br />
sudo apt-get source libgc-dev<br />
sudo apt-get install fakeroot debhelper<br />
cd libgc*<br />
sudo fakeroot dpkg-buildpackage -uc -us<br />
sudo dpkg -i ../libgc*.deb<br />
</pre><br />
<br />
If you want version 0.44 from Debian Unstable, you can compile it in the same way as libgc above:<br />
<br />
<pre><br />
apt-get source inkscape<br />
cd inkscape*<br />
fakeroot dpkg-buildpackage -uc -us<br />
sudo dpkg -i ../inkscape*.deb<br />
</pre><br />
<br />
To build the SVN snapshots:<br />
<br />
<pre><br />
# Untar and navigate to the inkscape source folder<br />
./configure<br />
make<br />
sudo make install<br />
</pre><br />
<br />
Instead of doing "make install", on Debian-based distributions (such as Ubuntu) it is better to do<br />
<pre><br />
sudo checkinstall<br />
</pre><br />
since checkinstall first builds the .deb package and then installs it, thus making the package system aware of the newly installed inkscape.<br />
If you get the "command not found" message, do<br />
<pre><br />
sudo apt-get install checkinstall<br />
</pre><br />
<br />
<br />
'''Notes:'''<br />
build-dep gets all the dependencies for the version of Inkscape that comes with Ubuntu. We're not building the same version, but most of the dependencies are the same. <br />
<br />
<br />
libcms-dev was required for ./configure to work<br />
<br />
<br />
This was done on a recently installed Dapper (Ubuntu 6.06) system. I built Inkscape version 0.44.<br />
<br />
<br />
<br />
<br />
The following packages are need to compile cvs inkscape under a default Ubuntu Hoary/Breezy/Dapper system:<br />
<pre><br />
apt-get install cvs build-essential intltool libtool libgtkmm-2.4-dev \<br />
libglib2.0-dev libpng12-dev libxslt1-dev libsigc++-2.0-dev libpopt-dev libgc-dev<br />
</pre><br />
<br />
Inkscape requires libgc-6.7.<br />
<br />
Breezy uses 6.4, Dapper uses 6.6, Edgy uses 6.7<br />
<br />
Hoary uses version 6.3, which is provided in the Repos. (Is there somewhere to get a .deb for 6.4?)<br />
<br />
To overwrite libgc-6.3 with libgc-6.4:<br />
Download gc6.4<br />
./configure --prefix=/usr<br />
make<br />
sudo make install<br />
<br />
== Old libgc 6.5 debs for Breezy ==<br />
<br />
http://inkscape.modevia.com/ap/libgc-dev_6.5-1_i386.deb<br />
http://inkscape.modevia.com/ap/libgc1_6.5-1_i386.deb<br />
<br />
[[Category:Developer Documentation]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=CompilingUbuntu&diff=55579CompilingUbuntu2010-01-10T21:31:51Z<p>Steren: /* Getting source from SVN */</p>
<hr />
<div>== Hardy, Intrepid and Jaunty ==<br />
=== Consider using stable (recommended for production) ===<br />
This is a short how to build the latest svn version. Please note that SVN version may be buggy and crash often. This is released for people who want to help testing or need the very latest features. If you are not of developer kind, you are suggested to install the stable version from the repositories using Synaptic or from command line:<br />
<br />
<pre><br />
sudo apt-get install inkscape<br />
</pre><br />
<br />
=== Using prebuilt packages (recommended) ===<br />
For Ubuntu there are nightly builds available. <br />
<br />
Get your appropriate repository lines from launchpad (read about [https://help.ubuntu.com/community/Repositories/Ubuntu adding repositories]):<br />
<br />
https://launchpad.net/~inkscape-nightly/+archive/ppa<br />
<br />
<br />
Run following command to update the repository information and install inkscape:<br />
<pre> sudo apt-get update<br />
sudo apt-get install inkscape<br />
</pre><br />
<br />
=== Compiling unstable developement version ===<br />
==== Installing dependencies ====<br />
If you are sure you can face Inkscape being unstable, then please continue reading. First you should install all the dependencies. This can be done by:<br />
<br />
<pre><br />
sudo apt-get install build-essential autoconf automake intltool \<br />
libglib2.0-dev libpng12-dev libgc-dev libfreetype6-dev liblcms1-dev \<br />
libgtkmm-2.4-dev libxslt1-dev libboost-dev libpopt-dev libgsl0-dev libaspell-dev<br />
</pre><br />
<br />
Now you should have every dependency you need to build Inkscape.<br />
<br />
===== Additional dependencies =====<br />
If you want to have pdf support you need to install poppler:<br />
<br />
<pre><br />
sudo apt-get install libpoppler-dev libpoppler-glib-dev<br />
</pre><br />
<br />
If you want to have optional features you may need to install some more packages:<br />
<br />
<pre><br />
sudo apt-get install libgnome-vfsmm-2.6-dev libssl-dev libmagick++9-dev libwpg-dev<br />
</pre><br />
<br />
==== Getting source from Bazaar ====<br />
Inkscapenow uses Bazaar, pleaserefer to the [[Working with Bazaar]] page for details on how to get the Inkscape source code.<br />
<br />
==== Configuring and Compiling ====<br />
Enter the newly created inkscape directory.<br />
<br />
<pre><br />
cd inkscape<br />
</pre><br />
<br />
As you may have already noticed this folder contains some files with all CAPITAL letters like README, INSTALL, HACKING, COPYING and probably others. These contain the latest information about how to build the program. The README file says that if you have no configure script in the current directory you should run autogen script to create it:<br />
<br />
<pre><br />
./autogen.sh<br />
</pre><br />
<br />
Now run configure script which detects your system variables, installed software etc.:<br />
<br />
<pre><br />
./configure<br />
</pre><br />
<br />
or, if you want to make it install to an alternate location so that you can keep the standard version installed and untouched<br />
<br />
<code><br />
./configure --prefix=/home/''yourname''/opt/local<br />
</code><br />
(replacing "yourname" with your actual directory user name, of course)<br />
''All bug reporting testers may find it useful to install to use --prefix=/home/''yourname''/opt/inkscape-revision-19900 or --prefix=/opt/inkscape-19900 or something similar, replacing the revision number with correct one (this is shown when svn fetching finishes, also can be found in file .svn/entries). This way you can have several versions of inkscape installed at once.''<br />
<br />
or, if you want to have inkboard enabled,<br />
<br />
<pre><br />
./configure --enable-inkboard<br />
</pre><br />
<br />
If the configure script ends with no error messages, you are the lucky one, all system requirements are met. Run make to compile.<br />
<br />
<pre><br />
make<br />
</pre><br />
<br />
This may take some time, probably hours, depending on your machine's speed. On 1,4Ghz P3M with 512Mb clean build took 100 minutes.<br />
<br />
==== Installing ====<br />
<br />
If you used some --prefix=/... other than /usr, then you may install using usual 'make install' or 'sudo make install', depending on the location.<br />
If the the location prefix was /usr, then "sudo make install" is not recommended, as debian package manager would know nothing about new package. The better alternative is using checkinstall. If checkinstall is not installed, you can install it the usual way "sudo apt-get install checkinstall".<br />
<br />
<pre><br />
sudo checkinstall<br />
</pre><br />
<br />
Happy inkscapeing.<br />
<br />
===== Fix no icons problem =====<br />
<br />
If you run this and you find that you have no tool icons it's because it's looking in the wrong place for them. To fix that you need to make a symbolic link to the correct location. Here is an example:<br />
<br />
<pre><br />
sudo ln -s /usr/share/inkscape /usr/local/share/inkscape<br />
</pre><br />
<br />
==== Update your version ====<br />
<br />
If you want to update your already built inkscape to the very latest version, you need to run following commands in inkscape source directory. Please correct the configure line and use the same installation method as on first install.<br />
<br />
<pre><br />
svn update<br />
./configure --prefix=/home/''yourname''/opt/local<br />
make<br />
make install<br />
</pre><br />
<br />
== Dapper and Edgy ==<br />
If you're going to build Inkscape, you'll need to have a full complement of build requirements. This is very easy to do in Ubuntu Dapper and Edgy:<br />
<br />
Note: the libgc-6.7 that is available in Edgy removes the need for the following:<br />
<br />
<pre><br />
sudo apt-get build-dep inkscape<br />
sudo apt-get install liblcms-dev build-essential<br />
echo "deb-src http://ftp.us.debian.org/debian/ unstable main" >> /etc/apt/sources.list<br />
sudo apt-get update<br />
sudo apt-get source libgc-dev<br />
sudo apt-get install fakeroot debhelper<br />
cd libgc*<br />
sudo fakeroot dpkg-buildpackage -uc -us<br />
sudo dpkg -i ../libgc*.deb<br />
</pre><br />
<br />
If you want version 0.44 from Debian Unstable, you can compile it in the same way as libgc above:<br />
<br />
<pre><br />
apt-get source inkscape<br />
cd inkscape*<br />
fakeroot dpkg-buildpackage -uc -us<br />
sudo dpkg -i ../inkscape*.deb<br />
</pre><br />
<br />
To build the SVN snapshots:<br />
<br />
<pre><br />
# Untar and navigate to the inkscape source folder<br />
./configure<br />
make<br />
sudo make install<br />
</pre><br />
<br />
Instead of doing "make install", on Debian-based distributions (such as Ubuntu) it is better to do<br />
<pre><br />
sudo checkinstall<br />
</pre><br />
since checkinstall first builds the .deb package and then installs it, thus making the package system aware of the newly installed inkscape.<br />
If you get the "command not found" message, do<br />
<pre><br />
sudo apt-get install checkinstall<br />
</pre><br />
<br />
<br />
'''Notes:'''<br />
build-dep gets all the dependencies for the version of Inkscape that comes with Ubuntu. We're not building the same version, but most of the dependencies are the same. <br />
<br />
<br />
libcms-dev was required for ./configure to work<br />
<br />
<br />
This was done on a recently installed Dapper (Ubuntu 6.06) system. I built Inkscape version 0.44.<br />
<br />
<br />
<br />
<br />
The following packages are need to compile cvs inkscape under a default Ubuntu Hoary/Breezy/Dapper system:<br />
<pre><br />
apt-get install cvs build-essential intltool libtool libgtkmm-2.4-dev \<br />
libglib2.0-dev libpng12-dev libxslt1-dev libsigc++-2.0-dev libpopt-dev libgc-dev<br />
</pre><br />
<br />
Inkscape requires libgc-6.7.<br />
<br />
Breezy uses 6.4, Dapper uses 6.6, Edgy uses 6.7<br />
<br />
Hoary uses version 6.3, which is provided in the Repos. (Is there somewhere to get a .deb for 6.4?)<br />
<br />
To overwrite libgc-6.3 with libgc-6.4:<br />
Download gc6.4<br />
./configure --prefix=/usr<br />
make<br />
sudo make install<br />
<br />
== Old libgc 6.5 debs for Breezy ==<br />
<br />
http://inkscape.modevia.com/ap/libgc-dev_6.5-1_i386.deb<br />
http://inkscape.modevia.com/ap/libgc1_6.5-1_i386.deb<br />
<br />
[[Category:Developer Documentation]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_links_manager&diff=54455Image links manager2009-10-22T19:15:26Z<p>Steren: </p>
<hr />
<div>=Idea=<br />
As of Inkscape 0.47, the only way to manage images is to edit the XML of the document or to run not-so-user-friendly scripts.<br />
<br />
<br />
The idea is to provide an easy management of these images. The user should be able to :<br />
* replace an image with a new one<br />
* edit an image with an external raster editor<br />
* embed an image<br />
* decide to store externally an embedded image<br />
* decide is an external image is stored with an absolute path or a relative path<br />
* repair broken links by selecting ONE new image, the computer is then smart enough to test if other broken links are findable considering this new image location.<br />
<br />
=Images in inkscape=<br />
We can enumerate 3 types of images:<br />
* External with Absolute path<br />
** The file is stored externally<br />
** Path is absolute (loading on another computer fails)<br />
** example: <br />
<image<br />
xlink:href="file:///home/steren/Bureau/imgs/absolute.png"<br />
width="80"<br />
height="80"<br />
id="image57"<br />
x="40"<br />
y="152" /><br />
* External with Relative path<br />
** The file is stored externally<br />
** Path is relative (if well organized, loading on another computer is ok)<br />
** example: <br />
<image<br />
sodipodi:absref="/home/steren/Bureau/imgs/relative.png"<br />
xlink:href="imgs/relative.png"<br />
y="263.79077"<br />
x="40.000011"<br />
id="image71"<br />
height="80"<br />
width="80" /><br />
<br />
* Embedded<br />
** The file is stored into the document<br />
** Ok but cannot use external software to edit it <br />
** example: <br />
<image<br />
xlink:href="data:image/png;base64,iVBORw0KGgoAAAANS<br />
...***IMAGE STORED HERE***<br />
"<br />
width="80"<br />
height="80"<br />
id="image43"<br />
x="40"<br />
y="40" /><br />
<br />
<br />
A test file can be found [http://www.mediafire.com/?z1egt4tyjcd here], it contains a .svg with 3 images: relative, absolute and embedded.<br />
<br />
=UI Proposal=<br />
==Manager==<br />
[[File:Img_links_mockup.png]]<br />
<br />
(You can find the sources of this image [[Media:Img_links_mockup.svg|here]])<br />
<br />
<br />
Description of the UI: <br />
* Selection Buttons<br />
* Every image of the document appears on a list. Their order is theorder they appear in the XML.<br />
* each line contains:<br />
** a thumbnail of the image<br />
** its path OR ''Embedded'' OR ''Broken link''.<br />
* User can select multiple lines (one click selects a line)<br />
* When images are selected in the manager, they appear selected on the canvas. When images are selected on the canvas, they appear selectedon the manager.<br />
* Actions Buttons<br />
* If actions doesn't have sense for the current selection, the buttons are disabled (example: The selection contains external absolute and relative images, then the buttons "Make external" is disabled)<br />
<br />
Some specific points :<br />
* only image for which the action is relevant are considered.<br />
Example: selection contains embedded and external images, the user clicks "Embed", then already embedded images are not considered.<br />
<br />
==On canvas Right Click==<br />
When the user right clicks on an image, depending on its type, he can perform actions.<br />
<br />
'''Example''': The image is stored externally with an absolute path.<br />
A right-click makes these option appear:<br />
*Make Relative<br />
*Embed<br />
*Change<br />
*Reload<br />
*Edit externally<br />
<br />
==About Smart Broken link resolver==<br />
'''User case:'''<br />
Let's assume that there are 10 broken links in the document (images that cannot be found considering the given path).<br />
Assume that they are broken because they were stored in the same folder than the document and that the user wanted to clean his work and moved them in an img/ folder.<br />
<br />
Now if the user repairs one broken link by telling the system the new path (img/img1.png instead of img1.png). If the system detects that in this new folder, there are also files that are missing (img/img2.png, img/img3.png), then it asks the user if links should be automatically corrected for img2 and img3.<br />
<br />
=Discussion=<br />
Please, use the thread in the Inkscape-dev mailing list to discuss around this idea.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=User_talk:Steren&diff=54437User talk:Steren2009-10-22T10:39:36Z<p>Steren: </p>
<hr />
<div>== Hi Seren ==<br />
<br />
Did you want to provide a vector image of the dialog by [[:File:Img links mockup.svg]], should it be "repaired" (means simplified)? Please have a look on this [[File:Image_links_mockup.svg|30px]]? Regards --[[User:Uncopy|Uncopy]] 08:09, 22 October 2009 (UTC)<br />
: The problem with the wiki-auto-conversion-tool is text, sometimes transparency and layers. To convert a text into a single path use the following sequence<br>&nbsp;<br />
:* {{Keyb|Ctrl}}+{{Keyb|Shift}}+{{Keyb|C}} = object to path <br>&nbsp;<br />
:* {{Keyb|Ctrl}}+{{Keyb|Shift}}+{{Keyb|G}} = ungroup <br>&nbsp;<br />
:* {{Keyb|Ctrl}}+{{Keyb|Shift}}+{{Keyb|+}} = combine <br>&nbsp;<br />
: --[[User:Uncopy|Uncopy]] 08:22, 22 October 2009 (UTC)<br />
<br />
Hi, Thanks you for the tip. In fact I uploaded the .png [[File:Img_links_mockup.png|30px]] and provided the .svg source in a link because texts failed to display.<br />
<br />
I wonder : when I convert text into single path, it's not editable anymore so that's a problem. In fact I noticed that I used Inkscape's FlowText for text in an area. FlowText is SVG 1.2, that is why no other software can display it correctly. Maybe using "Text" > "convert to text" solves the problem. Because it convert this FlowText in Text, and Text is SVG1.1.<br />
<br />
I know that when using "text" and not "flowText", it display well in any other software I know.<br />
For me this is a serious Inkscape problem.<br />
--[[User:Steren|Steren]] 10:39, 22 October 2009 (UTC)</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_links_manager&diff=54311Image links manager2009-10-20T16:11:11Z<p>Steren: </p>
<hr />
<div>=Idea=<br />
As of Inkscape 0.47, the only way to manage images is to edit the XML of the document or to run not-so-user-friendly scripts.<br />
<br />
<br />
The idea is to provide an easy management of these images. The user should be able to :<br />
* replace an image with a new one<br />
* edit an image with an external raster editor<br />
* embed an image<br />
* decide to store externally an embedded image<br />
* decide is an external image is stored with an absolute path or a relative path<br />
* repair broken links by selecting ONE new image, the computer is then smart enough to test if other broken links are findable considering this new image location.<br />
<br />
=Images in inkscape=<br />
We can enumerate 3 types of images:<br />
* External with Absolute path<br />
** The file is stored externally<br />
** Path is absolute (loading on another computer fails)<br />
** example: <br />
<image<br />
xlink:href="file:///home/steren/Bureau/imgs/absolute.png"<br />
width="80"<br />
height="80"<br />
id="image57"<br />
x="40"<br />
y="152" /><br />
* External with Relative path<br />
** The file is stored externally<br />
** Path is relative (if well organized, loading on another computer is ok)<br />
** example: <br />
<image<br />
sodipodi:absref="/home/steren/Bureau/imgs/relative.png"<br />
xlink:href="imgs/relative.png"<br />
y="263.79077"<br />
x="40.000011"<br />
id="image71"<br />
height="80"<br />
width="80" /><br />
<br />
* Embedded<br />
** The file is stored into the document<br />
** Ok but cannot use external software to edit it <br />
** example: <br />
<image<br />
xlink:href="data:image/png;base64,iVBORw0KGgoAAAANS<br />
...***IMAGE STORED HERE***<br />
"<br />
width="80"<br />
height="80"<br />
id="image43"<br />
x="40"<br />
y="40" /><br />
<br />
<br />
A test file can be found [http://www.mediafire.com/?z1egt4tyjcd here], it contains a .svg with 3 images: relative, absolute and embedded.<br />
<br />
=UI Proposal=<br />
==Manager==<br />
[[File:Img_links_mockup.png]]<br />
<br />
(You can find the sources of this image [[Media:Img_links_mockup.svg|here]])<br />
<br />
<br />
Description of the UI: <br />
* Selection Buttons<br />
* Every image of the document appears on a list. Their order is theorder they appear in the XML.<br />
* each line contains:<br />
** a thumbnail of the image<br />
** its path OR ''Embedded'' OR ''Broken link''.<br />
* User can select multiple lines (one click selects a line)<br />
* When images are selected in the manager, they appear selected on the canvas. When images are selected on the canvas, they appear selectedon the manager.<br />
* Actions Buttons<br />
* If actions doesn't have sense for the current selection, the buttons are disabled (example: The selection contains external absolute and relative images, then the buttons "Make external" is disabled)<br />
<br />
Some specific points :<br />
* only image for which the action is relevant are considered.<br />
Example: selection contains embedded and external images, the user clicks "Embed", then already embedded images are not considered.<br />
<br />
==On canvas Right Click==<br />
When the user right clicks on an image, depending on its type, he can perform actions.<br />
<br />
'''Example''': The image is stored externally with an absolute path.<br />
A right-click makes these option appear:<br />
*Make Relative<br />
*Embed<br />
*Change<br />
*Reload<br />
*Edit externally<br />
<br />
==About Smart Broken link resolver==<br />
'''User case:'''<br />
Let's assume that there are 10 broken links in the document (images that cannot be found considering the given path).<br />
Assume that they are broken because they were stored in the same folder than the document and that the user wanted to clean his work and moved them in an img/ folder.<br />
<br />
Now if the user repairs one broken link by telling the system the new path (img/img1.png instead of img1.png). If the system detects that in this new folder, there are also files that are missing (img/img2.png, img/img3.png), then it asks the user if links should be automatically corrected for img2 and img3.<br />
<br />
=Discussion=<br />
Please, use the [[Talk:Image_links_manager|discussion page]] to discuss around thsi idea.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_links_manager&diff=54309Image links manager2009-10-20T16:07:17Z<p>Steren: </p>
<hr />
<div>=Idea=<br />
As of Inkscape 0.47, the only way to manage images is to edit the XML of the document or to run not-so-user-friendly scripts.<br />
<br />
<br />
The idea is to provide an easy management of these images. The user should be able to :<br />
* replace an image with a new one<br />
* edit an image with an external raster editor<br />
* embed an image<br />
* decide to store externally an embedded image<br />
* decide is an external image is stored with an absolute path or a relative path<br />
* repair broken links by selecting ONE new image, the computer is then smart enough to test if other broken links are findable considering this new image location.<br />
<br />
=Images in inkscape=<br />
We can enumerate 3 types of images:<br />
* External with Absolute path<br />
** The file is stored externally<br />
** Path is absolute (loading on another computer fails)<br />
** example: <br />
<image<br />
xlink:href="file:///home/steren/Bureau/imgs/absolute.png"<br />
width="80"<br />
height="80"<br />
id="image57"<br />
x="40"<br />
y="152" /><br />
* External with Relative path<br />
** The file is stored externally<br />
** Path is relative (if well organized, loading on another computer is ok)<br />
** example: <br />
<image<br />
sodipodi:absref="/home/steren/Bureau/imgs/relative.png"<br />
xlink:href="imgs/relative.png"<br />
y="263.79077"<br />
x="40.000011"<br />
id="image71"<br />
height="80"<br />
width="80" /><br />
<br />
* Embedded<br />
** The file is stored into the document<br />
** Ok but cannot use external software to edit it <br />
** example: <br />
<image<br />
xlink:href="data:image/png;base64,iVBORw0KGgoAAAANS<br />
...***IMAGE STORED HERE***<br />
"<br />
width="80"<br />
height="80"<br />
id="image43"<br />
x="40"<br />
y="40" /><br />
<br />
<br />
A test file can be found [http://www.mediafire.com/?z1egt4tyjcd here], it contains a .svg with 3 images: relative, absolute and embedded.<br />
<br />
=UI Proposal=<br />
==Manager==<br />
[[File:Img_links_mockup.png]]<br />
<br />
(You can find the sources of this image [[Media:Img_links_mockup.svg|here]])<br />
<br />
<br />
Description of the UI: <br />
* Selection Buttons<br />
* Every image of the document appears on a list. Their order is theorder they appear in the XML.<br />
* each line contains:<br />
** a thumbnail of the image<br />
** its path OR ''Embedded'' OR ''Broken link''.<br />
* User can select multiple lines (one click selects a line)<br />
* When images are selected in the manager, they appear selected on the canvas. When images are selected on the canvas, they appear selectedon the manager.<br />
* Actions Buttons<br />
* If actions doesn't have sense for the current selection, the buttons are disabled (example: The selection contains external absolute and relative images, then the buttons "Make external" is disabled)<br />
<br />
==Right Click==<br />
When the user right clicks on an image, depending on its type, he can perform actions.<br />
<br />
'''Example''': The image is stored externally with an absolute path.<br />
A right-click makes these option appear:<br />
*Make Relative<br />
*Embed<br />
*Change<br />
*Releod<br />
*Edit externally<br />
<br />
==About Smart Broken link resolver==<br />
'''User case:'''<br />
Let's assume that there are 10 broken links in the document (images that cannot be found considering the given path).<br />
Assume that they are broken because they were stored in the same folder than the document, and that the user wanted to clean his work and moved them in an img/ folder.<br />
<br />
Now if the user repair one broken link by telling the system the new path (img/img1.png instead of img1.png). If the system detects that in this new folder, there are also files that are missing (img/img2.png, img/img3.png), then it asks the user if links should be automatically corrected.<br />
<br />
<br />
<br />
<br />
<br />
=Discussion=<br />
Please, use the [[Talk:Image_links_manager|discussion page]] to discuss around thsi idea.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_links_manager&diff=54307Image links manager2009-10-20T15:59:26Z<p>Steren: </p>
<hr />
<div>=Idea=<br />
As of Inkscape 0.47, the only way to manage images is to edit the XML of the document or to run not-so-user-friendly scripts.<br />
<br />
<br />
The idea is to provide an easy management of these images. The user should be able to :<br />
* replace an image with a new one<br />
* edit an image with an external raster editor<br />
* embed an image<br />
* decide to store externally an embedded image<br />
* decide is an external image is stored with an absolute path or a relative path<br />
* repair broken links by selecting ONE new image, the computer is then clever enough to test if other broken links are findable considering this new image location.<br />
<br />
=Images in inkscape=<br />
We can enumerate 3 types of images:<br />
* External with Absolute path<br />
** The file is stored externally<br />
** Path is absolute (loading on another computer fails)<br />
** example: <br />
<image<br />
xlink:href="file:///home/steren/Bureau/imgs/absolute.png"<br />
width="80"<br />
height="80"<br />
id="image57"<br />
x="40"<br />
y="152" /><br />
* External with Relative path<br />
** The file is stored externally<br />
** Path is relative (if well organized, loading on another computer is ok)<br />
** example: <br />
<image<br />
sodipodi:absref="/home/steren/Bureau/imgs/relative.png"<br />
xlink:href="imgs/relative.png"<br />
y="263.79077"<br />
x="40.000011"<br />
id="image71"<br />
height="80"<br />
width="80" /><br />
<br />
* Embedded<br />
** The file is stored into the document<br />
** Ok but cannot use external software to edit it <br />
** example: <br />
<image<br />
xlink:href="data:image/png;base64,iVBORw0KGgoAAAANS<br />
...***IMAGE STORED HERE***<br />
"<br />
width="80"<br />
height="80"<br />
id="image43"<br />
x="40"<br />
y="40" /><br />
<br />
<br />
A test file can be found [http://www.mediafire.com/?z1egt4tyjcd here], it contains a .svg with 3 images: relative, absolute and embedded.<br />
<br />
=UI Proposal=<br />
==Manager==<br />
[[File:Img_links_mockup.png]]<br />
<br />
(You can find the sources of this image [[Media:Img_links_mockup.svg|here]])<br />
<br />
<br />
Description of the UI: <br />
* Selection Buttons<br />
* Every image of the document appears on a list. Their order is theorder they appear in the XML.<br />
* each line contains:<br />
** a thumbnail of the image<br />
** its path OR ''Embedded'' OR ''Broken link''.<br />
* User can select multiple lines (one click selects a line)<br />
* When images are selected in the manager, they appear selected on the canvas. When images are selected on the canvas, they appear selectedon the manager.<br />
* Actions Buttons<br />
* If actions doesn't have meaning for the current selection, the buttons are disabled (example: The selection contains external absolute and relative images, then the buttons "Make external" is disabled)<br />
<br />
==Right Click==<br />
When the user right clicks on an image, depending on its type, he can perform actions.<br />
<br />
'''Example''': The image is stored externally with an absolute path.<br />
A right-click makes these option appear:<br />
*Make Relative<br />
*Embed<br />
*Change<br />
*Releod<br />
*Edit externally<br />
<br />
=Discussion=<br />
Please, use the [[Talk:Image_links_manager|discussion page]] to discuss around thsi idea.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_links_manager&diff=54305Image links manager2009-10-20T15:55:49Z<p>Steren: </p>
<hr />
<div>=Idea=<br />
As of Inkscape 0.47, the only way to manage images is to edit the XML of the document or to run not-so-user-friendly scripts.<br />
<br />
<br />
The idea is to provide an easy management of these images. The user should be able to :<br />
* replace an image with a new one<br />
* edit an image with an external raster editor<br />
* embed an image<br />
* decide to store externally an embedded image<br />
* decide is an external image is stored with an absolute path or a relative path<br />
* repair broken links by selecting ONE new image, the computer is then clever enough to test if other broken links are findable considering this new image location.<br />
<br />
=Images in inkscape=<br />
We can enumerate 3 types of images:<br />
* External with Absolute path<br />
** The file is stored externally<br />
** Path is absolute (loading on another computer fails)<br />
** example: <br />
<image<br />
xlink:href="file:///home/steren/Bureau/imgs/absolute.png"<br />
width="80"<br />
height="80"<br />
id="image57"<br />
x="40"<br />
y="152" /><br />
* External with Relative path<br />
** The file is stored externally<br />
** Path is relative (if well organized, loading on another computer is ok)<br />
** example: <br />
<image<br />
sodipodi:absref="/home/steren/Bureau/imgs/relative.png"<br />
xlink:href="imgs/relative.png"<br />
y="263.79077"<br />
x="40.000011"<br />
id="image71"<br />
height="80"<br />
width="80" /><br />
<br />
* Embedded<br />
** The file is stored into the document<br />
** Ok but cannot use external software to edit it <br />
** example: <br />
<image<br />
xlink:href="data:image/png;base64,iVBORw0KGgoAAAANS<br />
...***IMAGE STORED HERE***<br />
"<br />
width="80"<br />
height="80"<br />
id="image43"<br />
x="40"<br />
y="40" /><br />
<br />
=UI Proposal=<br />
==Manager==<br />
[[File:Img_links_mockup.png]]<br />
<br />
(You can find the sources of this image [[Media:Img_links_mockup.svg|here]])<br />
<br />
<br />
Description of the UI: <br />
* each line contains:<br />
** a thumbnail of the image<br />
** its path OR ''Embedded'' OR ''Broken link''.<br />
* User can select multiple lines (one click selects a line)<br />
* When images are selected in the manager, they appear selected on the canvas. When images are selected on the canvas, they appear selectedon the manager.<br />
* If actions doesn't have meaning for the current selection, the buttons are disabled (example: The selection contains external absolute and relative images, then the buttons "Make external" is disabled)<br />
<br />
<br />
A test file can be found [http://www.mediafire.com/?z1egt4tyjcd here], it contains a .svg with 3 images: relative, absolute and embedded.<br />
<br />
==Right Click==<br />
When the user right clicks on an image, depending on its type, he can perform actions.<br />
<br />
'''Example''': The image is stored externally with an absolute path.<br />
A right-click makes these option appear:<br />
*Make Relative<br />
*Embed<br />
*Change<br />
*Releod<br />
*Edit externally<br />
<br />
=Discussion=<br />
Please, use the [[Talk:Image_links_manager|discussion page]] to discuss around thsi idea.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=File:Img_links_mockup.svg&diff=54303File:Img links mockup.svg2009-10-20T15:38:16Z<p>Steren: uploaded a new version of "File:Img links mockup.svg"</p>
<hr />
<div></div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=File:Img_links_mockup.png&diff=54301File:Img links mockup.png2009-10-20T15:37:19Z<p>Steren: uploaded a new version of "File:Img links mockup.png"</p>
<hr />
<div></div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_links_manager&diff=54299Image links manager2009-10-20T15:36:17Z<p>Steren: </p>
<hr />
<div>=Idea=<br />
As of Inkscape 0.47, the only way to manage images is to edit the XML of the document or to run not-so-user-friendly scripts.<br />
<br />
<br />
The idea is to provide an easy management of these images. The user should be able to :<br />
* replace an image with a new one<br />
* edit an image with an external raster editor<br />
* embed an image<br />
* decide to store externally an embedded image<br />
* decide is an external image is stored with an absolute path or a relative path<br />
<br />
* repair broken links<br />
<br />
=Images in inkscape=<br />
We can enumerate 3 types of images:<br />
* External with Absolute path<br />
** The file is stored externally<br />
** Path is absolute (loading on another computer fails)<br />
** example: <br />
<image<br />
xlink:href="file:///home/steren/Bureau/imgs/absolute.png"<br />
width="80"<br />
height="80"<br />
id="image57"<br />
x="40"<br />
y="152" /><br />
* External with Relative path<br />
** The file is stored externally<br />
** Path is relative (if well organized, loading on another computer is ok)<br />
** example: <br />
<image<br />
sodipodi:absref="/home/steren/Bureau/imgs/relative.png"<br />
xlink:href="imgs/relative.png"<br />
y="263.79077"<br />
x="40.000011"<br />
id="image71"<br />
height="80"<br />
width="80" /><br />
<br />
* Embedded<br />
** The file is stored into the document<br />
** Ok but cannot use external software to edit it <br />
** example: <br />
<image<br />
xlink:href="data:image/png;base64,iVBORw0KGgoAAAANS<br />
...***IMAGE STORED HERE***<br />
"<br />
width="80"<br />
height="80"<br />
id="image43"<br />
x="40"<br />
y="40" /><br />
<br />
=UI Proposal=<br />
==Manager==<br />
[[File:Img_links_mockup.png]]<br />
<br />
each line contain : a thumbnail of the image and its path.<br />
<br />
(You can find the sources of this image [[Media:Img_links_mockup.svg|here]])<br />
<br />
A test file can be found [http://www.mediafire.com/?z1egt4tyjcd here], it contains a .svg with 3 images: relative, absolute and embedded.<br />
<br />
<br />
* if current selection on the canvas contains images, they appear selected when the manager is opened.<br />
* when images are selected in the manager, they appear selected on the canvas.<br />
<br />
<br />
==Right Click==<br />
<br />
<br />
=Discussion=<br />
Please, use the [[Talk:Image_links_manager|discussion page]] to discuss around thsi idea.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_links_manager&diff=54297Image links manager2009-10-20T15:33:37Z<p>Steren: </p>
<hr />
<div>=Idea=<br />
As of Inkscape 0.47, the only way to manage images is to edit the XML of the document or to run not-so-user-friendly scripts.<br />
<br />
<br />
The idea is to provide an easy management of these images. The user should be able to :<br />
* replace an image with a new one<br />
* embed an image<br />
* decide to store externally an embedded image<br />
* decide is an external image is stored with an absolute path or a relative path<br />
<br />
* repair broken links<br />
<br />
=Images in inkscape=<br />
We can enumerate 3 types of images:<br />
* External with Absolute path<br />
** The file is stored externally<br />
** Path is absolute (loading on another computer fails)<br />
** example: <br />
<image<br />
xlink:href="file:///home/steren/Bureau/imgs/absolute.png"<br />
width="80"<br />
height="80"<br />
id="image57"<br />
x="40"<br />
y="152" /><br />
* External with Relative path<br />
** The file is stored externally<br />
** Path is relative (if well organized, loading on another computer is ok)<br />
** example: <br />
<image<br />
sodipodi:absref="/home/steren/Bureau/imgs/relative.png"<br />
xlink:href="imgs/relative.png"<br />
y="263.79077"<br />
x="40.000011"<br />
id="image71"<br />
height="80"<br />
width="80" /><br />
<br />
* Embedded<br />
** The file is stored into the document<br />
** Ok but cannot use external software to edit it <br />
** example: <br />
<image<br />
xlink:href="data:image/png;base64,iVBORw0KGgoAAAANS<br />
...***IMAGE STORED HERE***<br />
"<br />
width="80"<br />
height="80"<br />
id="image43"<br />
x="40"<br />
y="40" /><br />
<br />
=UI Proposal=<br />
==Manager==<br />
[[File:Img_links_mockup.png]]<br />
<br />
each line contain : a thumbnail of the image and its path.<br />
<br />
(You can find the sources of this image [[Media:Img_links_mockup.svg|here]])<br />
<br />
A test file can be found [http://www.mediafire.com/?z1egt4tyjcd here], it contains a .svg with 3 images: relative, absolute and embedded.<br />
<br />
<br />
* if current selection on the canvas contains images, they appear selected when the manager is opened.<br />
* when images are selected in the manager, they appear selected on the canvas.<br />
<br />
<br />
==Right Click==<br />
<br />
<br />
=Discussion=<br />
Please, use the [[Talk:Image_links_manager|discussion page]] to discuss around thsi idea.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_links_manager&diff=54295Image links manager2009-10-20T15:28:08Z<p>Steren: </p>
<hr />
<div>=Idea=<br />
As of Inkscape 0.47, the only way to manage images is to edit the XML of the document or scripts.<br />
By managing images I mean embed them, change them, make them relative, export them...<br />
<br />
=Images in inkscape=<br />
We can enumerate 3 types of images:<br />
* External with Absolute path<br />
** The file is stored externally<br />
** Path is absolute (loading on another computer fails)<br />
** example: <br />
<image<br />
xlink:href="file:///home/steren/Bureau/imgs/absolute.png"<br />
width="80"<br />
height="80"<br />
id="image57"<br />
x="40"<br />
y="152" /><br />
* External with Relative path<br />
** The file is stored externally<br />
** Path is relative (if well organized, loading on another computer is ok)<br />
** example: <br />
<image<br />
sodipodi:absref="/home/steren/Bureau/imgs/relative.png"<br />
xlink:href="imgs/relative.png"<br />
y="263.79077"<br />
x="40.000011"<br />
id="image71"<br />
height="80"<br />
width="80" /><br />
<br />
* Embedded<br />
** The file is stored into the document<br />
** Ok but cannot use external software to edit it <br />
** example: <br />
<image<br />
xlink:href="data:image/png;base64,iVBORw0KGgoAAAANS<br />
...***IMAGE STORED HERE***<br />
"<br />
width="80"<br />
height="80"<br />
id="image43"<br />
x="40"<br />
y="40" /><br />
<br />
=UI Proposal=<br />
==Manager==<br />
[[File:Img_links_mockup.png]]<br />
<br />
each line contain : a thumbnail of the image and its path.<br />
<br />
(You can find the sources of this image [[Media:Img_links_mockup.svg|here]])<br />
<br />
A test file can be found [http://www.mediafire.com/?z1egt4tyjcd here], it contains a .svg with 3 images: relative, absolute and embedded.<br />
<br />
==Right Click==<br />
<br />
<br />
=Discussion=<br />
Please, use the [[Talk:Image_links_manager|discussion page]] to discuss around thsi idea.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_links_manager&diff=54293Image links manager2009-10-20T15:25:03Z<p>Steren: </p>
<hr />
<div>=Idea=<br />
As of Inkscape 0.47, the only way to manage images is to edit the XML of the document or scripts.<br />
By managing images I mean embed them, change them, make them relative, export them...<br />
<br />
=Images in inkscape=<br />
We can enumerate 3 types of images:<br />
==External with Absolute path==<br />
example: <br />
<image<br />
xlink:href="file:///home/steren/Bureau/imgs/absolute.png"<br />
width="80"<br />
height="80"<br />
id="image57"<br />
x="40"<br />
y="152" /><br />
==External with Relative path==<br />
example:<br />
<image<br />
sodipodi:absref="/home/steren/Bureau/imgs/relative.png"<br />
xlink:href="imgs/relative.png"<br />
y="263.79077"<br />
x="40.000011"<br />
id="image71"<br />
height="80"<br />
width="80" /><br />
<br />
==Embedded==<br />
example:<br />
<image<br />
xlink:href="data:image/png;base64,iVBORw0KGgoAAAANS<br />
...***IMAGE STORED HERE***<br />
"<br />
width="80"<br />
height="80"<br />
id="image43"<br />
x="40"<br />
y="40" /><br />
<br />
=UI Proposal=<br />
==Manager==<br />
[[File:Img_links_mockup.png]]<br />
<br />
each line contain : a thumbnail of the image and its path.<br />
<br />
(You can find the sources of this image [[Media:Img_links_mockup.svg|here]])<br />
<br />
A test file can be found [http://www.mediafire.com/?z1egt4tyjcd here], it contains a .svg with 3 images: relative, absolute and embedded.<br />
<br />
==Right Click==<br />
<br />
<br />
=Discussion=<br />
Please, use the [[Talk:Image_links_manager|discussion page]] to discuss around thsi idea.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Image_links_manager&diff=54291Image links manager2009-10-20T15:15:40Z<p>Steren: Created page with '=Idea= =Images in inkscape= ==External with Absolute path== ==External with Relative path== ==Embedded== =UI Proposal= File:Img_links_mockup.png each line contain : a ...'</p>
<hr />
<div>=Idea=<br />
<br />
<br />
=Images in inkscape=<br />
==External with Absolute path==<br />
<br />
==External with Relative path==<br />
<br />
==Embedded==<br />
<br />
<br />
=UI Proposal=<br />
[[File:Img_links_mockup.png]]<br />
<br />
each line contain : a thumbnail of the image and its path.<br />
<br />
(You can find the sources of this image [[Media:Img_links_mockup.svg|here]])<br />
<br />
A test file can be found [http://www.mediafire.com/?z1egt4tyjcd here], it contains a .svg with 3 images: relative, absolute and embedded.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=File:Img_links_mockup.svg&diff=54289File:Img links mockup.svg2009-10-20T15:05:54Z<p>Steren: </p>
<hr />
<div></div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=File:Img_links_mockup.png&diff=54287File:Img links mockup.png2009-10-20T15:05:16Z<p>Steren: </p>
<hr />
<div></div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=New_feature_proposals&diff=54285New feature proposals2009-10-20T15:03:29Z<p>Steren: </p>
<hr />
<div>=== Proposals for New Features ===<br />
<br />
'''Please think twice when you edit this page: we use Launchpad's [https://blueprints.launchpad.net/inkscape/ blueprints] for all this now.'''<br />
<br />
This page is for links to pages describing concepts, proposals, and specs for new features, major architectural changes, large scale codebase refactorings, etc. As they are implemented, these links should be moved to more appropriate areas of the Wiki.<br />
The idea here is to enable everyone to hash out requirements and design of a potential new feature in detail prior to implementation. See also: <br />
<br />
[[InkscapeExperimental]] and [[Roadmap]].<br />
* [[User:Davidhewitt|Bottom Tool-bar update proposal]]: Outlines my proposal for a UI facelift for the Bottom Tool bar. Also introduces a new mode of operation for the palette itself.<br />
* [[User:Bats|A user's list of suggestions/wishes]]: I recently finished a web project using Inkscape (mainly). This is a list of the things I wished it had, the things I liked but wanted to tweak and other observations as I was working. Perhaps it will help the programmers to see what a designer sees. I hope.<br />
* [[InkscapeNeeds]]<br />
* [[FeatureNotePad]]: use this for small notes and enhancement ideas, or for temporarily dumping feature requests (e.g. from mailing lists) before they are thought over, categorized, and put into pages of their own<br />
<br />
* [[DirectoryReorgProposal]] [DONE]<br />
* [[NonRecursiveMakefile]] [DONE]<br />
* [[NewTools]]<br />
* [[NetworkedEditing]]<br />
* [[SharingDefs]]: Not exactly new, but need conversion/upgrade<br />
* [[AdvancedFileAccess]]<br />
* [[DocumentLayers]]<br />
* [[PlugIns]]: This could be script ideas as well.<br />
* [[HUD]]: putting head up displays on the sp-canvas<br />
* [[PathOps]]<br />
* [[InfoPalette]]<br />
* [[ColorPalette]]<br />
* [[UnitConversion]]<br />
* [[ScriptingLanguages]] & options for handling extensibility<br />
* [[TestingFramework]]: Creating testing framework<br />
* [[PreferencesDialog]]<br />
* [[BreadthFirstUndo]]<br />
* [[CadInteroperability]]<br />
* [[FontKerning]]<br />
* [[PathfinderPalette]]<br />
* [[PreserveOverTransform]]<br />
* [[GimpInteraktion]]<br />
* [[ClipTemplates]] - svg templates<br />
* [[StockLibraryInterface]]<br />
* [[Cairoification]]: replace svg renderer<br />
* [[OpenPublishingToolsOrganization]]<br />
* [[HelpMenu]]<br />
* [[FormObject]]<br />
* [[AST]]<br />
* [[SpellCheckForTextNodes]]<br />
* [[XML repair]] service for broken or weird files<br />
* [[MoreUsableWorkingFolders]]<br />
* [[SplitPaneUI]] View<br />
* [[Pre-installed gradients]]<br />
* [[rotate group of path points(knots)]]<br />
* [[Searching within Inkscape]]<br />
* [[UsingTheConnectorTool]] (various improvements to the Connector tool)<br />
* [[PureSVG]]: SVG that plays well with others<br />
* [[Image links manager]] an UI for a better management of image links<br />
<br />
=== Review Inkscape RFE's and [[SodiPodi]]'s Tasks ===<br />
<br />
Please review the following links, extract ideas, and develop them further for inclusion and discussion on this WIKI page.<br />
<br />
* [http://sourceforge.net/tracker/?group_id=93438&atid=604309 Inkscape RFE's]<br />
* [http://www.sodipodi.com/index.php3?section=development/tasks [[SodiPodi]] Task List] -- I think this link is outdated and leads to a wrong page. The newest release of Sodipodi is of june 2004. Although there is some activity on the svn uploads I would recommend removing this link or replacing it by [http://sourceforge.net/projects/sodipodi Sodipodi on Sourceforge]. --[[User:Gman beginner|Gman beginner]] 22:34, 13 July 2009 (UTC)<br />
<br />
[[Category:Developer Discussion]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=SpecSprayTool&diff=38634SpecSprayTool2008-11-11T10:46:43Z<p>Steren: /* UI */</p>
<hr />
<div>'''NOTE: If you want to propose something, please put it on a separate section. It helps me keeping my part tidy.''' --[[User:Pajarico|Pajarico]] 05:26, 10 August 2008 (UTC)<br />
----<br />
Launchpad Entry:<br />
https://blueprints.launchpad.net/inkscape/+spec/spray-tool<br />
<br />
inkscape-devel thread:<br />
http://www.nabble.com/Spray-tool-discussion-td18860839.html<br />
<br />
== Summary ==<br />
This tool allows "painting" of motifs on the canvas. When clicking and dragging, several copies are scattered following the drawn stroke. Controls to adjust scaling, rotation, color (HSLO) and the randomness (or limits) of each parameter should be made available.<br />
The radius of the tool controls the main active zone where the copies will be drawn. The described controls set how the copies vary. The result could be:<br />
* Copies.<br />
* Clones (shift+D would point the original).<br />
* Everything is rendered to a single-path object. Having a selected object would ADD to it.<br />
<br />
The motifs are taken from the clipboard but some default shapes could be provided (like a circle, a square, a snow flake...). Some of the UI elements keep similarities with the Tweak tool.<br />
<br />
== Release Note ==<br />
== Rationale ==<br />
<br />
== Design ==<br />
<br />
=== UI ===<br />
[[Image:Spray-tool-ui01.png]]<br />
<br />
'''Other options...'''<br />
<br />
[[Image:Spray-tool-ui02.png]]<br />
<br />
* '''Scaling:''' Define how object's scale should vary.<br />
* '''Rotation:''' Define how object's rotation should vary.<br />
* '''Color:''' Define how object's color should vary. Settings for controlling HSLO.<br />
<br />
The above settings variation are controlled by:<br />
* '''Randomness:''' Define to which extent the attributes above should vary randomly.<br />
<br />
* '''Limits:''' Min and max values for the variation. E.g.: <br />
** For scaling: ''max: 110%, min: 80%''<br />
** For rotation: ''max: 180º, min: 30º'' (values between 0 and 360º)<br />
** For color: Two user-selected colors are compared in HSL values, according to what is set on the HSLO buttons, the sprayed items color will be between their H, S, L and/or O attributes.<br />
For example:<br />
* Setting a non-zero value for randomness and limits ''max: 180º, min: 30º'' would rotate the objects randomly only between 30 and 180º.<br />
<br />
* '''Use path:''' Use an already drawn path as a guide for spraying using current settings.<br />
<br />
=== Usage ===<br />
The radiuses on the first example show one of the possible ways to configure the spraying density:<br />
<br />
[[Image:Spray-tool-usage01.png]]<br />
<br />
However, a secondary system (which is more powerful) works like this. Note that this example correlates to the UI example proposed by Pajarico above. It uses a curve to adjust the density instead of two radiuses:<br />
<br />
[[Image:Spray-tool-cursor01.png]]<br />
[[Image:Spray-tool-cursor02.png]]<br />
<br />
This system allows:<br />
* Literally draw densities in a intuitive way.<br />
* Adjust a different density for each object, or share them via Presets.<br />
* Set density functions that has a hole in them or concentric rings.<br />
* Set degrees of density that you can't get with the 2-radiuses approach.<br />
<br />
----<br />
<br />
On the following mockup is shown how the limits and randomness work for Hue. Depending on the limits the user gets a different gamma of possible colors; and randomness controls the distribution of the Hue values inside those limits:<br />
<br />
[[Image:Spray-tool-attributes01.png]]<br />
<br />
Randomness=0 means "pick the middle value between limits".<br />
<br />
=== SVG representation ===<br />
<br />
== TODO ==<br />
<br />
== Discussion ==</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=SpecSprayTool&diff=34124SpecSprayTool2008-08-10T01:57:11Z<p>Steren: /* UI */</p>
<hr />
<div>Launchpad Entry:<br />
https://blueprints.launchpad.net/inkscape/+spec/spray-tool<br />
<br />
== Summary ==<br />
This tool allows "painting" of motifs on the canvas. When clicking and dragging, several copies are scattered following the drawn stroke. Controls to adjust scaling, rotation, color (HSLO) and the randomness (or limits) of each parameter should be made available.<br />
The radius of the tool controls the main active zone where the copies will be drawn. The described controls set how the copies vary. The result could be:<br />
* Copies.<br />
* Clones (shift+D would point the original).<br />
* Everything is rendered to a single-path object. Having a selected object would ADD to it.<br />
<br />
The motifs are taken from the clipboard but some default shapes could be provided (like a circle, a square, a snow flake...). Some of the UI elements keep similarities with the Tweak tool.<br />
<br />
== Release Note ==<br />
== Rationale ==<br />
<br />
== Design ==<br />
<br />
=== UI ===<br />
[[Image:Spray-tool-ui01.png]]<br />
<br />
'''Other options...'''<br />
<br />
[[Image:Spraytool_dialogue_steren.png]]<br />
<br />
* '''Scaling:''' Define how object's scale should vary.<br />
* '''Rotation:''' Define how object's rotation should vary.<br />
* '''Color:''' Define how object's color should vary. Settings for controlling HSLO.<br />
<br />
The above settings variation are controlled by:<br />
* '''Randomness:''' Define to which extent the attributes above should vary randomly.<br />
<br />
Here is the link between the randomness number and the actual distribution :<br />
<br />
[[Image:Random spray.png]]<br />
<br />
* '''Limits:''' Min and max values for the variation. E.g.: <br />
** For scaling: ''max: 110%, min: 80%''<br />
** For rotation: ''max: 180º, min: 30º'' (values between 0 and 360º)<br />
** For color: Two user-selected colors are compared in HSL values, according to what is set on the HSLO buttons, the sprayed items color will be between their H, S, L and/or O attributes.<br />
For example:<br />
* Setting a non-zero value for randomness and limits ''max: 180º, min: 30º'' would rotate the objects randomly only between 30 and 180º.<br />
<br />
* '''Use path:''' Use an already drawn path as a guide for spraying using current settings.<br />
<br />
=== Usage ===<br />
[[Image:Spray-tool-usage01.png]]<br />
<br />
=== SVG representation ===<br />
<br />
== TODO ==<br />
<br />
== Discussion ==</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=SpecSprayTool&diff=34114SpecSprayTool2008-08-10T01:56:51Z<p>Steren: randomness</p>
<hr />
<div>Launchpad Entry:<br />
https://blueprints.launchpad.net/inkscape/+spec/spray-tool<br />
<br />
== Summary ==<br />
This tool allows "painting" of motifs on the canvas. When clicking and dragging, several copies are scattered following the drawn stroke. Controls to adjust scaling, rotation, color (HSLO) and the randomness (or limits) of each parameter should be made available.<br />
The radius of the tool controls the main active zone where the copies will be drawn. The described controls set how the copies vary. The result could be:<br />
* Copies.<br />
* Clones (shift+D would point the original).<br />
* Everything is rendered to a single-path object. Having a selected object would ADD to it.<br />
<br />
The motifs are taken from the clipboard but some default shapes could be provided (like a circle, a square, a snow flake...). Some of the UI elements keep similarities with the Tweak tool.<br />
<br />
== Release Note ==<br />
== Rationale ==<br />
<br />
== Design ==<br />
<br />
=== UI ===<br />
[[Image:Spray-tool-ui01.png]]<br />
<br />
'''Other options...'''<br />
<br />
[[Image:Spraytool_dialogue_steren.png]]<br />
<br />
* '''Scaling:''' Define how object's scale should vary.<br />
* '''Rotation:''' Define how object's rotation should vary.<br />
* '''Color:''' Define how object's color should vary. Settings for controlling HSLO.<br />
<br />
The above settings variation are controlled by:<br />
* '''Randomness:''' Define to which extent the attributes above should vary randomly.<br />
Here is the link between the randomness number and the actual distribution :<br />
[[Image:Random spray.png]]<br />
<br />
* '''Limits:''' Min and max values for the variation. E.g.: <br />
** For scaling: ''max: 110%, min: 80%''<br />
** For rotation: ''max: 180º, min: 30º'' (values between 0 and 360º)<br />
** For color: Two user-selected colors are compared in HSL values, according to what is set on the HSLO buttons, the sprayed items color will be between their H, S, L and/or O attributes.<br />
For example:<br />
* Setting a non-zero value for randomness and limits ''max: 180º, min: 30º'' would rotate the objects randomly only between 30 and 180º.<br />
<br />
* '''Use path:''' Use an already drawn path as a guide for spraying using current settings.<br />
<br />
=== Usage ===<br />
[[Image:Spray-tool-usage01.png]]<br />
<br />
=== SVG representation ===<br />
<br />
== TODO ==<br />
<br />
== Discussion ==</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=File:Random_spray.png&diff=34104File:Random spray.png2008-08-10T01:39:09Z<p>Steren: randomness parameter forspray tool</p>
<hr />
<div>randomness parameter forspray tool</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=SpecSprayTool&diff=34094SpecSprayTool2008-08-10T00:57:21Z<p>Steren: more options dialogue</p>
<hr />
<div>Launchpad Entry:<br />
https://blueprints.launchpad.net/inkscape/+spec/spray-tool<br />
<br />
== Summary ==<br />
This tool allows "painting" of motifs on the canvas. When clicking and dragging, several copies are scattered following the drawn stroke. Controls to adjust scaling, rotation, color (HSLO) and the randomness (or limits) of each parameter should be made available.<br />
The radius of the tool controls the main active zone where the copies will be drawn. The described controls set how the copies vary. The result could be:<br />
* Copies.<br />
* Clones (shift+D would point the original).<br />
* Everything is rendered to a single-path object. Having a selected object would ADD to it.<br />
<br />
The motifs are taken from the clipboard but some default shapes could be provided (like a circle, a square, a snow flake...). Some of the UI elements keep similarities with the Tweak tool.<br />
<br />
== Release Note ==<br />
== Rationale ==<br />
<br />
== Design ==<br />
<br />
=== UI ===<br />
[[Image:Spray-tool-ui01.png]]<br />
<br />
'''Other options...'''<br />
<br />
[[Image:Spraytool_dialogue_steren.png]]<br />
<br />
* '''Scaling:''' Define how object's scale should vary.<br />
* '''Rotation:''' Define how object's rotation should vary.<br />
* '''Color:''' Define how object's color should vary. Settings for controlling HSLO.<br />
<br />
The above settings variation are controlled by:<br />
* '''Randomness:''' Define to which extent the attributes above should vary randomly.<br />
* '''Limits:''' Min and max values for the variation. E.g.: <br />
** For scaling: ''max: 110%, min: 80%''<br />
** For rotation: ''max: 180º, min: 30º'' (values between 0 and 360º)<br />
** For color: Two user-selected colors are compared in HSL values, according to what is set on the HSLO buttons, the sprayed items color will be between their H, S, L and/or O attributes.<br />
For example:<br />
* Setting a non-zero value for randomness and limits ''max: 180º, min: 30º'' would rotate the objects randomly only between 30 and 180º.<br />
<br />
* '''Use path:''' Use an already drawn path as a guide for spraying using current settings.<br />
<br />
=== Usage ===<br />
[[Image:Spray-tool-usage01.png]]<br />
<br />
=== SVG representation ===<br />
<br />
== TODO ==<br />
<br />
== Discussion ==</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=File:Spraytool_dialogue_steren.png&diff=34084File:Spraytool dialogue steren.png2008-08-10T00:54:43Z<p>Steren: a mock up for the parameters dialogue of the spray tool.</p>
<hr />
<div>a mock up for the parameters dialogue of the spray tool.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Lpe-blueprint&diff=32854Lpe-blueprint2008-07-21T23:51:42Z<p>Steren: /* Deformation Envelope */</p>
<hr />
<div>''''Live path effects' blue print proposal.'''<br />
<br />
----<br />
<br />
This page aims at gathering propositions about what the (eventually long term) future of live path effects could be. The goal is to have better view of what could be done, what is hard, what is easy, what is worth and what is not,<br />
list possible alternatives, etc...<br />
Please add your comment and propositions!<br />
<br />
Some of this already exists : see the great [http://wiki.inkscape.org/wiki/index.php/MakingLivePathEffects#Current_Projects projects] currently under developpement!<br />
<br />
<br />
==Live Path Effect alias Modifier stack==<br />
This is a rather long term proposition, formulated from the Features and UI point of view. The basic observation is that it is natural to have several successive live path effects applied to the same object, leading to an effect stack. The proposition below mimics the modifier stack found in most 3D software. <br />
As it is also natural to allow sophisticated objects (groups, or objects carrying effects on their own) as input, edition of nested effects can become tricky (consider for instance non destructive boolean operation of two objects, both carrying effects). This proposition tries to address this point.<br />
<br />
To end this introduction, consider the two baby cases below, trying to illustrate the need of "rich objects" (i.e. full svg data) both as input paramters and output.<br />
<br />
<center>[[Image:lpe_need_rich_input.png]]</center><br />
<br />
The first example shows a boolean operation (difference) of two objects, but the second one recieves a small offset before doing the difference. This kind of "outline" appears frequently in logo design. Notice that both operand carry an effect. For this operation to be non destructive, stacking of effects should be possible not only on one root object, but also on input parameters. Suppose it's not the case: should the sun be the main input of a "boolean-operation" effect, would the offset width be lost (i.e. not editable anymore); should it be the cloud would the pattern-along-path be lost. <br />
<br />
<center>[[Image:lpe_need_rich_output.png]]</center><br />
<br />
This second example is about lpe output: alowing full svg data would widely enlarge the range of possibilities, for instance deforming colorfull objects (notice this already possible using [http://wiki.inkscape.org/wiki/index.php/LPE_for_groups lpe on groups]!!), or interpolate between styles at the same time as shapes. <br />
<br />
<br />
<br />
===Effect stack: features and UI===<br />
<br />
Steren : A team of french students is currently implementing this, see [[LPE_stacking]].<br />
<br />
====General usage====<br />
A side panel is dedicated to the effect stack. On the top is displayed <br />
the stack itself, and below the parameters of particular effects.<br />
The picture below summerizes the main features of the stack area.<br />
<br />
A side panel is dedicated to the effect stack. On the top is displayed <br />
the stack itself, and below the parameters of particular effects.<br />
The picture below summerizes the main features of the stack area. <br />
<br />
[[Image:lpestack.png]]<br />
<br />
The full stack can be navigated and any effect in the stack can be selected to <br />
become active. The pannel below the stack displays the active effects <br />
parameters. In the main window (the canvas), the output of the active effect <br />
is displayed (ideally, a button near the stack toggles wether the stack is<br />
blocked at the active level, or runs to its end)<br />
<br />
*The stack can be collapsed (1) from the active effect to the original shape. The output of the active effect becomes the new original shape.<br />
*Each effect can be temporariliy (4) bypassed to save performance and interactivity<br />
*Effects can be draged and droped to reorganize the stack<br />
*Effects can copied, pasted, cloned (i.e. shared) between objects (6). Shared effects can be made unique (3).<br />
*Effects names (i.e. svg id attribute) can be edited.<br />
<br />
====Sublevel navigation====<br />
<br />
Some effect use other objects (paths, groups...) as parameters. In this case, <br />
the line of the effect in the stack can be expanded to show the list of all <br />
object parameters (see fig. 2).<br />
<br />
[[Image:lpestackeditmode.png]]<br />
<br />
As such objects might be "virtual" (i.e. not available on the canvas) and<br />
complex (typically groups of objects carrying effects on their own),<br />
an edit mode is needed for such objects that goes beyond the node editor: <br />
all operations (style, z-order, path effects...) should be availble. <br />
<br />
To this end, selecting an object parameter in the effect stack enters edit mode<br />
for that object: its own effect stack is inserted in the global stack(bracketed<br />
with easily identified color), and each level of it can be edited normally (in particular, deeper object parameters might be recursively edited). <br />
<br />
Edit mode exits when the effect is not active anymore, i.e.<br />
*another object parameter is selected, <br />
*the list of object parameters is closed, <br />
*another effect is selected, <br />
*the object is deselected. <br />
(for convenience, a level in the stack could be pined, to avoid non intentional exits).<br />
<br />
'''Note:''' For groups, the first line in the stack should be a "group" pseudo effect, meant to allow selection of objects within the group.<br />
<br />
===An alternative: effect stack within object browser===<br />
Sooner or later, we will have an object browser (more user oriented than the xml browser). If we manage to make it effect-aware, all this should be in fact included in the object browser...<br />
Object carrying effects would have a special icon as child; clicking it would expand the effect stack, and in turn, each effect would have its parameter objects as childs... <br />
<br />
<br />
===Generic effect: features and UI===<br />
This section describes the general features desired for lpes.<br />
<br />
*input:<br />
**use any object as input(s): groups, clones, text... </li> (Steren : the french students are currently implementing this, see [[LPE_for_groups]]).<br />
**check restrictions for input, and eventually warn the user (eg. accept only connected paths...)<br />
**object paramters are picked with the mouse, and copied, cloned, or moved into the effect according to user choice (see fig. 1).<br />
**be aware of the style of the inputs.<br />
*output:<br />
**can output full svg data,<br />
**recieves an extra selection of the input (a list of objects, path componenents or nodes(?) of the input) to restrict, if possible, the effect to this selection. Outputs the relevant selection, for the eventual next effect.<br />
*interaction:<br />
**can perform all inkscape operations on the active object (node-edition, z-order, insert new lpe, etc...)<br />
**pick buttons<br />
**fancy "tools": can display it's own temporary objects for user interaction purpose, and define how to react to selection/edition of such objects with the node tool.<br />
<br />
===Particular effects: per effect specifications===<br />
<br />
====Boolean operation====<br />
Non destructive operation are usefull. Use Mgsloan work on 2geom-intersection here!<br />
<br />
====Transform effect====<br />
Applies a transform matrix to the object; automatically added before a new <br />
effect if the object has a non empty transform attribute. This is needed since<br />
transforms and effects do not commute in general...<br />
<br />
====Style effect====<br />
Applies a given style to the object; added automatically when a new style is<br />
applied to an object with non empty stack. Usefull to overwrite the default <br />
style produced by other effects. Should allow to set the priority of each<br />
style component (replace old style, replace only if not set...)<br />
<br />
====Selector====<br />
This effect selects a part of the input. It has 3 modes:<br />
*object level: selects object(s) within a group.<br />
*path level: selects component(s) within a path.<br />
*[node level: selects node(s) within a path.](? --- delicate)<br />
<br />
The subsequent effects should work on this selection, and leave everything else <br />
unchanged. (usefull to apply different effects to different step of an interpolate effect for instance)<br />
<br />
Notice that whenever the stack is modified before this effect, the user should be warned that this modifier depends on the "topology" of the input...<br />
<br />
====Pattern along path====<br />
*Take a group as pattern, and set the style of the output according to it, to allow color full pattern stroke.<br />
*Allow space between copies, normal and tangential offsets.<br />
*Add an option to fuse nearby ends (to allow gluing of the successive patterns into a single connected path for instance)(?)<br />
*Option to leave the original shape in the output(?) (to allow filling of the area)<br />
*Use another pattern for the "corners"(?) <br />
<br />
====Offset====<br />
Dynmical offset could naturally be turned into an effect (it is not compatible with lpe at the moment).<br />
<br />
====Fillet/champfer====<br />
Add specification here!<br />
<br />
====Thick/Thin strokes====<br />
Add specification here!<br />
<br />
====Interpolate====<br />
Intermediate shapes could follow a distorted path instead of a straight line...<br />
Add specification here!<br />
<br />
====Knotting effect====<br />
click on a crossing to flip it. The UI should have a node tool button labeled "flip crossings". When this is selected, small red circles are drawn at each crossing. A a click in such an area flips the coresponding crossing...<br />
<br />
====So many more!!====<br />
All the effects we have as extensions can become live effects rather easily.<br />
Please add your propositions here!<br />
<br />
====Dynamic drop shadow====<br />
Currently doable with blur, blur+clip path, or with an array of filters, and probably some more ways but not so nice to make and re-edit (especially re-edit) and it would be good to have an on-canvas real time editing effect like this. Numerical parameters could include: opacity, size (complete size of the shadow), extension (how the intensity of the shadow decay, could be related to a blur factor), color, angle and distance.<br />
<br />
Angle and distance should be editable numerically on the effect dialog and those values linked to the canvas position of the shadow and its angle, so its easy to adjust both manually or numerically.<br />
<br />
Color could be a plain color or a gradient.<br />
<br />
The shadow could have a turbulence/convolution filter applied to it.<br />
--[[User:Pajarico|Pajarico]] 01:30, 1 March 2008 (UTC)<br />
<br />
====Perspective====<br />
<br />
Same as the one in ''Effects->Modify Path'' but editable on-canvas. The editable part is a square bounding box which has four pullable corners to do the perspective (or this is an envelope? I tend to get these two confused...)<br />
<br />
If this spec gets approved, a shadow could be rendered in perspective chaining a dynamic drop shadow and a perspective effects together.<br />
--[[User:Pajarico|Pajarico]] 01:30, 1 March 2008 (UTC)<br />
<br />
A first version of a perspective LPE has been in SVN for a while now, although it still lacks a lot of interactivity. This will be improved after this year's Summer of Code when LPEs will be a lot better integrated (e.g., when handle management is added). (Max, 08 June 2008)<br />
<br />
<br />
<br />
====Bevel====<br />
Adds a bevel to an object. Some of the options could be:<br />
* Bevel extension.<br />
* Bevel height. The height is simulated with the luminosity of the sides of the bevel.<br />
* Sharpness, i. e.: how rounded/hard should the corners be.<br />
* Direction of light (in degrees).<br />
* Distance from the light to the object.<br />
* Color of the light.<br />
* Shape of the bevel.<br />
* Any other? Add it here.<br />
<br />
The bevel should be simulated with multiples facets, each one having a varying shade of light according to light parameters and the object's own color. The extension and light position should be editable on canvas.<br />
I will try to do a full fledged blueprint on the following days.<br />
<br />
==SVG representation==<br />
<br />
<br />
==API design==</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Release_notes/0.47&diff=30454Release notes/0.472008-06-10T16:14:45Z<p>Steren: Live path effects stacking</p>
<hr />
<div>=Inkscape 0.47=<br />
'''(not released yet)'''<br />
<br />
=Refactoring effort=<br />
[mention the 'main' goal of 0.47 and list which things have been refactored and the benefits/new features/different workflow? --johan]<br />
<br />
=Tools=<br />
<br />
==Node tool==<br />
<br />
* [helper path display, flashing - johan]<br />
* The Node tool can now edit '''clipping paths''' and '''masks''' of objects on canvas, without releasing them. If the selected object has a clipping path and mask, the corresponding buttons on the controls bar of the tool will be enabled; pressing these buttons will display the editable paths or handles of the clippath or mask. A clipping path is stroked green, a mask is stroked blue (the same colors as those used for them in Outline mode).<br />
* Snapping has been improved (more details in Snapping below)<br />
* When dragging a node '''handle with Ctrl''', it now snaps not only to the 15 degree increments starting from 0 and to the original handle direction, but also to the direction of the '''opposite handle''' (if it exists) or of the '''opposite line segment''' (if it is a straight line).<br />
* The behavior of the buttons/shortucts that make a node smooth or cusp has been improved:<br />
:* If a node is already cusp (diamond shaped), pressing Shift+C again on it will retract both its handles. As this works for any number of selected nodes, you can always retract all handles in all nodes by selecting all nodes and pressing Shift+C twice.<br />
:* If a non-smooth node is next to a straight line segment, pressing Shift+S once makes it ''half-smooth'': it now has one handle aligned with that line segment. Another press of Shift+S will expand the second handle as well turning it into a full smooth node. If a node is between two curve segments, Shift+S will expand both handles as before.<br />
<br />
==Calligraphy tool ==<br />
Added 4 preset buttons for dip, pen, brush and reed in the toolbox. Clicking one button sets the calligraphic tool with the matching presets.<br />
<br />
==Paint Bucket tool==<br />
* Paint Bucket is now more tightly integrated with potrace. As a result, memory and CPU usage on each fill operation have been reduced significantly.<br />
<br />
==Eraser Tool==<br />
A new eraser tool has been added. It has two main modes:<br />
* Delete-mode where any shape touched by the tool is deleted completely. This operation is in line with "vector" editing.<br />
* Cut mode where erasing acts similar to erasing in a standard bitmap editor.<br />
Erasing is also limited to the currently selected objects if there are any selected.<br />
<br />
=Transform dialog=<br />
<br />
Previously, the '''Apply to each object separately''' checkbox had no effect for the '''Move''' tab. Now, if several objects are selected, this checkbox is on, and "Relative move" is on, each object is shifted relative to the closest selected object on the left (for X) or below (for Y). <br />
<br />
For example, if you have a horizontal row of objects and you move them relatively by X=5px with "Apply to each object separately" on, the leftmost object will shift by 5px, the next one to the right by 10px, and so on; the rightmost selected object is displaced by 5*n px where n is the number of selected objects. As a result, the distance in each pair of adjacent objects will increase by 5px and the whole row will be spaced out, much like a letterspacing adjustment spaces out a text string. Moving these objects by X=-5px will, conversely, squeeze them tighter together: the leftmost will move by -5px, the next one by -10px, and so on. For Y, the effect is the same except that the move starts from the object closest to the bottom (i.e. with smallest Y coordinate). <br />
<br />
When determining the order of shifting objects, for X, the left edges of their bounding boxes are sorted horizontally, and for Y, the bottoms of their bounding boxes are sorted vertically. Order of selecting the objects or z-order does not matter.<br />
<br />
=Live path effects=<br />
== Notable bug fixes and effect changes==<br />
We try to refrain from changing the behavior of LPE's, because it will change appearance in old files when opened in Inkscape¹. But when an effect is really broken, we have to fix it.<br />
<br />
[¹ fixme: Shouldn't the above say "it will change editing behaviour in old files" ? If it changes the appearance, then that's a bug: inkscape should always save SVG that represents the appearance, and should display according to the SVG rather than any inkscape:blah annotations. --pjrm <br><br />
What is meant is the following. Files with LPEs opened in a random viewer will always look the same, regardless of Inkscape version. However, when viewed in Inkscape, the LPE is recalculated. When LPE behavior changes, the appearance will change. --johan]<br />
<br />
* The Pattern Along Path effect used to stretch the pattern across discontinuities. This has been fixed; now it treats a discontinuous path as a group of continuous paths and applied the effect separately to each.<br />
<br />
==New effects==<br />
[new: sketch, von koch, knot]<br />
<br />
* '''Perspective paths''': Draw an arbitrary path as if viewed in perspective. This is work in progress. Known limitations (among others): It can only use the first perspective that exists in the document defs, and the perspective cannot be adapted interactively yet (the effect must be removed and reapplied after modifying the perspective). [max]<br />
<br />
* '''Spiro splines''' are a novel way of defining curvilinear paths [http://www.levien.com/spiro/ developed by Raph Levien]. It takes some getting used to, but for certain tasks (such as lettershape design) Spiros have a clear advantage over Bezier curves. Recently, Spiro support was added to the FontForge font editor; now it is available in Inkscape too, which means you can use all the convenient Inkscape path tools (moving and transforming groups of nodes, node sculpting, etc.) on Spiro paths.<br />
<br />
:A Spiro path is defined by a sequence of points, but unlike a regular path with Bezier curves, all Spiro points lie on the path and there are no off-path handles. The curvature of the path is defined entirely by the positions of the points and their types. The path behaves very similar to a springy rod which is forced to pass through the given points and which uses the minimum possible curvature to satisfy the requirement. As such, it feels quite natural and the resulting path is very smooth - not just superficially smooth (i.e. having no cusps), but smooth at a deeper level, which you can achieve with Beziers only after a lot of laborious tweaking. <br />
<br />
:To create a Spiro path, select any path and assign the "Spiro spline" path effect to it. There are no parameters. Each node of your path becomes a point of a Spiro path, depending on the type of node:<br />
<br />
:* Smooth nodes (those with two collinear Bezier handles; use Shift+S to make a node smooth) become smooth curve points of the Spiro path. Note that the length or direction of the Bezier handles of the source path is ignored; the only thing that matters is their collinearity.<br />
<br />
:* Cusp nodes of the source path become corner points of the Spiro path, like free hinges on the springy rod. Between two corner points, the path is always a straight line. To make a node cusp, retract its Bezier handles by Ctrl+click, or press Shift+C and move one of the handles so they are no longer collinear.<br />
<br />
:* Half-smooth nodes - those with one Bezier handle collinear with a straight line segment on the other hand - become "left" or "right" points on the Spiro path which behave exactly the same: they sit between a straight line and a curve and enforce that these two segments join smoothly without a cusp. To create such a node, make sure one of the segments is a line (select its ends and press Shift+L), then Ctrl+drag the remaining handle to make it snap to the direction of the straight line segment on the other side, or press Shift+S to lock it to that direction.<br />
<br />
:Note that what matters is the actual collinearity of a node's handles, regardless of the node type that the node has in the Node tool; for example, if a node designated as cusp (diamond-shaped) has collinear handles, it will become a smooth curve point of the Spiro path. <br />
<br />
:Some configurations of points do not converge and produce wild loops and spirals instead of a smooth curve. According to Raph, "The spline solver in this release is _not_ numerically robust. When you start drawing random points, you'll quickly run into divergence. However, "sensible" plates based on real fonts usually converge." Avoid too sharp changes in direction between points to prevent divergence. Hopefully, the robustness of the algorithm will be improved in future releases.<br />
<br />
:For now, to edit Spiro paths viewing the result in real time, you have to use the Node tool; it is recommended to turn off the red highlight of the source path as it is a distraction. The Pen tool does not yet allow you to preview a Spiro as you draw, although you can paste the Spiro effect on the path and see the result as soon as the path is finalized. <br />
<br />
:You can always use the Node tool to continue a Spiro path by duplicating and dragging away its end nodes. Also, when you have a Spiro path selected, you can add a new subpath to it with Pen or Pencil if you start drawing with Shift.<br />
<br />
* '''Construct Grid''' [johan]<br />
<br />
* '''Perpendicular bisector''' [max]<br />
<br />
* '''Tangent to a curve''' [max]<br />
<br />
* '''Envelope Deformation''' allows the user to deform an object (or a group of object) by deforming its sides. Modifications are done by deforming the 4 Path parameters : Top and Bottom, Left and Right.<br />
<br />
* '''Lattice Deformation''' allows the user to deform an object (or a group of object) by moving 16 control points.<br />
<br />
==New features==<br />
* The '''Paste Path Effect''' command is enabled to assign the path effect of the clipboard to any number of paths, going recursively into groups if necessary.<br />
<br />
* A new command, '''Remove path effect''' removes any path effects from all selected objects, going recursively into groups if necessary. <br />
<br />
* Along with the commands to open the path effects dialog and to paste path effects, the three commands were collected in a submenu under Path menu.<br />
<br />
* Live path effects can now be assigned to the sides of a 3D box (use Ctrl+click to select individual sides).<br />
<br />
* The Pen and Pencil tools now correctly work with paths with LPEs: you can continue such a path or add a new subpath to it by drawing with Shift, all preserving the effect applied to it.<br />
<br />
* Path type parameters can now link to existing shapes <b>and text</b>, like clones do. Now it is possible to use text as input for the Pattern Along Path effect for example!<br />
<br />
* Lib2geom now has an implementation for EllipticalArc. For Inkscape, this means that it is now possible to directly copy-paste ellipse shapes on path parameters (e.g. 'pattern' in Pattern along Path), without the need to convert the ellipse object to path first. [needs coding and checking]<br />
<br />
==Live Path Effects for groups==<br />
<br />
LPE can now be assigned to a group. For most LPE, the effect is applied recursively but for Bend Path or Deformations the result is more powerful : the distortion applies on the whole group. <br />
<br />
*You can as usual enter the group by double-clicking on it. <br />
*It applies recursively, this means that a LPE can be assigned to groups of groups <br />
*The Effect can be applied definitively with "Convert Object to path"<br />
<br />
==Live Path Effects stacking==<br />
<br />
With Live Path Effects stacking, more than one Live Path Effect can be assigned to an item. A new UI was created to control the stack.<br />
<br />
=Import/Export=<br />
==Corel DRAW files import==<br />
<br />
Now Inkscape can import more Corel DRAW files of following types:<br />
<br />
* Corel DRAW Compressed Exchange files (CCX)<br />
* Corel DRAW 7-X4 Template files (CDT)<br />
* Corel DRAW Presentation Exchange files (CMX)<br />
<br />
Text objects are not supported as of UniConvertor 1.1.1.<br />
<br />
==sK1 files import==<br />
<br />
Inkscape uses UniConvertor to import sK1 files. Text objects are not supported as of UniConvertor 1.1.1.<br />
<br />
==CGM import==<br />
<br />
Inkscape uses UniConvertor to import Computer Graphics Metafile (CGM) files. Text objects are not supported as of UniConvertor 1.1.1.<br />
<br />
==PDF export==<br />
<br />
With PDF export, it is now possible to make the PDF page the size of the entire drawing, instead of the same as SVG page as before by the "Export drawing, not page" checkbox in PDF export options. Also, you can export a single object from a complex document to PDF if you specify the ID of that object in the "Limit export to the object with ID" field; the page of such PDF will be the same size as the bounding box of that object and will show only that object (all others will be hidden).<br />
<br />
The same capabilities are available from the command line by using <code>--export-area-drawing</code> and <code>--export-id=ID</code> parameters with <code>--export-pdf</code> (previously, they only worked for PNG export).<br />
<br />
==HPGL export==<br />
<br />
HPGL means Hewlett-Packard Graphics Language. It is a file format that is used for various cutters/plotters.<br />
<br />
=Extension effects=<br />
==New and improved effects==<br />
<br />
* The new '''Arrange > Restack''' extension restacks the Z-order of selected objects, from left to right, top to bottom (or vice versa), with radial outward or inward or by an arbitrary angle, specifying the base point for comparison (top, left, middle, etc.).<br />
* The improved '''Modify Path > Add Nodes''' extension now also allows segments to be divided into a given number of subsegments.<br />
* The new '''Render > Alphabet Soup''' extension is a vector rework of Matt Chrisholm's GPLed script [http://www.theory.org/artprojects/alphabetsoup/main.html]. Alphabet Soup randomly mashes glyph-elements together to make exotic looking text.<br />
* The new '''Render > Cartesian Grid''' extension plots Cartesian (square) grids that do not fill the page, but offer three levels of division, logarithmic scales (with clutter-reduction and arbitrary base) and customisable line width. All like elements (eg x-axis subminor divisions) are put into subgroups together. A proper border is also drawn, with an independent line thickness.<br />
* The new '''Render > Polar Grid''' extension plots a polar co-ordinate grid, with options for arbitrary-base logarithmic subdivisions, clutter-reduction around the origin, circumferential labels and custom line widths.<br />
* The new '''Text > Convert to Braille''' extension recodes English (or just Latin letters) text to [http://en.wikipedia.org/wiki/Braille Braille] code created for visually impaired people.<br />
<br />
==API changes==<br />
<br />
While the "Live preview" checkbox is useful for most effects, for some it just does not make sense. Now, you can add the attribute <code>needs-live-preview="false"</code> in the <code>effect</code> element in the .inx file of the effect to suppress this checkbox for your effect.<br />
<br />
Parameters passed to extensions (via the <param> element) now have a new boolean attribute - <code>gui-hidden</code> to indicate that the parameter should not be represented in the GUI. If all parameters are marked as hidden no GUI is presented for such extension.<br />
<br />
All '''.inx''' files are now properly formatted XML files with its own namespace of: <code><nowiki>http://www.inkscape.org/namespace/inkscape/extension</nowiki></code> and a Relax NG schema to define it. More information can be found in the [[Extensions]] Article.<br />
<br />
=SVG output=<br />
<br />
==Optimized CSS properties==<br />
<br />
As a file size optimization, Inkscape does not write into SVG some of the stroke properties if the object has stroke:none and some of the fill properties when it has fill:none. The only situation where this might affect you is if you remove stroke from an object and then turn it back on - the object will get the default stroke instead of the same it had before. <br />
<br />
Also, in manually-edited SVG where a parent group has no stroke but sets some stroke properties to be inherited by its descendants, you will need to set stroke property to other than none on the group, and suppress inheritance with stroke:none on those children that don't need it.<br />
<br />
Specifically, if stroke:none, the following properties do not get written to SVG:<br />
<br />
stroke-width<br />
stroke-linecap<br />
stroke-linejoin<br />
stroke-miterlimit<br />
stroke-opacity<br />
stroke-dasharray<br />
stroke-dashoffset<br />
<br />
Note that this does not include marker properties, which means you can still have markers on a path without visible stroke.<br />
<br />
If fill:none, the following properties do not get written to SVG:<br />
<br />
fill-opacity<br />
fill-rule<br />
<br />
==Optimized path data==<br />
<br />
In this version, the size of the path data written in the <code>d=</code> attribute of <code>path</code> elements is reduced by about 10%. Inkscape generates the shortest possible path strings by avoiding repeated operators and using relative coordinates (when it helps).<br />
<br />
This is controlled by the following attributes in <code>group id="svgoutput"</code> in your preferences.xml file:<br />
<br />
* allowrelativecoordinates (default 1) to switch relative coordinates on (1) or off (0)<br />
* forcerepeatcommands (default 0) to force repeating operators (1) or allow use of the more compact representation without repeated operators (0)<br />
<br />
=User interface=<br />
==Filters can be disabled==<br />
In order to facilitate editing documents that use lots of SVG filter effects, filter effects can now be disabled for a particular document window by selecting '''View|Display mode|No Filters''' from its menu. This provides an intermediate step between "normal" and "outline" view modes.<br />
<br />
The Toggle view command in the Display mode submenu (Ctrl+keypad 5) toggles between the outline view and either regular or no-filters view, depending on which was used most recent.<br />
<br />
==Native file dialogs for Windows==<br />
The windows builds of inkscape now have Windows-native file dialogs to keep consistency with other windows applications.<br />
<br />
==Clipboard enhancements==<br />
<br />
The clipboard used by Inkscape is now system-wide instead of being confined to a single instance of the application. Copied elements are exported to the clipboard using all the available output formats. SVG data can be pasted into other applications supporting one of Inkscape's output formats, and SVG data provided by other applications can be pasted into Inkscape.<br />
<br />
If you copy a string that can be interpreted as a hexadecimal color specification, i.e. 2f7ab4 or #014522b0, and then paste it into Inkscape, the fill of the selected objects will change to the given color. This is especially useful when working with HTML pages.<br />
<br />
==Masks and clipping paths==<br />
<br />
[editable in node tool - johan]<br />
<br />
==Stroke width changeable by dragging==<br />
<br />
[bbyak]<br />
<br />
==Enhanced Tablet Support==<br />
<br />
===Input device tool switching===<br />
<br />
Tablets and other input devices that report separate hardware are now recognized and current tool and/or settings can be set to switch in response to the physical tool being used.<br />
<br />
===Extended input device configuration===<br />
<br />
The stock Input Devices dialog has been replaced with a completely redone version that provides a more useful representation of settings. It also contains a simple area for testing different inputs of different devices.<br />
<br />
Additionally hardware setup itself has been separated from general settings to allow for easier dynamic switching of settings appropriate to the task at hand.<br />
<br />
==Dropper tool==<br />
<br />
The confusing icons on buttons in the controls bar of the Dropper tool (pick/assign opacity) are replaced by text labels.<br />
<br />
==Swatches==<br />
<br />
Hovering over a swatch now shows the name of the swatch in the status bar. This makes it easier for tablet users to identify a swatch by name, as holding a stylus still enough to show a tool tip is difficult.<br />
<br />
==Toolbars==<br />
<br />
The toolbar icon sizes for the three main toolbars are now separately configurable and to a few different sizes. This allows users to get a smaller UI on certain systems, including Ubuntu.<br />
<br />
==External Image Editing and Reload==<br />
<br />
Linked bitmaps have a context menu option to launch editing in an external application. Linked images now will reload when the linked file changes on disk. Both the external editor application and the reload behavior can be controlled by user preferences.<br />
<br />
=Grids, guides, snapping=<br />
<br />
==Grids==<br />
* The dotted rectangular grid now shows small crosses at the intersection points of emphasis lines.<br />
<br />
==Guides==<br />
<br />
There is now an option to treat groups as single objects during conversion to guides (as opposed to converting each object inside the group separately).<br />
<br />
==Snapping==<br />
Snapping has been implemented or improved in these areas:<br />
* The '''node tool''' now snaps to any unselected node (cusp or smooth) within the path that's being edited, and to cusp nodes of other paths. It also snaps to the path itself, but only to the stationary segments in between two unselected nodes. It is now also possible to snap while moving nodes along a vertical or horizontal constraint<br />
* The object snapper now also allows to snap to the '''page border'''<br />
* In the selector tool, snapping while '''skewing ''' or '''constrained translating''' have been improved<br />
* When creating '''new shapes''', all of their handle points now snap<br />
* In the document properties dialog, the checkbox for ''' 'always'''' snap has been replaced by two radiobuttons; this should eliminate most of the confusion surrounding this option<br />
* The code relating to the snapping mechanisms has undergone '''major refactoring''' to make it more reliable and easier to use from a developer's perspective<br />
<br />
==Snap indicator==<br />
When snapping has occurred, an indicator is displayed at that specific position. For now that indicator is just a cross that disappears in a second. In the future the shape of the indicator will be related to the type of target that has been snapped to. The snapping indicator can be disabled in the Document Properties dialog.<br />
<br />
=Notable bug fixes=<br />
<br />
* The '''visual bounding box''' (which is the default bounding box type used by Inkscape) of an object with a filter applied, now includes the expanded area of the filter. For '''single blur filter''' (such as the blur you apply with a slider in the Fill and Stroke dialog), this expands the bounding box by 2.4*radius; although theoretically, blur is infinite, this is the distance at which the opacity of the object drops below the perceptibility threshold of our renderer. For all other filters, the area is expanded by the relative amounts you specify on the "Filter general settings" tab of the Filter Effects dialog.<br />
<br />
:Only visual bounding box is affected; if you use geometric bounding box, you will notice no change in most cases. However, the Export bitmap dialog always uses the visual bbox for selection of the export area; this means that you can now export a blurred object to bitmap without any clipping of the blur.<br />
<br />
* Several fixes allows Inkscape to correctly render and edit SVG files that use <code>currentColor</code> in objects' style (this includes files created by gnuplot).<br />
<br />
= Previous releases =<br />
<br />
* [[ReleaseNotes046]]<br />
* [[ReleaseNotes045]]<br />
* [[ReleaseNotes044]]<br />
* [[ReleaseNotes043]]<br />
* [[ReleaseNotes042]]<br />
* [[ReleaseNotes041]]<br />
* [[ReleaseNotes040]]<br />
* [[ReleaseNotes039]]<br />
* [[ReleaseNotes038]]<br />
* [[ReleaseNotes037]]<br />
* [[ReleaseNotes036]]<br />
* [[ReleaseNotes035]]<br />
<br />
[[Category:Marketing]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Release_notes/0.47&diff=30304Release notes/0.472008-06-07T18:18:39Z<p>Steren: /* New effects */</p>
<hr />
<div>=Inkscape 0.47=<br />
'''(not released yet)'''<br />
<br />
=Refactoring effort=<br />
[mention the 'main' goal of 0.47 and list which things have been refactored and the benefits/new features/different workflow? --johan]<br />
<br />
=Tools=<br />
<br />
==Node tool==<br />
<br />
* [helper path display, flashing - johan]<br />
* The Node tool can now edit '''clipping paths''' and '''masks''' of objects on canvas, without releasing them. If the selected object has a clipping path and mask, the corresponding buttons on the controls bar of the tool will be enabled; pressing these buttons will display the editable paths or handles of the clippath or mask. A clipping path is stroked green, a mask is stroked blue (the same colors as those used for them in Outline mode).<br />
* Snapping has been improved (more details in Snapping below)<br />
* When dragging a node '''handle with Ctrl''', it now snaps not only to the 15 degree increments starting from 0 and to the original handle direction, but also to the direction of the '''opposite handle''' (if it exists) or of the '''opposite line segment''' (if it is a straight line).<br />
* The behavior of the buttons/shortucts that make a node smooth or cusp has been improved:<br />
:* If a node is already cusp (diamond shaped), pressing Shift+C again on it will retract both its handles. As this works for any number of selected nodes, you can always retract all handles in all nodes by selecting all nodes and pressing Shift+C twice.<br />
:* If a non-smooth node is next to a straight line segment, pressing Shift+S once makes it ''half-smooth'': it now has one handle aligned with that line segment. Another press of Shift+S will expand the second handle as well turning it into a full smooth node. If a node is between two curve segments, Shift+S will expand both handles as before.<br />
<br />
==Calligraphy tool ==<br />
Added 4 preset buttons for dip, pen, brush and reed in the toolbox. Clicking one button sets the calligraphic tool with the matching presets.<br />
<br />
==Paint Bucket tool==<br />
* Paint Bucket is now more tightly integrated with potrace. As a result, memory and CPU usage on each fill operation have been reduced significantly.<br />
<br />
==Eraser Tool==<br />
A new eraser tool has been added. It has two main modes:<br />
* Delete-mode where any shape touched by the tool is deleted completely. This operation is in line with "vector" editing.<br />
* Cut mode where erasing acts similar to erasing in a standard bitmap editor.<br />
Erasing is also limited to the currently selected objects if there are any selected.<br />
<br />
=Transform dialog=<br />
<br />
Previously, the '''Apply to each object separately''' checkbox had no effect for the '''Move''' tab. Now, if several objects are selected, this checkbox is on, and "Relative move" is on, each object is shifted relative to the closest selected object on the left (for X) or below (for Y). <br />
<br />
For example, if you have a horizontal row of objects and you move them relatively by X=5px with "Apply to each object separately" on, the leftmost object will shift by 5px, the next one to the right by 10px, and so on; the rightmost selected object is displaced by 5*n px where n is the number of selected objects. As a result, the distance in each pair of adjacent objects will increase by 5px and the whole row will be spaced out, much like a letterspacing adjustment spaces out a text string. Moving these objects by X=-5px will, conversely, squeeze them tighter together: the leftmost will move by -5px, the next one by -10px, and so on. For Y, the effect is the same except that the move starts from the object closest to the bottom (i.e. with smallest Y coordinate). <br />
<br />
When determining the order of shifting objects, for X, the left edges of their bounding boxes are sorted horizontally, and for Y, the bottoms of their bounding boxes are sorted vertically. Order of selecting the objects or z-order does not matter.<br />
<br />
=Live path effects=<br />
== Notable bug fixes and effect changes==<br />
We try to refrain from changing the behavior of LPE's, because it will change appearance in old files when opened in Inkscape¹. But when an effect is really broken, we have to fix it.<br />
<br />
[¹ fixme: Shouldn't the above say "it will change editing behaviour in old files" ? If it changes the appearance, then that's a bug: inkscape should always save SVG that represents the appearance, and should display according to the SVG rather than any inkscape:blah annotations. --pjrm <br><br />
What is meant is the following. Files with LPEs opened in a random viewer will always look the same, regardless of Inkscape version. However, when viewed in Inkscape, the LPE is recalculated. When LPE behavior changes, the appearance will change. --johan]<br />
<br />
* The Pattern Along Path effect used to stretch the pattern across discontinuities. This has been fixed; now it treats a discontinuous path as a group of continuous paths and applied the effect separately to each.<br />
<br />
==New effects==<br />
[new: sketch, von koch, knot]<br />
<br />
* '''Perspective paths''': Draw an arbitrary path as if viewed in perspective. This is work in progress. Known limitations (among others): It can only use the first perspective that exists in the document defs, and the perspective cannot be adapted interactively yet (the effect must be removed and reapplied after modifying the perspective). [max]<br />
<br />
* '''Spiro splines''' are a novel way of defining curvilinear paths [http://www.levien.com/spiro/ developed by Raph Levien]. It takes some getting used to, but for certain tasks (such as lettershape design) Spiros have a clear advantage over Bezier curves. Recently, Spiro support was added to the FontForge font editor; now it is available in Inkscape too, which means you can use all the convenient Inkscape path tools (moving and transforming groups of nodes, node sculpting, etc.) on Spiro paths.<br />
<br />
:A Spiro path is defined by a sequence of points, but unlike a regular path with Bezier curves, all Spiro points lie on the path and there are no off-path handles. The curvature of the path is defined entirely by the positions of the points and their types. The path behaves very similar to a springy rod which is forced to pass through the given points and which uses the minimum possible curvature to satisfy the requirement. As such, it feels quite natural and the resulting path is very smooth - not just superficially smooth (i.e. having no cusps), but smooth at a deeper level, which you can achieve with Beziers only after a lot of laborious tweaking. <br />
<br />
:To create a Spiro path, select any path and assign the "Spiro spline" path effect to it. There are no parameters. Each node of your path becomes a point of a Spiro path, depending on the type of node:<br />
<br />
:* Smooth nodes (those with two collinear Bezier handles; use Shift+S to make a node smooth) become smooth curve points of the Spiro path. Note that the length or direction of the Bezier handles of the source path is ignored; the only thing that matters is their collinearity.<br />
<br />
:* Cusp nodes of the source path become corner points of the Spiro path, like free hinges on the springy rod. Between two corner points, the path is always a straight line. To make a node cusp, retract its Bezier handles by Ctrl+click, or press Shift+C and move one of the handles so they are no longer collinear.<br />
<br />
:* Half-smooth nodes - those with one Bezier handle collinear with a straight line segment on the other hand - become "left" or "right" points on the Spiro path which behave exactly the same: they sit between a straight line and a curve and enforce that these two segments join smoothly without a cusp. To create such a node, make sure one of the segments is a line (select its ends and press Shift+L), then Ctrl+drag the remaining handle to make it snap to the direction of the straight line segment on the other side, or press Shift+S to lock it to that direction.<br />
<br />
:Note that what matters is the actual collinearity of a node's handles, regardless of the node type that the node has in the Node tool; for example, if a node designated as cusp (diamond-shaped) has collinear handles, it will become a smooth curve point of the Spiro path. <br />
<br />
:Some configurations of points do not converge and produce wild loops and spirals instead of a smooth curve. According to Raph, "The spline solver in this release is _not_ numerically robust. When you start drawing random points, you'll quickly run into divergence. However, "sensible" plates based on real fonts usually converge." Avoid too sharp changes in direction between points to prevent divergence. Hopefully, the robustness of the algorithm will be improved in future releases.<br />
<br />
:For now, to edit Spiro paths viewing the result in real time, you have to use the Node tool; it is recommended to turn off the red highlight of the source path as it is a distraction. The Pen tool does not yet allow you to preview a Spiro as you draw, although you can paste the Spiro effect on the path and see the result as soon as the path is finalized. <br />
<br />
:You can always use the Node tool to continue a Spiro path by duplicating and dragging away its end nodes. Also, when you have a Spiro path selected, you can add a new subpath to it with Pen or Pencil if you start drawing with Shift.<br />
<br />
* '''Construct Grid''' [johan]<br />
<br />
* '''Perpendicular bisector''' [max]<br />
<br />
* '''Tangent to a curve''' [max]<br />
<br />
* '''Envelope Deformation''' allows the user to deform an object (or a group of object) by deforming its sides. Modifications are done by deforming the 4 Path parameters : Top and Bottom, Left and Right.<br />
<br />
* '''Lattice Deformation''' allows the user to deform an object (or a group of object) by moving 16 control points.<br />
<br />
==New features==<br />
* The '''Paste Path Effect''' command is enabled to assign the path effect of the clipboard to any number of paths, going recursively into groups if necessary.<br />
<br />
* A new command, '''Remove path effect''' removes any path effects from all selected objects, going recursively into groups if necessary. <br />
<br />
* Along with the commands to open the path effects dialog and to paste path effects, the three commands were collected in a submenu under Path menu.<br />
<br />
* Live path effects can now be assigned to the sides of a 3D box (use Ctrl+click to select individual sides).<br />
<br />
* The Pen and Pencil tools now correctly work with paths with LPEs: you can continue such a path or add a new subpath to it by drawing with Shift, all preserving the effect applied to it.<br />
<br />
* Path type parameters can now link to existing shapes <b>and text</b>, like clones do. Now it is possible to use text as input for the Pattern Along Path effect for example!<br />
<br />
* Lib2geom now has an implementation for EllipticalArc. For Inkscape, this means that it is now possible to directly copy-paste ellipse shapes on path parameters (e.g. 'pattern' in Pattern along Path), without the need to convert the ellipse object to path first. [needs coding and checking]<br />
<br />
==Live Path Effect for groups==<br />
<br />
LPE can now be assigned to a group. For most LPE, the effect is applied recursively but for Bend Path or Deformations the result is more powerful : the distortion applies on the whole group. <br />
<br />
*You can as usual enter the group by double-clicking on it. <br />
*It applies recursively, this means that a LPE can be assigned to groups of groups <br />
*The Effect can be applied definitively with "Convert Object to path"<br />
<br />
=Import/Export=<br />
==Corel DRAW files import==<br />
<br />
Now Inkscape can import more Corel DRAW files of following types:<br />
<br />
* Corel DRAW Compressed Exchange files (CCX)<br />
* Corel DRAW 7-X4 Template files (CDT)<br />
* Corel DRAW Presentation Exchange files (CMX)<br />
<br />
Text objects are not supported as of UniConvertor 1.1.1.<br />
<br />
==sK1 files import==<br />
<br />
Inkscape uses UniConvertor to import sK1 files. Text objects are not supported as of UniConvertor 1.1.1.<br />
<br />
==CGM import==<br />
<br />
Inkscape uses UniConvertor to import Computer Graphics Metafile (CGM) files. Text objects are not supported as of UniConvertor 1.1.1.<br />
<br />
==PDF export==<br />
<br />
With PDF export, it is now possible to make the PDF page the size of the entire drawing, instead of the same as SVG page as before by the "Export drawing, not page" checkbox in PDF export options. Also, you can export a single object from a complex document to PDF if you specify the ID of that object in the "Limit export to the object with ID" field; the page of such PDF will be the same size as the bounding box of that object and will show only that object (all others will be hidden).<br />
<br />
The same capabilities are available from the command line by using <code>--export-area-drawing</code> and <code>--export-id=ID</code> parameters with <code>--export-pdf</code> (previously, they only worked for PNG export).<br />
<br />
==HPGL export==<br />
<br />
HPGL means Hewlett-Packard Graphics Language. It is a file format that is used for various cutters/plotters.<br />
<br />
=Extension effects=<br />
==New and improved effects==<br />
<br />
* The new '''Arrange > Restack''' extension restacks the Z-order of selected objects, from left to right, top to bottom (or vice versa), with radial outward or inward or by an arbitrary angle, specifying the base point for comparison (top, left, middle, etc.).<br />
* The improved '''Modify Path > Add Nodes''' extension now also allows segments to be divided into a given number of subsegments.<br />
* The new '''Render > Alphabet Soup''' extension is a vector rework of Matt Chrisholm's GPLed script [http://www.theory.org/artprojects/alphabetsoup/main.html]. Alphabet Soup randomly mashes glyph-elements together to make exotic looking text.<br />
* The new '''Render > Cartesian Grid''' extension plots Cartesian (square) grids that do not fill the page, but offer three levels of division, logarithmic scales (with clutter-reduction and arbitrary base) and customisable line width. All like elements (eg x-axis subminor divisions) are put into subgroups together. A proper border is also drawn, with an independent line thickness.<br />
* The new '''Render > Polar Grid''' extension plots a polar co-ordinate grid, with options for arbitrary-base logarithmic subdivisions, clutter-reduction around the origin, circumferential labels and custom line widths.<br />
* The new '''Text > Convert to Braille''' extension recodes English (or just Latin letters) text to [http://en.wikipedia.org/wiki/Braille Braille] code created for visually impaired people.<br />
<br />
==API changes==<br />
<br />
While the "Live preview" checkbox is useful for most effects, for some it just does not make sense. Now, you can add the attribute <code>needs-live-preview="false"</code> in the <code>effect</code> element in the .inx file of the effect to suppress this checkbox for your effect.<br />
<br />
Parameters passed to extensions (via the <param> element) now have a new boolean attribute - <code>gui-hidden</code> to indicate that the parameter should not be represented in the GUI. If all parameters are marked as hidden no GUI is presented for such extension.<br />
<br />
All '''.inx''' files are now properly formatted XML files with its own namespace of: <code><nowiki>http://www.inkscape.org/namespace/inkscape/extension</nowiki></code> and a Relax NG schema to define it. More information can be found in the [[Extensions]] Article.<br />
<br />
=SVG output=<br />
<br />
==Optimized CSS properties==<br />
<br />
As a file size optimization, Inkscape does not write into SVG some of the stroke properties if the object has stroke:none and some of the fill properties when it has fill:none. The only situation where this might affect you is if you remove stroke from an object and then turn it back on - the object will get the default stroke instead of the same it had before. <br />
<br />
Also, in manually-edited SVG where a parent group has no stroke but sets some stroke properties to be inherited by its descendants, you will need to set stroke property to other than none on the group, and suppress inheritance with stroke:none on those children that don't need it.<br />
<br />
Specifically, if stroke:none, the following properties do not get written to SVG:<br />
<br />
stroke-width<br />
stroke-linecap<br />
stroke-linejoin<br />
stroke-miterlimit<br />
stroke-opacity<br />
stroke-dasharray<br />
stroke-dashoffset<br />
<br />
Note that this does not include marker properties, which means you can still have markers on a path without visible stroke.<br />
<br />
If fill:none, the following properties do not get written to SVG:<br />
<br />
fill-opacity<br />
fill-rule<br />
<br />
==Optimized path data==<br />
<br />
In this version, the size of the path data written in the <code>d=</code> attribute of <code>path</code> elements is reduced by about 10%. Inkscape generates the shortest possible path strings by avoiding repeated operators and using relative coordinates (when it helps).<br />
<br />
This is controlled by the following attributes in <code>group id="svgoutput"</code> in your preferences.xml file:<br />
<br />
* allowrelativecoordinates (default 1) to switch relative coordinates on (1) or off (0)<br />
* forcerepeatcommands (default 0) to force repeating operators (1) or allow use of the more compact representation without repeated operators (0)<br />
<br />
=User interface=<br />
==Filters can be disabled==<br />
In order to facilitate editing documents that use lots of SVG filter effects, filter effects can now be disabled for a particular document window by selecting '''View|Display mode|No Filters''' from its menu. This provides an intermediate step between "normal" and "outline" view modes.<br />
<br />
The Toggle view command in the Display mode submenu (Ctrl+keypad 5) toggles between the outline view and either regular or no-filters view, depending on which was used most recent.<br />
<br />
==Native file dialogs for Windows==<br />
The windows builds of inkscape now have Windows-native file dialogs to keep consistency with other windows applications.<br />
<br />
==Clipboard enhancements==<br />
<br />
The clipboard used by Inkscape is now system-wide instead of being confined to a single instance of the application. Copied elements are exported to the clipboard using all the available output formats. SVG data can be pasted into other applications supporting one of Inkscape's output formats, and SVG data provided by other applications can be pasted into Inkscape.<br />
<br />
If you copy a string that can be interpreted as a hexadecimal color specification, i.e. 2f7ab4 or #014522b0, and then paste it into Inkscape, the fill of the selected objects will change to the given color. This is especially useful when working with HTML pages.<br />
<br />
==Masks and clipping paths==<br />
<br />
[editable in node tool - johan]<br />
<br />
==Stroke width changeable by dragging==<br />
<br />
[bbyak]<br />
<br />
==Enhanced Tablet Support==<br />
<br />
===Input device tool switching===<br />
<br />
Tablets and other input devices that report separate hardware are now recognized and current tool and/or settings can be set to switch in response to the physical tool being used.<br />
<br />
===Extended input device configuration===<br />
<br />
The stock Input Devices dialog has been replaced with a completely redone version that provides a more useful representation of settings. It also contains a simple area for testing different inputs of different devices.<br />
<br />
Additionally hardware setup itself has been separated from general settings to allow for easier dynamic switching of settings appropriate to the task at hand.<br />
<br />
==Dropper tool==<br />
<br />
The confusing icons on buttons in the controls bar of the Dropper tool (pick/assign opacity) are replaced by text labels.<br />
<br />
==Swatches==<br />
<br />
Hovering over a swatch now shows the name of the swatch in the status bar. This makes it easier for tablet users to identify a swatch by name, as holding a stylus still enough to show a tool tip is difficult.<br />
<br />
==Toolbars==<br />
<br />
The toolbar icon sizes for the three main toolbars are now separately configurable and to a few different sizes. This allows users to get a smaller UI on certain systems, including Ubuntu.<br />
<br />
==External Image Editing and Reload==<br />
<br />
Linked bitmaps have a context menu option to launch editing in an external application. Linked images now will reload when the linked file changes on disk. Both the external editor application and the reload behavior can be controlled by user preferences.<br />
<br />
=Grids, guides, snapping=<br />
<br />
==Grids==<br />
* The dotted rectangular grid now shows small crosses at the intersection points of emphasis lines.<br />
<br />
==Guides==<br />
<br />
There is now an option to treat groups as single objects during conversion to guides (as opposed to converting each object inside the group separately).<br />
<br />
==Snapping==<br />
Snapping has been implemented or improved in these areas:<br />
* The '''node tool''' now snaps to any unselected node (cusp or smooth) within the path that's being edited, and to cusp nodes of other paths. It also snaps to the path itself, but only to the stationary segments in between two unselected nodes. It is now also possible to snap while moving nodes along a vertical or horizontal constraint<br />
* The object snapper now also allows to snap to the '''page border'''<br />
* In the selector tool, snapping while '''skewing ''' or '''constrained translating''' have been improved<br />
* When creating '''new shapes''', all of their handle points now snap<br />
* In the document properties dialog, the checkbox for ''' 'always'''' snap has been replaced by two radiobuttons; this should eliminate most of the confusion surrounding this option<br />
* The code relating to the snapping mechanisms has undergone '''major refactoring''' to make it more reliable and easier to use from a developer's perspective<br />
<br />
==Snap indicator==<br />
When snapping has occurred, an indicator is displayed at that specific position. For now that indicator is just a cross that disappears in a second. In the future the shape of the indicator will be related to the type of target that has been snapped to. The snapping indicator can be disabled in the Document Properties dialog.<br />
<br />
=Notable bug fixes=<br />
<br />
* The '''visual bounding box''' (which is the default bounding box type used by Inkscape) of an object with a filter applied, now includes the expanded area of the filter. For '''single blur filter''' (such as the blur you apply with a slider in the Fill and Stroke dialog), this expands the bounding box by 2.4*radius; although theoretically, blur is infinite, this is the distance at which the opacity of the object drops below the perceptibility threshold of our renderer. For all other filters, the area is expanded by the relative amounts you specify on the "Filter general settings" tab of the Filter Effects dialog.<br />
<br />
:Only visual bounding box is affected; if you use geometric bounding box, you will notice no change in most cases. However, the Export bitmap dialog always uses the visual bbox for selection of the export area; this means that you can now export a blurred object to bitmap without any clipping of the blur.<br />
<br />
* Several fixes allows Inkscape to correctly render and edit SVG files that use <code>currentColor</code> in objects' style (this includes files created by gnuplot).<br />
<br />
= Previous releases =<br />
<br />
* [[ReleaseNotes046]]<br />
* [[ReleaseNotes045]]<br />
* [[ReleaseNotes044]]<br />
* [[ReleaseNotes043]]<br />
* [[ReleaseNotes042]]<br />
* [[ReleaseNotes041]]<br />
* [[ReleaseNotes040]]<br />
* [[ReleaseNotes039]]<br />
* [[ReleaseNotes038]]<br />
* [[ReleaseNotes037]]<br />
* [[ReleaseNotes036]]<br />
* [[ReleaseNotes035]]<br />
<br />
[[Category:Marketing]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Creating_Live_Path_Effects&diff=29904Creating Live Path Effects2008-06-03T22:40:31Z<p>Steren: Bounding box for LPE on groups</p>
<hr />
<div>Instructions for making Live Path Effects.<br />
<br />
=How does LPE work?=<br />
<br />
The following schematic tries to explain how LPE work.<br />
<br />
original style ------------> output style<br />
original path --> LPE --> output path<br />
^<br />
|<br />
parameters<br />
<br />
The original style and path are from the path that the effect is applied on. The output is what is visible on screen. What is very important to notice is that <b>output style equals original style</b>.<br />
<br />
The parameters can be paths, numbers, points, text, in principle anything.<br />
<br />
=Groundwork=<br />
It is best to put your new effect in the /live_effects directory. Copy lpe-skeleton.cpp and lpe-skeleton.h to your files (say lpe-youreffect.cpp and lpe-youreffect.h), and rename everything from <i>skeleton</i> to your name.<br />
<br />
In effect.h:<br />
Add your effect to the enumeration: "enum EffectType". This way, Inkscape knows how to refer to your effect.<br />
<br />
In effect.cpp:<br />
<br />
-Add #include "live_effects/lpe-youreffect.h" (below //include effects )<br />
<br />
-Add your effect to the "const Util::EnumData<EffectType> LPETypeData[INVALID_LPE]" array. This way, Inkscape knows how to tell the user what the name of the effect is and also how to write its name to SVG.<br />
<br />
-Tell inkscape how to create it by inserting it in<br />
...<br />
Effect*<br />
Effect::New(EffectType lpenr, LivePathEffectObject *lpeobj)<br />
...<br />
case YOUREFFECT:<br />
neweffect = (Effect*) new LPEYourEffect(lpeobj);<br />
break;<br />
...<br />
...<br />
.<br />
<br />
One more thing to do: add your files to /live_effects/Makefile_insert. (Be aware of the spaces and tabs in that file!)<br />
<br />
That's all! Now your effect should pop up in the LivePathEffect dialog in Inkscape! But your effect won't do anything now, it would just pass along the original path. Time to start writing the main machinery of your cool effect!<br />
<br />
<br />
<br />
=Write your effect=<br />
<br />
The effect code should go into a doEffect function. The doEffect function receives the original path, and should return the path that results from your effect.<br />
<br />
<b>You have to choose between 4 doEffect functions and implement just one of them.</b> There is a "chain" of these functions. The first doEffect function calls the second, which calls the 3rd, which calls the 4th. The 4th returns its result to the 3rd which returns its result to the 2nd which returns it to the first and finally Inkscape receives the result. But all these standard functions do nothing real, they just change the path from one type to another. You have to determine which type is most convenient for you and <i>overload</i> that function. This means you put your own doEffect function in the place where normally the standard function would be called.<br />
<br />
These are the doEffect functions in the order in which they are called:<br />
<br />
1) void doEffect (SPCurve * curve)<br><br />
2) std::vector<Geom::Path> doEffect_path (std::vector<Geom::Path> & path_in)<br><br />
3) Geom::Piecewise<Geom::D2<Geom::SBasis> > doEffect_pwd2 (Geom::Piecewise<Geom::D2<Geom::SBasis> > & pwd2_in)<br />
<br />
It is easy to replace the standard doEffect function with yours. Let's say you want to create your effect with the path types of the 3rd function. You have to declare that one for your effect in lpe-youreffect.h: they are already writting down in there, you just have to un-comment the one you want, and you can delete the other doEffect functions. You must do the same in lpe-youreffect.cpp. <br />
<br />
The first 2 doEffect_xxxs receive the full <svg:path>, the 3rd (_pwd2) only continuous paths. What happens is that the default std::vector<Geom::Path> doEffect_path function splits the path into continuous parts (if there are more) and calls doEffect_pwd2 for each path part; then it combines the results again into its output std::vector<Geom::Path>. If you do not want this behavior but would like to use _pwd2, you must set the 'concatenate_before_pwd2' boolean to true in the constructor of your effect (see for example LPEBendPath).<br />
<br />
A "copy" effect has already been put in the .cpp file, you have to spice that up to make it do what you want. It is best to have a look at the doEffect functions of other effects and lpe-skeleton.cpp to see what is possible and how to implement something!<br />
<br />
=Parameter types:=<br />
<br />
Your effect can have any number of parameters that you'd like. You have to define them in the .h file. "RealParam number" is already there in the skeleton file; you can delete this if you do not want that kind of parameter ofcourse. That is the location where you can put the parameters that you want.<br><br />
You also have to initialise and register them, so Inkscape knows about them. This you should do in the .cpp file: <br />
<br />
// initialise your parameters here:<br />
number(_("Float parameter"), _("just a real number like 1.4!"), "svgname", &wr, this, 1.2)<br />
<br />
The arguments are respectively, the name of the parameter in the UI, the tooltip text, the name of the parameter in SVG, 2 parameters that you don't have to bother about (they are always the same), and finally the default value. You can also omit the default value.<br />
<br />
And these lines register your parameter:<br />
<br />
// register all your parameters here, so Inkscape knows which parameters this effect has:<br />
registerParameter( dynamic_cast<Parameter *>(&number) );<br />
<br />
==Available parameter types== <br />
Check the /live_effects/parameter dir for more up-to-date info; perhaps some parameter types were added! You have to include the .h file that belongs to the parameter type in your own .h file to be able to use that parameter type.<br />
* <b>ScalarParam</b>: a number of type 'gdouble'. <br><br />
include "live_effects/parameter/parameter.h" <br><br />
(see lpe-slant.cpp to learn how to use this type)<br />
* <b>PathParam</b>: a parameter that is a path. This is a single path! If the input for this parameter are multiple paths, it is converted to just one path.<br><br />
include "live_effects/parameter/path.h"<br><br />
(see lpe-skeletal.cpp to learn how to use this type)<br />
* <b>EnumParam</b>: a parameter that lets the user choose between a number of options from a dropdown box. <br><br />
include "live_effects/parameter/enum.h"<br><br />
(see lpe-skeletal.cpp to learn how to use this type)<br />
* <b>BoolParam</b>: <br><br />
include "live_effects/parameter/bool.h"<br><br />
* <b>RandomParam</b>: <br><br />
include "live_effects/parameter/random.h"<br><br />
This gives a random value between 0 and the value set by the user. See how to use it in lpe-curvestitch.cpp)<br />
* <b>PointParam</b>: a parameter that describes a coordinate on the page. <br><br />
include "live_effects/parameter/point.h"<br><br />
<br />
The parameters will automatically appear in the Live Path Effects dialog!<br />
<br />
[[Category:Developer Documentation]]<br />
<br />
=LPE on group : get the entire bounding box=<br />
Some effects, such as [[Bend_Path|Bend Path]], need the information of the size of the entire Bounding Box of the item on which the effect is applied.<br />
<br />
How to get the Bounding box of the item ?<br />
<br />
in ''lpe-YourEffect.h :''<br />
<br />
#include "live_effects/lpegroupbbox.h"<br />
<br />
Then inherit from GroupBBoxEffect :<br />
<br />
class LPESkeleton : public Effect, GroupBBoxEffect {<br />
<br />
Now we can use the ''original_bbox(SPLPEItem *)'' method.<br />
When it is called, it stores the bounding box dimensions in ''Geom::Interval boundingbox_X'' and ''Geom::Interval boundingbox_Y''. So let's call it before the calculation of the effect :<br />
<br />
- Overload the ''doBeforeEffect'' method<br />
<br />
'''lpe-YourEffect.h''' :<br />
virtual void doBeforeEffect (SPLPEItem *lpeitem);<br />
<br />
'''lpe-YourEffect.cpp''' :<br />
void<br />
LPEBendPath::doBeforeEffect (SPLPEItem *lpeitem)<br />
{<br />
original_bbox(lpeitem);<br />
}<br />
<br />
And to set defaults values :<br />
<br />
- the ''reset Defaults'' method<br />
'''lpe-YourEffect.h :'''<br />
virtual void resetDefaults(SPItem * item);<br />
<br />
'''lpe-YourEffect.cpp :'''<br />
void<br />
LPEBendPath::resetDefaults(SPItem * item)<br />
{<br />
original_bbox(SP_LPE_ITEM(item));<br />
}<br />
<br />
=Examples and details=<br />
*[[Bend Path]]<br />
*[[Envelope Deformation]]<br />
*[[Latice Deformation]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Latice_Deformation&diff=29894Latice Deformation2008-06-03T22:23:28Z<p>Steren: </p>
<hr />
<div>The effect is based on a mathematical object from [[Lib2geom_FAQ|2geom]], called "d2sb2d", in which we store the values necessary for the deformation, and the 2geom function "compose", which computes the mathematical composition of functions. In this case, we compose the original path with the 2dsb2d (which holds the wanted deformation).<br />
<br />
The effect needs 16 control points we called "handles" -- they are meant to be positioned by hand -- placed as a rectangular grid over the shape. The four corners are those of the bounding box of the path, and the others divide the rectangle evenly to form their original position. It is the difference between the actual position of the handles (chosen by the user) and their original position that is stored in the d2sb2d structure. This is done with a simple formula, which depends on the numbering of the handles, which is itself quite odd:<br />
<br />
[[Image:Numbers.png]]<br />
<br />
Inside the algorithm, two variables, ''corner'' and ''i'' are used to select the handle. ''i'' is the big rectangle ([0 1 2 3], [4 5 6 7], [8 9 10 11], or [12 13 14 15]), and ''corner'' is its corner, so that any individual handle is computed ''corner + 4*i''. But it is even more complicated since the algorithm loops on four other variables, ui, vi, iu, iv, each taking either 0 or 1 as a value, in such a way that ''corner = iu + 2*iv'' and ''i = ui + 2*vi''. Why so many complications ? Because the formula used to store values in the d2sb2d seems to need, for each handle, the associated value for ''ui+vi''.<br />
<br />
And it is not over yet! Apparently, for the effect to work properly, the path has to be translated to (0,0), and resized to be exactly 1 unit wide. Then, it should be translated back to its original position.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=File:Numbers.png&diff=29884File:Numbers.png2008-06-03T22:22:26Z<p>Steren: d2sb2d handles numerotation</p>
<hr />
<div>d2sb2d handles numerotation</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Latice_Deformation&diff=29874Latice Deformation2008-06-03T22:19:56Z<p>Steren: </p>
<hr />
<div>The effect is based on a mathematical object from [[Lib2geom_FAQ|2geom]], called "d2sb2d", in which we store the values necessary for the deformation, and the 2geom function "compose", which computes the mathematical composition of functions. In this case, we compose the original path with the 2dsb2d (which holds the wanted deformation).<br />
<br />
The effect needs 16 control points we called "handles" -- they are meant to be positioned by hand -- placed as a rectangular grid over the shape. The four corners are those of the bounding box of the path, and the others divide the rectangle evenly to form their original position. It is the difference between the actual position of the handles (chosen by the user) and their original position that is stored in the d2sb2d structure. This is done with a simple formula, which depends on the numbering of the handles, which is itself quite odd:<br />
<br />
<br />
Inside the algorithm, two variables, ''corner'' and ''i'' are used to select the handle. ''i'' is the big rectangle ([0 1 2 3], [4 5 6 7], [8 9 10 11], or [12 13 14 15]), and ''corner'' is its corner, so that any individual handle is computed ''corner + 4*i''. But it is even more complicated since the algorithm loops on four other variables, ui, vi, iu, iv, each taking either 0 or 1 as a value, in such a way that ''corner = iu + 2*iv'' and ''i = ui + 2*vi''. Why so many complications ? Because the formula used to store values in the d2sb2d seems to need, for each handle, the associated value for ''ui+vi''.<br />
<br />
And it is not over yet! Apparently, for the effect to work properly, the path has to be translated to (0,0), and resized to be exactly 1 unit wide. Then, it should be translated back to its original position.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Latice_Deformation&diff=29854Latice Deformation2008-06-03T22:15:18Z<p>Steren: New page: The effect is based on a mathematical object from 2geom, called "d2sb2d", in which we store the values necessary for the deformation, and the 2geom function "compose", which computes t...</p>
<hr />
<div>The effect is based on a mathematical object from [[2geom]], called "d2sb2d", in which we store the values necessary for the deformation, and the 2geom function "compose", which computes the mathematical composition of functions. In this case, we compose the original path with the 2dsb2d (which holds the wanted deformation).<br />
<br />
The effect needs 16 control points we called "handles" -- they are meant to be positioned by hand -- placed as a rectangular grid over the shape. The four corners are those of the bounding box of the path, and the others divide the rectangle evenly to form their original position. It is the difference between the actual position of the handles (chosen by the user) and their original position that is stored in the d2sb2d structure. This is done with a simple formula, which depends on the numbering of the handles, which is itself quite odd:<br />
<br />
<br />
Inside the algorithm, two variables, ''corner'' and ''i'' are used to select the handle. ''i'' is the big rectangle ([0 1 2 3], [4 5 6 7], [8 9 10 11], or [12 13 14 15]), and ''corner'' is its corner, so that any individual handle is computed ''corner + 4*i''. But it is even more complicated since the algorithm loops on four other variables, ui, vi, iu, iv, each taking either 0 or 1 as a value, in such a way that ''corner = iu + 2*iv'' and ''i = ui + 2*vi''. Why so many complications ? Because the formula used to store values in the d2sb2d seems to need, for each handle, the associated value for ''ui+vi''.<br />
<br />
And it is not over yet! Apparently, for the effect to work properly, the path has to be translated to (0,0), and resized to be exactly 1 unit wide. Then, it should be translated back to its original position.</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Creating_Live_Path_Effects&diff=29844Creating Live Path Effects2008-06-03T22:08:43Z<p>Steren: /* Examples: */</p>
<hr />
<div>Instructions for making Live Path Effects.<br />
<br />
=How does LPE work?=<br />
<br />
The following schematic tries to explain how LPE work.<br />
<br />
original style ------------> output style<br />
original path --> LPE --> output path<br />
^<br />
|<br />
parameters<br />
<br />
The original style and path are from the path that the effect is applied on. The output is what is visible on screen. What is very important to notice is that <b>output style equals original style</b>.<br />
<br />
The parameters can be paths, numbers, points, text, in principle anything.<br />
<br />
=Groundwork=<br />
It is best to put your new effect in the /live_effects directory. Copy lpe-skeleton.cpp and lpe-skeleton.h to your files (say lpe-youreffect.cpp and lpe-youreffect.h), and rename everything from <i>skeleton</i> to your name.<br />
<br />
In effect.h:<br />
Add your effect to the enumeration: "enum EffectType". This way, Inkscape knows how to refer to your effect.<br />
<br />
In effect.cpp:<br />
<br />
-Add #include "live_effects/lpe-youreffect.h" (below //include effects )<br />
<br />
-Add your effect to the "const Util::EnumData<EffectType> LPETypeData[INVALID_LPE]" array. This way, Inkscape knows how to tell the user what the name of the effect is and also how to write its name to SVG.<br />
<br />
-Tell inkscape how to create it by inserting it in<br />
...<br />
Effect*<br />
Effect::New(EffectType lpenr, LivePathEffectObject *lpeobj)<br />
...<br />
case YOUREFFECT:<br />
neweffect = (Effect*) new LPEYourEffect(lpeobj);<br />
break;<br />
...<br />
...<br />
.<br />
<br />
One more thing to do: add your files to /live_effects/Makefile_insert. (Be aware of the spaces and tabs in that file!)<br />
<br />
That's all! Now your effect should pop up in the LivePathEffect dialog in Inkscape! But your effect won't do anything now, it would just pass along the original path. Time to start writing the main machinery of your cool effect!<br />
<br />
<br />
<br />
=Write your effect=<br />
<br />
The effect code should go into a doEffect function. The doEffect function receives the original path, and should return the path that results from your effect.<br />
<br />
<b>You have to choose between 4 doEffect functions and implement just one of them.</b> There is a "chain" of these functions. The first doEffect function calls the second, which calls the 3rd, which calls the 4th. The 4th returns its result to the 3rd which returns its result to the 2nd which returns it to the first and finally Inkscape receives the result. But all these standard functions do nothing real, they just change the path from one type to another. You have to determine which type is most convenient for you and <i>overload</i> that function. This means you put your own doEffect function in the place where normally the standard function would be called.<br />
<br />
These are the doEffect functions in the order in which they are called:<br />
<br />
1) void doEffect (SPCurve * curve)<br><br />
2) std::vector<Geom::Path> doEffect_path (std::vector<Geom::Path> & path_in)<br><br />
3) Geom::Piecewise<Geom::D2<Geom::SBasis> > doEffect_pwd2 (Geom::Piecewise<Geom::D2<Geom::SBasis> > & pwd2_in)<br />
<br />
It is easy to replace the standard doEffect function with yours. Let's say you want to create your effect with the path types of the 3rd function. You have to declare that one for your effect in lpe-youreffect.h: they are already writting down in there, you just have to un-comment the one you want, and you can delete the other doEffect functions. You must do the same in lpe-youreffect.cpp. <br />
<br />
The first 2 doEffect_xxxs receive the full <svg:path>, the 3rd (_pwd2) only continuous paths. What happens is that the default std::vector<Geom::Path> doEffect_path function splits the path into continuous parts (if there are more) and calls doEffect_pwd2 for each path part; then it combines the results again into its output std::vector<Geom::Path>. If you do not want this behavior but would like to use _pwd2, you must set the 'concatenate_before_pwd2' boolean to true in the constructor of your effect (see for example LPEBendPath).<br />
<br />
A "copy" effect has already been put in the .cpp file, you have to spice that up to make it do what you want. It is best to have a look at the doEffect functions of other effects and lpe-skeleton.cpp to see what is possible and how to implement something!<br />
<br />
=Parameter types:=<br />
<br />
Your effect can have any number of parameters that you'd like. You have to define them in the .h file. "RealParam number" is already there in the skeleton file; you can delete this if you do not want that kind of parameter ofcourse. That is the location where you can put the parameters that you want.<br><br />
You also have to initialise and register them, so Inkscape knows about them. This you should do in the .cpp file: <br />
<br />
// initialise your parameters here:<br />
number(_("Float parameter"), _("just a real number like 1.4!"), "svgname", &wr, this, 1.2)<br />
<br />
The arguments are respectively, the name of the parameter in the UI, the tooltip text, the name of the parameter in SVG, 2 parameters that you don't have to bother about (they are always the same), and finally the default value. You can also omit the default value.<br />
<br />
And these lines register your parameter:<br />
<br />
// register all your parameters here, so Inkscape knows which parameters this effect has:<br />
registerParameter( dynamic_cast<Parameter *>(&number) );<br />
<br />
==Available parameter types== <br />
Check the /live_effects/parameter dir for more up-to-date info; perhaps some parameter types were added! You have to include the .h file that belongs to the parameter type in your own .h file to be able to use that parameter type.<br />
* <b>ScalarParam</b>: a number of type 'gdouble'. <br><br />
include "live_effects/parameter/parameter.h" <br><br />
(see lpe-slant.cpp to learn how to use this type)<br />
* <b>PathParam</b>: a parameter that is a path. This is a single path! If the input for this parameter are multiple paths, it is converted to just one path.<br><br />
include "live_effects/parameter/path.h"<br><br />
(see lpe-skeletal.cpp to learn how to use this type)<br />
* <b>EnumParam</b>: a parameter that lets the user choose between a number of options from a dropdown box. <br><br />
include "live_effects/parameter/enum.h"<br><br />
(see lpe-skeletal.cpp to learn how to use this type)<br />
* <b>BoolParam</b>: <br><br />
include "live_effects/parameter/bool.h"<br><br />
* <b>RandomParam</b>: <br><br />
include "live_effects/parameter/random.h"<br><br />
This gives a random value between 0 and the value set by the user. See how to use it in lpe-curvestitch.cpp)<br />
* <b>PointParam</b>: a parameter that describes a coordinate on the page. <br><br />
include "live_effects/parameter/point.h"<br><br />
<br />
The parameters will automatically appear in the Live Path Effects dialog!<br />
<br />
[[Category:Developer Documentation]]<br />
<br />
=Examples and details=<br />
*[[Bend Path]]<br />
*[[Envelope Deformation]]<br />
*[[Latice Deformation]]</div>Sterenhttps://wiki.inkscape.org/wiki/index.php?title=Envelope_Deformation&diff=29524Envelope Deformation2008-05-28T09:48:20Z<p>Steren: /* Envelope Deformation */</p>
<hr />
<div>=Envelope Deformation=<br />
<br />
The code of Envelope Deformation uses the [[Bend Path]] code.<br />
<br />
We first define four path parameters around the item bounding box: Top and Bottom, Left and Right. Each path represents a side of the deformation envelope and acts as a Bend Path effect.<br />
<br />
Then the idea is to blend those four deformed paths is order to generate the final deformed path. To do this, we will use weighting: The closer a point is to a Bend Path, the more it will be affected by this Bend Path. So we had to find simple weight coefficients to use.<br />
<br />
The first step is to blend the Top and the Bottom deformation. To do this, the rule is simple: the Top deformed path must be dominant for small y and the Bottom deformed path must be dominant for small (Bbox_y - y). We generate the blended path (named ''output-y'') with the following formula:<br />
<br />
(Bbox_y - y) * Deformation-Up + y * Deformation-Bottom<br />
<br />
The following figure illustrates the process. It is important to notice that y + (Bbox_y - y) = constant. Indeed, we only have then to divide the result by Bbox_y to scale it to the original size.<br />
<br />
[[Image:Envelopeyy.jpg]]<br />
<br />
Using the same model, the second step is to blend the Left and Right Deformations (we name it ''output-x'').<br />
<br />
The final step uses the same method but is not as accurate as the previous operation. Indeed, in the end we will average two different results.<br />
Our first result is the calculation of ''output-1'': The more a point is close to Top and Down, the less it will be affected by ''output-x''. The following figure illustrates the process.<br />
<br />
[[Image:Output.jpg]]<br />
<br />
The weight coefficients used were y(Bbox_y - y) and (Bbox_y/4) - y(Bbox_y - y). We notice again that their sum is constant.<br />
<br />
We then calculate ''output-2'': The more a point is close to Left and Right, the less it will be affected by ''output-y''.<br />
In the end, we do the mean between ''output-1'' and ''output-2''. Of course, from a mathematical point of view, the result is not perfect, but on a graphical one, we can consider that this is sufficient.</div>Steren