Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Elisa Godoy de Castro Guerra]

2017-05-11 22:55 GMT+02:00 Maren Hachmann :

> Hi Elisa,
>
> thank you very much for asking the flossmanuals.net manager!
> Would you keep us updated on whether it works or not?
>
>
yes of course.

Elisa


> Kind Regards,
>  Maren
>
> Am 11.05.2017 um 16:09 schrieb Elisa Godoy de Castro Guerra:
> > Hello,
> >
> > Mick Is the manager of floss manuals english.
> > I ask him for the possibility of import the book.
> > I give him the url, he is trying.
> >
> > Regards,
> > Elisa
> >
> > 2017-05-11 1:07 GMT+02:00 Maren Hachmann  > >:
> >
> > @jazznico: Is there a way to transfer books between the French
> > flossmanuals site and the English one? I.e. would it be possible to
> > export and import a book? Or would it be possible to have a language
> > selection menu on flossmanualsfr instead, with English available for
> > selection? This would make it easier for our international editors to
> > deal with the interface.
> >
> > Hi Brynn,
> >
> > thanks for taking a closer look! (I'm so glad someone was able to
> take
> > the time for this.)
> >
> > FLOSS is the abbreviation for 'Free/Libre Open Source Software'.
> > The websites are flossmanualsfr.net  /
> > flossmanuals.net  respectively.
> > They allow for collaborative writing of manuals for FLOSS.
> >
> > I fully understand the need for a WYSIWYG editor. The one from
> Booktype
> > is quite okay. Where it lacks is when you want to insert a file or
> image
> > - because you need to upload it first, then you need to find out that
> > the link to it that you need to enter in the insertion dialog is
> > '/static/filename.ext'. That's more difficult than it would need to
> be
> > (but you can use the same image file on different pages this way).
> >
> > (Btw. what do you think of helping with the translation by making
> sure
> > that all images get uploaded? When I copy-paste from the French
> book, I
> > get all the images, but they are just links to the original book, not
> > part of the one I'm editing. And it takes quite some time to rename
> the
> > files to something English,  upload, add a useful placeholder text
> and
> > then exchange the links. I'd prefer to spend that time on
> translating.)
> >
> > About the 'location', I've had this silly idea:
> >
> > As a first step, we create/translate/update this introductory manual
> at
> > flossmanuals (if possible at the English site, to make it easier for
> > contributors). It's a great way for getting people started with
> > Inkscape.
> >
> > As a second step, or in parallel, we could also have a more
> > glossary-like, more technical manual, that explains what each menu
> item
> > /LPE/... does. This technical manual could also be used by
> developers to
> > document their changes, and it could use the more technical style
> with
> > Sphinx/reST/readthedocs. It could even start out simple, with
> keywords /
> > lists, and be refined by people who don't like those ;-)
> >
> > (btw. I have volunteered to set this up, seems you overlooked ;-) -
> for
> > customization, translation and version branches, I'd still have to
> learn
> > a bit, but it doesn't appear to be too hard).
> >
> > The one issue I see with this split is that it would spread resources
> > (us) a bit wide, maybe. But from the time when I started using
> Inkscape,
> > I know that having a manual like the one Elisa wrote would have
> helped
> > me a lot - I barely understood a word in Tav's manual.
> >
> > Now, as an advanced user, I (claim I) know everything that Elisa
> > explains, but Tav's more technical manual contains so much more info,
> > which I'm now able to understand (and often have the urge to update).
> >
> > So that's why I think that having two different manuals wouldn't be
> such
> > a bad idea. The technical manual could be written by the more
> technical
> > users and, hopefully, devs (when they change something).
> >
> > Well, just an idea. Let me know if you think it's crap ;-)
> >
> > Kind Regards,
> >  Maren
> >
> > Am 10.05.2017 um 07:47 schrieb brynn:
> > > Hi Everyone,
> > >I've tried to read up and study and understand the info
> which
> > > Maren presented.  Because my understanding is extremely limited, I
> > > hesitate to offer any comments at all.  But for whatever it might
> be
> > > worth, here they arealong with a couple of questions.
> > >
> > >First, one of your last comments:
> > >
> > >> All of them would be FLOSS, have support for internal linking,
> > allow to
> > > insert images and allow editing via browser.
> > >
> > >I think you're using "FLOSS" as a generic umbrella term, as
> > > opposed to the FLOSS Manuals, right?  Because a 

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Hi Brynn,

indeed, you got the wrong book, Brynn. Just wait a day or two (or
however long it'll take to contact Mick and get a couple of things
sorted out), then you'll see. We're definitely going to need someone who
renames the images that will be in that book.
You don't need to work on it yet.


> -- Not so silly.

- Oh :)

> -- Since we already do have the technical style of manual, outdated
> though it may be, I would suggest getting the new one finished and
> published first.

- I agree.

> -- Perhaps Tav would consider releasing the content of his current
> manual, to be used as a starting point for the technical one?

- I already had asked him about this, and, AFAIR, his answer went into
the direction of 'This may be difficult to do (because the book is
copyrighted and a publisher holds the rights), don't count on it ever
happening. Rather start something new.'

> -- Likely certain people would be better suited for writing this more
> technical one.  I know for myself, I couldn't write it, no matter how
> hard I tried.  Often I find myself writing in simple language, even when
> I know the reader doesn't need it simplified.  Must be in my DNA, haha.

- There may be others reading it, aside from the person who asked.

> -- I wonder if having 2 manuals would be confusing for users?  I think
> as long as the titles of the manuals makes it very clear, it would be
> ok.  Such as Introduction to Inkscape for the beginnners' manual or
> Technical Inkscape Manual for the other.  Something like that.  (And
> also make sure the URLs include the distinction, so searching isn't
> confusing either.)

- Yes, I agree 100%.

> Somewhat random thought.  I guess both Floss Manuals and Booktypes can
> be themed or branded?  Perhaps at some time during this
> manual-translating and then writing process, the community can have a
> discussion about Inkscape branding? I'm not sure if we can say it's
> overdue, but I would suggest that the time has come  :-)

