- Inkscape Devel - Inkscape Mailman

Style Editing
by Martin Owens 16 Mar '14

16 Mar '14

Hi devs, Sorry if this has been worked on before, none of my searches came up with anything. Mockup time: http://wiki.inkscape.org/wiki/index.php/Style_Editor A idea to non-invasively allow any existing css style to be changed. Screenshot for mockup taken from 0.48 Thoughts? suggestions? Martin,

1 0

Inkscape sponsorship for LGM attendees
by Bryce Harrington 15 Mar '14

15 Mar '14

Interested in meeting up with fellow Inkscapers? Thanks to generous donations to the project, we are able to provide funds to reimburse five developers up to $500 each for attendance at the Libre Graphics Meeting in Leipzig in April. Anyone in the AUTHORS file as of Feb 19th, 2014 is eligible to apply. To register, please email Tavmjong Bah, our coordinator for the event, by March 6th to get on the list. He'll let you know what position you are in the list. Then, register for the conference, enjoy your time, and save your receipts. Afterwards email copies of the receipts to Tav, who will forward them along to SFC for reimbursement. A maximum of $500 US each will be reimbursed to five attendees for travel, hotel room, and food. Note that the LGM meeting may also give partial reimbursements, so if your total costs exceed $500 they may be able to help. In addition, the board is sponsoring Tavmjong Bah to attend both LGM as a speaker and as our event coordinator, and the co-located SVG Working Group Meeting. Tav will be representing Inkscape's interests at the SVG meeting, and will be working with them on features including mesh gradients, hatched fills, and auto-flowed text. Thank you to everyone who has contributed to Inkscape in the past. Your funding has made these sponsorships possible. We've found these face-to-face meetings invaluable both for sharing ideas and as general inspiration for advancement of the project. Bryce

6 7

Careful with C-strings!
by Johan Engelen 14 Mar '14

14 Mar '14

Hi all, *Please take this to heart: be very careful when handling C-strings. And try hard to use std::string, even if it involves a bit of work / adding helper functions.* Another C-string induced memleak was added today. Actually, the change fixed one memleak, but replaces it with the same one. Fixed in r13101. How to go about things using std::string in this particular case, see for example: http://stackoverflow.com/questions/20446201/how-to-check-if-string-ends-wit… ciao, Johan

6 13

Optionally disable antialiasing - implement based on existing SVG 1.1 rendering properties?
by su_v 13 Mar '14

13 Mar '14

> revno: 13144 > fixes bug: https://launchpad.net/bugs/170356 > committer: Krzysztof Kosiński <tweenk.pl@...400...> > branch nick: trunk > timestamp: Thu 2014-03-13 05:45:38 +0100 > message: > Provide a toggle in the document properties to optionally turn off > antialiasing for display and export. > Fixes a nearly 10 year old bug #170356 Questions related to rev 13144 (just curious): a) Why not implement such a feature based on existing SVG 1.1 rendering instructions (instead of a custom inkscape attribute of <namedview>)? Ideally, the user could then optionally apply this to individual objects (which may trigger bug #170356 if the objects' edges are adjacent), to groups or layers, or to the document itself, and the same effect may even be supported in other SVG renderers? AFAIU to disable antialiasing globally, these attributes could be added to top-level <svg> element: shape-rendering="crispEdges" text-rendering="optimizeSpeed" I'm not sure whether this one too: image-rendering="optimizeSpeed" <http://www.w3.org/TR/SVG11/painting.html#RenderingProperties> <http://www.w3.org/TR/SVG11/painting.html#ShapeRenderingProperty> <http://www.w3.org/TR/SVG11/painting.html#TextRenderingProperty> <http://www.w3.org/TR/SVG11/painting.html#ImageRenderingProperty> The attributes are also in the SVG2 draft: <http://www.w3.org/TR/SVG2/painting.html#RenderingHints> If implemented based on these rendering attributes, the feature should (or rather: could) also allow to control the rendering of different types separately (i.e. disable for shapes only, or for text only, or both), and maybe other text rendering modes can be added in the future (e.g. aliased with hinting for 'optimizeLegibility'). Note that support for 'image-rendering="optimizeSpeed"' has already been implemented (currently settable on import, and in objects properties for bitmap images (linked, or embedded)). b) Alternatively (based on other user requests), if the implementation stays a custom inkscape feature only: what about splitting it into a display mode (for rendering on-canvas, in the 'View' menu), and a bitmap export option which can also be used on the command line (without having to first edit the document properties via GUI)? Regards, V P.S. Personally, I somewhat disagree with closing bug #170356 based on a solution which globally disables antialiasing (for all shapes and text in the current document) - that report originally tracked an issue with a very specific aspect of antialiasing (adjacent edges); the current solution seems more like a workaround to me (disable antialiasing just for everything, including text (which - especially at smaller sizes - tends to looks bad (AFAIU due to lack of hinting) and objects not affected by bug #170356 at all). With r13144, antialiasing btw returns if an object (or group) has a reduced object (aka global) opacity, or uses a filter effect, for clipped or masked objects and probably other special cases.

2 3

Font selection
by Martin Owens 13 Mar '14

13 Mar '14

Hi devs, I was just making some art and noticed I couldn't select any fonts in the latest ppa build. Is this a known problem? Martin,

3 2

Re: [Inkscape-devel] Help with bzr
by Krzysztof Kosiński 13 Mar '14

13 Mar '14

