- Inkscape Devel - Inkscape Mailman

Changing trunk to 96 pixels per inch.
by Tavmjong Bah 22 Sep '14

22 Sep '14

Hi, The experimental branch has been using 96 pixels per inch per the CSS 2.1 standard for over two months now without complaint. Is there any objection to switching trunk to this value? As Inkscape has switched to using 'pt' for text size by default, it is important that this change happen to ensure that the size of text rendered in browsers match the size of text rendered in Inkscape. Tav

8 22

Paying for Downloads
by Martin Owens 22 Sep '14

22 Sep '14

I've here at Free Software Day (Boston) and have just completed a panel on the economics of Free Software development. Something which came up and something I want to have a serious discussion about is the implementation of an opportunity to donate screen like libreOffice: http://donate.libreoffice.org/home/dl/deb-x86_64/4.3.1/en-US/LibreOffice_4.… If one clicks on this link, it waits a few seconds and gives you the file. But as well as the file it also offers you an opportunity to donate/contribute to the project. I'd like to implement this for inkscape.org but it would have to be blessed by the community since other developers are users may have valid concerns which should be taken into account with this format. Things I'm thinking about: * Making sure we have suggested amounts * Offering something in return? Maybe offer an ability to buy swag? * What is SFC's position on these kinds of pages? * Have an invitation to contribute other things. Time, bug tracking etc? * Give donators a badge on their website user? I'm looking for any contribution to this discussion, good or bad. Please let me know what you think. Best Regards, Martin Owens

7 8

Windows testing needed
by Josh Andler 21 Sep '14

21 Sep '14

Can someone on Windows please apply the following patch and check to see if it affects building? https://bugs.launchpad.net/inkscape/+bug/1323592/+attachment/4184115/+files… Cheers, Josh

3 2

Inkscape Hackfest Planning IRC Report #1
by Tavmjong Bah 16 Sep '14

16 Sep '14

Contents: * Introduction * Hackfest LGM * Hackfest FOSDEM * Updating FSA * Mac OSX Introduction ============ A group of interested Inkscape developers met via IRC with Karen Sandler, the Executive Director of the Software Freedom Conservancy (SFC)[1]. The primary motive for the meeting was to discuss organizing a hackfest in conjunction with the 2015 Libre Graphics Meeting (LGM) at the end of April in Toronto.[2] If you are interested in participating, please add your name at: http://wiki.inkscape.org/wiki/index.php/Hackfest2015 We also briefly discussed updating the Fiscal Sponsorship Agreement (FSA) and the Mac OSX port. We will meet again next week at the same time (Monday 19:00 UTC, 21:00 CEST, 15:00 EDT, 12:00 PDT) at inkscape-devel on freenode. Hackfest LGM ============ Hackfest: Location ------------------ Two possibilities: Toronto: Advantage: No extra travel required. Cheaper hotels, etc.? Disadvantage: Need to find local host. Boston: Advantage: There are many possible places to hold the hackfest. Disadvantage: Extra travel to/from Toronto. US Visa requirements. Possible place: MIT * Martin is contacting LGM to see if they can help us find space. Hackfest: Costs --------------- What will Inkscape pay for? Travel, accommodation, food for sponsored attendees? Refreshments? Equipment? Video projector? We need to decide who to sponsor. Probably 10, maybe up to 20 people. Preferably those with a "job to do" and not just passers-by. Hackfest: Topics ---------------- Code and documentation, see web page for ideas (and add your own). We should outreach to new contributors; maybe have a training period the first morning. Hackfest: Sponsors ------------------ We discussed who might sponsor a hackfest (and why they might). * Karen will inquire with RedHat and Google. * Bryce will contact Samsung. * Intel? Canonical? * ScislaC will compile a list of companies using Inkscape. Hackfest: FOSDEM ================ It might be possible to have a "warm-up" hackfest at FOSDEM.[3] Hacking is one of the main activities at this conference and there should be no problem finding space. FOSDEM 2015 is the weekend of 31 January/1 February in Brussels. Updating the FSA ================ Before we started discussing the hackfest, we briefly discussed updating our Fiscal Sponsorship Agreement (FSA) with SFC. Inkscape was one of the first groups to join FSA and our FSA is a bit out-dated. There are at least two places where changes are needed: 1. The SFC is financed by its members. Member groups are required to give 10% of the funds they raise to the SFC. Inkscape's agreement predates this requirement. The SFC would like to see Inkscape's FSA brought into alignment. The Inkscape board has agreed in principle to this change. 2. Inkscape needs an active board to successfully manage Inkscape's resources. At the moment, board member serve until they resign or until they are removed by a majority vote of the community members. It would good to have a criteria for removing inactive board members without the need for a potentially disruptive vote by the community members. Karen and Bradley will be at the Google Summer of Code Mentor's meet-up as will three Inkscape board members. This will be a good time to finalize the new agreement. Mac OSX ======= We discussed the status of the native Mac OSX port and the possibility of paying a developer to finish it off. The port is done but there seem to be problems with the underlying libraries (Wayland or gtk+/quartz).