- flossmanuals does appear to have an option for adding some kind of
home page. It seems to be a bit complicated, but possible. Not so much
for branding the book, there are three themes to choose from, which is
an experimental option (and I haven't tested). But as it's html, it may
be possible to do some post-processing...

(*This* kind of thing is a lot more controllable with readthedocs/Sphinx.)

It's not very high priority, though. However, it would be extremely cool
if we could manage to have a pdf or a set of web pages ready for
inclusion in one of the next Inkscape versions this year.

Maren

Am 12.05.2017 um 08:00 schrieb brynn:
>> (Btw. what do you think of helping with the translation by making sure
> that all images get uploaded? When I copy-paste from the French book, I
> get all the images, but they are just links to the original book, not
> part of the one I'm editing. And it takes quite some time to rename the
> files to something English,  upload, add a useful placeholder text and
> then exchange the links. I'd prefer to spend that time on translating.)
> 
> Sure, if I'm just taking the images from one and putting into the other,
> I could do that.  I just didn't like the idea of making new screenshots,
> using my theme. Although, at least the images I've looked at so far,
> already have English names.
> 
> Hhmm  Hopefully Sylvain can answer the questions I asked about the
> work that has been done to date. (in a different message)
> (https://sourceforge.net/p/inkscape/mailman/message/35828296/)  Could I
> be looking at the wrong documents?  Besides different chapters, I'm
> seeing vastly different content between the French and the translated
> English.  It's not just translated, it appears to be entirely rewritten,
> and also using completely different images!
> 
> I might think I was mistakenly looking at the original Inkscape Floss
> Manual, except both of the ones I'm looking are on the fr subdomain. 
> Let's get this straightened out, so I'm working on the right documents. 
> So using "L'outil Sélecteur", which is Selection Tool, right?  To me,
> this page:
> 
> https://fr.flossmanuals.net/start-with-inkscape/select-tool/
> 
> is not just a translation of
> 
> https://fr.flossmanuals.net/inkscape/selector-tool-a/
> 
> I certainly don't mind editing the pages that are already translated, to
> put the same images from the French manual, but I'd have to make major
> text edits too. (Or we, or whomever.)
> 
> Surely one of the 2 I'm looking at is the wrong one?
> 
> 
> Re: "silly idea"  Some comments.
> 
> -- Not so silly.
> -- Since we already do have the technical style of manual, outdated
> though it may be, I would suggest getting the new one finished and
> published first.
> -- Perhaps Tav would consider releasing the content of his current
> manual, to be used as a starting point for the technical one?
> -- Likely certain people would be better suited for writing this more
> technical one.  I know for myself, I couldn't write it, no matter h

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

> (Btw. what do you think of helping with the translation by making sure
that all images get uploaded? When I copy-paste from the French book, I
get all the images, but they are just links to the original book, not
part of the one I'm editing. And it takes quite some time to rename the
files to something English,  upload, add a useful placeholder text and
then exchange the links. I'd prefer to spend that time on translating.)

Sure, if I'm just taking the images from one and putting into the other, I 
could 
do that.  I just didn't like the idea of making new screenshots, using my 
theme. 
Although, at least the images I've looked at so far, already have English names.

Hhmm  Hopefully Sylvain can answer the questions I asked about the work 
that 
has been done to date. (in a different message) 
(https://sourceforge.net/p/inkscape/mailman/message/35828296/)  Could I be 
looking at the wrong documents?  Besides different chapters, I'm seeing vastly 
different content between the French and the translated English.  It's not just 
translated, it appears to be entirely rewritten, and also using completely 
different images!

I might think I was mistakenly looking at the original Inkscape Floss Manual, 
except both of the ones I'm looking are on the fr subdomain.  Let's get this 
straightened out, so I'm working on the right documents.  So using "L'outil 
Sélecteur", which is Selection Tool, right?  To me, this page:

https://fr.flossmanuals.net/start-with-inkscape/select-tool/

is not just a translation of

https://fr.flossmanuals.net/inkscape/selector-tool-a/

I certainly don't mind editing the pages that are already translated, to put 
the 
same images from the French manual, but I'd have to make major text edits too. 
(Or we, or whomever.)

Surely one of the 2 I'm looking at is the wrong one?


Re: "silly idea"  Some comments.

-- Not so silly.
-- Since we already do have the technical style of manual, outdated though it 
may be, I would suggest getting the new one finished and published first.
-- Perhaps Tav would consider releasing the content of his current manual, to 
be 
used as a starting point for the technical one?
-- Likely certain people would be better suited for writing this more technical 
one.  I know for myself, I couldn't write it, no matter how hard I tried.  
Often 
I find myself writing in simple language, even when I know the reader doesn't 
need it simplified.  Must be in my DNA, haha.
-- I wonder if having 2 manuals would be confusing for users?  I think as long 
as the titles of the manuals makes it very clear, it would be ok.  Such as 
Introduction to Inkscape for the beginnners' manual or Technical Inkscape 
Manual 
for the other.  Something like that.  (And also make sure the URLs include the 
distinction, so searching isn't confusing either.)


> (btw. I have volunteered to set this up, seems you overlooked ;-) - for
customization, translation and version branches, I'd still have to learn
a bit, but it doesn't appear to be too hard).

No, I read it.  But since I was "voting" for the Booktype option, I didn't have 
any reason to make a comment about setting up the Sphinx option.

I sincerely hope I have a wrong manual that I'm looking at, and that we don't 
have a serious problem with the translation being not strictly a translation!

Somewhat random thought.  I guess both Floss Manuals and Booktypes can be 
themed 
or branded?  Perhaps at some time during this manual-translating and then 
writing process, the community can have a discussion about Inkscape branding? 
I'm not sure if we can say it's overdue, but I would suggest that the time has 
come  :-)

All best,
brynn

-Original Message- 
From: Maren Hachmann
Sent: Wednesday, May 10, 2017 5:07 PM
To: brynn ; C R ; Inkscape Devel List ; Inkscape-Docs
Subject: Re: [Inkscape-devel] Any chance we can make some docs material? 
(targeting the moon)

@jazznico: Is there a way to transfer books between the French
flossmanuals site and the English one? I.e. would it be possible to
export and import a book? Or would it be possible to have a language
selection menu on flossmanualsfr instead, with English available for
selection? This would make it easier for our international editors to
deal with the interface.

Hi Brynn,

thanks for taking a closer look! (I'm so glad someone was able to take
the time for this.)

FLOSS is the abbreviation for 'Free/Libre Open Source Software'.
The websites are flossmanualsfr.net / flossmanuals.net respectively.
They allow for collaborative writing of manuals for FLOSS.

I fully understand the need for a WYSIWYG editor. The one from Booktype
is quite okay. Where it lacks is when you want to insert a file or image
- because you need to upload it first, then you need to find out that
the link to it that you need to enter in the insertion dialog is
'/static/filename.ext'. That's more difficult than it would need to be
(but you can use the same image file on different pages this way).

(Btw. what d

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Hi Elisa,

thank you very much for asking the flossmanuals.net manager!
Would you keep us updated on whether it works or not?

Kind Regards,
 Maren

Am 11.05.2017 um 16:09 schrieb Elisa Godoy de Castro Guerra:
> Hello,
> 
> Mick Is the manager of floss manuals english.
> I ask him for the possibility of import the book.
> I give him the url, he is trying.
> 
> Regards,
> Elisa
> 
> 2017-05-11 1:07 GMT+02:00 Maren Hachmann  >:
> 
> @jazznico: Is there a way to transfer books between the French
> flossmanuals site and the English one? I.e. would it be possible to
> export and import a book? Or would it be possible to have a language
> selection menu on flossmanualsfr instead, with English available for
> selection? This would make it easier for our international editors to
> deal with the interface.
> 
> Hi Brynn,
> 
> thanks for taking a closer look! (I'm so glad someone was able to take
> the time for this.)
> 
> FLOSS is the abbreviation for 'Free/Libre Open Source Software'.
> The websites are flossmanualsfr.net  /
> flossmanuals.net  respectively.
> They allow for collaborative writing of manuals for FLOSS.
> 
> I fully understand the need for a WYSIWYG editor. The one from Booktype
> is quite okay. Where it lacks is when you want to insert a file or image
> - because you need to upload it first, then you need to find out that
> the link to it that you need to enter in the insertion dialog is
> '/static/filename.ext'. That's more difficult than it would need to be
> (but you can use the same image file on different pages this way).
> 
> (Btw. what do you think of helping with the translation by making sure
> that all images get uploaded? When I copy-paste from the French book, I
> get all the images, but they are just links to the original book, not
> part of the one I'm editing. And it takes quite some time to rename the
> files to something English,  upload, add a useful placeholder text and
> then exchange the links. I'd prefer to spend that time on translating.)
> 
> About the 'location', I've had this silly idea:
> 
> As a first step, we create/translate/update this introductory manual at
> flossmanuals (if possible at the English site, to make it easier for
> contributors). It's a great way for getting people started with
> Inkscape.
> 
> As a second step, or in parallel, we could also have a more
> glossary-like, more technical manual, that explains what each menu item
> /LPE/... does. This technical manual could also be used by developers to
> document their changes, and it could use the more technical style with
> Sphinx/reST/readthedocs. It could even start out simple, with keywords /
> lists, and be refined by people who don't like those ;-)
> 
> (btw. I have volunteered to set this up, seems you overlooked ;-) - for
> customization, translation and version branches, I'd still have to learn
> a bit, but it doesn't appear to be too hard).
> 
> The one issue I see with this split is that it would spread resources
> (us) a bit wide, maybe. But from the time when I started using Inkscape,
> I know that having a manual like the one Elisa wrote would have helped
> me a lot - I barely understood a word in Tav's manual.
> 
> Now, as an advanced user, I (claim I) know everything that Elisa
> explains, but Tav's more technical manual contains so much more info,
> which I'm now able to understand (and often have the urge to update).
> 
> So that's why I think that having two different manuals wouldn't be such
> a bad idea. The technical manual could be written by the more technical
> users and, hopefully, devs (when they change something).
> 
> Well, just an idea. Let me know if you think it's crap ;-)
> 
> Kind Regards,
>  Maren
> 
> Am 10.05.2017 um 07:47 schrieb brynn:
> > Hi Everyone,
> >I've tried to read up and study and understand the info which
> > Maren presented.  Because my understanding is extremely limited, I
> > hesitate to offer any comments at all.  But for whatever it might be
> > worth, here they arealong with a couple of questions.
> >
> >First, one of your last comments:
> >
> >> All of them would be FLOSS, have support for internal linking,
> allow to
> > insert images and allow editing via browser.
> >
> >I think you're using "FLOSS" as a generic umbrella term, as
> > opposed to the FLOSS Manuals, right?  Because a couple of the Cons are
> > lack of wysiwyg, which I've had the understanding Floss Manuals has
> > (although I haven't seen it yet).  So you don't mean that Floss
> Manuals
> > can be used for the writing, for all of them, and then exported out or
> > transfered elsewhere for pu

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Elisa Godoy de Castro Guerra]

Hello,

Mick Is the manager of floss manuals english.
I ask him for the possibility of import the book.
I give him the url, he is trying.

Regards,
Elisa

2017-05-11 1:07 GMT+02:00 Maren Hachmann :

> @jazznico: Is there a way to transfer books between the French
> flossmanuals site and the English one? I.e. would it be possible to
> export and import a book? Or would it be possible to have a language
> selection menu on flossmanualsfr instead, with English available for
> selection? This would make it easier for our international editors to
> deal with the interface.
>
> Hi Brynn,
>
> thanks for taking a closer look! (I'm so glad someone was able to take
> the time for this.)
>
> FLOSS is the abbreviation for 'Free/Libre Open Source Software'.
> The websites are flossmanualsfr.net / flossmanuals.net respectively.
> They allow for collaborative writing of manuals for FLOSS.
>
> I fully understand the need for a WYSIWYG editor. The one from Booktype
> is quite okay. Where it lacks is when you want to insert a file or image
> - because you need to upload it first, then you need to find out that
> the link to it that you need to enter in the insertion dialog is
> '/static/filename.ext'. That's more difficult than it would need to be
> (but you can use the same image file on different pages this way).
>
> (Btw. what do you think of helping with the translation by making sure
> that all images get uploaded? When I copy-paste from the French book, I
> get all the images, but they are just links to the original book, not
> part of the one I'm editing. And it takes quite some time to rename the
> files to something English,  upload, add a useful placeholder text and
> then exchange the links. I'd prefer to spend that time on translating.)
>
> About the 'location', I've had this silly idea:
>
> As a first step, we create/translate/update this introductory manual at
> flossmanuals (if possible at the English site, to make it easier for
> contributors). It's a great way for getting people started with Inkscape.
>
> As a second step, or in parallel, we could also have a more
> glossary-like, more technical manual, that explains what each menu item
> /LPE/... does. This technical manual could also be used by developers to
> document their changes, and it could use the more technical style with
> Sphinx/reST/readthedocs. It could even start out simple, with keywords /
> lists, and be refined by people who don't like those ;-)
>
> (btw. I have volunteered to set this up, seems you overlooked ;-) - for
> customization, translation and version branches, I'd still have to learn
> a bit, but it doesn't appear to be too hard).
>
> The one issue I see with this split is that it would spread resources
> (us) a bit wide, maybe. But from the time when I started using Inkscape,
> I know that having a manual like the one Elisa wrote would have helped
> me a lot - I barely understood a word in Tav's manual.
>
> Now, as an advanced user, I (claim I) know everything that Elisa
> explains, but Tav's more technical manual contains so much more info,
> which I'm now able to understand (and often have the urge to update).
>
> So that's why I think that having two different manuals wouldn't be such
> a bad idea. The technical manual could be written by the more technical
> users and, hopefully, devs (when they change something).
>
> Well, just an idea. Let me know if you think it's crap ;-)
>
> Kind Regards,
>  Maren
>
> Am 10.05.2017 um 07:47 schrieb brynn:
> > Hi Everyone,
> >I've tried to read up and study and understand the info which
> > Maren presented.  Because my understanding is extremely limited, I
> > hesitate to offer any comments at all.  But for whatever it might be
> > worth, here they arealong with a couple of questions.
> >
> >First, one of your last comments:
> >
> >> All of them would be FLOSS, have support for internal linking, allow to
> > insert images and allow editing via browser.
> >
> >I think you're using "FLOSS" as a generic umbrella term, as
> > opposed to the FLOSS Manuals, right?  Because a couple of the Cons are
> > lack of wysiwyg, which I've had the understanding Floss Manuals has
> > (although I haven't seen it yet).  So you don't mean that Floss Manuals
> > can be used for the writing, for all of them, and then exported out or
> > transfered elsewhere for publishing, right?
> >
> > Gitlab Wiki + X
> > It seems to me like the lack of a wysiwyg editor is the most limiting
> > factor (at least for as much as I understand). I'm just thinking of
> > people who might be interested in joining the manual or documentation
> > team.  This is a good non-coding opportunity for non-programmers, to
> > contribute to the project.  They might be less likely to participate if
> > they had to learn, even a simple language like Markdown, or whatever you
> > call the code that wikis use.
> >
> > Gitlab Editor + Sphinx / readthedocs
> >
> >> - learning curve for admin (theming, plugins,...)
> >
> 

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

@jazznico: Is there a way to transfer books between the French
flossmanuals site and the English one? I.e. would it be possible to
export and import a book? Or would it be possible to have a language
selection menu on flossmanualsfr instead, with English available for
selection? This would make it easier for our international editors to
deal with the interface.

Hi Brynn,

thanks for taking a closer look! (I'm so glad someone was able to take
the time for this.)

FLOSS is the abbreviation for 'Free/Libre Open Source Software'.
The websites are flossmanualsfr.net / flossmanuals.net respectively.
They allow for collaborative writing of manuals for FLOSS.

I fully understand the need for a WYSIWYG editor. The one from Booktype
is quite okay. Where it lacks is when you want to insert a file or image
- because you need to upload it first, then you need to find out that
the link to it that you need to enter in the insertion dialog is
'/static/filename.ext'. That's more difficult than it would need to be
(but you can use the same image file on different pages this way).

(Btw. what do you think of helping with the translation by making sure
that all images get uploaded? When I copy-paste from the French book, I
get all the images, but they are just links to the original book, not
part of the one I'm editing. And it takes quite some time to rename the
files to something English,  upload, add a useful placeholder text and
then exchange the links. I'd prefer to spend that time on translating.)

About the 'location', I've had this silly idea:

As a first step, we create/translate/update this introductory manual at
flossmanuals (if possible at the English site, to make it easier for
contributors). It's a great way for getting people started with Inkscape.

As a second step, or in parallel, we could also have a more
glossary-like, more technical manual, that explains what each menu item
/LPE/... does. This technical manual could also be used by developers to
document their changes, and it could use the more technical style with
Sphinx/reST/readthedocs. It could even start out simple, with keywords /
lists, and be refined by people who don't like those ;-)

(btw. I have volunteered to set this up, seems you overlooked ;-) - for
customization, translation and version branches, I'd still have to learn
a bit, but it doesn't appear to be too hard).

The one issue I see with this split is that it would spread resources
(us) a bit wide, maybe. But from the time when I started using Inkscape,
I know that having a manual like the one Elisa wrote would have helped
me a lot - I barely understood a word in Tav's manual.

Now, as an advanced user, I (claim I) know everything that Elisa
explains, but Tav's more technical manual contains so much more info,
which I'm now able to understand (and often have the urge to update).

So that's why I think that having two different manuals wouldn't be such
a bad idea. The technical manual could be written by the more technical
users and, hopefully, devs (when they change something).

Well, just an idea. Let me know if you think it's crap ;-)

Kind Regards,
 Maren

Am 10.05.2017 um 07:47 schrieb brynn:
> Hi Everyone,
>I've tried to read up and study and understand the info which
> Maren presented.  Because my understanding is extremely limited, I
> hesitate to offer any comments at all.  But for whatever it might be
> worth, here they arealong with a couple of questions.
> 
>First, one of your last comments:
> 
>> All of them would be FLOSS, have support for internal linking, allow to
> insert images and allow editing via browser.
> 
>I think you're using "FLOSS" as a generic umbrella term, as
> opposed to the FLOSS Manuals, right?  Because a couple of the Cons are
> lack of wysiwyg, which I've had the understanding Floss Manuals has
> (although I haven't seen it yet).  So you don't mean that Floss Manuals
> can be used for the writing, for all of them, and then exported out or
> transfered elsewhere for publishing, right?
> 
> Gitlab Wiki + X
> It seems to me like the lack of a wysiwyg editor is the most limiting
> factor (at least for as much as I understand). I'm just thinking of
> people who might be interested in joining the manual or documentation
> team.  This is a good non-coding opportunity for non-programmers, to
> contribute to the project.  They might be less likely to participate if
> they had to learn, even a simple language like Markdown, or whatever you
> call the code that wikis use.
> 
> Gitlab Editor + Sphinx / readthedocs
> 
>> - learning curve for admin (theming, plugins,...)
> 
> You must mean that someone else besides Martin would be the admin for
> the manual project?  Or, as admin for the gitlab account, is there
> something about this option that he would need to learn still?
> 
> All the pros for this option make it sound so good (at least what I can
> understand).  But still no wysiwyg editor.  I still think that might
> scare away some p

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

Hi Everyone,
I've tried to read up and study and understand the info which Maren 
presented.  Because my understanding is extremely limited, I hesitate to offer 
any comments at all.  But for whatever it might be worth, here they 
arealong 
with a couple of questions.

First, one of your last comments:

> All of them would be FLOSS, have support for internal linking, allow to
insert images and allow editing via browser.

I think you're using "FLOSS" as a generic umbrella term, as opposed to 
the FLOSS Manuals, right?  Because a couple of the Cons are lack of wysiwyg, 
which I've had the understanding Floss Manuals has (although I haven't seen it 
yet).  So you don't mean that Floss Manuals can be used for the writing, for 
all 
of them, and then exported out or transfered elsewhere for publishing, right?

Gitlab Wiki + X
It seems to me like the lack of a wysiwyg editor is the most limiting factor 
(at 
least for as much as I understand). I'm just thinking of people who might be 
interested in joining the manual or documentation team.  This is a good 
non-coding opportunity for non-programmers, to contribute to the project.  They 
might be less likely to participate if they had to learn, even a simple 
language 
like Markdown, or whatever you call the code that wikis use.

Gitlab Editor + Sphinx / readthedocs

> - learning curve for admin (theming, plugins,...)

You must mean that someone else besides Martin would be the admin for the 
manual 
project?  Or, as admin for the gitlab account, is there something about this 
option that he would need to learn still?

All the pros for this option make it sound so good (at least what I can 
understand).  But still no wysiwyg editor.  I still think that might scare away 
some potential contributors.

Booktype

So far, this sounds like the best option to me.

Gitbook

The 5 contributor limit for free hosting sounds untennable to me.

So based on my feeble understanding of all this, I'd vote for Booktype.

All best,
brynn


-Original Message- 
From: Maren Hachmann
Sent: Tuesday, May 02, 2017 5:59 PM
To: C R ; Inkscape Devel List ; Inkscape-Docs
Subject: Re: [Inkscape-devel] Any chance we can make some docs material?
(targeting the moon)

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 o

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Am 08.05.2017 um 13:13 schrieb brynn:
> Oh, thank you so much for explaining it!  Well I'll get subscribed on
> FLOSS and give the editing a test.
> 
> And I'll also read through your notes now, and share comments about the
> other options, if I have any that are different from yours.
> 
>> However, it lacks some features that
> would be very useful for us, e.g. customization, versioning with undo,
> support for different software versions and languages.
> 
> Versioning?  I thought the whole point of a manual which the community
> can maintain, would be to have A manual, which is theoretically always
> being edited (although more around Inkscape release times) and always up
> to date.  Do you mean that if people wanted to print as an ebook or
> download  PDF, those would have versions?

- I mean that we need to have a way to prepare a manual for the next
release, while not showing those changes in the one that is publicly
available. So, e.g. the fillet/chamfer lpe doesn't need to be explained
in the manual for 0.91. Screenshots will also look different.

But we may want to have the newer version ready on release, so it could
be included with the software (long-term goal, not achievable for the
next couple of versions at least, I think).

Also, as we both know, people may use different versions, and will not
want to read the wrong instructions.

> Languages?  It seems like FLOSS does provide support for, well, at least
> 2 different languages, case in point, the French version which is being
> translated.  Do you mean some kind of automatic translation?

- No, I mean that I would like to have multiple languages in one place,
not in two completely separate places, as it is with Booktype. This is
so they could share screenshots, and images. Chapters that are not
translated will have a fallback in English.

So partial translations would also make sense, and the untranslated
parts would always be kept in sync with the English ones (because they
*are* the English ones, which are shown when a translation of that file
is missing).

Take a look at the django documentation to see how it's organized. You
can select different language and program versions there in the
overlayed numbers at the bottom right:
https://docs.djangoproject.com/en/1.10/topics/i18n/translation/

Maren

> Thanks again,
> brynn
> 
> 
> -Original Message- From: Maren Hachmann
> Sent: Sunday, May 07, 2017 2:54 PM
> To: brynn ; C R ; Inkscape Devel List ; Inkscape-Docs
> Subject: Re: [Inkscape-devel] Any chance we can make some docs material?
> (targeting the moon)
> 
> Am 05.05.2017 um 16:04 schrieb brynn:
>> Hi Maren and all,
>>I appreciate your research into, and review of.well I don't
>> even understand what this is.
>>
>>Could someone give me a simple explanation?  I'm still thinking
>> "translate French FLOSS manual" and then update and expand the
>> translation as a FLOSS doc.  I don't think we should abandon that, after
>> all the work that Sylvain and Hineringi have put in.  Not to forget the
>> French team too.
> 
> - Yes, that would be one of the options (the last one in the list I
> posted).
> But there are more ways to write documentation, especially if you're
> dealing with maintaining different versions of the software (and thus
> the manual) in parallel, and different languages.
> 
> I'm not suggesting abandoning that book. On the contrary, yesterday I've
> translated one more short chapter (and found the editor to be less
> comfortable than the one we have on our django website, esp. for
> inserting files/pictures), and I've just sent out a private email to
> Hinerangi, because I think she might not be listening here currently,
> but we'd need her consent for a licence change from GPL (which is
> generally deemed unsuitable for documentation) to a CC licence.
> 
> But it would be entirely possible to manage the book's contents on a
> different website, using a different system.
> 
>>Are we moving away from FLOSS because of its license?  This is a
>> fine point which I don't get.  Could someone make this simple for me,
>> too?
> 
> - No, the licence discussion is not related to the discussion about
> finding a suitable editing platform.
> 
> The website where the book lives currently, flossmanualsfr.com, is a
> fine website for writing books. However, it lacks some features that
> would be very useful for us, e.g. customization, versioning with undo,
> support for different software versions and languages.
> 
> Likewise, the other suggested platforms lack features (especially in
> contributor-usability), and there exist other platforms that people may
> know about.
> 
> I was hoping to get some input on what is more important to people. To
> me as someone who would probably be working on the more organizational
> side, the frontend doesn't matter so much. I'm used to doing my editing
> in a text editor, and to use a preview. I'm also used to
> installing/running software on my computer, for testin

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

Oh, thank you so much for explaining it!  Well I'll get subscribed on FLOSS and 
give the editing a test.

And I'll also read through your notes now, and share comments about the other 
options, if I have any that are different from yours.

> However, it lacks some features that
would be very useful for us, e.g. customization, versioning with undo,
support for different software versions and languages.

Versioning?  I thought the whole point of a manual which the community can 
maintain, would be to have A manual, which is theoretically always being edited 
(although more around Inkscape release times) and always up to date.  Do you 
mean that if people wanted to print as an ebook or download  PDF, those would 
have versions?

Languages?  It seems like FLOSS does provide support for, well, at least 2 
different languages, case in point, the French version which is being 
translated.  Do you mean some kind of automatic translation?

Thanks again,
brynn


-Original Message- 
From: Maren Hachmann
Sent: Sunday, May 07, 2017 2:54 PM
To: brynn ; C R ; Inkscape Devel List ; Inkscape-Docs
Subject: Re: [Inkscape-devel] Any chance we can make some docs material? 
(targeting the moon)

Am 05.05.2017 um 16:04 schrieb brynn:
> Hi Maren and all,
>I appreciate your research into, and review of.well I don't
> even understand what this is.
>
>Could someone give me a simple explanation?  I'm still thinking
> "translate French FLOSS manual" and then update and expand the
> translation as a FLOSS doc.  I don't think we should abandon that, after
> all the work that Sylvain and Hineringi have put in.  Not to forget the
> French team too.

- Yes, that would be one of the options (the last one in the list I posted).
But there are more ways to write documentation, especially if you're
dealing with maintaining different versions of the software (and thus
the manual) in parallel, and different languages.

I'm not suggesting abandoning that book. On the contrary, yesterday I've
translated one more short chapter (and found the editor to be less
comfortable than the one we have on our django website, esp. for
inserting files/pictures), and I've just sent out a private email to
Hinerangi, because I think she might not be listening here currently,
but we'd need her consent for a licence change from GPL (which is
generally deemed unsuitable for documentation) to a CC licence.

But it would be entirely possible to manage the book's contents on a
different website, using a different system.

>Are we moving away from FLOSS because of its license?  This is a
> fine point which I don't get.  Could someone make this simple for me, too?

- No, the licence discussion is not related to the discussion about
finding a suitable editing platform.

The website where the book lives currently, flossmanualsfr.com, is a
fine website for writing books. However, it lacks some features that
would be very useful for us, e.g. customization, versioning with undo,
support for different software versions and languages.

Likewise, the other suggested platforms lack features (especially in
contributor-usability), and there exist other platforms that people may
know about.

I was hoping to get some input on what is more important to people. To
me as someone who would probably be working on the more organizational
side, the frontend doesn't matter so much. I'm used to doing my editing
in a text editor, and to use a preview. I'm also used to
installing/running software on my computer, for testing my edits locally
(which wouldn't be mandatory, though - a website that allows to edit the
texts is available for each of the items on the list). What matters to
me is that it is easy to have multiple versions and translations
available, and to be able to automate the process. Also, to allow people
who aren't involved in the project yet to do quick edits and request
their inclusion into the manual. And to have a highly customizable
output - concerning output formats (ebook formats, html, pdf, maybe even
an 'app'), and styling of those (which I think CR might enjoy).

But I know that many of the possible editors might be afraid of the
gitlab workflow, and I wanted people to be able to take a look at the
different options.

I've got one more platform to add to the list (as 'looked at, I'd
discourage usage'):

***

Gitbook

WHAT: node.js-based modern toolchain to build docs from
markdown/Asciidoc (locally installable version available) - disclaimer:
didn't test, only read.

PROS:
- comes with an editor that is graphical, and integrates support for
the version control part, so users do not need to worry about learning
git or finding their way around the git**b user interfaces.
- includes support for multiple language versions
- customizable templates / themes
- free hosting available

CONS:
- the above mentioned editor is proprietary. There exists a
no-longer-in-development open source legacy version.
- free h

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Am 05.05.2017 um 16:04 schrieb brynn:
> Hi Maren and all,
>I appreciate your research into, and review of.well I don't
> even understand what this is.
> 
>Could someone give me a simple explanation?  I'm still thinking
> "translate French FLOSS manual" and then update and expand the
> translation as a FLOSS doc.  I don't think we should abandon that, after
> all the work that Sylvain and Hineringi have put in.  Not to forget the
> French team too.

- Yes, that would be one of the options (the last one in the list I posted).
But there are more ways to write documentation, especially if you're
dealing with maintaining different versions of the software (and thus
the manual) in parallel, and different languages.

I'm not suggesting abandoning that book. On the contrary, yesterday I've
translated one more short chapter (and found the editor to be less
comfortable than the one we have on our django website, esp. for
inserting files/pictures), and I've just sent out a private email to
Hinerangi, because I think she might not be listening here currently,
but we'd need her consent for a licence change from GPL (which is
generally deemed unsuitable for documentation) to a CC licence.

But it would be entirely possible to manage the book's contents on a
different website, using a different system.

>Are we moving away from FLOSS because of its license?  This is a
> fine point which I don't get.  Could someone make this simple for me, too?

- No, the licence discussion is not related to the discussion about
finding a suitable editing platform.

The website where the book lives currently, flossmanualsfr.com, is a
fine website for writing books. However, it lacks some features that
would be very useful for us, e.g. customization, versioning with undo,
support for different software versions and languages.

Likewise, the other suggested platforms lack features (especially in
contributor-usability), and there exist other platforms that people may
know about.

I was hoping to get some input on what is more important to people. To
me as someone who would probably be working on the more organizational
side, the frontend doesn't matter so much. I'm used to doing my editing
in a text editor, and to use a preview. I'm also used to
installing/running software on my computer, for testing my edits locally
(which wouldn't be mandatory, though - a website that allows to edit the
texts is available for each of the items on the list). What matters to
me is that it is easy to have multiple versions and translations
available, and to be able to automate the process. Also, to allow people
who aren't involved in the project yet to do quick edits and request
their inclusion into the manual. And to have a highly customizable
output - concerning output formats (ebook formats, html, pdf, maybe even
an 'app'), and styling of those (which I think CR might enjoy).

But I know that many of the possible editors might be afraid of the
gitlab workflow, and I wanted people to be able to take a look at the
different options.

I've got one more platform to add to the list (as 'looked at, I'd
discourage usage'):

***

Gitbook

WHAT: node.js-based modern toolchain to build docs from
markdown/Asciidoc (locally installable version available) - disclaimer:
didn't test, only read.

PROS:
- comes with an editor that is graphical, and integrates support for
the version control part, so users do not need to worry about learning
git or finding their way around the git**b user interfaces.
- includes support for multiple language versions
- customizable templates / themes
- free hosting available

CONS:
- the above mentioned editor is proprietary. There exists a
no-longer-in-development open source legacy version.
- free hosting limited to 5 contributors
- all in all (if you take away the limited hosting and the non-free
editor) similar to the readthedocs version, but building on a system I
wouldn't be able to deal with, userbase / maturity is probably a lot
smaller/less than the one of readthedocs/sphinx.

Homepage: https://www.gitbook.com/
Source repo example: https://github.com/GitbookIO/gitbook/tree/master/docs
Example web page:
https://www.gitbook.com/book/frontendmasters/front-end-handbook/details



Kind Regards,
 Maren

> Thanks,
> brynn
> 
> -Original Message- From: Maren Hachmann
> Sent: Tuesday, May 02, 2017 5:59 PM
> To: C R ; Inkscape Devel List ; Inkscape-Docs
> Subject: Re: [Inkscape-devel] Any chance we can make some docs material?
> (targeting the moon)
> 
> 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 

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Martin Owens]

On Fri, 2017-05-05 at 08:12 -0600, brynn wrote:
> I don't understand the first thing you described, about something
> build and translate svg.  But "the SVG screenshots program" caught my
> attention.  What is that?

It's a way of taking a screenshot, where instead of getting a png with
a flat canvas of pixels, you get an svg, with boxes and text where they
appeared on the screen.

It only works for Gtk3 apps, so inskcape 0.91, gimp, anything written
for Qt, windows programs and Firefox all wouldn't work. (although there
are browser screenshot programs for that)

I suspect that such a venture would be fraught with niggles like menus,
spacing, default icon themes and so on. So I put it on the back burner.
But an interesting idea if anyone else is excited by it.

Best Regards, Martin Owens

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

I'd be ALL for standardized screenshots.  Otherwise, we'd be depending on only 
certain people who have a nice display, to do it.  And preferably, the exact 
same display, throughout the manual.

I don't understand the first thing you described, about something build and 
translate svg.  But "the SVG screenshots program" caught my attention.  What is 
that?

brynn

-Original Message- 
From: Martin Owens
Sent: Tuesday, May 02, 2017 12:36 PM
To: Maren Hachmann ; brynn ; C R
Cc: Inkscape-Devel ; Inkscape-Docs
Subject: Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs 
material? (targeting the moon)

On Tue, 2017-05-02 at 20:29 +0200, Maren Hachmann wrote:
>
> > If it needs screenshots that are close up, showing a drawing, I
> could do
> > that. But anything showing dialogs, it would not be a good idea,
> imo.
> >
> > But I'll have a go at using a translator.  And if I see any places
> where
> > I can make a screenshot ready, I'll do that too.
> >
>
> - Sounds great :) Thank you, Brynn!

I was thinking of something a little bit mad. Taking screenshots of our
gtk3 inkscape build using the svg screenshots program. Seeing if we
could standardise the size and look of any of our screenshots and maybe
even translate the svg instead of the app each time.

But so far that's just a whistful thought.

Martin, 


--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

Hi Maren and all,
I appreciate your research into, and review of.well I don't even 
understand what this is.

Could someone give me a simple explanation?  I'm still thinking 
"translate French FLOSS manual" and then update and expand the translation as a 
FLOSS doc.  I don't think we should abandon that, after all the work that 
Sylvain and Hineringi have put in.  Not to forget the French team too.

Are we moving away from FLOSS because of its license?  This is a fine 
point which I don't get.  Could someone make this simple for me, too?

Thanks,
brynn

-Original Message- 
From: Maren Hachmann
Sent: Tuesday, May 02, 2017 5:59 PM
To: C R ; Inkscape Devel List ; Inkscape-Docs
Subject: Re: [Inkscape-devel] Any chance we can make some docs material? 
(targeting the moon)

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 diff

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Victor Westmann]

Ok everyone,

So since we are elaborating a LOT on this matter let's hope we can define a
couple of things for us to be able to take action as soon as this is
decided.

If you all want to go crazy on this topic these is an amazing link that
shows the most used licenses: https://choosealicense.com/appendix/

This could be useful. My vote is for CC 0 (Public Domain).



--Victor Westmann

2017-05-02 17:13 GMT-07:00 Victor Westmann :

> Hi Martin, that is indeed a MAD idea! But a quite attractive one!
>
> Keep me posted if this gets off the ground.
>
>
>
> --Victor Westmann
>
> 2017-05-02 11:36 GMT-07:00 Martin Owens :
>
>> On Tue, 2017-05-02 at 20:29 +0200, Maren Hachmann wrote:
>> >
>> > > If it needs screenshots that are close up, showing a drawing, I
>> > could do
>> > > that. But anything showing dialogs, it would not be a good idea,
>> > imo.
>> > >
>> > > But I'll have a go at using a translator.  And if I see any places
>> > where
>> > > I can make a screenshot ready, I'll do that too.
>> > >
>> >
>> > - Sounds great :) Thank you, Brynn!
>>
>> I was thinking of something a little bit mad. Taking screenshots of our
>> gtk3 inkscape build using the svg screenshots program. Seeing if we
>> could standardise the size and look of any of our screenshots and maybe
>> even translate the svg instead of the app each time.
>>
>> But so far that's just a whistful thought.
>>
>> Martin,
>>
>> 
>> --
>> 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@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/inkscape-docs
>>
>
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Victor Westmann]

Hi Martin, that is indeed a MAD idea! But a quite attractive one!

Keep me posted if this gets off the ground.



--Victor Westmann

2017-05-02 11:36 GMT-07:00 Martin Owens :

> On Tue, 2017-05-02 at 20:29 +0200, Maren Hachmann wrote:
> >
> > > If it needs screenshots that are close up, showing a drawing, I
> > could do
> > > that. But anything showing dialogs, it would not be a good idea,
> > imo.
> > >
> > > But I'll have a go at using a translator.  And if I see any places
> > where
> > > I can make a screenshot ready, I'll do that too.
> > >
> >
> > - Sounds great :) Thank you, Brynn!
>
> I was thinking of something a little bit mad. Taking screenshots of our
> gtk3 inkscape build using the svg screenshots program. Seeing if we
> could standardise the size and look of any of our screenshots and maybe
> even translate the svg instead of the app each time.
>
> But so far that's just a whistful thought.
>
> Martin,
>
> 
> --
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-docs
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

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

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Thanks again, Nicolas! Booktype 2.x (and its predecessor) definitely
looks nice, seems to be easy to use and to produce quality output.

