- Inkscape Docs - Inkscape Mailman

Re: [Inkscape-docs] [Inkscape-translator] Website: Download page updated
by Maren Hachmann 01 Jun '17

01 Jun '17

Hi Eduard, feel free to edit the page to make it look nicer :) (would be really kind if you could adapt the German version then, too) I'm keeping translators informed of updates (if the authors forget to do it themselves), and translating. Contents discussions are a subject for the docs mailing list, so I'm including them in my reply. Kind Regards, Maren Am 01.06.2017 um 21:14 schrieb Eduard Braun: > Am 01.06.2017 um 21:02 schrieb Maren Hachmann: >> Hi translators, >> >> hope you're having some nice sunny days, too :) >> >> Marc has updated the Download page at https://inkscape.org/en/download/ >> to be a bit clearer on the meaning of the icons, by adding some text >> below them. >> >> Maybe you can make some time this weekend to edit them in in your >> language? >> >> Thank you! >> >> Kind Regards, >> Maren > > Do we need the "For " and "..."? It looks a bit cluttered. > Also "... or get the code." gets wrapped in an ugly way (maybe just use > "Source code"?). > > Centering and bolding of those labels would probably improve clarity yet > another bit. > > Regards > Eduard >

1 0

[Manual] Terminology
by brynn 22 May '17

22 May '17

Hi Friends, I think Maren mentioned to Carl about terminology (in a different message) and I agree that one of the most important things we need to do, is use the same terminology throughout the manual. However, that said, I'm not sure what the best way to accomplish that would be. Actually I was going to propose some changes to some of the section and chapter titles, in this message. But now that I think about it, that might be putting the cart before the horse (as we say here, sometimes). Should we create a Glossary? I mean as part of the manual? Or should we create a glossary that we just use for our own reference, as we write? Maybe make it part of the wiki? The gitlab wiki? Once or twice I've had a thought about making a glossary for the website someday. But until the website contains more instructional info, it probably has no purpose yet. But what I mean is that creating a glossary, whether formally part of the manual, or just in the wiki, could also be used on the website someday. If not glossary, what are some other ways we could keep ourselves all on the same page regarding terminology? What about one person (or 2?) who primarily takes care of that? Other ideas? All best, brynn

5 6

Re: [Inkscape-docs] [Manual] Terminology
by brynn 22 May '17

22 May '17