1 0

IRC meeting for hackfest planning and fundraising
by Bryce Harrington 15 Sep '14

15 Sep '14

When: Tomorrow, Monday Sept 15th at 12 noon (3pm eastern) Where: #inkscape-devel on Freenode IRC Who: Inkscape team; Karen Sandler Karen and I will be discussing plans/ideas for an upcoming Inkscape hackfest. The principal topic we want to discuss is the fundraising/budgeting side of things, but other aspects are within scope. All are welcomed to attend, but this will mostly be interesting to people wishing to help out in organizing the hackfest and/or fundraisers. Bryce

3 3

Merging Policy
by Tavmjong Bah 15 Sep '14

15 Sep '14

Hi, The merge of the latest features from Liam into the Experimental branch raises the question of best practices for merging. In particular, I am not sure that merging multiple features at one time is a good idea. Other projects seem to divide commits into the smallest possible pieces. I think that this is good practice as it better documents what is being committed, allows for better reviews, and makes it easier to cherry-pick from one branch to another. In particular, the commit message: "Merge in ponyscape features by Theo and worked on my LiamW" doesn't give any information about what are the purpose of the changes. It takes reading the code and/or searching the web to find this information. (See: http://liamwhite1.deviantart.com/journal/ ) As far as I can tell, the commit: 1. Adds the new LPE's: * Attach path * Bounding box * Ellipse * Fill between many * Fill between strokes * Joint type * Taper stroke 2. A tagging system. 3. Objects dialog. 4. Multi-path manipulator 5. Filter effects chooser. I think these should have been committed separately with a line or two explaining what each does. Also, each LPE should be a separate commit. As an additional question: is the experimental branch going to become 0.92? I think there have been too many changes to the experimental branch to try to merge it with trunk. Tav

6 6

Units in Inkscape
by Tavmjong Bah 15 Sep '14

15 Sep '14