I'm compiling a list of the different options atm. with pros and cons.

Maren

Am 01.05.2017 um 22:08 schrieb Nicolas Dufour:
> 
> Le Lundi 1 mai 2017 21h28, Maren Hachmann  a
> écrit :
>> - How does version control work for booktype? Could it be combined
>> with a git repository, or does it use a fully independent system? 
>> (I couldn't find a direct hint, maybe it's just using the django 
>> database to keep track of changes/edits?)
> 
> 
> As far as I can tell, everything (except the attached documents, e.g.
> images embedded in the chapters) is stored in a database. Each
> version of a chapter is stored with a revision number and can be
> compared with any other revision of the same chapter (the user
> interface looks like a wikimedia version history page). So I'm not
> sure using git to store the content (the database dump?) is a good
> idea here.
> 
>> - What is the source file format of booktype? Markdown? (guessing
>> from the requirements for pip)
> 
> 
> No, Booktype uses an online wysiwyg editor to edit the books and save
> the chapters in HTML directly.
> 
> Note that both the English and French Flossmanuals servers still use
> an old (1.6.1) Booktype version, and things may have changed in the
> new 2.x branch (officially launched last year).
> 
> Regards, -- Nicolas
> 


--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Martin Owens]

On Tue, 2017-05-02 at 20:29 +0200, Maren Hachmann wrote:
> 
> > If it needs screenshots that are close up, showing a drawing, I
> could do
> > that. But anything showing dialogs, it would not be a good idea,
> imo.
> > 
> > But I'll have a go at using a translator.  And if I see any places
> where
> > I can make a screenshot ready, I'll do that too.
> > 
> 
> - Sounds great :) Thank you, Brynn!

I was thinking of something a little bit mad. Taking screenshots of our
gtk3 inkscape build using the svg screenshots program. Seeing if we
could standardise the size and look of any of our screenshots and maybe
even translate the svg instead of the app each time.

But so far that's just a whistful thought.

Martin,

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Am 02.05.2017 um 09:13 schrieb brynn:
...

> If it needs screenshots that are close up, showing a drawing, I could do
> that. But anything showing dialogs, it would not be a good idea, imo.
> 
> But I'll have a go at using a translator.  And if I see any places where
> I can make a screenshot ready, I'll do that too.
> 

