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+ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-docs mailing list Inkscape-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-docs