Units in Inkscape ================= Introduction ----------- The recent debate about units in Inkscape highlights the fact that we do not have a clearly defined approach on how to handle units in Inkscape. Units are not as straight-forward as one should think they are. This essay attempts to resolve this problem. Historical View --------------- Part of the problem with units in SVG and CSS in general is why they are there in the first place. In the early days it was assumed that one would want to display drawings on a screen at full scale. In other words, a "one inch square" would be display on a screen as a physical one inch square. This required that displays be queryable as to what there true DPI was. Display manufactures rarely provided the means to query the DPI of the display, and when they did, they often returned incorrect results. Thus, the use of "real" units never became popular and in reality is usually not what one wanted. Eventually, after long arguments, the CSS working group dictated that one inch would be fixed to 96 pixels regardless of screen resolution (ironically, with so called "Retina" displays, there is once again interest in scaling drawings based on DPI). A Philosophy ------------ Absolute units should not be used inside an SVG file with one exception: The 'root' width and height may have units, which with a proper 'viewBox' determines an appropriate scale for a drawing. (This sets the 'real' world value of the SVG 'user unit.) This reflect the opinion of the majority of the SVG working group. It should be noted that the relative units 'em', 'ex', and '%' can be useful in some cases. Inkscape & Units ---------------- Inkscape should not write out absolute units other than in the root SVG element. Inkscape must, however, be able to interpret units from non-Inkscape produced files according to the CSS defined value of 96 pixels (initial user-units) per inch. The use of units in the Inkscape GUI is for ease of authoring only. The actual values should be stored as 'user-units'. Changing the "Inkscape GUI unit" should not introduce any 'transforms' on elements (as seems to being done now) nor should changing the SVG root 'width'/'height units or the 'viewBox'. The GUI should reflect the chosen Inkscape GUI unit scaled to take into account the SVG root 'width'/'height' and 'viewBox'. For example: <svg width="100mm" height="100mm" viewBox="0 0 100 100"> describes a drawing 100mm x 100mm where one 'user-unit' is equivalent to one mm. If the Inkscape property inkscape:document-units="mm" then the GUI would show a width of '25.4' for a rectangle 25.4 'user-units' wide. If inkscape:document-units="in", the GUI would show '1.0'. To implement this, one either needs to find the proper scaling from examining the SVG root 'width'/'height' and 'viewBox' properties or create a new Inkscape property that fixes this scale (in which case changing the 'width'/'height' would change the 'viewBox' and vice versa). Tav

8 26

Re: [Inkscape-devel] Units in Inkscape
by mathog 12 Sep '14

12 Sep '14

On 11-Sep-2014 10:23, Nathan Hurst wrote: > Ok, that's another vote for using double precision everywhere. That > gets us 14-15 digits, which should be enough for anybody. Adding more digits to the numerical representation does not in itself provide numerical stability, it just makes it easier to sweep the problem under the carpet of "looking at a smallish number of digits". Conversely, at least with respect to this units question, numerical stability, which for the purposes of this conversation means when a diff of two SVG's shows no changes, can be achieved if the lengths and coordinates inside the document are never changed, instead only one transform (or its equivalent) at the top level is. Then an end user could flip endlessly between different document units and never corrupt the numerical representations in the drawing. The only change that would show up, if no other changes were made, would be the values for that one transform. This assumes that the code did this: "we are currently using mm, user wants inches, REPLACE document unit transform with the pixels to inch transform" If instead it did: "we are currently using mm, user wants inches, MULTIPLY document transform by mm to inches conversion" then the single unit transform itself might not be numerically stable. (It could be if all of the units scaling factors have terminating binary representations with precision to spare, and the same is true for all combinations of their products.) Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

3 2

Inkscape devel very slow
by Javier García 11 Sep '14

11 Sep '14

Hi, I'm running inkscape devel on ubuntu 14.04 and it is going very slow even in smal documents.. what should I do? If you need some info about my computer/operative system I will be pleased to give you. Javi

1 0

problem in po/cs.po while compiling rev 13546 on Windows XP.
by alvinpenner 09 Sep '14

09 Sep '14

while synching with the trunk I got some error messages related to .po files, but I neglected to write them down. after compiling I get the messages below, related to po/cs.po Cheers, Alvin .................................................................. ============ cmd ============ strip build\inkscape-console.exe ============================= ##### Target : i18n ##### compile gettext .po files to .mo --- i18n / msgfmt ============ cmd ============ msgfmt po/am.po -o build/locale/am/LC_MESSAGES/inkscape.mo ============================= ============ cmd ============ msgfmt po/ar.po -o build/locale/ar/LC_MESSAGES/inkscape.mo ============================= ============ cmd ============ msgfmt po/az.po -o build/locale/az/LC_MESSAGES/inkscape.mo ============================= ============ cmd ============ msgfmt po/be.po -o build/locale/be/LC_MESSAGES/inkscape.mo ============================= ============ cmd ============ msgfmt po/bg.po -o build/locale/bg/LC_MESSAGES/inkscape.mo ============================= ============ cmd ============ msgfmt po/bn.po -o build/locale/bn/LC_MESSAGES/inkscape.mo ============================= ============ cmd ============ msgfmt po/bn_BD.po -o build/locale/bn_BD/LC_MESSAGES/inkscape.mo ============================= ============ cmd ============ msgfmt po/br.po -o build/locale/br/LC_MESSAGES/inkscape.mo ============================= ============ cmd ============ msgfmt po/ca.po -o build/locale/ca/LC_MESSAGES/inkscape.mo ============================= ============ cmd ============ msgfmt po/ca@...3150... -o build/locale/ca@...1971.../LC_MESSAGES/inkscape.mo ============================= ============ cmd ============ msgfmt po/cs.po -o build/locale/cs/LC_MESSAGES/inkscape.mo ============================= Make error line 421: <msgfmt> problem: po/cs.po: warning: Charset missing in header. Message conversion to user's charset will not work. po/cs.po:12:2: syntax error po/cs.po:12: keyword "TREE" unknown po/cs.po:18: keyword "MERGE" unknown po/cs.po:145: missing `msgstr' section po/cs.po:146:2: syntax error po/cs.po:146: keyword "TREE" unknown po/cs.po:150: keyword "MERGE" unknown po/cs.po:197: missing `msgstr' section po/cs.po:198:2: syntax error po/cs.po:198: keyword "TREE" unknown po/cs.po:202: keyword "MERGE" unknown po/cs.po:243: missing `msgstr' section po/cs.po:244:2: syntax error po/cs.po:244: keyword "TREE" unknown po/cs.po:248: keyword "MERGE" unknown po/cs.po:403: missing `msgstr' section po/cs.po:404:2: syntax error po/cs.po:404: keyword "TREE" unknown po/cs.po:408: keyword "MERGE" unknown po/cs.po:1925: missing `msgstr' section msgfmt: too many errors, aborting -- View this message in context: http://inkscape.13.x6.nabble.com/problem-in-po-cs-po-while-compiling-rev-13… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

4 10

Re: [Inkscape-devel] Inkscape 0.48.5 Released
by Jon A. Cruz 09 Sep '14

09 Sep '14

On Jul 19, 2014 9:20 AM, Partha Bagchi <partha1b@...400...> wrote: > > I would think that any build (Mac/Windows/Linux) uses external libraries since Inkscape depends on gtk+ and friends. Only difference, on Linux it comes with the OS and so the user does not have to do the legwork while for the other 2 OSes, one has to build the dependencies. > Kinda, sorta on Mac. Some libraries do come with the system but may be optionally included with the distributed program. Others require a developer to explicitly include them. Also, the standard for applications on OSX is for each app to include its own copies of external libs, but infernally as part of the application bundle itself. For the end user on a Mac no extra legwork is needed as all external libs are internal in the "application binary". It's also common to end up with multiple app versions side-by-side by simply changing the name on one app package before copying the next into the Applications folder.

1 0

Please check r13544 or later for problems at unit change
by mathog 08 Sep '14

08 Sep '14

One of the changes I introduced at revision 13544 was a modification of scaleChildItemsRec() so that it no longer recurses into groups to apply scaling changes associated with a change of units. This was breaking EMF import of clipped objects. That happened because during the recursion the coordinates of the clipped objects were changed directly, not by a transform. Since the clipping object (in defs) was not similarly scaled this broke the clip. See for instance: https://bugs.launchpad.net/inkscape/+bug/1348417 In the changed version the scaling change is applied as a transform at the group level, and all the coordinates within that group are not directly modified, so the clipping object and clipped objects are still at the same scale and they continue to work together. Since EMF import of clipped objects always works like (pseudocode): <g (clip reference)> clipped objects </g> applying the transform at the group level fixes the problem in that context. I suspect that scaleChildItemsRec() is still going to cause problems for any SVG object other than a group that looks something like (pseudocode): <(not a group) (a clip or mask ref) x=100 y=100 (other stuff) > when the document units are changed because it will change the 100's to something else, and not modify the referenced clipping object. I have not confirmed this though. In any case, would the people who worked on document units please see if my changes at revision 13544 break anything when the document units are changed? I did some preliminary testing and it looked OK, but I don't really know what test cases to use to explore all the edge cases. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

5 13

Re: [Inkscape-devel] Please check r13544 or later for problems at unit change
by mathog 08 Sep '14

08 Sep '14

On 07-Sep-2014 02:45, alvinpenner wrote: > two comments: the pre-existing bug has been reported at Bug 307656 and > Bug > 1366434. It appears to be related specifically to the rectangle tool > F4. > However there are two new regressions which are not related to F4. > > First one: rev 13544 has broken one of the fixes for Bug 1240455, > comment > 24: > https://bugs.launchpad.net/inkscape/+bug/1240455/comments/24 > > using Extensions->Render->Grids->Grid and using the default spacing of > 10 > px. > - case 1 : open Inkscape with default units of px, draw default Grid > - case 2 : open Inkscape, change units to mm, draw default Grid > > the expectation is that these two grids will look the same relative to > the > page size. Rev 13534 shows the expected behavior, rev 13546 does not. > > Second one: > - open Inkscape, draw two objects, a rectangle and a star, or ellipse > - select both of them > - change document units > - the expectation is that the shapes should not change size > - Rev 13534 shows the expected behavior, rev 13546 does not. I will revert that change in a little bit. Actually I'm going to add a parameter to the call, so that it can work one way (so that it works like it does now) for a call from EMF import, and as it did before when called from elsewhere (only one other place that I know of.) This is a short term hack until the actual problem is sorted. And I think the actual problem is in those parts of Inkscape which fail when the scale is applied to a top group. It is perfectly valid SVG to do: <g (scale to whatever conversion one wants)> (bunch of objects in completely arbitrary units. </g> All transform operations up the stack must be applied to an object. If some part of Inkscape only shows units properly when the top level scale is not present, then it is not correctly applying those transforms. How is it not that part of Inkscape that is broken? Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 1

Old Website will be Decommissioned
by Martin Owens 06 Sep '14

06 Sep '14

Dear Inkscape Devels, This is a warning that the old inkscape website currently at dev.inkscape.org will be decommissioned by November. Please make sure that any important information has been moved to the new django-cms website by then and let me know as soon as possible if you need help making this happen. Best Regards, Martin Owens

4 3

VALS Semester of Code
by Tavmjong Bah 06 Sep '14

06 Sep '14

Hi, Do we want to participate in "VALS Semester of Code"? http://semesterofcode.com/?p=22 We should be able to come up with one or two good ideas. Deadline is Sept 12th. Tav

2 2

Website Upgrade (1.2) Tonight
by Martin Owens 06 Sep '14

06 Sep '14

Dear Develoeprs, The inkscape website (inkscape.org) may be unavailable from 1am UTC (9pm EST) for a period lasting about half an hour. This upgrade will take us from django 1.5 to 1.6.5, django-cms from 1.4.2 to 3.0, haystack from 2.0 to 2.2, Whoosh 2.4 to 2.6 and finally inkscape-web from 1.1 to 1.2. The upgrade process involves a bunch of manual steps to the database and command line and I hope these will be completed shortly after upgrading the code. My thanks to Hachmann, jazzynico, Brynn and others in helping prepare this release. After the upgrade, content will be uploadable to inkscape.org and you may wish to populate your user account with some of your svg files to get the ball rolling. Also available will be the ability to upload Addon tarballs and inkscape release builds (exe files/tarballs etc) which can be used instead of sourceforge or your friendly file dumping service. Please see me directly if you need an increased quota to upload large release files. I'm going to start everyone off with 10MB quota to start gently. The idea for most users is to upload svg files which aren't that big. But we can increase this for different auth groups as needed. Any questions, reply here. Best Regards, Martin Owens

4 6

LPE Powerstroke
by Johan Engelen 05 Sep '14

05 Sep '14

Hi all, Release is getting closer, and we need to decide what parts of Powerstroke we are going to release. After release, it will be very annoying for users if we change the output of Powerstroke for certain input parameters. So we have to avoid having to do that. Ideas: - remove reflection-based extrapolated miters (my original extrapolation), add the arc extrapolation miter - remove CubicBezierFit and CubicBezierJohan interpolators, add Catmull-Rom interpolator thanks for input. I hope to work on this soon. -Johan

3 13

Re: [Inkscape-devel] LPE Powerstroke
by Johan Engelen 05 Sep '14

05 Sep '14

On 4-9-2014 3:52, Liam White wrote: > On Wed, Sep 3, 2014 at 5:36 PM, Johan Engelen > <jbc.engelen@...2592... <mailto:jbc.engelen@...2592...>> wrote: > > Ideas: > - remove reflection-based extrapolated miters (my original > extrapolation), add the arc extrapolation miter > > I like this, the arc extrapolation miter is stable and produces > consistently better results than the reflection-based miter. I have committed the change that enables Extrapolated Arc (used to be only available with specialized build) and removes Extrapolated (mirroring) from the UI. The code to deal with the old extrapolation setting still works, for people that use it in their files. I am not sure if we should keep that code around or not. It won't hurt too much for now, but may become a maintenance burden. (and I don't like having such undocumented features) The arc extrapolation definitely has issues, and needs to be improved (I feel). cheers, Johan