- Sounds great :) Thank you, Brynn!

Maren


> Sorry about getting the page wrong.  Not 2 minutes after I sent the
> message, I realized it was not the first page.  Oh well.
> 
> All best,
> brynn
> 
> -Original Message- From: Maren Hachmann
> Sent: Monday, May 01, 2017 5:06 AM
> To: brynn ; C R
> Cc: Inkscape-Devel ; Inkscape-Docs ; Victor Westmann
> Subject: Re: [Inkscape-devel] Any chance we can make some docs material?
> (targeting the moon)
> 
> Am 01.05.2017 um 07:19 schrieb brynn:
>>> @Brynn: if you want to help with the translation of that 'intro' book,
>> you could, for example, make corresponding screenshots for it, of the
>> English version. You could also get an account on that site, and explain
>> to others who speak both French and English how it works, and what they
>> would need to do to join. Or write a news article asking for translators
>> who would like to help.
>> Also, you could add a 'Credits' page at the end, which seems to be
>> missing still.
>> And, of course, you can proofread and edit. Sylvain has already
>> translated quite a bit.
>>
>> Thanks Maren.  I'll jump right in, as much as possible.  But I don't
>> understand this part:
>>
>> "make corresponding screenshots for it"
>>
>> Screenshots for what purpose?
> 
> - The English screenshots need to be made. The original book is in
> French and has French screenshots, with French menus and maybe example
> texts in French (don't know for sure), as far as I know. Some may not
> need any translation, because there may not be any words in them, but
> others will.
> 
> They could be inserted into the corresponding chapters, even if there is
> no text yet.
> 
>> Getting an account on FLOSS Manuals goes without saying, once the
>> translation is finished and we can go ahead updating and expanding.  But
>> I'll be in the same boat as potential new translators, for learning how
>> it works.  I won't be in a position to help newcomers, until I've had a
>> little experience myself.
>>
>> Credits page -- the first page gives all the credits.  Is something more
>> needed?
> 
> - Ah, yes, I've found it now, thanks. It's here:
> https://fr.flossmanuals.net/start-with-inkscape/about-this-book/ (not
> first page, though)
> 
> Maren
> 
>> Proofreading -- I've read several pages already, and the English is
>> flawless so far!  But before I go on, I'd like to hear if anyone else is
>> proofreading, so we don't waste our collective time.
>>
>> Actually, because of our previous discussions, I've been waiting for
>> Sylvain to let me know when something is ready for proofing.  I could
>> still do it anyway. But maybe I'll message him and ask.
>>
>> All best,
>> brynn
>>
>> -Original Message- From: Maren Hachmann
>> Sent: Saturday, April 29, 2017 4:29 PM
>> To: C R ; brynn
>> Cc: Inkscape-Devel ; Inkscape-Docs ; Victor Westmann
>> Subject: Re: [Inkscape-devel] Any chance we can make some docs material?
>> (targeting the moon)
>>
>> Hi all,
>>
>> oh, wow, I've just been offline for a couple of hours - wouldn't have
>> expected that, if finally someone gives the 'go' for a manual, there
>> would be such a huge echo (we've been discussing this on and off for a
>> /very/ long time already). That's just cool :D
>>
>> Just some comments to various things that were mentioned:
>>
>> @CR: I think Scribus is a great tool for making the kind of graphical,
>> polished, sellable, printable, book-with-columns-like structure which
>> was linked in that very first link. For something that is really nice to
>> look at, and is fun to read and touch.
>>
>> I also think this is not the same as a manual, which should be quick to
>> browse, quick to grasp, with lots of interlinks, with a file format
>> suitable for version control (well, yes, Scribus is xml, I've been told,
>> so it would be /readable/ - but those diffs are really ugly), with
>> out-of-the-box automated generation of online versions of a manual - as
>> can be done with tools like sphinx/readthedocs, doctype, and other tools
>> specifically tailored for open source documentation + gitlab CI.
>> You can take a look at the link from Victor's message to the mailing
>> list, if you would like to know more:
>> https://sourceforge.net/p/inkscape/mailman/message/35773618/
>>
>> Even the booktype server of flossmanuals works with automation.
>> Using one of those would also have the advantage that, once set up, this
>> system could be used for both developer as well as user documentation
>> (as Victor wrote in his post - and I agree with him).
>>
>> As for the attribution, I think especially the book-like structure would
>> profit from it, as I believe that artists may be mor

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

I don't know C R.

I'm stuck on copyright, because the link Victor gave in his original post 
showed 
an image of a hardback book.  Since I'm old and old fashioned, I naturally 
think 
a published hardback book probably has a copyright.  I do realize there are 
other kinds of  publishing.

I'm a little confused still, but I'm hoping Maren can clear it up soon.  First 
we were talking about this book of tutorials.  Then we realized that we should 
get this long awaited, much discussed, and pretty much direly needed manual off 
the ground.  For a minute, we were all on the same page.

Then for some reason, you and Maren and Martin were discussing about using the 
website's gitlab account for writing something - the manual? the book?  I don't 
know what you were discussing.  I remain confused on that point.  And part of 
that seems to involve some kind of license, whether public domain or other, I 
didn't catch that part.

Maren mentioned an idea she has for combining both projects, but hasn't had a 
lot of time lately.  But soon, hopefully she can clarify.

So that's where I'm coming from.

I see a manual as part of official documention ought to have an open license, 
if 
only to facilitate allowing anyone to make future edits, so we aren't held back 
by needing a single author to edit it.

But a published book of tutorials -- I see that as a money-making project of a 
single author or maybe small team, which could only have a copyright, to get 
published (the old-fashioned hardback way) and make sales.

As I said, I have a hard time seeing these 2 different projects married.  But I 
look forward to hearing Maren's idea.

All best,
brynn

-Original Message- 
From: C R
Sent: Tuesday, May 02, 2017 4:14 AM
To: brynn
Cc: Nicolas Dufour ; Maren Hachmann ; inkscape-devel ; Inkscape-Docs
Subject: Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs 
material? (targeting the moon)

Is anyone discussing a copyrighted book or manual at this point? If
so, let's not. It's Copyleft or Public Domain. No proprietary books or
content should be included in official Inkscape documentation. We need
to be able to freely revise, edit, distribute without the legal
entanglements.

-C

On Tue, May 2, 2017 at 8:28 AM, brynn  wrote:
>> - How does version control work for booktype?
>
>
> This question will probably make more sense when you make the next post you
> promised from a different message.  I had asked why we were talking about
> using gitlab and all that, if we were still focused on the FLOSS
> translation/manual. And you said you had an idea to present that you didn't
> have time at that moment.
>
> I can't really see a marriage of these 2 projects (free manual, copyrighted
> book of tutorials).  But I'm looking forward to hearing your proposal :-)
>
> All best,
> brynn
>
> -Original Message- From: Maren Hachmann
> Sent: Monday, May 01, 2017 1:28 PM
> To: Nicolas Dufour ; brynn ; C R
> Cc: inkscape-devel ; Inkscape-Docs
> Subject: Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some
> docs material? (targeting the moon)
>
>
> Hi Nicolas :D,
>
> thank you!
>
> What I would like to know (and what is now buried deep in the email
> stream) is:
>
> - How does version control work for booktype? Could it be combined with
> a git repository, or does it use a fully independent system?
> (I couldn't find a direct hint, maybe it's just using the django
> database to keep track of changes/edits?)
>
> - What is the source file format of booktype? Markdown? (guessing from
> the requirements for pip)
>
> Regards,
> Maren
>
> Am 01.05.2017 um 21:08 schrieb Nicolas Dufour:
>>
>> Hi all,
>>
>> I'm just back from two weeks away, and as the thread is very long now
>> I didn't find time to read everything. Sorry if I'm off-topic.
>>
>> Le Lundi 1 mai 2017 13h07, Maren Hachmann  a
>> écrit :
>>>
>>> I only wish Nicolas or Elisa could be here to give us some more
>>> in-depth
>>
>>
>>> info about their server's capabilities
>>
>>
>>
>> Not sure what you mean. Of course the Inkscape project can use the
>> French FM server for the translation, but note that an English
>> version also exists (http://write.flossmanuals.net/). It would
>> probably be easier to work on the English server directly.
>>
>>
>>> and their book's licencing.
>>
>>
>> If I remember correctly, the GPLv2 was the first license that was
>> chosen when the FM project was created about 10 years ago, and some
>> books still use it. But the server allows users to choose a diff

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

> - How does version control work for booktype?

This question will probably make more sense when you make the next post you 
promised from a different message.  I had asked why we were talking about using 
gitlab and all that, if we were still focused on the FLOSS translation/manual. 
And you said you had an idea to present that you didn't have time at that 
moment.

I can't really see a marriage of these 2 projects (free manual, copyrighted 
book 
of tutorials).  But I'm looking forward to hearing your proposal :-)

All best,
brynn

-Original Message- 
From: Maren Hachmann
Sent: Monday, May 01, 2017 1:28 PM
To: Nicolas Dufour ; brynn ; C R
Cc: inkscape-devel ; Inkscape-Docs
Subject: Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs 
material? (targeting the moon)

Hi Nicolas :D,

thank you!

What I would like to know (and what is now buried deep in the email
stream) is:

- How does version control work for booktype? Could it be combined with
a git repository, or does it use a fully independent system?
(I couldn't find a direct hint, maybe it's just using the django
database to keep track of changes/edits?)

- What is the source file format of booktype? Markdown? (guessing from
the requirements for pip)

Regards,
Maren

Am 01.05.2017 um 21:08 schrieb Nicolas Dufour:
> Hi all,
>
> I'm just back from two weeks away, and as the thread is very long now
> I didn't find time to read everything. Sorry if I'm off-topic.
>
> Le Lundi 1 mai 2017 13h07, Maren Hachmann  a
> écrit :
>> I only wish Nicolas or Elisa could be here to give us some more
>> in-depth
>
>> info about their server's capabilities
>
>
> Not sure what you mean. Of course the Inkscape project can use the
> French FM server for the translation, but note that an English
> version also exists (http://write.flossmanuals.net/). It would
> probably be easier to work on the English server directly.
>
>
>> and their book's licencing.
>
> If I remember correctly, the GPLv2 was the first license that was
> chosen when the FM project was created about 10 years ago, and some
> books still use it. But the server allows users to choose a different
> license when creating a new book (CC, GPL, PD). As for the Inkscape
> book, I see it's under a GPLv3. I don't know if it can be changed
> (and how) or not. Elisa could probably give more details.
>
> Regards, -- Nicolas
> 

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

Ooohhh, you mean the images, the graphics!  Now I understand!

I probably would not be the best perseon to do that, because I use an unusual 
theme color,  a flat color with no "aero", which is not particularly 
attractive. 
I use it because it's easy on my eyes.  But it would make the pages look so 
ugly!

If it needs screenshots that are close up, showing a drawing, I could do that. 
But anything showing dialogs, it would not be a good idea, imo.

But I'll have a go at using a translator.  And if I see any places where I can 
make a screenshot ready, I'll do that too.

Sorry about getting the page wrong.  Not 2 minutes after I sent the message, I 
realized it was not the first page.  Oh well.

All best,
brynn

-Original Message- 
From: Maren Hachmann
Sent: Monday, May 01, 2017 5:06 AM
To: brynn ; C R
Cc: Inkscape-Devel ; Inkscape-Docs ; Victor Westmann
Subject: Re: [Inkscape-devel] Any chance we can make some docs material? 
(targeting the moon)

Am 01.05.2017 um 07:19 schrieb brynn:
>> @Brynn: if you want to help with the translation of that 'intro' book,
> you could, for example, make corresponding screenshots for it, of the
> English version. You could also get an account on that site, and explain
> to others who speak both French and English how it works, and what they
> would need to do to join. Or write a news article asking for translators
> who would like to help.
> Also, you could add a 'Credits' page at the end, which seems to be
> missing still.
> And, of course, you can proofread and edit. Sylvain has already
> translated quite a bit.
>
> Thanks Maren.  I'll jump right in, as much as possible.  But I don't
> understand this part:
>
> "make corresponding screenshots for it"
>
> Screenshots for what purpose?

- The English screenshots need to be made. The original book is in
French and has French screenshots, with French menus and maybe example
texts in French (don't know for sure), as far as I know. Some may not
need any translation, because there may not be any words in them, but
others will.

They could be inserted into the corresponding chapters, even if there is
no text yet.

> Getting an account on FLOSS Manuals goes without saying, once the
> translation is finished and we can go ahead updating and expanding.  But
> I'll be in the same boat as potential new translators, for learning how
> it works.  I won't be in a position to help newcomers, until I've had a
> little experience myself.
>
> Credits page -- the first page gives all the credits.  Is something more
> needed?

- Ah, yes, I've found it now, thanks. It's here:
https://fr.flossmanuals.net/start-with-inkscape/about-this-book/ (not
first page, though)

Maren

> Proofreading -- I've read several pages already, and the English is
> flawless so far!  But before I go on, I'd like to hear if anyone else is
> proofreading, so we don't waste our collective time.
>
> Actually, because of our previous discussions, I've been waiting for
> Sylvain to let me know when something is ready for proofing.  I could
> still do it anyway. But maybe I'll message him and ask.
>
> All best,
> brynn
>
> -Original Message- From: Maren Hachmann
> Sent: Saturday, April 29, 2017 4:29 PM
> To: C R ; brynn
> Cc: Inkscape-Devel ; Inkscape-Docs ; Victor Westmann
> Subject: Re: [Inkscape-devel] Any chance we can make some docs material?
> (targeting the moon)
>
> Hi all,
>
> oh, wow, I've just been offline for a couple of hours - wouldn't have
> expected that, if finally someone gives the 'go' for a manual, there
> would be such a huge echo (we've been discussing this on and off for a
> /very/ long time already). That's just cool :D
>
> Just some comments to various things that were mentioned:
>
> @CR: I think Scribus is a great tool for making the kind of graphical,
> polished, sellable, printable, book-with-columns-like structure which
> was linked in that very first link. For something that is really nice to
> look at, and is fun to read and touch.
>
> I also think this is not the same as a manual, which should be quick to
> browse, quick to grasp, with lots of interlinks, with a file format
> suitable for version control (well, yes, Scribus is xml, I've been told,
> so it would be /readable/ - but those diffs are really ugly), with
> out-of-the-box automated generation of online versions of a manual - as
> can be done with tools like sphinx/readthedocs, doctype, and other tools
> specifically tailored for open source documentation + gitlab CI.
> You can take a look at the link from Victor's message to the mailing
> list, if you would like to know more:
> https://sourceforge.net/p/inkscape/mailman/message/35773618/
>
> Even the booktype server of flossmanuals works with automation.
> Using one of those would also have the advantage that, once set up, this
> system could be used for both developer as well as user documentation
> (as Victor wrote in his post - and I agree with him).
>
> As for the attribution, I think especially the book

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Nicolas Dufour]

Le Lundi 1 mai 2017 21h28, Maren Hachmann  a écrit :
> - How does version control work for booktype? Could it be combined with
> a git repository, or does it use a fully independent system?
> (I couldn't find a direct hint, maybe it's just using the django
> database to keep track of changes/edits?)


As far as I can tell, everything (except the attached documents, e.g. images 
embedded in the chapters) is stored in a database. Each version of a chapter is 
stored with a revision number and can be compared with any other revision of 
the same chapter (the user interface looks like a wikimedia version history 
page). So I'm not sure using git to store the content (the database dump?) is a 
good idea here.

