- Inkscape Docs - Inkscape Mailman

tutorials
by Alexandre Prokoudine 13 Feb '08

13 Feb '08

Hi, Here is the list of tutorials that we might still do for 0.46: http://wiki.inkscape.org/wiki/index.php/TutorialUpdates-0.46#New_Tutorials I can do docbookification in no time. Let's decide which ones we want for 0.46 to be really good and ready, so that translators had enough time to make their part of the work. To me it looks like "Clipping, Masking and Patterns" and "Paint Bucket Tool" have most chances, but both need some work. And |Interpolation" is in SVN already. What do you think? Alexandre

1 0

Preparing Next inkscape realease
by radar.map35＠...6... 21 Dec '07

21 Dec '07

lo everyone, We have been quiet these last weeks, but now Inskcape is nearly to reach the next release. It would be nice if we've had documented new features are proof-read existing for changes. I know we wanted to make some deep changes, but i think we won't haev time for now and keep that in mind for the next rel. Would someone have time or wishes to read or add some parts, and eventually which one ? pygmee

4 5

Translate Doc file for Inkscape
by Khoem Sokhem 13 Nov '07

13 Nov '07

Hi All, Now I am updating translations for Khmer for Inkscape, It will be finished soon. And I also would like to translate the Help for Inkscape. I want Inkscape to be fully in Khmer both applications and help. Where can start for this? Your respone is welcome! Thanks, Sokhem

3 2

defining tags
by Joshua Facemyer / Impressus Art 13 Nov '07

13 Nov '07

On #Inkscape today we were discussing the possibility of using the tag <formalpara> to replace <simplesect> so that we can have titles built into our paragraphs when necessary. From what I can tell, this works the same as a <para> tag and it takes a <title> tag as well. This would be a whole lot easier than encapsulating every <para> that needs a title with <section> or some other tag simply to give it a title. It would make more sense with the formatting scripts as well, and would keep other tags like <section> free solely for their primary uses. Does anyone know of any reasons not to do this? If not, what's the best way to test it? Finally, I've been working (following up on someone else's work) at putting all the tags we'll be using on the wiki at http://wiki.inkscape.org/wiki/index.php/DocumentationStandards along with their purpose so we're more unified in our restructuring and future writing. Please look over it and add tags or comments that are missing. JF

1 0

help and toc
by radar.map35＠...6... 09 Nov '07

09 Nov '07

Lo, I took advantage of travelling a lot by train this week to read carefully alexander mail. 1) happy to see that you follow the way i've already begun with , ie style 1 +2 ;) 2) context-sensitive help would need that the team had chosen a "help browser" and have ertainly done sone modifications in the core to allow this. For the help browser (which scribus has for example), we could use yelp that is nearly fully docbook compliant but the question many oppose to that is how would it work on other OSs. This is a big problem and until we find a solution, the only easy way would use web browser and have some "html name rewrite" from an ID that could be used as context reference. We cannot go further this way without talking aboutthis with other guys of the core-team. From that, what can we thing of grouping elements in the TOC? Grouping is a common task for any author. It tries to organize the needs to help the reader to understand. In the actual manual, you may see that in most part, it describes menus one by one, and in more thematic way some more complex tools or concepts. Why this ? Because if you think of the manual as a help sensitive system, you guess that the reader would read from the beginning to the end but will browse it in search of a specific info (for ex: what means mass in Calligraphic tool and how it is made for). Sure there could ne many ways in grouping elements, but at least we can simply do link to other parts if needed so, the place of one is less important that it can be in a book. hypertext navigation is not a space navigation so it doesn't change anything for the reader if we use in one part a page that is written in another. An example of this. In your Proposal, Alex, have a specific part for Preferences. right. But some tool need to be set in preferences quite often, for ex 3d tool) so that preferences is in this case a real part of the tool usage. HAving a complete reference to the page related to this is a must in this case, and would be a gooduse of non-linear reading. Thinking of some special elements like Color management or icon preview, I'm just wondering if it would not be usefull to have some part about specific usage of Inkscape. I'm thinking of : - Inkscape for press - Inkscape for theme design - inkscape for web design ans so on. Having fill'n'stroke in colours is also something strange especially for stroke settings which can be considered as object properties. I'm not sure if we should map all this to visualize the several relationship that can be set between pages. We also need to define a basis structure of each pages. Is the one we already have good enough (title+screenshot+Intro+Activation+Procedure+Additional infos+Links) ? Alex, i'm also wondering if it would not be better to split much than you did. I would do : One file per TOC entry. I didn't follow the new gimp's process, but that was what they had some years ago when i contributed. Roman could be open to help us in a reasonable way, he always answered my mails ;) A+

4 3

TOC on the wiki?
by Joshua Facemyer / Impressus Art 29 Oct '07

29 Oct '07

I've updated the TOC according to my understanding of what you mean, Alexandre. If it's incorrect, please fix or let me know to fix it. I'd like to be sure about what you had wanted before we continue. JF

1 0

Tag fixing in inkscapeUTFfr.xml
by Colin Marquardt 25 Oct '07

25 Oct '07

Hi, I just changed inkscapeUTFfr.xml so that xml2po is happy with it. I had to change a lot of <para></para> or <para /> to <para>some text</para> (I used FIXME instead of "some text"), since xml2po doesn't seem to like such empty tags. (Not just paras, also terms and titles etc.) Doing xmllint --valid --noout inkscapeUTFfr.xml still complains about some issues though. Oh, and I also changed "<para >" to "<para>" for cosmetic reasons. If you want to try creating a pot file youself, do: xml2po --output=inkscape_user_manual_orig_fr.pot inkscapeUTFfr.xml Cheers Colin

5 15

Automated screenshotting
by Colin Marquardt 23 Oct '07

23 Oct '07

Hi, I think we very much want something like this: http://www.gnome.org/~dscorgie/autoshot.html Doc is http://live.gnome.org/autoshot http://osdir.com/ml/gnome.documentation/2006-08/msg00044.html Cheers Colin

1 0

english file
by radar.map35＠...6... 22 Oct '07

22 Oct '07

I've been looking at the english splitted file and applied the same strategy on fr. For info, interested people may find a "translation" of the curriculum.xml file at http://www.le-radar.com/articles/drawinginkscape/html.en/index.html but in HTML. But if the file is kept, it might be a good start for improvments. regards pygmee

1 0

couple of questions
by Joshua Facemyer / Impressus Art 16 Oct '07

16 Oct '07

I'm working on a few minor translations to get started. A couple of questions: "Nom d'outil ou partie" I'm translating to "name of utility or function" - is "function" appropriate? I'm not sure what the comment signifies exactly, so need some help. The English version of the xml file is not really a translation of the French, as there is a lot of extra stuff in the English (for example, in the "SVG Goals" section). Should I attempt to reconcile the differences and cut everything extra out of the English version (most of it is not really useful, in my opinion), or is the extra stuff in the English version getting put into the French version eventually. Sorry if I'm a bit confused by this. I really want to get my hands dirty, but keep coming upon roadblocks :) JF

5 15