Hi Marietta 0, Are you interested in helping? You'd be welcome to help in any way you choose. Start a glossary, translate, edit, there are several different kind of tasks to accomplish. If you're interested, let us know, and we can get you started. Or you probably saw Maren's intial post about this, so you can follow the info in that message, to get a Floss manual account and etc. Anyway, we'd be happy to welcome you aboard :-) All best, brynn -----Original Message----- From: Marietta Walker Sent: Thursday, May 18, 2017 5:02 PM To: brynn Subject: Re: [Inkscape-docs] [Manual] Terminology I think a glossary would be fantastic. It would be nice for everyone to be on the same page when you are tying to help each other. Just my two cents. Marietta 0 On 5/18/2017 1:55 PM, brynn wrote: > Hi Friends, > I think Maren mentioned to Carl about terminology (in a different > message) and I agree that one of the most important things we need to do, is > use > the same terminology throughout the manual. However, that said, I'm not sure > what the best way to accomplish that would be. > > Actually I was going to propose some changes to some of the section > and > chapter titles, in this message. But now that I think about it, that might be > putting the cart before the horse (as we say here, sometimes). > > Should we create a Glossary? I mean as part of the manual? Or > should > we create a glossary that we just use for our own reference, as we write? > Maybe > make it part of the wiki? The gitlab wiki? > > Once or twice I've had a thought about making a glossary for the > website > someday. But until the website contains more instructional info, it probably > has no purpose yet. But what I mean is that creating a glossary, whether > formally part of the manual, or just in the wiki, could also be used on the > website someday. > > If not glossary, what are some other ways we could keep ourselves all > on > the same page regarding terminology? What about one person (or 2?) who > primarily takes care of that? Other ideas? > > All best, > brynn > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Inkscape-docs mailing list > Inkscape-docs(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-docs

1 0

[Manual] Organization of the new manual
by brynn 22 May '17

22 May '17

Hi Friends, First I just want to thank Maren again, for getting this manual set up, so that we can move forward with translating and editing. 3 Cheers!!! During our early discussions, I had mentioned, and she agreed, that since the Docs list covers kind of a lot of territory (website, new manual, various other documentation) we might want to identify discussions pertaining to the manual by something in the title of message. That's why I put [Manual] at the beginning of the title of this message. I'm not sure if it should maybe go at the end of the title? Or maybe should be [Man]? My main reason for this message, is because I want to start a discussion about overall organization of the chapters. To me, it makes sense to get that ironed out in the beginning. Because as it grows, it could become harder and harder to change how it's organized. (Note that in this message I'm more describing the chapter and section titles, because right after this, I want to send another message on the subject of possibly improving section and chapter titles. Eventually, they'll come together, but for getting everyone's ideas out, it's probably better to have separate threads.) So here are some thoughts I'm having on organization. If everyone else wants to wait, that's fine too. Just speak up :-) To me, the Selection tool is a global tool and does not belong under Geometric Shapes. That implies either it can only be used with the shape tools, or used best with them. And that's not the case at all, in my view. I'm thinking we need a new major section, that would go between Introduction and Geometric Shapes. Maybe it would be called something like The Basics or Getting Started? The purpose of it would be to quickly make newbies productive, while linking to the relevant parts of the manual, at each step. Then the rest of the manual would by and large be about the same (except I'll probably suggest a different order for some of chapters later). This could really almost be in the form of a tutorial, although not necessarily. This section I'm proposing would include the following -- the current Interface chapter -- the current Managing the Workspace chapter(which appears to be about Document Properties dialog) -- the current Selection tool -- the current Fill and Stroke dialog -- a new chapter which explains the difference between raster and vector (unless this already exists and I haven't found it yet?) -- current Importing raster images -- current exporting PNG -- current Copying/duplicating -- current Saving your work (these last 3 are currently way down the list, in advanced section) (see discussion below) -- a new chapter introducing transparency, but linking to deeper applications in Fill/Color and/or Advanced sections -- current Align and Distrib from Path section to here -- maybe Transform dialog? (not sure if currently exists) (not in that order - we can discuss the order later, if everyone agrees to this new section) I'm having a hesitation about including the Fill and Stroke dialog in this section. Most of it is about color and transparency. But because of the Stroke Style tab, it becomes more of a global tool. I generally have it open always. Other comments? The reason I would include Importing here, is because many newbies start out with Inkscape by needing to trace a raster image (auto-trace or manual). I tend to think of importing as part of setting up my document. Any other thoughts? To me, you can't get more global than copying/duplicating (except maybe selection tool). For Saving Your Work, it just doesn't make sense (to me) to have that in advanced section. I realize for many formats, it is advanced material. But I'm thinking -- have a simple explanation in this new section, but then have links to the more advanced info, which most newbies won't need, just to get started. For the section on Paths, I would suggest moving Strokes, Markers, and Custom Markers, out of the Fill/Colors section, into Paths section. That seems obvious to me, but I'd be interested to hear reasons for keeping them with Fill/Color. Ordering of fill/stroke/marker here too. Is the Transform dialog covered anywhere? I don't see it by browsing the chapters, but maybe is there somewhere? If not, I would put either in the Geometric Shapes section, or maybe even the new section. After some discussion, we can propose a good order for the chapters. Of course, I can only read those which have been translated. So maybe the current order will make more sense when I can read them. But for now, what do you all think about the idea of a new section? All best, brynn

2 3

howdy Inkscape manual writers
by Carl Symons 18 May '17

18 May '17

My name is Carl Symons from US-Washington State, Bellingham. Bellingham is th home of linuxfestnorthwest.org. For several years, I was one of the organizers and did a lot of pieces with Inkscape. On the main page, you can see the iconic LFNW Totem. Originally created in hardcopy with poster paint. I converted it to Inkscape SVG, used for many things including the large version seen on www.linuxfestnorthwest.org/2017/sponsors/world-famous-lfnw-raffle. While you're there, have a look at the World Famous Raffle sign thaht I also also created in Inkscape. Despite creating these, it's easy to imagine what Inkscape is like for someone just getting started...I'm not very skilled, but I have fun. For several years, worked on KDE news (dot.kde.org), writing (dot.kde.org/2012/10/15/plasma-active-3-improves-performance-brings-new-apps) and editing almost every piece for a couple of years (2010 - 2012) I'll assist with editing and proofreading as needed. Carl

2 3

zip versions of 0.48 not available
by brynn 17 May '17

17 May '17

Hi Friends, Just trying to get a version of 0.48 for testing (helping someone in a forum) and for both zip and 7z, it says Download Failed WARNING! The download for this isn't working or isn't set up right. Is this a problem? Or is there somewhere else where we can get older versions? Thanks, brynn

3 7

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)
by Maren Hachmann 17 May '17

17 May '17