> - What is the source file format of booktype? Markdown? (guessing from
> the requirements for pip)


No, Booktype uses an online wysiwyg editor to edit the books and save the 
chapters in HTML directly.

Note that both the English and French Flossmanuals servers still use an old 
(1.6.1) Booktype version, and things may have changed in the new 2.x branch 
(officially launched last year).

Regards,
--
Nicolas

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Hi Nicolas :D,

thank you!

What I would like to know (and what is now buried deep in the email
stream) is:

- How does version control work for booktype? Could it be combined with
a git repository, or does it use a fully independent system?
(I couldn't find a direct hint, maybe it's just using the django
database to keep track of changes/edits?)

- What is the source file format of booktype? Markdown? (guessing from
the requirements for pip)

Regards,
 Maren

Am 01.05.2017 um 21:08 schrieb Nicolas Dufour:
> Hi all,
> 
> I'm just back from two weeks away, and as the thread is very long now
> I didn't find time to read everything. Sorry if I'm off-topic.
> 
> Le Lundi 1 mai 2017 13h07, Maren Hachmann  a
> écrit :
>> I only wish Nicolas or Elisa could be here to give us some more
>> in-depth
> 
>> info about their server's capabilities
> 
> 
> Not sure what you mean. Of course the Inkscape project can use the
> French FM server for the translation, but note that an English
> version also exists (http://write.flossmanuals.net/). It would
> probably be easier to work on the English server directly.
> 
> 
>> and their book's licencing.
> 
> If I remember correctly, the GPLv2 was the first license that was
> chosen when the FM project was created about 10 years ago, and some
> books still use it. But the server allows users to choose a different
> license when creating a new book (CC, GPL, PD). As for the Inkscape
> book, I see it's under a GPLv3. I don't know if it can be changed
> (and how) or not. Elisa could probably give more details.
> 
> Regards, -- Nicolas
> 


--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Nicolas Dufour]

Hi all,

I'm just back from two weeks away, and as the thread is very long now I didn't 
find time to read everything. Sorry if I'm off-topic.

Le Lundi 1 mai 2017 13h07, Maren Hachmann  a écrit :
> I only wish Nicolas or Elisa could be here to give us some more in-depth

> info about their server's capabilities 


Not sure what you mean. Of course the Inkscape project can use the French FM 
server for the translation, but note that an English version also exists 
(http://write.flossmanuals.net/). It would probably be easier to work on the 
English server directly.


> and their book's licencing.

If I remember correctly, the GPLv2 was the first license that was chosen when 
the FM project was created about 10 years ago, and some books still use it. But 
the server allows users to choose a different license when creating a new book 
(CC, GPL, PD). As for the Inkscape book, I see it's under a GPLv3. I don't know 
if it can be changed (and how) or not. Elisa could probably give more details.

Regards,
--
Nicolas

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Am 01.05.2017 um 08:34 schrieb brynn:
>> I think google translate might cause more issues than solve them - but
> it has been getting better... I personally find that correcting a badly
> messed-up text which already gives me some 'scheme' tends to give worse
> translations, than when there is no scaffolding. It's because the
> machine translation is kind of giving the direction. It may be faster,
> but the translation sounds less natural.
> 
> No, I don't mean to leave it to where anyone would have a clue that any
> kind of automated translator was used.  I don't mean to paste in the
> translation, and make a couple of small edits.
> 
> What I mean is to use the translation just to give me an idea what's on
> that page.  Since I know Inkscape so well, I could write that page of
> the manual.  I can use pages which are already translated to keep the
> same format.

- Ah, yes. That's also what CR suggested, and it's a good idea :)

> And when I use google or bing, I never just leave it with what one of
> them tells me.  I use both.  And when they invariably give different
> answers, I take the different words or phrases and send them back
> through the translator, to find out which one is the closest to what I
> mean.
> 
> (You should have seen what happened when I used them to post a message
> on Framasoft's French forum!  You know, we were using Framapad, and
> needed some help.  They call each document a "pad".  Like a notepad.  So
> when I sent the translation back through, I saw that google had other
> ideas about what is a "pad"!)

- LOL... ;-D

> Well anyway, it can't hurt to try one page.  If it goes badly, then I'll
> give up.

- Ah no, don't give up after just the first trial! If Sylvain or one of
the others who already worked with it, have some time, maybe they'd be
willing to give some assistance. They also have mailing lists.

Regards,
 Maren