1 0

Report from the London SVG WG Face-to-Face meeting.
by Tavmjong Bah 05 Sep '14

05 Sep '14

Hi, I've just posted a blog with a report about the SVG Working Group's recent face-to-face meeting. You can find it at: http://tavmjong.free.fr/blog/?p=1100 Thanks to the Inkscape board for helping to fund my participation. Tav

1 0

Gtk+ 3 build bit-rot alert!
by Alex Valavanis 05 Sep '14

05 Sep '14

Hello All, I thought I'd quickly check how we're doing with the Gtk+ 3 build in Ubuntu Utopic, and was unpleasantly surprised to see that: (a) A tonne more symbols that have been deprecated in Gtk+ 3.10 (principally, GtkAction) (b) We have a few regressions, and have resumed use of some deprecated symbols that we had previously replaced. (e.g., GtkHBox) I have updated bug #1016020 with the latest build log (20k lines caused by deprecation warnings!!) and summarised the failures in the description. Obviously, (a) isn't our fault, but we should try to regain the progress we had made! (b) is more of a concern, since we're actually moving backwards! Ultimately, we should really try to enforce "-Werror=deprecated-declarations" in our dev builds, but clearly we're far away from that goal. Would it be reasonable to target a deprecation-free build for Inkscape 1.0? In the meantime, can I please request that from now on, everyone runs a strict build with both Gtk+ 2 and Gtk+ 3 before merging in any new features, so that we can ensure that we're not introducing any new warnings? Thanks, AV [1] https://bugs.launchpad.net/inkscape/+bug/1016020