2014-03-11 1:54 GMT+01:00 Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...>: > Thanks Krzysztof for the quick reply. > >> It is not removing the pushes, it is just changing the revision >> numbers so that the other users' pushes are in subrevisions. > > I feel confortable by this way but think isn't the normal usage in > inkscape trunk > >> If you want to prevent changes in revision numbers, use this: >> >> bzr config -d lp:path/to/branch append_revisions_only=True >> >> However if you set this, you won't be able to merge other users' >> changes and then push. Use this instead: >> >> bzr checkout lp:path/to/branch working_dir <-- only the first time >> cd working_dir >> bzr update <-- after the first time >> bzr merge <path to your working tree> >> bzr commit >> >> Another option - you need the "rebase" or "rewrite" plugin: >> >> bzr pull >> bzr rebase >> bzr push >> > Think one of this ways is the best, but i have the extra problem to > update the branch from trunk. Maybe this need to be done direcly in the > launchpad branch instead merge from trunk localy and push. Is correct? If you have your own branch on which you collaborate with a few users, you can just use a checkout. Instead of saying "bzr branch lp:path/to/branch" at the start, say "bzr checkout lp:path/to/branch". Then everything you commit will appear on Launchpad immediately, and to update you can simply say "bzr update". You can also say "bzr bind :push" to convert an existing non-diverged branch into a checkout. Regards, Krzysztof

4 13

Font weight variants - bug 167353
by Krzysztof Kosiński 12 Mar '14

12 Mar '14

Hello all There is a long standing bug about font variant selection. I can't seem to reproduce it on Ubuntu 13.10 - selecting a different variant with a non-default name works correctly. Can someone update the bug with up-to-date instructions on reproducing? Given that other comments suggest that the bug is specific to the interactive display, I think it could be fixed by changing the code in the display tree to be equivalent to the one in the Cairo renderer used by PDF export. Currently they use completely different operations to display the text. Regards, Krzysztof

1 0

Ungrouping switches
by Krzysztof Kosiński 12 Mar '14

12 Mar '14

This is related to https://bugs.launchpad.net/inkscape/+bug/1001756 The ungrouping code was treating svg:switch like groups. Is this the correct behavior? (For the time being, I modified it to ignore groups.) We don't use svg:switch in Inkscape-generated SVG at the moment, so this is relevant only to externally authored content. Regards, Krzysztof

3 6

Re: [Inkscape-devel] Help with bzr
by Jabiertxo Arraiza Cenoz 11 Mar '14

11 Mar '14

> > Can do a "bzr update" for two branches -trunk and a custom one-? > > I don't really understand the question :( I want to update the other users changes in the custom branch and have this custom branch updated from trunk. I think the way to update could be: https://asciinema.org/a/8109 Regards, Jabiertxo.

1 0

Fwd: GSOC 2014 - New patterns/paint servers UI
by Krzysztof Kosiński 11 Mar '14

11 Mar '14

[resend - accidentally sent off-list] 2014-03-10 13:23 GMT+01:00 Tomasz Boczkowski <penginsbacon@...400...>: > Hi! > > My name is Tomasz Boczkowski. I would like to apply for GSOC 2014 and spend > this summer coding Inkscape. > > I have an idea to revamp the pattern UI, currently being part of the Fill > and Stroke dialog. It would consist of a new "patterns" dialog and a new > on-canvas tool to edit patterns. The file new_patterns_ui.svg [2] contains > my first draft, how the improved UI could look like. Some comments on the UI mockup: 1. "Contour" should be "stroke" 2. The palette behavior should be reused in this dialog. Normal click should apply the pattern to fill and Shift-click should apply to stroke. 3. The way the pattern icons are supposed to "jump" when one of them is selected is very bad. 4. What is the purpose of the "transform" button? The pattern transform is specified on the object, not on the pattern, and is already editable on the canvas. This looks like a mistake. 5. I think it would be more sensible to embed the pattern preview and chooser into the existing fill and stroke dialog. > The new dialog would provide a way to browse, manage and apply patterns. > Some basic support for grouping patterns into collections would be provided. > By dragging a pattern and dropping it on an svg object or on Fill and Stroke > dialog, a user could apply it. After dropping a pattern on empty canvas, a > new object could be created. It would look like a mini-page and have the > size of pattern. Any objects inside this object would be treated as pattern > child elements. That would allow live modifications to existing patterns. How would this "new object" be represented at the XML level? I'm not convinced that this is the way to go. However, we definitely need a new UI concept for editing distinct "areas" of the document (e.g. separate pages, patterns, masks, and so on). It would be ideal if the concept you invent could eventually be reused for the other use cases. > An alternative to "patterns" dialog would be to implement a general "print > servers" dialog, enabling to manage, besides patterns, named colors, > gradients and hatches. The alternative is also enclosed in mockup drawing. I > suppose I would be able to implement support for selected print servers only > (eg. named colors + patterns) in GSOC timeframe. "Paint servers" is technical jargon and should not appear in the UI. "Swatches" or "Paints" is better. I think a generic dialog for all paints would be better than a dialog only for patterns. > Please tell me what do you think about this idea. Is it suitable as GSOC > project? Which alternative is better in your opinion? The proposal looks sensible. If you don't have too much experience with the Inkscape codebase, I think you could limit the proposal to providing the pattern preview in the fill and stroke dialog and converting a few things to C++ along the way. Regards, Krzysztof

1 0