> All best,
> brynn
> 
> -Original Message- From: Maren Hachmann
> Sent: Saturday, April 29, 2017 4:29 PM
> To: C R ; brynn
> Cc: Inkscape-Devel ; Inkscape-Docs ; Victor Westmann
> Subject: Re: [Inkscape-devel] Any chance we can make some docs material?
> (targeting the moon)
> 
> Hi all,
> 
> oh, wow, I've just been offline for a couple of hours - wouldn't have
> expected that, if finally someone gives the 'go' for a manual, there
> would be such a huge echo (we've been discussing this on and off for a
> /very/ long time already). That's just cool :D
> 
> Just some comments to various things that were mentioned:
> 
> @CR: I think Scribus is a great tool for making the kind of graphical,
> polished, sellable, printable, book-with-columns-like structure which
> was linked in that very first link. For something that is really nice to
> look at, and is fun to read and touch.
> 
> I also think this is not the same as a manual, which should be quick to
> browse, quick to grasp, with lots of interlinks, with a file format
> suitable for version control (well, yes, Scribus is xml, I've been told,
> so it would be /readable/ - but those diffs are really ugly), with
> out-of-the-box automated generation of online versions of a manual - as
> can be done with tools like sphinx/readthedocs, doctype, and other tools
> specifically tailored for open source documentation + gitlab CI.
> You can take a look at the link from Victor's message to the mailing
> list, if you would like to know more:
> https://sourceforge.net/p/inkscape/mailman/message/35773618/
> 
> Even the booktype server of flossmanuals works with automation.
> Using one of those would also have the advantage that, once set up, this
> system could be used for both developer as well as user documentation
> (as Victor wrote in his post - and I agree with him).
> 
> As for the attribution, I think especially the book-like structure would
> profit from it, as I believe that artists may be more likely to
> contribute their drawings if those are - at least - credited to them.
> 
> Also, it would be good if things like the keyboard+mouse reference and
> other stuff we already have could be included. It's faster that way.
> Faster also means: quicker rewards. This is good if you want to have
> many contributors. Also, crediting people for their work is just
> something that makes them more willing to contribute (as stated above).
> CC-By would lose that, after the first iteration, as far as my
> understanding of the licence goes.
> 
> Some of the people involved in flossmanualsfr are also long-time
> contributors to and developers of Inkscape, so that's the relation.
> 
> The other, English, outdated, manual that you linked to, has been
> written by many of the 'old hands' in the Inkscape community - some of
> whom have moved on, and some of whom are still involved.
> 
> @doctormo: "FLOSS Manuals utilise la licence libre GPL pour l'ensemble
> de ses travaux." - translates to: all manuals on flossmanuals are under
> the GPL (don't ask which version, doesn't say there on that page.
> (https://www.flossmanuals

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Am 01.05.2017 um 07:19 schrieb brynn:
>> @Brynn: if you want to help with the translation of that 'intro' book,
> you could, for example, make corresponding screenshots for it, of the
> English version. You could also get an account on that site, and explain
> to others who speak both French and English how it works, and what they
> would need to do to join. Or write a news article asking for translators
> who would like to help.
> Also, you could add a 'Credits' page at the end, which seems to be
> missing still.
> And, of course, you can proofread and edit. Sylvain has already
> translated quite a bit.
> 
> Thanks Maren.  I'll jump right in, as much as possible.  But I don't
> understand this part:
> 
> "make corresponding screenshots for it"
> 
> Screenshots for what purpose?

- The English screenshots need to be made. The original book is in
French and has French screenshots, with French menus and maybe example
texts in French (don't know for sure), as far as I know. Some may not
need any translation, because there may not be any words in them, but
others will.

They could be inserted into the corresponding chapters, even if there is
no text yet.

> Getting an account on FLOSS Manuals goes without saying, once the
> translation is finished and we can go ahead updating and expanding.  But
> I'll be in the same boat as potential new translators, for learning how
> it works.  I won't be in a position to help newcomers, until I've had a
> little experience myself.
> 
> Credits page -- the first page gives all the credits.  Is something more
> needed?

- Ah, yes, I've found it now, thanks. It's here:
https://fr.flossmanuals.net/start-with-inkscape/about-this-book/ (not
first page, though)

Maren

> Proofreading -- I've read several pages already, and the English is
> flawless so far!  But before I go on, I'd like to hear if anyone else is
> proofreading, so we don't waste our collective time.
> 
> Actually, because of our previous discussions, I've been waiting for
> Sylvain to let me know when something is ready for proofing.  I could
> still do it anyway. But maybe I'll message him and ask.
> 
> All best,
> brynn
> 
> -Original Message- From: Maren Hachmann
> Sent: Saturday, April 29, 2017 4:29 PM
> To: C R ; brynn
> Cc: Inkscape-Devel ; Inkscape-Docs ; Victor Westmann
> Subject: Re: [Inkscape-devel] Any chance we can make some docs material?
> (targeting the moon)
> 
> Hi all,
> 
> oh, wow, I've just been offline for a couple of hours - wouldn't have
> expected that, if finally someone gives the 'go' for a manual, there
> would be such a huge echo (we've been discussing this on and off for a
> /very/ long time already). That's just cool :D
> 
> Just some comments to various things that were mentioned:
> 
> @CR: I think Scribus is a great tool for making the kind of graphical,
> polished, sellable, printable, book-with-columns-like structure which
> was linked in that very first link. For something that is really nice to
> look at, and is fun to read and touch.
> 
> I also think this is not the same as a manual, which should be quick to
> browse, quick to grasp, with lots of interlinks, with a file format
> suitable for version control (well, yes, Scribus is xml, I've been told,
> so it would be /readable/ - but those diffs are really ugly), with
> out-of-the-box automated generation of online versions of a manual - as
> can be done with tools like sphinx/readthedocs, doctype, and other tools
> specifically tailored for open source documentation + gitlab CI.
> You can take a look at the link from Victor's message to the mailing
> list, if you would like to know more:
> https://sourceforge.net/p/inkscape/mailman/message/35773618/
> 
> Even the booktype server of flossmanuals works with automation.
> Using one of those would also have the advantage that, once set up, this
> system could be used for both developer as well as user documentation
> (as Victor wrote in his post - and I agree with him).
> 
> As for the attribution, I think especially the book-like structure would
> profit from it, as I believe that artists may be more likely to
> contribute their drawings if those are - at least - credited to them.
> 
> Also, it would be good if things like the keyboard+mouse reference and
> other stuff we already have could be included. It's faster that way.
> Faster also means: quicker rewards. This is good if you want to have
> many contributors. Also, crediting people for their work is just
> something that makes them more willing to contribute (as stated above).
> CC-By would lose that, after the first iteration, as far as my
> understanding of the licence goes.
> 
> Some of the people involved in flossmanualsfr are also long-time
> contributors to and developers of Inkscape, so that's the relation.
> 
> The other, English, outdated, manual that you linked to, has been
> written by many of the 'old hands' in the Inkscape community - some of
> whom have moved on, and some of whom are still inv

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

We can do both :) (and even combine them). I've been thinking we're
exploring options. I'll make a suggestion shortly.

I only wish Nicolas or Elisa could be here to give us some more in-depth
info about their server's capabilities and their book's licencing.

Kind Regards,
 Maren

Am 01.05.2017 um 07:07 schrieb brynn:
> I'm confused -- I missed a step somewhere.
> 
> Are we no longer talking about translating the French manual on FLOSS
> Manuals?
> 
> Or are you talking about something else entirely?
> 
> Sorry to be so simple-minded.
> 
> Thanks,
> brynn
> 
> -Original Message- From: C R
> Sent: Sunday, April 30, 2017 3:39 AM
> To: Maren Hachmann
> Cc: Victor Westmann ; inkscape-devel ; Inkscape-Docs ; brynn
> Subject: Re: [Inkscape-devel] Any chance we can make some docs material?
> (targeting the moon)
> 
> I also think this is not the same as a manual, which should be quick to
> browse, quick to grasp, with lots of interlinks, with a file format
> suitable for version control (well, yes, Scribus is xml, I've been told,
> so it would be /readable/ - but those diffs are really ugly), with
> out-of-the-box automated generation of online versions of a manual - as
> can be done with tools like sphinx/readthedocs, doctype, and other tools
> 
> Martin and I are thinking gitlab + markdown will suffice for the basis
> of contribution, and we can worry about scribus and doc publishing later.
> 
> Also, it would be good if things like the keyboard+mouse reference and
> other stuff we already have could be included.
> 
> Probably should use markdown code to identify key shortcuts in plain
> text. Makes them easier to edit, diff, and provides an easy way to add
> new ones.
> 
> Also, crediting people for their work is just
> something that makes them more willing to contribute (as stated above).
> CC-By would lose that, after the first iteration, as far as my
> understanding of the licence goes.
> 
> 
> We get into the territory of having to  edit each and every diagram or
> screen capture. It's messy. I think a better credit would be to have a
> contributor page for those who contribute the most. If that's
> insufficient credit, I think people might be contributing for the wrong
> reasons.
> 
> Some of the people involved in flossmanualsfr are also long-time
> contributors to and developers of Inkscape, so that's the relation.
> 
> But you see how the licensing gets in the way? We can't use any of it
> now. People wanted credit more than they wanted to have the contents be
> reusable. GPL is for software. People try to rewrite for content, but
> that's not what it's for. Worse, it imposes more restrictions than CC-BY.
> 
> I think it's best to say something like: "Unless otherwise stated, all
> content in this book is CC0, Public Domain." Then, those who require
> attribution can include it in the caption below the graphics.
> 
> The NC licence is maybe a bit overprotective, but I'm all for crediting
> and having a manual be available for anyone who needs it.
> 
> Yes, let's not do NC. The point of this is to get it into as many hands
> as possible. People want a bit of money to handle printing and
> distribution, let them. It's less work for the project and more free
> publicity.
> 
> -C
> 
> Maren
> 
> Am 29.04.2017 um 21:22 schrieb C R:
>> Also this: http://write.flossmanuals.net/inkscape/
>>
>> On Sat, Apr 29, 2017 at 8:04 PM, C R  wrote:
> Books done in Scribus can be "published" in a variety of ways,


 Yes, I understand that.  But I thought Victor was talking about a
 hardback
 book, like at the link he provided.  That kind of book is hard to get
 published, unless you have some prior agreement with a publisher. 
 At least
 that's my understanding.
>>>
>>> We can self-publish, but we'd have to order a thousand copies, which
>>> would take some startup funds. I don't think hardback would be
>>> necessary.
>>> In fact, I don't imagine printing is necessary. We could render out a
>>> nice illustration of the book, with "ebook" under it, and people can
>>> enjoy the aesthetic without downing a bunch of trees to make physical
>>> copies of the manual. Virtual copies have great things like
>>> hyperlinks, and text search capabilities. So there are more benefits
>>> to having a digital copy anyway.
>>>
 Somewhere in this thread was some discussion about licensing.  If
 this is to
 be a hardback book (old fashioned way of publishing) *to me* it
 makes more
 sense to carry a copyright.
>>>
>>> The only requirement for a published physical book is an isbn number
>>> (for product catalog, and inventory purposes). The license of the
>>> book, as I understand it, is left completely open to the authors. We
>>> would not have this published by a company interested in owning the
>>> copyright, of course.
>>>
 As far as I understand, publishers take a cut
 of sales.  And if it's a public domain content, there wouldn't be many
 sales.  It seems 

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

> I think google translate might cause more issues than solve them - but
it has been getting better... I personally find that correcting a badly
messed-up text which already gives me some 'scheme' tends to give worse
translations, than when there is no scaffolding. It's because the
machine translation is kind of giving the direction. It may be faster,
but the translation sounds less natural.

No, I don't mean to leave it to where anyone would have a clue that any kind of 
automated translator was used.  I don't mean to paste in the translation, and 
make a couple of small edits.

What I mean is to use the translation just to give me an idea what's on that 
page.  Since I know Inkscape so well, I could write that page of the manual.  I 
can use pages which are already translated to keep the same format.

And when I use google or bing, I never just leave it with what one of them 
tells 
me.  I use both.  And when they invariably give different answers, I take the 
different words or phrases and send them back through the translator, to find 
out which one is the closest to what I mean.

(You should have seen what happened when I used them to post a message on 
Framasoft's French forum!  You know, we were using Framapad, and needed some 
help.  They call each document a "pad".  Like a notepad.  So when I sent the 
translation back through, I saw that google had other ideas about what is a 
"pad"!)

Well anyway, it can't hurt to try one page.  If it goes badly, then I'll give 
up.

All best,
brynn

-Original Message- 
From: Maren Hachmann
Sent: Saturday, April 29, 2017 4:29 PM
To: C R ; brynn
Cc: Inkscape-Devel ; Inkscape-Docs ; Victor Westmann
Subject: Re: [Inkscape-devel] Any chance we can make some docs material? 
(targeting the moon)

Hi all,

oh, wow, I've just been offline for a couple of hours - wouldn't have
expected that, if finally someone gives the 'go' for a manual, there
would be such a huge echo (we've been discussing this on and off for a
/very/ long time already). That's just cool :D

Just some comments to various things that were mentioned:

@CR: I think Scribus is a great tool for making the kind of graphical,
polished, sellable, printable, book-with-columns-like structure which
was linked in that very first link. For something that is really nice to
look at, and is fun to read and touch.

I also think this is not the same as a manual, which should be quick to
browse, quick to grasp, with lots of interlinks, with a file format
suitable for version control (well, yes, Scribus is xml, I've been told,
so it would be /readable/ - but those diffs are really ugly), with
out-of-the-box automated generation of online versions of a manual - as
can be done with tools like sphinx/readthedocs, doctype, and other tools
specifically tailored for open source documentation + gitlab CI.
You can take a look at the link from Victor's message to the mailing
list, if you would like to know more:
https://sourceforge.net/p/inkscape/mailman/message/35773618/

Even the booktype server of flossmanuals works with automation.
Using one of those would also have the advantage that, once set up, this
system could be used for both developer as well as user documentation
(as Victor wrote in his post - and I agree with him).

As for the attribution, I think especially the book-like structure would
profit from it, as I believe that artists may be more likely to
contribute their drawings if those are - at least - credited to them.

Also, it would be good if things like the keyboard+mouse reference and
other stuff we already have could be included. It's faster that way.
Faster also means: quicker rewards. This is good if you want to have
many contributors. Also, crediting people for their work is just
something that makes them more willing to contribute (as stated above).
CC-By would lose that, after the first iteration, as far as my
understanding of the licence goes.

Some of the people involved in flossmanualsfr are also long-time
contributors to and developers of Inkscape, so that's the relation.

The other, English, outdated, manual that you linked to, has been
written by many of the 'old hands' in the Inkscape community - some of
whom have moved on, and some of whom are still involved.

@doctormo: "FLOSS Manuals utilise la licence libre GPL pour l'ensemble
de ses travaux." - translates to: all manuals on flossmanuals are under
the GPL (don't ask which version, doesn't say there on that page.
(https://www.flossmanualsfr.net/faq-floss-manuals-francophone/ch011_quest-ce-que-lopen-source-et-quelle-est-la-difference-entre-free-libre-et-open).

@Brynn: if you want to help with the translation of that 'intro' book,
you could, for example, make corresponding screenshots for it, of the
English version. You could also get an account on that site, and explain
to others who speak both French and English how it works, and what they
would need to do to join. Or write a news article asking for translators
who would like to help.
A

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

> @Brynn: if you want to help with the translation of that 'intro' book,
you could, for example, make corresponding screenshots for it, of the
English version. You could also get an account on that site, and explain
to others who speak both French and English how it works, and what they
would need to do to join. Or write a news article asking for translators
who would like to help.
Also, you could add a 'Credits' page at the end, which seems to be
missing still.
And, of course, you can proofread and edit. Sylvain has already
translated quite a bit.

Thanks Maren.  I'll jump right in, as much as possible.  But I don't understand 
this part:

"make corresponding screenshots for it"

Screenshots for what purpose?

Getting an account on FLOSS Manuals goes without saying, once the translation 
is 
finished and we can go ahead updating and expanding.  But I'll be in the same 
boat as potential new translators, for learning how it works.  I won't be in a 
position to help newcomers, until I've had a little experience myself.

Credits page -- the first page gives all the credits.  Is something more needed?

Proofreading -- I've read several pages already, and the English is flawless so 
far!  But before I go on, I'd like to hear if anyone else is proofreading, so 
we 
don't waste our collective time.

Actually, because of our previous discussions, I've been waiting for Sylvain to 
let me know when something is ready for proofing.  I could still do it anyway. 
But maybe I'll message him and ask.

All best,
brynn

-Original Message- 
From: Maren Hachmann
Sent: Saturday, April 29, 2017 4:29 PM
To: C R ; brynn
Cc: Inkscape-Devel ; Inkscape-Docs ; Victor Westmann
Subject: Re: [Inkscape-devel] Any chance we can make some docs material? 
(targeting the moon)

Hi all,

oh, wow, I've just been offline for a couple of hours - wouldn't have
expected that, if finally someone gives the 'go' for a manual, there
would be such a huge echo (we've been discussing this on and off for a
/very/ long time already). That's just cool :D

Just some comments to various things that were mentioned:

@CR: I think Scribus is a great tool for making the kind of graphical,
polished, sellable, printable, book-with-columns-like structure which
was linked in that very first link. For something that is really nice to
look at, and is fun to read and touch.

I also think this is not the same as a manual, which should be quick to
browse, quick to grasp, with lots of interlinks, with a file format
suitable for version control (well, yes, Scribus is xml, I've been told,
so it would be /readable/ - but those diffs are really ugly), with
out-of-the-box automated generation of online versions of a manual - as
can be done with tools like sphinx/readthedocs, doctype, and other tools
specifically tailored for open source documentation + gitlab CI.
You can take a look at the link from Victor's message to the mailing
list, if you would like to know more:
https://sourceforge.net/p/inkscape/mailman/message/35773618/

Even the booktype server of flossmanuals works with automation.
Using one of those would also have the advantage that, once set up, this
system could be used for both developer as well as user documentation
(as Victor wrote in his post - and I agree with him).

As for the attribution, I think especially the book-like structure would
profit from it, as I believe that artists may be more likely to
contribute their drawings if those are - at least - credited to them.

Also, it would be good if things like the keyboard+mouse reference and
other stuff we already have could be included. It's faster that way.
Faster also means: quicker rewards. This is good if you want to have
many contributors. Also, crediting people for their work is just
something that makes them more willing to contribute (as stated above).
CC-By would lose that, after the first iteration, as far as my
understanding of the licence goes.

Some of the people involved in flossmanualsfr are also long-time
contributors to and developers of Inkscape, so that's the relation.

The other, English, outdated, manual that you linked to, has been
written by many of the 'old hands' in the Inkscape community - some of
whom have moved on, and some of whom are still involved.

@doctormo: "FLOSS Manuals utilise la licence libre GPL pour l'ensemble
de ses travaux." - translates to: all manuals on flossmanuals are under
the GPL (don't ask which version, doesn't say there on that page.
(https://www.flossmanualsfr.net/faq-floss-manuals-francophone/ch011_quest-ce-que-lopen-source-et-quelle-est-la-difference-entre-free-libre-et-open).

@Brynn: if you want to help with the translation of that 'intro' book,
you could, for example, make corresponding screenshots for it, of the
English version. You could also get an account on that site, and explain
to others who speak both French and English how it works, and what they
would need to do to join. Or write a news article asking for translators
who wou

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

I'm confused -- I missed a step somewhere.

Are we no longer talking about translating the French manual on FLOSS Manuals?

Or are you talking about something else entirely?

Sorry to be so simple-minded.

Thanks,
brynn

-Original Message- 
From: C R
Sent: Sunday, April 30, 2017 3:39 AM
To: Maren Hachmann
Cc: Victor Westmann ; inkscape-devel ; Inkscape-Docs ; brynn
Subject: Re: [Inkscape-devel] Any chance we can make some docs material? 
(targeting the moon)

I also think this is not the same as a manual, which should be quick to
browse, quick to grasp, with lots of interlinks, with a file format
suitable for version control (well, yes, Scribus is xml, I've been told,
so it would be /readable/ - but those diffs are really ugly), with
out-of-the-box automated generation of online versions of a manual - as
can be done with tools like sphinx/readthedocs, doctype, and other tools

Martin and I are thinking gitlab + markdown will suffice for the basis of 
contribution, and we can worry about scribus and doc publishing later.

Also, it would be good if things like the keyboard+mouse reference and
other stuff we already have could be included.

Probably should use markdown code to identify key shortcuts in plain text. 
Makes 
them easier to edit, diff, and provides an easy way to add new ones.

Also, crediting people for their work is just
something that makes them more willing to contribute (as stated above).
CC-By would lose that, after the first iteration, as far as my
understanding of the licence goes.


We get into the territory of having to  edit each and every diagram or screen 
capture. It's messy. I think a better credit would be to have a contributor 
page 
for those who contribute the most. If that's insufficient credit, I think 
people 
might be contributing for the wrong reasons.

Some of the people involved in flossmanualsfr are also long-time
contributors to and developers of Inkscape, so that's the relation.

But you see how the licensing gets in the way? We can't use any of it now. 
People wanted credit more than they wanted to have the contents be reusable. 
GPL 
is for software. People try to rewrite for content, but that's not what it's 
for. Worse, it imposes more restrictions than CC-BY.

I think it's best to say something like: "Unless otherwise stated, all content 
in this book is CC0, Public Domain." Then, those who require attribution can 
include it in the caption below the graphics.

The NC licence is maybe a bit overprotective, but I'm all for crediting
and having a manual be available for anyone who needs it.

Yes, let's not do NC. The point of this is to get it into as many hands as 
possible. People want a bit of money to handle printing and distribution, let 
them. It's less work for the project and more free publicity.

-C

Maren

Am 29.04.2017 um 21:22 schrieb C R:
> Also this: http://write.flossmanuals.net/inkscape/
>
> On Sat, Apr 29, 2017 at 8:04 PM, C R  wrote:
 Books done in Scribus can be "published" in a variety of ways,
>>>
>>>
>>> Yes, I understand that.  But I thought Victor was talking about a hardback
>>> book, like at the link he provided.  That kind of book is hard to get
>>> published, unless you have some prior agreement with a publisher.  At least
>>> that's my understanding.
>>
>> We can self-publish, but we'd have to order a thousand copies, which
>> would take some startup funds. I don't think hardback would be
>> necessary.
>> In fact, I don't imagine printing is necessary. We could render out a
>> nice illustration of the book, with "ebook" under it, and people can
>> enjoy the aesthetic without downing a bunch of trees to make physical
>> copies of the manual. Virtual copies have great things like
>> hyperlinks, and text search capabilities. So there are more benefits
>> to having a digital copy anyway.
>>
>>> Somewhere in this thread was some discussion about licensing.  If this is to
>>> be a hardback book (old fashioned way of publishing) *to me* it makes more
>>> sense to carry a copyright.
>>
>> The only requirement for a published physical book is an isbn number
>> (for product catalog, and inventory purposes). The license of the
>> book, as I understand it, is left completely open to the authors. We
>> would not have this published by a company interested in owning the
>> copyright, of course.
>>
>>> As far as I understand, publishers take a cut
>>> of sales.  And if it's a public domain content, there wouldn't be many
>>> sales.  It seems like it would make it even harder to find a publisher.
>>
>> A publisher isn't necessary for this project, assuming the content is
>> what's important. If we want book sales out of this, that's the point
>> where it will become an issue.
>>
>>> I don't know, maybe I'm old and old fashioned.  But the FLOSS manual, on the
>>> other hand, certainly should be either public domain, or CC-BY-NC-SA might
>>> be better.  Whatever it needs to have, to allow the community to edit.
>>
>> All I can guarantee i

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Am 30.04.2017 um 11:39 schrieb C R:
> 
> 
> I also think this is not the same as a manual, which should be quick to
> browse, quick to grasp, with lots of interlinks, with a file format
> suitable for version control (well, yes, Scribus is xml, I've been told,
> so it would be /readable/ - but those diffs are really ugly), with
> out-of-the-box automated generation of online versions of a manual - as
> can be done with tools like sphinx/readthedocs, doctype, and other tools
> 
> 
> Martin and I are thinking gitlab + markdown will suffice for the basis
> of contribution, and we can worry about scribus and doc publishing later.
> 

- This sounds to me like it would be duplicating work, when automated
systems exist, but aren't used from the start.

> 
> Also, it would be good if things like the keyboard+mouse reference and
> other stuff we already have could be included. 
> 
> 
> Probably should use markdown code to identify key shortcuts in plain
> text. Makes them easier to edit, diff, and provides an easy way to add
> new ones.

- Yes, but we could copy the structure and contents, which are both
good. I certainly don't know all the shortcuts by heart. And there are
many that aren't listed in the keys.xml file.

>  Also, crediting people for their work is just
> something that makes them more willing to contribute (as stated above).
> CC-By would lose that, after the first iteration, as far as my
> understanding of the licence goes.
> 
> 
> We get into the territory of having to  edit each and every diagram or
> screen capture. It's messy. I think a better credit would be to have a
> contributor page for those who contribute the most. If that's
> insufficient credit, I think people might be contributing for the wrong
> reasons.
> 

- I fully agree that a general 'Credits' page would be sufficient. The
Inkscape website contents is dual licenced, too. And we do not have
individual credits for each page, word, image, link or whatever. It
would be very difficult to do that anyway.
Do you think that poses a problem?

If someone wants to know specifically, a git blame would be sufficient
to find out (this wouldn't work for the website's CMS, though)...


> Some of the people involved in flossmanualsfr are also long-time
> contributors to and developers of Inkscape, so that's the relation.
> 
> 
> But you see how the licensing gets in the way? We can't use any of it
> now. People wanted credit more than they wanted to have the contents be
> reusable. GPL is for software. People try to rewrite for content, but
> that's not what it's for. Worse, it imposes more restrictions than CC-BY. 

- We could, if we used GPL... It doesn't prevent translation or
modification. And we can ask, as Martin suggested.

> I think it's best to say something like: "Unless otherwise stated, all
> content in this book is CC0, Public Domain." Then, those who require
> attribution can include it in the caption below the graphics. 

- That's certainly possible. However, I wouldn't contribute text or
proofreading or maintenance help under these circumstances. There are
many things that I have published as CC0 (Public Domain is impossible in
Germany, because there are certain moral rights, such as 'authorship'
that one cannot give up, even if one wanted to).
But a manual that is made for an open source, copyleft software should
fit the philosophy, in my opinion. I care about attributing work to the
people who did it, and I don't want that someone who comes along to grab
what they did can just deprive them of it.

Regards,
 Maren



--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Martin Owens]

Hi Maren,

I talked with Chris this morning about how to set things up. But we
were mostly trialing, thinking and researching. So not decisions or
anything.

> Even the booktype server of flossmanuals works with automation.
> Using one of those would also have the advantage that, once set up,
> this
> system could be used for both developer as well as user documentation
> (as Victor wrote in his post - and I agree with him).

Developer documentation is a very different beast and I'd like to if at
all possible keep that separate. wiki.inkscape.org is the best location
for that at the moment.

One of the ideas we were playing with, was getting contributors to edit
content directly at gitlab.com, then we have a bunch of scripts that
consume the wiki git repository, generate pot/po files, and provide the
raw resource for an optional secondary step.

The second step would be a sort of publishing step. Where we take the
content as a specific time, and produce it into a cleaned up, pretty
book/pdf.

I imagine contributors like CR would be most interested in this step.

But everyone would be involved in the raw materials step (writing words
and getting screenshots into the wiki)


> CC-By would lose that, after the first iteration, as far as my
> understanding of the licence goes.

That's not how licenses work (at least not these ones), you can't
remove any prior terms, you can only add terms. Technically you could
take a CC-BY work and wrap it in a CC-BY-SA work, or relicense as All
Rights Reserved. BUT everyone would still be required to attend that
that attribution of the original license. SA means you can't /add
licenses/ to make it more restrictive.

> @doctormo: "FLOSS Manuals utilise la licence libre GPL pour
> l'ensemble
> de ses travaux." - translates to: all manuals on flossmanuals are
> under
> the GPL (don't ask which version, doesn't say there on that page.
> (https://www.flossmanualsfr.net/faq-floss-manuals-francophone/ch011_q
> uest-ce-que-lopen-source-et-quelle-est-la-difference-entre-free-
> libre-et-open).

Ugh, not dual licensed then. This is where a CC0 or PD would have been
better. We can't do anything with the content if we want to use CC-BY-
SA since the licenses are incompatible.

We'll have to be careful.

Best Regards, Martin Owens

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Victor Westmann]

Hi Miguel,

I think this is a GREAT advantage for the entire Inkscape project. It makes
all the sense of the world to help users do all the needed workarounds and,
if they want, help send funds to the project ($$) and/or a bug request on
Gitlab(is it at Gitlab really?).

Amazing. The more transparent we are (and we really are) the better.



--Victor Westmann

2017-04-29 10:39 GMT-07:00 Miguel Lopez :

> I want to put out something regarding documentations. What about
> workarounds to Inkscape limitations as part of the documentation? Some
> users really need some answers to the limitation of Inkscape. There's
> another idea I have in mind. For making tutorials shorter, we can use
> existing tutorials of our own and linking to them as part of advanced
> section of Inkscape tutorials. Advanced users should already know the
> program in and out to know how to apply them for advanced rendering.
> Some of those might need workarounds though.
>
> My only issue with those workaround is the amount of time they require,
> and the tax on limited resources. Otherwise, if those weren't a issue,
> they would be fantastic though they're still not a replacement to what
> other programs has to offer. I can offer making workaround docs if
> anyone wants me to show how to work around Inkscape limits.
>
> For example :
>
> 1) Gradient Stroke -
>
> 1a) Method 1 (If profile line aren't needed) - Duplicate and then adjust
> stroke width, and then convert to path. Every strokes must be converted
> to path. You copy and paste the path that is going to get removed by
> applying the path difference. You repeat the process, and then you get
> every individual stroke which can be colored as however you please.
>
> 1b) Method 2 (If profile line is needed) You apply the same thing to the
> above, but you are not going to use stroke width. Instead, you are going
> to use power stroke to emulate profile line with gradient stroke.
>
> 2) Realistic Rendering of convulated objects like a shoe.
>
> 2a) This involves series of clipping, blurring, gradient mesh and
> brushing. Right now, Inkscape users can only use gradient mesh for basic
> overall lighting, and some bit of coloring using filtering since
> gradient mesh is underdeveloped in Inkscape. You apply blur to brushes
> in order to emulate shading. Doing this a lot can give very sastifying
> result within Inkscape, but also drains so much of rendering speed
> within Inkscape even with a powerful computer. But results are literally
> comparable to raster programs, and in some way even better because well,
> it's scalable.
>
> 3) The lack of warp tool for textures workaround
>
> 3a) As of now, we do have lattice tool, and the tweak liquifying tool.
> Those two can be used as a workaround to the lack of warp tool. Lattice
> deformation tool should had the option of allowing users to tweak the
> tangency line though instead of the tangency line being tangent to the
> horizontal and vertical direction. This is not something that can have a
> decent workaround since it requires duplicating so many objects and then
> tweaking it would be a major pain. For complicated textures, it can't be
> done within Inkscape unless you have a infinite amount of time and
> resource, and as we all know that's not possible.
>
> 4) For people who have trouble with tangency snapping (I'm one of
> those), and no that snapping option does not help one bit.
>
> 4a) The obvious workaround involves using the show handles. You can make
> tangent line utilizing the result of the show handles LPE. Also, this
> enables users to be able to create perpendicular, and tangent spiro path.
>
> 5)  The lack of ease regarding manipulating mask/clip
>
> 5a) The workaround to this is well, using the clone as the
> masking/clipping source while retaining the original for
> clipping/masking at another location. This workaround works because you
> can always manipulate the source object, and hide it. It is almost
> exactly like as if you were manipulating transparency mask within Krita
> or Photoshop or GIMP. After testing it, it's beautiful really when you
> change between layer/group.
>
> 6) PDF export limitation
>
> 6a) The obvious workaround here is well, export to png and then convert
> to pdf. Of course, some rasterization would be needed if one has to
> convert to pdf, literally at times.
>
> I think those are the 6 issues that could be addressed via docs tutorial
> for those who are desperate to find a solution to those. They can always
> resort to Krita for those (except 6 because pdf export is not planned),
> but that's not a option if they have to create a vector render. If
> there's anything I miss regarding workarounds, lemme know. I can
> probably add more workarounds if I miss anything as I know the program
> in and out from a user perspective.
>
>
> On 4/29/2017 11:54 AM, C R wrote:
> >> I don't mean to slow anyone's roll here.  But wouldn't it make more
> sense to put
> >> any kind of energy towards documentation i

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Victor Westmann]

