radar.map35@...6... wrote:

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.

How do other apps (gimp, etc) handle this? Maybe we can use yelp or kde help (whatever it's called) when it is available (check at run time), and if not, use a browser. I know it complicates things a little, but (without knowing much) sounds like a reasonable solution.

Another possibility is to use the integrated help browsers on Mac and Win, generating a platform-specific help file at compile time. I'm certain there are tools to convert help files from docbook to those platforms' help apps, but again, don't know for sure.

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.

Since it's unlikely that this manual will be published in paper form, I agree that things can be in "arbitrary" places. But it may still be read as a book, even online, so it should have a usable outline or structure for straight reading. I think I'm just agreeing with you here? Maybe I'm not quite sure what you're trying to say...

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.

I like this idea. However, couldn't we do a "generic" manual, then have a page which basically groups links to pertinent references (with descriptive text, of course)? I don't think we should necessarily separate out "Color Profiling" from the base of the manual and put it into an "Inkscape for press" section, if that's what you're saying, just group it under that heading with other topics.

Having fill'n'stroke in colours is also something strange especially for stroke settings which can be considered as object properties.

I think bulia said the plan was to change this dialog to "object properties", since it contains all different types of object properties anyway.

I'm not sure if we should map all this to visualize the several relationship that can be set between pages.

That might work very well - is there a way to do this on the wiki? Or maybe we could use an svg diagram file on the wiki?

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) ?

Is there anything else we need?

One thing that Colin and I discussed was whether proliferation of screen shots is necessary. He's working on a screenshot script so that we can all take relatively similar screenshots, which should make things easier. I think you all know that po tools don't help with updating or translating screenshots, so we had agreed that unless/until a better solution is found for automation, the fewer screenshots we have the better.

I think a lot of the shots could be reused. For instance, we could have one screenshot called something like "main_ui.png" which is referenced by, for instance, "On-Canvas Editing", "Toolbars", "Menus", etc.

In addition, it might be beneficial to put only screenshots where they are absolutely necessary, such as where one may find it difficult to understand without an illustration. I know that's difficult to ascertain in many cases, but I think we should make an effort to do it nonetheless.

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 ;)

That seems like a lot of files, and might get a little messy. Is there a benefit to having lots of files rather than one or a few, if we're using po tools?

JF