Hi, sorry for the delay. I've been trying things out a bit, and I feel I haven't seen enough yet, but I won't have time tomorrow, so posting anyway now. So, it seems that what we still need for a manual (any kind) is a platform to create it (not only write, but also output to different formats). I have had a chance to look at 3 different platforms on my list, and I'm trying to outline the pros and cons, as I perceive them, please add yours to the list. There are many more platforms in existance (see also: https://github.com/PharkMillups/beautiful-docs#generating-docs), and if anyone here has some experience with them, please add. ************* - Gitlab Wiki + X, as suggested by Martin. WHAT: An online Wiki on gitlab with a source code editor, associated with a gitlab project. PROS: - custom-made to suit the project's individual needs (no specifics yet) - Preview functionality CONS: - only (limited set of) Markdown, RDoc or AsciiDoc - limited formatting options, formatting not so much about 'roles' of formatted text, but more about 'looks' - the backend isn't written yet - no option for branches via interface (so we could start writing for trunk, and continue fixing for stable) - no direct translation support - support for the backend depends upon a single individual, no user community - no WYSIWYG editor - no GUI access to git repo, for managing where to put uploaded files etc. - no GUI for undoing a change (like in a 'normal' Wiki), or looking at a diff EXAMPLE (frontend): https://gitlab.com/inkscape/inkscape-web/wikis/home ************* - Gitlab Editor + Sphinx / readthedocs: WHAT: A git repository with an online source code editor and documentation update on readthedocs.org on save (i.e. commit). PROS: - available quickly (didn't know how it works exactly, but got it all up and running with test content within an evening) - uses git and reStructured Text - allows to have branches, so devel version features can be documented when they are coded - supports translations (not entirely sure how, though, haven't tested it yet, wanted to send this email instead. E.g. Django docs are translated. Fallback to English if no translation of a document. I think they use different branches.) - free theming, separately for each output format - free hosting, can also use our own domain name with readthedocs.org, e.g. docs.inkscape.org - after installing some programs, tool chain runs locally - preview via gitlab editor or local editor - same toolchain can be used for developer documentation (includes code documentation from docstrings) - extensible via plugins (haven't had a chance to take a closer look yet or test any) - I think it's possible to add a 'edit this page on gitlab' link to each page, to get new contributors, even when using readthedocs.org (not tested, but read that others did similar things) - extremely wide range of export formats via plugins - infinite hierarchy nesting - syntax highlighting (e.g. for command line usage instructions, or extension writers) - video embedding (not tested) CONS: - learning curve for admin (theming, plugins,...) - learning curve for editors (syntax, workflow) - no WYSIWYG editor, only preview (incomplete, because doesn't support all sphinx stuff) EXAMPLE: - repository: https://gitlab.com/Moini/inkscape-extensions-multi-bool/tree/master/docs - rendered documentation: http://inkscape-multi-bool-extension.readthedocs.io/en/latest/index.html ************* - Booktype: WHAT: A web portal for creating books, hosted by friends of the Inkscape project. PROS: - available right now, no further setup required - best interface by far, easy and intuitive to use - team functions, user roles, chat - prevents concurrent editing - wide range of export and import formats - support for themes/settings for specific export formats (e.g. different font sizes etc.) - free hosting and maintenance via flossmanuals(fr) - community of experienced documentors CONS: - confinement to django database for version control, more difficult to get data out of it again for editing - no direct translation support (make a copy of the book, copy changes over after doing a comparison in the history) - limited versioning support (only the latest one can be edited) - we'd need to ask someone to add CC-By-SA licence (currently, the options I got were CC-By, GPL. I guess this would be quick and easy to solve.) EXAMPLE (rendered documentation): https://www.flossmanualsfr.net/initiation-inkscape/ ************* All of them would be FLOSS, have support for internal linking, allow to insert images and allow editing via browser. ************* I wish it were possible to combine the ease of use of the booktype frontend with the portability, branch support, sustainability and versatility of the gitlab/sphinx/readthedocs backend... (In German that's called the 'eierlegende Wollmilchsau' - egg-laying wool- and milk-giving pig...) For the sphinx option, I believe I'd be able to take on the first setup and some of the tasks that come with customization and extending, as well as basic maintenance. For Booktype, anyone of the documentation writers could do that easily. Regards, Maren

4 16

website moderation policy final
by brynn 12 May '17

12 May '17

Hi Friends, It seems like this last message about moderation policy got buried in all the recent important chatter. So I'm re-sending the most vital parts of it, so we can finish this up. For convenience, https://inkscape.org/community/coc/ And here's the suggested change: In the Guidelines for User-Submitted Content section, replace "Art and other content submitted to the Inkscape website should adhere to the following rules:" with "Content uploaded to the gallery should be related to Inkscape (e.g. created with Inkscape, created for use with Inkscape, showing how to work with Inkscape, etc.). We reserve the right to remove any content that does not seem appropriate or does not adhere to the following obligatory rules:" C R said > Little thing, but "created for use with Inkscape" could cover things like just regular images... in fact it could cover just about anything, even things made with Adobe Illustrator. I'd simply cut that bit out. Hhmm.....yes, I see what you mean. My interpretation of that, is for things like extensions or filters. But maybe there's a better way to say it? What about "created to be installed in Inkscape"? Or maybe just "to be installed in Inkscape"? That would eliminate any kind of image. Any other suggestions out there? Eduard? I wonder about adding "Inkscape Project"? Such as: "Content uploaded to the gallery should be related to Inkscape or the Inkscape Project (e.g. created...." That would cover things like a website graphics or page mockup, board meeting transcript, etc. C R said > If there's a significant amount of undesirable content currently, it's probably best to make it retroactive. If it's just a few things, then we should approach the owners about it. Not to be pushy, but to inform them of the new policy. To me, it's a significant amount. By my estimate, probably 1 or 2 thumbnails per page of the gallery are random photos! So that's way too many to consider trying to contact them. Personally, I would love to delete them without notice. But since the policy was not available at the time they uploaded, technically I think it's not fair to delete them. But they'll soon be shuffled further and further back, as the gallery grows. I'm happy just to get the policy settled and put it into effect. Thanks everyone for taking the time, and helping to finalize this issue. As far as I know, this will be the last step before we can start recruiting moderators, and using the system officially. All best, brynn

3 9

moderators needed for the website
by brynn 12 May '17

12 May '17

Hi Friends, Thanks to Martin for creating the most amazing moderation system I've ever seen, for the website. Now that it's ready, volunteers are invited to join the website Moderation Team. Moderators work together to make decisions about each reported item (image, comment or member). No particular skills are needed. The biggest qualification is to care about maintaining the website as a beautiful and safe place for members to show their Inkscape work and interact. Most days you would only need to spend 15 to 20 minutes or less, although in the beginning, a little more time will probably be needed to become familiar with the system. And visit as many days as you can. The more moderators we have, the less time we each have to spend moderating. If you're interested in helping, please go to Community tab > Teams page (https://inkscape.org/en/teams/) and click on "Moderation Team". On the next page, click to request to join the team. (Sorry, I don't know exactly what the text is, for that link, but it will be regular size text, and orange color). After that, we'll contact you, and get you started. Thanks for your interest in contributing to the Inkscape Project :-) All best, brynn