I agree with Brynn. We should first focus in create the official/original
doc of Inkscape on Gitlab and then try to do this hard copy book to sell in
the inkscape store.

I just wanted to gather the opinions of you guys if more or less following
the index of a 3rd party material is a good idea or at least a good place
to start. We don't have to copy it topic by topic but we could inspire
ourselves in it.

Cheers,



--Victor Westmann

2017-04-29 6:19 GMT-07:00 brynn :

> I don't mean to slow anyone's roll here.  But wouldn't it make more sense
> to put any kind of energy towards documentation into the much discussed,
> direly needed, user-focused, step by step manual?  Rather than starting
> from scratch on a whole different kind of project?
>
> There are many books out there already, which amount to a series of
> tutorials. It's not a bad thing.  I just think this kind of project is
> better suited for a single author, or maybe a small team.  And I think the
> project needs the manual much, more more than the community needs another
> book of tutorials.
>
> As far as I understand, all that's needed is an English translation
> of...well I can't find a link to the French version.  Here's a link to
> whatever has been translated already: https://fr.flossmanuals.net/st
> art-with-inkscape/introduction/
>
> Once we have the translation, we'll be off and running to update and
> finish it! By the way, is there anything those of us who can't translate,
> can do, to help the translators?
>
> And won't such a new book of tutorials have to be published?  A big
> obstacle to writing any book is getting it published.  You almost have to
> have an invitation from a publisher to be certain a book will get
> published.  Or publish it yourself, which is not easy eitiher.
>
> Just my opinion  :-)
>
> brynn
>
> -Original Message- From: Maren Hachmann
> Sent: Friday, April 28, 2017 4:01 PM
> To: Inkscape-Docs ; Inkscape Devel List
> Subject: Re: [Inkscape-devel] Any chance we can make some docs material?
> (targeting the moon)
>
>
> Would it make sense to use gitlab's new subgroups feature for this?
>
> The inkscape-docs team could be a sub-team of Inkscape, that way. There
> are only 4 members as of now, so changing wouldn't be so difficult as it
> might be later on.
>
> Maren
>
> Am 28.04.2017 um 16:14 schrieb Martin Owens:
>>
>>> On Fri, 2017-04-28 at 12:39 +0100, C R wrote:
>>>
 I'd love to quit my job and just do docs. :) Unfortunately, that's
 what it would probably take to get docs going to the extent we'd
 like.
 It's been discussed before, but never gone anywhere because of lack
 of time/hands involved.

 Yes, we should use Scribus to do it. In fact, it should probably be a
 github project to attract contributors. This way we can patch what
 needs to be patched when stuff changes in subsequent releases.

>>>
>>> Sounds like you have a solid step one Chris.
>>>
>>> Here's the inkscape-docs group on gitlab, EVERYONE should join, there
>>> should be a button to join:
>>>
>>> https://gitlab.com/inkscape-docs
>>>
>>> And here's the new book/manual/docs project where files can be put:
>>>
>>> https://gitlab.com/inkscape/manuals
>>>
>>> I recommend using the wiki attached to the project to plan the
>>> adventure slowly. Add a bit at a time and don't rush to have something
>>> "complete" but have something small produced.
>>>
>>> Best Regards, Martin Owens
>>>
>>>
>>> 
>>> --
>>> 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-de...@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-de...@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-docs mailing list
Inkscape-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Hi all,

oh, wow, I've just been offline for a couple of hours - wouldn't have
expected that, if finally someone gives the 'go' for a manual, there
would be such a huge echo (we've been discussing this on and off for a
/very/ long time already). That's just cool :D

Just some comments to various things that were mentioned:

@CR: I think Scribus is a great tool for making the kind of graphical,
polished, sellable, printable, book-with-columns-like structure which
was linked in that very first link. For something that is really nice to
look at, and is fun to read and touch.

I also think this is not the same as a manual, which should be quick to
browse, quick to grasp, with lots of interlinks, with a file format
suitable for version control (well, yes, Scribus is xml, I've been told,
so it would be /readable/ - but those diffs are really ugly), with
out-of-the-box automated generation of online versions of a manual - as
can be done with tools like sphinx/readthedocs, doctype, and other tools
specifically tailored for open source documentation + gitlab CI.
You can take a look at the link from Victor's message to the mailing
list, if you would like to know more:
https://sourceforge.net/p/inkscape/mailman/message/35773618/

Even the booktype server of flossmanuals works with automation.
Using one of those would also have the advantage that, once set up, this
system could be used for both developer as well as user documentation
(as Victor wrote in his post - and I agree with him).

As for the attribution, I think especially the book-like structure would
profit from it, as I believe that artists may be more likely to
contribute their drawings if those are - at least - credited to them.

Also, it would be good if things like the keyboard+mouse reference and
other stuff we already have could be included. It's faster that way.
Faster also means: quicker rewards. This is good if you want to have
many contributors. Also, crediting people for their work is just
something that makes them more willing to contribute (as stated above).
CC-By would lose that, after the first iteration, as far as my
understanding of the licence goes.

Some of the people involved in flossmanualsfr are also long-time
contributors to and developers of Inkscape, so that's the relation.

The other, English, outdated, manual that you linked to, has been
written by many of the 'old hands' in the Inkscape community - some of
whom have moved on, and some of whom are still involved.

@doctormo: "FLOSS Manuals utilise la licence libre GPL pour l'ensemble
de ses travaux." - translates to: all manuals on flossmanuals are under
the GPL (don't ask which version, doesn't say there on that page.
(https://www.flossmanualsfr.net/faq-floss-manuals-francophone/ch011_quest-ce-que-lopen-source-et-quelle-est-la-difference-entre-free-libre-et-open).

@Brynn: if you want to help with the translation of that 'intro' book,
you could, for example, make corresponding screenshots for it, of the
English version. You could also get an account on that site, and explain
to others who speak both French and English how it works, and what they
would need to do to join. Or write a news article asking for translators
who would like to help.
Also, you could add a 'Credits' page at the end, which seems to be
missing still.
And, of course, you can proofread and edit. Sylvain has already
translated quite a bit.

The NC licence is maybe a bit overprotective, but I'm all for crediting
and having a manual be available for anyone who needs it. I personally
wouldn't mind if someone prints and sells it and makes money with that.
As long as that is not the only source of the book/manual, this doesn't
cause me any worries.

I think google translate might cause more issues than solve them - but
it has been getting better... I personally find that correcting a badly
messed-up text which already gives me some 'scheme' tends to give worse
translations, than when there is no scaffolding. It's because the
machine translation is kind of giving the direction. It may be faster,
but the translation sounds less natural.

@jazzynico or Elisa: Can you tell us the specific flossmanuals licence?
GPLv2 or 3? Or, if not specified, do you know which version it would use
then, legally? Does Booktype use any kind of version control that is
compatible with git? What is the source file format?

@Miguel: yes, we're discussing those workarounds (and many others) on
the forums on a regular basis. It would certainly be cool if someone
could compile the 'Tips + Tricks' (sounds better than workarounds?) to
make up a separate section in the manual, or even a separate manual by
its own.

(sorry for the long post, there was a lot to reply to :D)

Maren


Am 29.04.2017 um 21:22 schrieb C R:
> Also this: http://write.flossmanuals.net/inkscape/
> 
> On Sat, Apr 29, 2017 at 8:04 PM, C R  wrote:
 Books done in Scribus can be "published" in a variety of ways,
>>>
>>>
>>> Yes, I understand that.  But I thought Victor was 

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

>> And won't such a new book of tutorials have to be published? .

> Books done in Scribus can be "published" in a variety of ways,

Yes, I understand that.  But I thought Victor was talking about a hardback 
book, 
like at the link he provided.  That kind of book is hard to get published, 
unless you have some prior agreement with a publisher.  At least that's my 
understanding.


Somewhere in this thread was some discussion about licensing.  If this is to be 
a hardback book (old fashioned way of publishing) *to me* it makes more sense 
to 
carry a copyright.  As far as I understand, publishers take a cut of sales.  
And 
if it's a public domain content, there wouldn't be many sales.  It seems like 
it 
would make it even harder to find a publisher.

I don't know, maybe I'm old and old fashioned.  But the FLOSS manual, on the 
other hand, certainly should be either public domain, or CC-BY-NC-SA might be 
better.  Whatever it needs to have, to allow the community to edit.


I'm not sure what has the translators on pause.  But that seems to be the 
"blocker" at the moment.  That's why I was asking if there was anything we 
non-translators can do to help.  I wish I knew anyone I could ask to help, but 
I 
sure don't.

This is probably a bad idea.  But I'm trying to think outside the box.  What if 
I (or other non-French-speaker) took one of the French pages, and sent it 
through the public google and/or bing translators.  I know those are far from 
perfect.  (So far!)  But since I know Inkscape, it seems like it would give 
me enough of a clue what it's about, to be able to write it properly in English.

Then maybe the translators can proof read it, to make sure something important 
wasn't missed?  Proof reading would seem to be much less time-consuming for 
them.

Would that work??

All best,
brynn

-Original Message- 
From: C R
Sent: Saturday, April 29, 2017 9:54 AM
To: brynn
Cc: Inkscape-Docs ; Inkscape Devel List ; Maren Hachmann ; Victor Westmann
Subject: Re: [Inkscape-devel] Any chance we can make some docs material? 
(targeting the moon)

> I don't mean to slow anyone's roll here.  But wouldn't it make more sense to 
> put
> any kind of energy towards documentation into the much discussed, direly 
> needed,
> user-focused, step by step manual?  Rather than starting from scratch on a 
> whole
> different kind of project?

Yea, this actually makes a lot of sense as a first step.

> There are many books out there already, which amount to a series of tutorials.
> It's not a bad thing.  I just think this kind of project is better suited for 
> a
> single author, or maybe a small team.  And I think the project needs the 
> manual
> much, more more than the community needs another book of tutorials.

I agree. I think the book could be a lot of things in one. But I agree
with finishing what we already have before starting something new.


> As far as I understand, all that's needed is an English translation of...well
> can't find a link to the French version.  Here's a link to whatever has been
> translated already:
> https://fr.flossmanuals.net/start-with-inkscape/introduction/

I can't help with translation, unfortunately. But I'd like to see this
finished. So +1 for the suggestion.

> Once we have the translation, we'll be off and running to update and finish 
> it!
> By the way, is there anything those of us who can't translate, can do, to help
> the translators?

I volunteer to help this effort in what ways are needed.

> And won't such a new book of tutorials have to be published?  A big obstacle 
> to
> writing any book is getting it published.  You almost have to have an 
> invitation
> from a publisher to be certain a book will get published.  Or publish it
> yourself, which is not easy eitiher.

Books done in Scribus can be "published" in a variety of ways, opened
in browsers, laptops, eReaders, or just printed out. We could sell
printed copies along with other Inkscape stuff. Maybe copies signed by
members of the project would be kinda cool. No idea what the market is
for it, but the idea that we could do all of these at once is
attractive, and why I recommend Scribus.

-C

>
> Just my opinion  :-)
>
> brynn
>
> -Original Message-
> From: Maren Hachmann
> Sent: Friday, April 28, 2017 4:01 PM
> To: Inkscape-Docs ; Inkscape Devel List
> Subject: Re: [Inkscape-devel] Any chance we can make some docs material?
> (targeting the moon)
>
> Would it make sense to use gitlab's new subgroups feature for this?
>
> The inkscape-docs team could be a sub-team of Inkscape, that way. There
> are only 4 members as of now, so changing wouldn't be so difficult as it
> might be later on.
>
> Maren
>
>> Am 28.04.2017 um 16:14 schrieb Martin Owens:
>>> On Fri, 2017-04-28 at 12:39 +0100, C R wrote:
 I'd love to quit my job and just do docs. :) Unfortunately, that's
 what it would probably take to get docs going to the extent we'd
 like.
 It's been discussed before, but never g

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Martin Owens]