7 13

Re: [Inkscape-devel] LPE Powerstroke
by Johan Engelen 04 Sep '14

04 Sep '14

On 4-9-2014 23:32, Johan Engelen wrote: > On 4-9-2014 3:52, Liam White wrote: >> On Wed, Sep 3, 2014 at 5:36 PM, Johan Engelen >> <jbc.engelen@...2592... <mailto:jbc.engelen@...2592...>> wrote: >> >> Ideas: >> - remove reflection-based extrapolated miters (my original >> extrapolation), add the arc extrapolation miter >> >> I like this, the arc extrapolation miter is stable and produces >> consistently better results than the reflection-based miter. >> >> - remove CubicBezierFit and CubicBezierJohan interpolators >> >> >> I am not so sure about this one. When we announce the 0.91 release, >> we are going to have a lot of users that previously used the >> derivative Ponyscape and were encouraged to use either of these two >> interpolators. >> I also believe we should add in Ponyscape's CubicBezierSmooth >> interpolator[0] to aid in the migration process. >> >> add Catmull-Rom interpolator >> >> I just tested and saw that Catmull-Rom has quite some disadvantages compared to CubicBezierJohan. So we should keep that or perhaps your "Smooth" variant. If we keep the Johan variant, we must give it a different name (in SVG) and so will definitely be incompatible with Ponyscape files that use CubicBezierJohan. (we really can't release with that name in SVG) -Johan

