Inkscape Wiki - User contributions [en]

Release notes/0.47

2008-03-13T19:29:35Z

Aubanel: /* Tools */

=Inkscape 0.47=
'''(not released yet)'''

=Tools=

==Node tool==

* [helper path display - johan]
* on-canvas mask/clip edit - johan
* snapping has been improved (more details in the snapping paragraph)

==Calligraphy tool ==
Added 4 preset buttons for dip, pen, brush and reed in the toolbox. Clicking one button sets the calligraphic tool with the matching presets.

=Live path effects=

[sketch, von koch, ...]

=Import/Export=
==Corel DRAW files import==

Now Inkscape can import more Corel DRAW files of following types:

* Corel DRAW Compressed Exchange files (CCX)
* Corel DRAW 7-X4 Template files (CDT)
* Corel DRAW Presentation Exchange files (CMX)

Text objects are not supported as of UniConvertor 1.1.1.

==sK1 files import==

Inkscape uses UniConvertor to import sK1 files. Text objects are not supported as of UniConvertor 1.1.1.

==CGM import==

Inkscape uses UniConvertor to import Computer Graphics Metafile (CGM) files. Text objects are not supported as of UniConvertor 1.1.1.

==PDF export==

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).

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).

=Extension effects=
==New and improved effects==

* 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.

=User interface=
==Native File Dialogs for Windows==
The windows builds of inkscape now have Windows-native file dialogs to keep consistency with other windows applications.

==Masks and clipping paths==

[johan]

==Dropper tool==

The confusing icons on buttons in the controls bar of the Dropper tool (pick/assign opacity) are replaced by text labels.

=Grids, guides, snapping=
==Snapping==
Snapping has been implemented or improved in these areas:
* 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.
* The object snapper now also allows to snap to the '''page border'''

=Notable bug fixes=

* Live path effects can now be assigned to the sides of a 3D box (use Ctrl+click to select individual sides).

= Previous releases =

* [[ReleaseNotes046]]
* [[ReleaseNotes045]]
* [[ReleaseNotes044]]
* [[ReleaseNotes043]]
* [[ReleaseNotes042]]
* [[ReleaseNotes041]]
* [[ReleaseNotes040]]
* [[ReleaseNotes039]]
* [[ReleaseNotes038]]
* [[ReleaseNotes037]]
* [[ReleaseNotes036]]
* [[ReleaseNotes035]]

[[Category:Marketing]]

SpecIccForCairo

2008-02-27T13:56:09Z

Aubanel: /* Functional spec */

== Why ==
In order for inkscape to produce CMYK PDFs and PSs with cairo, Cairo needs to support ICC. This is an intent to propose a Cairo API that would be suitable with inkscape needs.

== Profiles ==
A set of profiles will apply to the whole Cairo surface.
Cairo needs to be able to compute a transform from this set.
We can get inspiration from the lcms api [http://www.littlecms.com/LCMSAPI.TXT], in particular the cmsCreateMultiprofileTransform (more generic than cmsCreateTransform that handles only a single pair of color profiles).

So a proposal would be:

typedef enum cairo_color_intent {
CAIRO_COLOR_INTENT_PERCEPTUAL,
CAIRO_COLOR_INTENT_RELATIVE_COLORIMETRIC,
CAIRO_COLOR_INTENT_SATURATION,
CAIRO_COLOR_INTENT_ABSOLUTE_COLORIMETRIC
} cairo_color_intent_t;

typedef struct cairo_color_profile cairo_color_profile_t;

void cairo_surface_set_color_profile_srgb(cairo_surface_t *surf);

void
cairo_surface_set_color_profile(cairo_surface_t *surf,
cairo_color_profile_t *profile);

cairo_color_profile_t *
cairo_surface_get_color_profile(cairo_surface_t *surf);

void
cairo_surface_add_profile_mapping(cairo_surface_t *surf,
cairo_color_profile_t *in,
cairo_color_profile_t *out);

void
cairo_surface_remove_profile_mappings(cairo_surface_t *surf);

void
cairo_surface_set_color_intent(cairo_surface_t *surf,
cairo_color_intent_t intent);

cairo_color_intent_t
cairo_surface_get_color_intent(cairo_surface_t *surf);

void
cairo_set_source_icc_color(cairo_t *cr,
cairo_color_profile_t *profile,
const double *components,
int num_components);

Color transformations would be performed when painting from a pattern
to a surface, based on the surface's profile, mappings, intent, etc.

== Functional spec ==
Cairo has several ways to accept color information (e.g. cairo_set_source_rgb). The cairo back-end produces an output (a file or calls to third party libraries). The colors of this output are only back-end and cairo dependent, and there is no way for the cairo user to specify something different.

A color management system provides a way to specify input and output color formats (bit orders, meaning of the channels, etc) as well as a way to transform input colors to output ones.

Cairo needs a ways to permit cairo users to input this information (basically, those would be stored alongside the surface).

As the format for inputing colors is variable, a color is defined as an array of doubles (size to be specified at each time, each double is a channel). Cairo stores these informations internally.

At render time, the backend computes the color transformation (typically a call to cmsCreateTransform ) and applies it to every color. Back-end will also use the color output format as a clue to the desired output (e.g. the pdf backend with color output format TYPE_CMYK_8 will generate a CMYK pdf). Each cairo backend will be able to render only some of the output color formats (e.g. X backend does not know how to render CMYK, but would know ho to render RGBA 32, RGB 24). Trying to render to an unsupported color format would trigger an error.

== Open issues ==

=== Should surface profile/color rendering changes be allowed once the surface is being actively used? ===

:Why should we allow this ? Is there any use case ? The ones I can see are: render the same surface with two different profiles at the same time (e.g. on a multihead screen with different profiles, but is'nt X already handling that, batch export of the same file in many different colorspaces)

=== How should gradients work in this regime? ===
:What is the issue here ? like we have a set_source_icc_color, we can have a set_stop_icc color, isnt'it ?
=== How should '''cairo_color_profile_t'''s be created/loaded?===

:lcms provides 2 ways, load from a file or from memory. I think cairo should provide the same ways, I dont see an additional one that could bring some benefit here, appart from direct reuse of a lcms handler for applications already using lcms like inkscape but that's not really clean - makes cairo API depend from lcms API.

SpecIccForCairo

2008-02-27T13:35:44Z

Aubanel:

SpecIccForCairo

2008-02-26T16:35:31Z

Aubanel: /* Open issues */

SpecIccForCairo

2008-02-22T19:25:19Z

Aubanel: /* Colors */ typo

SpecIccForCairo

2008-02-22T19:24:44Z

Aubanel: /* Profiles */

SpecIccForCairo

2008-02-22T19:17:02Z

Aubanel: New page: == Why == In order for inkscape to produce CMYK PDFs and PSs with cairo, Cairo needs to support ICC. This is an intent to propose a Cairo API that would be suitable with inkscape needs. =...