On Sat, 2017-04-29 at 07:19 -0600, brynn wrote:
> As far as I understand, all that's needed is an English translation
> of...well I 
> can't find a link to the French version.  Here's a link to whatever
> has been 
> translated already: 
> https://fr.flossmanuals.net/start-with-inkscape/introduction/

No, that's not licensed. We can't and shouldn't use it until it has a
known and open license.

Unfortunately there are going to be lots of good resources that we just
can't use.

But you can use "the idea" of the content. So having similar sections
and covering similar ground.

Best Regards, Martin Owens

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Martin Owens]

> It's fine to pull content
> from properly licenced sources, imho, too.
> 
> I disagree. This would create a tangle of licenses and attribution
> requirements that will make the contents less usable in/by other
> projects. We should remove the burden of attribution where possible.

It doesn't have to be a tangle if you set out the rules from the start.
Copyleft exists to protect projects and attribution exists to give
authors credit for their hard work.

A CC-BY-SA project should be doable. But I'm hoping to examples of
situations where educational materials were harmed by choosing an
attribution style license.

(also, if it's in a repository, the "who wrote what" becomes a bit
easier)

As for pulling in content from outside. Ask. Firstly ask if the author
would like their work included, then ask if they could relicense their
work to whatever is needed and then finally if the other two were met
with enthusiasm, ask them to join the team. :-)

Best Regards, Martin Owens

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[brynn]

I don't mean to slow anyone's roll here.  But wouldn't it make more sense to 
put 
any kind of energy towards documentation into the much discussed, direly 
needed, 
user-focused, step by step manual?  Rather than starting from scratch on a 
whole 
different kind of project?

There are many books out there already, which amount to a series of tutorials. 
It's not a bad thing.  I just think this kind of project is better suited for a 
single author, or maybe a small team.  And I think the project needs the manual 
much, more more than the community needs another book of tutorials.

As far as I understand, all that's needed is an English translation of...well I 
can't find a link to the French version.  Here's a link to whatever has been 
translated already: 
https://fr.flossmanuals.net/start-with-inkscape/introduction/

Once we have the translation, we'll be off and running to update and finish it! 
By the way, is there anything those of us who can't translate, can do, to help 
the translators?

And won't such a new book of tutorials have to be published?  A big obstacle to 
writing any book is getting it published.  You almost have to have an 
invitation 
from a publisher to be certain a book will get published.  Or publish it 
yourself, which is not easy eitiher.

Just my opinion  :-)

brynn

-Original Message- 
From: Maren Hachmann
Sent: Friday, April 28, 2017 4:01 PM
To: Inkscape-Docs ; Inkscape Devel List
Subject: Re: [Inkscape-devel] Any chance we can make some docs material? 
(targeting the moon)

Would it make sense to use gitlab's new subgroups feature for this?

The inkscape-docs team could be a sub-team of Inkscape, that way. There
are only 4 members as of now, so changing wouldn't be so difficult as it
might be later on.

Maren

> Am 28.04.2017 um 16:14 schrieb Martin Owens:
>> On Fri, 2017-04-28 at 12:39 +0100, C R wrote:
>>> I'd love to quit my job and just do docs. :) Unfortunately, that's
>>> what it would probably take to get docs going to the extent we'd
>>> like.
>>> It's been discussed before, but never gone anywhere because of lack
>>> of time/hands involved.
>>>
>>> Yes, we should use Scribus to do it. In fact, it should probably be a
>>> github project to attract contributors. This way we can patch what
>>> needs to be patched when stuff changes in subsequent releases.
>>
>> Sounds like you have a solid step one Chris.
>>
>> Here's the inkscape-docs group on gitlab, EVERYONE should join, there
>> should be a button to join:
>>
>> https://gitlab.com/inkscape-docs
>>
>> And here's the new book/manual/docs project where files can be put:
>>
>> https://gitlab.com/inkscape/manuals
>>
>> I recommend using the wiki attached to the project to plan the
>> adventure slowly. Add a bit at a time and don't rush to have something
>> "complete" but have something small produced.
>>
>> Best Regards, Martin Owens
>>
>>
>> --
>> 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-de...@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-de...@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-docs mailing list
Inkscape-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Am 29.04.2017 um 10:05 schrieb C R:
> I have requested access to the gitlab repo. Once allowed, I'll drop a
> Scribus document in there with a cover, and the master pages with some
> initial styling for the document. I'll also do a README file with an
> initial layout/contents proposal based on some of the ideas here.
> 
> To my mind, the most useful thing would be getting an inkscape
> quick-start guide going as the preface. This way users can start
> making use of the document right away.
> 
> We may also want to publish each section of the book as a pdf as we go
> along, so users don't have to clone our repos just to get the
> information. :)
> 
> Contributors should also be aware that it's not okay to copy/paste
> content from blogs, tutorials, etc. For this document, everything must
> be re-written from scratch, and all screen captures, graphics etc.
> must be of our own making and cc0 (public domain). Anyone not
> interested in contributing 100% public domain content, should not
> contribute to this project.

- For a printable book, this sounds like a good idea :D

For a more 'scientific' manual, I think it's not suitable to do this in
Scribus, and that we should turn to a proven documentation software.

I've heard that Scribus performance drops dramatically with the number
of pages. How would you go about translatating the book?

I strongly disagree with CC0 - I would only contribute to something that
where attribution and copyleft are honored. It's fine to pull content
from properly licenced sources, imho, too. There are quick start guides
with good licences - this would make the process a lot faster, if it
wouldn't need to be written from scratch, but only modified. So yeah,
count me out :)

Maren

> -C
> 
> 
> 
> On Sat, Apr 29, 2017 at 12:01 AM, Maren Hachmann
>  wrote:
>> Great :)
>>
>> I think, in this context, it makes sense to also link to the thread on
>> the translators mailing list, where many of us have already been
>> discussing the issue, and started to investigate options.
>>
>> https://sourceforge.net/p/inkscape/mailman/inkscape-translator/thread/CAPOH7%3DZn3sWhZ%3D1DDB-1FUp%2BQUZzrLmyy7iOFiL1VcfY0maG9g%40mail.gmail.com/#msg35807172
>>
>> Victor (who initiated the thread) has already written about his findings
>> about Sphinx there, and he also linked to a list on github, where
>> different documentation systems are listed (sorry, your latest email is
>> still on my todo list, Victor).
>>
>> Elisa has mentioned the Booktype instance of flossmanualsfr, as far as I
>> remember.
>>
>> Regards,
>>  Maren
>>
>> Am 29.04.2017 um 00:17 schrieb Martin Owens:
>>> On Sat, 2017-04-29 at 00:01 +0200, Maren Hachmann wrote:
 Would it make sense to use gitlab's new subgroups feature for this?

 The inkscape-docs team could be a sub-team of Inkscape, that way.
 There
 are only 4 members as of now, so changing wouldn't be so difficult as
 it
 might be later on.
>>>
>>> Agreed.
>>>
>>> I've moved everything around and re-added the members to the group.
>>>
>>> Project is now: https://gitlab.com/inkscape/inkscape-docs/manuals
>>> Group is now: https://gitlab.com/inkscape/inkscape-docs
>>>
>>> Best Regards, Martin Owens
>>>
>>
>>
>> --
>> 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-de...@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-docs mailing list
Inkscape-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Great :)

I think, in this context, it makes sense to also link to the thread on
the translators mailing list, where many of us have already been
discussing the issue, and started to investigate options.

https://sourceforge.net/p/inkscape/mailman/inkscape-translator/thread/CAPOH7%3DZn3sWhZ%3D1DDB-1FUp%2BQUZzrLmyy7iOFiL1VcfY0maG9g%40mail.gmail.com/#msg35807172

Victor (who initiated the thread) has already written about his findings
about Sphinx there, and he also linked to a list on github, where
different documentation systems are listed (sorry, your latest email is
still on my todo list, Victor).

Elisa has mentioned the Booktype instance of flossmanualsfr, as far as I
remember.

Regards,
 Maren

Am 29.04.2017 um 00:17 schrieb Martin Owens:
> On Sat, 2017-04-29 at 00:01 +0200, Maren Hachmann wrote:
>> Would it make sense to use gitlab's new subgroups feature for this?
>>
>> The inkscape-docs team could be a sub-team of Inkscape, that way.
>> There
>> are only 4 members as of now, so changing wouldn't be so difficult as
>> it
>> might be later on.
> 
> Agreed.
> 
> I've moved everything around and re-added the members to the group.
> 
> Project is now: https://gitlab.com/inkscape/inkscape-docs/manuals
> Group is now: https://gitlab.com/inkscape/inkscape-docs
> 
> Best Regards, Martin Owens
> 


--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Martin Owens]

On Sat, 2017-04-29 at 00:01 +0200, Maren Hachmann wrote:
> Would it make sense to use gitlab's new subgroups feature for this?
> 
> The inkscape-docs team could be a sub-team of Inkscape, that way.
> There
> are only 4 members as of now, so changing wouldn't be so difficult as
> it
> might be later on.

Agreed.

I've moved everything around and re-added the members to the group.

Project is now: https://gitlab.com/inkscape/inkscape-docs/manuals
Group is now: https://gitlab.com/inkscape/inkscape-docs

Best Regards, Martin Owens

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Maren Hachmann]

Would it make sense to use gitlab's new subgroups feature for this?

The inkscape-docs team could be a sub-team of Inkscape, that way. There
are only 4 members as of now, so changing wouldn't be so difficult as it
might be later on.

Maren

> Am 28.04.2017 um 16:14 schrieb Martin Owens:
>> On Fri, 2017-04-28 at 12:39 +0100, C R wrote:
>>> I'd love to quit my job and just do docs. :) Unfortunately, that's
>>> what it would probably take to get docs going to the extent we'd
>>> like.
>>> It's been discussed before, but never gone anywhere because of lack
>>> of time/hands involved.
>>>
>>> Yes, we should use Scribus to do it. In fact, it should probably be a
>>> github project to attract contributors. This way we can patch what
>>> needs to be patched when stuff changes in subsequent releases.
>>
>> Sounds like you have a solid step one Chris.
>>
>> Here's the inkscape-docs group on gitlab, EVERYONE should join, there
>> should be a button to join:
>>
>> https://gitlab.com/inkscape-docs
>>
>> And here's the new book/manual/docs project where files can be put:
>>
>> https://gitlab.com/inkscape/manuals
>>
>> I recommend using the wiki attached to the project to plan the
>> adventure slowly. Add a bit at a time and don't rush to have something
>> "complete" but have something small produced.
>>
>> Best Regards, Martin Owens
>>
>>
>> --
>> 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-de...@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-docs mailing list
Inkscape-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Victor Westmann]

Already subscribed to the doc project on Gitlab.

Sorry guys. I know I do am asking for a LOT... but it never hurts to gather
opinions from others as well.

Cheers,



--Victor Westmann

2017-04-28 7:14 GMT-07:00 Martin Owens :

> On Fri, 2017-04-28 at 12:39 +0100, C R wrote:
> > I'd love to quit my job and just do docs. :) Unfortunately, that's
> > what it would probably take to get docs going to the extent we'd
> > like.
> > It's been discussed before, but never gone anywhere because of lack
> > of time/hands involved.
> >
> > Yes, we should use Scribus to do it. In fact, it should probably be a
> > github project to attract contributors. This way we can patch what
> > needs to be patched when stuff changes in subsequent releases.
>
> Sounds like you have a solid step one Chris.
>
> Here's the inkscape-docs group on gitlab, EVERYONE should join, there
> should be a button to join:
>
> https://gitlab.com/inkscape-docs
>
> And here's the new book/manual/docs project where files can be put:
>
> https://gitlab.com/inkscape/manuals
>
> I recommend using the wiki attached to the project to plan the
> adventure slowly. Add a bit at a time and don't rush to have something
> "complete" but have something small produced.
>
> Best Regards, Martin Owens
>
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Re: [Inkscape-docs] [Inkscape-devel] Any chance we can make some docs material? (targeting the moon)

[Martin Owens]

On Fri, 2017-04-28 at 12:39 +0100, C R wrote:
> I'd love to quit my job and just do docs. :) Unfortunately, that's
> what it would probably take to get docs going to the extent we'd
> like.
> It's been discussed before, but never gone anywhere because of lack
> of time/hands involved.
> 
> Yes, we should use Scribus to do it. In fact, it should probably be a
> github project to attract contributors. This way we can patch what
> needs to be patched when stuff changes in subsequent releases.

Sounds like you have a solid step one Chris.

Here's the inkscape-docs group on gitlab, EVERYONE should join, there
should be a button to join:

https://gitlab.com/inkscape-docs

And here's the new book/manual/docs project where files can be put:

https://gitlab.com/inkscape/manuals

I recommend using the wiki attached to the project to plan the
adventure slowly. Add a bit at a time and don't rush to have something
"complete" but have something small produced.

Best Regards, Martin Owens


--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-docs