1 0

Stroke placement
by Tavmjong Bah 04 Sep '14

04 Sep '14

Hi, We discussed variable placement of stroke (e.g. inside/outside/10% inside,90% outside). The key to implementing this is having a good way to offset a path as then one can use existing rendering libraries to draw the stroke (including things like dashes, line-caps). If I can provide a clear (testable) algorithm for how to offset a path, there is a good chance we can get this into SVG 2. The current Inkscape code for offsetting is a bit buggy. I believe lib2geom has better code. Can anybody comment? Thanks, Tav

4 7

need advice on faq item re command line
by Brynn 02 Sep '14

02 Sep '14

Hi Friends, FAQ #3.8.1 contains some garbled text. Unfortunately, I don't know anything about using Inkscape from the command line.....or much about the command line, in the first place. So I'm not sure exactly how to fix it. The current text is below, for convenience. Or here's the URL: http://inkscape.org/en/learn/faq/#Missing_console_output_issue Fyi, I'll be combining this with item #2.20. Could someone either fix the current text, or offer a short re-write for me? It's the first sentence or 2, which need attention. Or if that info is outdated, I need to know the new info. If anyone wants to see what I'm working on: http://staging.inkscape.org/en/brynns-user-faq Comments welcome. Besides updating and re-organizing, I'm taking out a whole bunch of old useless code! (whole bunch!) It's probably about halfway finished, and then I'll start on the faq for developers. Note that I have uploaded some tiny images of icons, in the How-To section, but they have somehow become lost. Martin is on the case ;-) And btw, when I get to work on the Developer FAQ, for the most part, all I'll be able to do, is take out the useless code, and *try* to reorganize the items. Since I'm such a newbie to this world, I won't be able to decide if some need to be deleted, or if some text needs to be updated, or if new items need to be added. That part will have to be up to you guys :-) Text below. Thanks, brynn "As of the 0.48.2 release of the windows installer an inkscape.exe and an inkscape.com. The start menu shortcut points to inkscape.exe which does not write any output to the console. However, if you type inkscape in a command prompt, and the install directory (C:\Program Files (x86)\Inkscape\) is in your path, the command prompt will resolve inkscape.com before inkscape.exe. The file inkscape.com is actually a windows executable, that callsinkscape.exe and attaches it to the console window, therefore displaying stdout and stderr to said console. If you call inkscape.exe from the command prompt, things like exporting or converting to plain SVG do work, they just do not output anything to the console. If you are using an older version of Inkscape, or just wish for historical context, see this mailing list thread."

2 3

Inkscape 0.91 About Screen Contest is a go!
by Josh Andler 02 Sep '14

02 Sep '14

Hey All, We've reached that time in the dev cycle for the About Screen Contest to happen. If you'd like to find out more about please visit the relevant DeviantART journal link below. http://inkscapers.deviantart.com/blog/479716764/ Cheers, Josh

2 1

Alignment in C++ classes
by Liam White 31 Aug '14

31 Aug '14

While browsing through header files in experimental I found these sort of things: sp-object.h unsigned int cloned : 1; unsigned int set : 1; unsigned int value : 1; sp-namedview.h unsigned int editable : 1; unsigned int showguides : 1; unsigned int showborder : 1; unsigned int showpageshadow : 1; These look very much like a holdover from C which did not have a boolean type like C does. Is there any viable reason for not simply converting these to boolean? There are other, similar things that I saw as well (sp-namedview.h): unsigned int borderlayer : 2; and I believe this variable is meant to hold an enum type. Should it just be changed to the type of the enum with no alignment or is there a reason to not do that?

4 4