On 4/23/05, John Taber <jtaber@...480...> wrote:
Very nice. It makes it even easier for some of us to contribute to the documentation. Question: what are you going to use to display the html in Inkscape? gtkhtml? mozembed?
No, Inkscape does not display HTML. In Inkscape, tutorials remain in SVG. The only difference is that now, that SVG is generated from the DocBook source, as is HTML.
And wondering if you had any plans to display the images in SVG as opposed to PNG - thinking that maybe mozembed might support SVG with the new SVG rendering in Firefox.
Maybe, but this does not make much sense. The idea of the illustrations is that they are interactive - you can drag or tweak anything in a tutorial. Since HTML loses the interactivity anyway, SVG is not any better for illustrations in HTML than PNG. The HTML is mainly intended for printing or away-from-Inkscape reading.
This sounds really great. Is this the process? docbook =>(via XSLT)=> svg + html => (modify docs) => convert to svg output helpfile => render helpfile in Inkscape? Then I guess one could also simply load the output svg file into a gtk image and place it into a frame with scrollbars? Obviously static, but great for output display. Is there something like a wiki on this to read? Sidenote: what editor is being used for docbook writing? John
On Saturday 23 April 2005 10:21, bulia byak wrote:
On 4/23/05, John Taber <jtaber@...480...> wrote:
Very nice. It makes it even easier for some of us to contribute to the documentation. Question: what are you going to use to display the html in Inkscape? gtkhtml? mozembed?
No, Inkscape does not display HTML. In Inkscape, tutorials remain in SVG. The only difference is that now, that SVG is generated from the DocBook source, as is HTML.
And wondering if you had any plans to display the images in SVG as opposed to PNG - thinking that maybe mozembed might support SVG with the new SVG rendering in Firefox.
Maybe, but this does not make much sense. The idea of the illustrations is that they are interactive - you can drag or tweak anything in a tutorial. Since HTML loses the interactivity anyway, SVG is not any better for illustrations in HTML than PNG. The HTML is mainly intended for printing or away-from-Inkscape reading.
On 4/23/05, John Taber <jtaber@...480...> wrote:
This sounds really great. Is this the process? docbook =>(via XSLT)=> svg + html
Yes
=> (modify docs) => convert to svg output helpfile => render helpfile in Inkscape?
In this part, when you need to modify anything, you modify the docbook and regenerate SVG and HTML from it.
Other formats can be added if needed; one possibility is PDF (via XSL-FO). Another is paginated SVG (when Inkscape supports multipage).
Then I guess one could also simply load the output svg file into a gtk image and place it into a frame with scrollbars? Obviously static, but great for output display.
Probably, though HTML is likely easier for static display.
Is there something like a wiki on this to read?
Not yet
Sidenote: what editor is being used for docbook writing?
I use my XEmacs for everything :)
Okay, when I get this all figured out, if you want, I will make my first contribution on this as a guide for beginning volunteers like myself on how they can contribute documentation.
I understand the first part of creating the svg + html from docbook but as you mentioned, documentation is displayed in Inkscape as a svg file, right? So then doesn't the (svg+html) have to be converted back to a single svg file so that Inkscape can render it? Or then what is the purpose of creating the html? I was thinking the purpose was for the user to write docs in html but it sounds like all documentation would still be written in docbook. Can you help me understand? John
On Saturday 23 April 2005 11:43, bulia byak wrote:
On 4/23/05, John Taber <jtaber@...480...> wrote:
This sounds really great. Is this the process? docbook =>(via XSLT)=> svg + html
Yes
=> (modify docs) => convert to svg output helpfile => render helpfile in Inkscape?
In this part, when you need to modify anything, you modify the docbook and regenerate SVG and HTML from it.
Other formats can be added if needed; one possibility is PDF (via XSL-FO). Another is paginated SVG (when Inkscape supports multipage).
Then I guess one could also simply load the output svg file into a gtk image and place it into a frame with scrollbars? Obviously static, but great for output display.
Probably, though HTML is likely easier for static display.
Is there something like a wiki on this to read?
Not yet
Sidenote: what editor is being used for docbook writing?
I use my XEmacs for everything :)
On Sat, Apr 23, 2005 at 12:21:19PM -0600, John Taber wrote:
I understand the first part of creating the svg + html from docbook but as you mentioned, documentation is displayed in Inkscape as a svg file, right? So then doesn't the (svg+html) have to be converted back to a single svg file so that Inkscape can render it? Or then what is the purpose of creating the html? I was thinking the purpose was for the user to write docs in html but it sounds like all documentation would still be written in docbook. Can you help me understand?
Ah... bit of confusion. The use of DocBook means you edit one file, and produce a variety of different files for use in Inkscape, printing, viewing on the web, etc.
+------------+ +---> SVG | DocBook | | | Source |-----> Processor --+---> HTML | Text | | +------------+ +---> PDF
^ ^ | | Edit here View/Read any of these
Bryce
On 4/23/05, John Taber <jtaber@...480...> wrote:
Okay, when I get this all figured out, if you want, I will make my first contribution on this as a guide for beginning volunteers like myself on how they can contribute documentation.
I understand the first part of creating the svg + html from docbook but as you mentioned, documentation is displayed in Inkscape as a svg file, right? So then doesn't the (svg+html) have to be converted back to a single svg file so that Inkscape can render it? Or then what is the purpose of creating the html? I was thinking the purpose was for the user to write docs in html but it sounds like all documentation would still be written in docbook. Can you help me understand?
Sure. This is called single-source. Your text in DocBook/XML is always the source. Both HTML and SVG versions of your guide are created from your DocBook/XML file. Every time you want to modify your guide, you edit your docbook/xml file, and then you run conversion script to produce HTML and SVG versions.
Alexandre
On 4/23/05, John Taber <jtaber@...480...> wrote:
Okay, when I get this all figured out, if you want, I will make my first contribution on this as a guide for beginning volunteers like myself on how they can contribute documentation.
Thanks :)
I understand the first part of creating the svg + html from docbook but as you mentioned, documentation is displayed in Inkscape as a svg file, right?
Yes
So then doesn't the (svg+html) have to be converted back to a single svg file so that Inkscape can render it?
No, in Inkscape everything is in a single SVG file, both text and illustrations. In HTML rendition, text is in HTML and illustrations are in PNG. In the _source_, text is DocBook and illustrations are separate SVG files, one per illustration.
Or then what is the purpose of creating the html?
So it can be printed, read away from Inkscape, searched, indexed by Google, etc. etc.
I was thinking the purpose was for the user to write docs in html but it sounds like all documentation would still be written in docbook.
Yes. You write in DocBook (with SVG illustrations) and get HTML+PNG and single-file-SVG from that automatically.
Maybe this has been addressed or discussed before, but for us, using the Bezier tool button for drawing straight lines leads to a lot of mis-clicks/drags resulting in getting bezier curves when we want straight lines. Since the line tool is used so much, it would be nicer to have a separate button for straight lines and polygons - openoffice draw has this and it's much easier to use. Any thoughts? John
On 4/23/05, John Taber <jtaber@...480...> wrote:
Maybe this has been addressed or discussed before, but for us, using the Bezier tool button for drawing straight lines leads to a lot of mis-clicks/drags resulting in getting bezier curves when we want straight lines.
Try increasing the "Click/drag threshold" in the Inkscape prefs (Mouse page). This value is how many pixels you need to drag to get a drag, not click. Larger values make the mouse less sensitive to slips and jerks when clicking.
Since the line tool is used so much, it would be nicer to have a separate button for straight lines and polygons - openoffice draw has this and it's much easier to use. Any thoughts?
I don't think a separate tool is necessary.
bulia byak wrote:
I don't think a separate tool is necessary.
Well, yes. You don't need one, since you know.
:-)
It's the poor unwashed masses who jump in it the first time who need a bit of help.
However... at the moment I think there's a decent balance. The icon conveys the dual nature, the tooltip is informative, and use is fairly coherent. I do see where for many a dedicated tool could come in handy. But better than that, I think perhaps the need could be solved by adding a keyboard modifyier to prevent the segments from going curved.
The key constraint thing is probably the best approach.
Hmmm... but we do happen to have the secondary toolbar. That could also be a decent place to mirror the constraint.
John Taber wrote:
Maybe this has been addressed or discussed before, but for us, using the Bezier tool button for drawing straight lines leads to a lot of mis-clicks/drags resulting in getting bezier curves when we want straight lines. Since the line tool is used so much, it would be nicer to have a separate button for straight lines and polygons - openoffice draw has this and it's much easier to use. Any thoughts?
Agreed.
participants (6)
-
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
John Taber -
Jon A. Cruz -
Jonathan Leighton