1 0

Re: [Inkscape-docs] [Inkscape-devel] License for the new manual
by brynn 12 May '17

12 May '17

Thanks Maren. Sorry for replying twice. After I sent the first, I realized it needed to be copied to Docs list. Can you give link to the new English one? Thanks, brynn -----Original Message----- From: Maren Hachmann Sent: Thursday, May 11, 2017 6:40 PM To: inkscape-devel(a)lists.sourceforge.net Subject: Re: [Inkscape-devel] [Inkscape-docs] License for the new manual I've just played around at flossmanuals.net a bit, and was surprised how easy and quick it is to import the book there from the French site. (I intended to just give it a try, but it worked so well, that I got carried away starting to edit it...) Elisa, can you give Mick the heads up that we've managed to do the import ourselves already? I'm working on importing the chapters from the French book, so we have the files and the original texts readily available. When that's done, I'll send a message to the list to invite editors. Kind Regards, Maren Am 11.05.2017 um 22:58 schrieb Maren Hachmann: > Great :) > > So let's keep our fingers crossed that it'll be possible to have an > English interface for working on the book - and then we can call out for > people to open up accounts. > > Kind Regards, > Maren > > Am 11.05.2017 um 21:05 schrieb C R: >> Thanks for clarifying, Martin! >> -C >> >> On Thu, May 11, 2017 at 5:54 PM, Martin Owens <doctormo@...2...> wrote: >>> Hi Maren, Victor, CR, >>> >>> Yes, let's settle this. CC-BY 4.0 >>> >>> https://creativecommons.org/licenses/by/4.0/ >>> >>> Shall be used for the inkscape manual. >>> >>> I believe there's a weighty enough consensus not to beat around the >>> bush any more. >>> >>> Best Regards, Martin Owens >>> >>> On Thu, 2017-05-11 at 01:18 +0200, Maren Hachmann wrote: >>>> Sorry, I think I need to explain and ask one last question: >>>> >>>> I asked for CC-By, because that allows the licence to be changed when >>>> you make derivatives, and because it wasn't clear yet which licence >>>> we >>>> might want to use in the end, and because this wasn't my decision to >>>> make. >>>> >>>> Martin, you took it on you to count the votes. I think CC0 is out of >>>> the >>>> question by now. What is the current status? >>>> >>>> (Mc asked about CC-By, I think. I bet CR would prefer CC-By to CC-By- >>>> SA, >>>> from what I read.) >>>> >>>> Do people now just want to go with CC-By, either because they like it >>>> most, or to just 'be done' with it and start working? (I'd like to >>>> have >>>> some kind of final decision). >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Inkscape-devel mailing list >>> Inkscape-devel(a)lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel >> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 2