Hi,
Thanks for the update.. I got occupied with something and it took me a little longer than I thought. But I have the sync of lostwages to docs faq in my tree.
I will now rm -rf it
Regards,
Tom
On Wed, 20 Aug 2003, Tom wrote:
Hi,
Thanks for the update.. I got occupied with something and it took me a little longer than I thought. But I have the sync of lostwages to docs faq in my tree.
I will now rm -rf it
I think you should not. The update I made is not to sync lostwages with the Wine FAQ, just some points that I felt needed to be addressed. So your updates are probably still very much needed.
Francois Gouget wrote:
On Wed, 20 Aug 2003, Tom wrote:
Hi,
Thanks for the update.. I got occupied with something and it took me a little longer than I thought. But I have the sync of lostwages to docs faq in my tree.
I will now rm -rf it
I think you should not. The update I made is not to sync lostwages with the Wine FAQ, just some points that I felt needed to be addressed. So your updates are probably still very much needed.
I will wait for your changes to go into cvs then I will send my patch(s). Should I send two patches lostwages to docs, docs to lostwages ? Where they will both be in sync at the same time. Or just one patch to docs and we could build a html of it and place it in lostwages.. I have three free day's next week I will have it done by then. how would you prefer me to do this.
Tom
On Wed, 20 Aug 2003, Tom wrote: [...]
I will wait for your changes to go into cvs then I will send my patch(s). Should I send two patches lostwages to docs, docs to lostwages ? Where they will both be in sync at the same time. Or just one patch to docs and we could build a html of it and place it in lostwages.. I have three free day's next week I will have it done by then. how would you prefer me to do this.
I think the way to go is to send one patch to fix faq.sgml, and then someone will build the FAQ html file and put it on the web site.
Jeremy, the documentation section of http://www.winehq.com is updated automatically right? Can we do the same thing for the FAQ?
On Thu, 2003-08-21 at 05:35, Francois Gouget wrote:
I think the way to go is to send one patch to fix faq.sgml, and then someone will build the FAQ html file and put it on the web site.
Jeremy, the documentation section of http://www.winehq.com is updated automatically right? Can we do the same thing for the FAQ?
Yes the docs are built when we do an official wine release. But, I don't see a way to update the lostwages version of the FAQ easily. The HTML generated by the SGML parser is ugly. We could write a script that strips out the header and body tags so it's just the content. For now, someone (ie Tom) could just submit a patch for the website version.
Jeremy Newman wrote:
On Thu, 2003-08-21 at 05:35, Francois Gouget wrote:
I think the way to go is to send one patch to fix faq.sgml, and then someone will build the FAQ html file and put it on the web site.
Jeremy, the documentation section of http://www.winehq.com is updated automatically right? Can we do the same thing for the FAQ?
Yes the docs are built when we do an official wine release. But, I don't see a way to update the lostwages version of the FAQ easily. The HTML generated by the SGML parser is ugly. We could write a script that strips out the header and body tags so it's just the content. For now, someone (ie Tom) could just submit a patch for the website version.
I will send two patches and have both in sync. I can keep the lostwages FAQ in sync as the FAQ should only recieve a couple nice updates a year. Well in theory anyway....
Tom
On 21 Aug 2003, Jeremy Newman wrote: [...]
Yes the docs are built when we do an official wine release. But, I don't see a way to update the lostwages version of the FAQ easily. The HTML generated by the SGML parser is ugly. We could write a script that strips out the header and body tags so it's just the content. For now, someone (ie Tom) could just submit a patch for the website version.
Well, that a problem. We cannot maintain have two versions of the FAQ. It too much work and they will never be in sync.
I can see that one problem with the generated HTML is that it a standalone HTML pages whereas for the web site we need something that can be included by the PHP template system. But it seems that it should be easy to strip anything before <body> and after </body>, even manually.
What are the other problems with the generated HTML?
Clearly we have the same issue with the documentation but the same solution can be applied to both cases. Maybe if you provide the requirements someone will volunteer to write a script to post-process the generated HTML files or do some DSSL hack to generate the right thing from the start?
On Thu, 2003-08-21 at 19:19, Francois Gouget wrote:
What are the other problems with the generated HTML?
For the docs the hyperlinks would need to be changed.
Clearly we have the same issue with the documentation but the same solution can be applied to both cases. Maybe if you provide the requirements someone will volunteer to write a script to post-process the generated HTML files or do some DSSL hack to generate the right thing from the start?
I don't play with SGML much, but it should be possible to have the SGML output a modified HTML format, John Sheets did it once for me to have the SGML output SHTML with the correct includes. If we could get it to output in my .template format with the correct paths for links, then everyone would be happy.
On August 21, 2003 10:20 pm, Jeremy Newman wrote:
I don't play with SGML much, but it should be possible to have the SGML output a modified HTML format, John Sheets did it once for me to have the SGML output SHTML with the correct includes. If we could get it to output in my .template format with the correct paths for links, then everyone would be happy.
Would that allow us to get rid of the SHTML for Docs? Whatever happened to the patch I sent it long time ago to simply publish the HTML instead of the SHTML? Why are we keeping the darn thing?
On Thu, 2003-08-21 at 22:30, Dimitrie O. Paun wrote:
On August 21, 2003 10:20 pm, Jeremy Newman wrote:
I don't play with SGML much, but it should be possible to have the SGML output a modified HTML format, John Sheets did it once for me to have the SGML output SHTML with the correct includes. If we could get it to output in my .template format with the correct paths for links, then everyone would be happy.
Would that allow us to get rid of the SHTML for Docs? Whatever happened to the patch I sent it long time ago to simply publish the HTML instead of the SHTML? Why are we keeping the darn thing?
Yes, finally it would. And... I know you'll like the fact the docs would then match the site design.
Your patch sat on the back burner so long it burnt up and disappeared. Oops. ;)
On 21 Aug 2003, Jeremy Newman wrote:
On Thu, 2003-08-21 at 19:19, Francois Gouget wrote:
What are the other problems with the generated HTML?
For the docs the hyperlinks would need to be changed.
Currently we get relative links to shtml files, e.g.: <a href="introduction.shtml">Introduction</a>
What would we need? Something like this? <a href="introduction">Introduction</a>
It turns out this would be trivial (I'm quite surprised). The following patch would do it: (it's bit more complex because we would only want to do it when generating the doc for WineHQ, but still...)
Index: default.dsl =================================================================== RCS file: /home/wine/wine/documentation/default.dsl,v retrieving revision 1.1 diff -u -r1.1 default.dsl --- default.dsl 13 Dec 2000 21:52:37 -0000 1.1 +++ default.dsl 22 Aug 2003 10:54:30 -0000 @@ -8,7 +8,7 @@ <style-specification-body>
(define %use-id-as-filename% #t) -(define %html-ext% ".html") +(define %html-ext% "") (define %html-header-tags% '())
;;(define %stylesheet% "../../winehq.css")
[...]
I don't play with SGML much, but it should be possible to have the SGML output a modified HTML format, John Sheets did it once for me to have the SGML output SHTML with the correct includes. If we could get it to output in my .template format with the correct paths for links, then everyone would be happy.
Except for editing documents I'm not very familiar with SGML either.
From my understanding, all we want to do should be feasible in DSSSL. We
already have a bit of DSSSL code in documentation/default.dsl so this may be used as a starting point. Here are some more resources.
http://www.jclark.com/dsssl/ http://docbook.sourceforge.net/projects/dsssl/
So this is a call for volunteers. Could someone write some DSSL code so we only output the stuff that's supposed to go inside the '<body>' tag. I have looke a little bit into this but I did not find an obvious way to do it.
On Fri, 2003-08-22 at 06:05, Francois Gouget wrote:
On 21 Aug 2003, Jeremy Newman wrote:
On Thu, 2003-08-21 at 19:19, Francois Gouget wrote:
What are the other problems with the generated HTML?
For the docs the hyperlinks would need to be changed.
Currently we get relative links to shtml files, e.g.: <a href="introduction.shtml">Introduction</a>
What would we need? Something like this? <a href="introduction">Introduction</a>
Yes, that would be fine, the actual url would then be: http://www.winehq.org/site/docs/wine-user/introduction
I would need to update the site engine to know how to handle the docs virtual path. I would place the newly generated docs into the website path as: templates/en/docs/wine-[user|devel]/*.template They would not need to be in CVS then, I would just put a .cvsignore in the templates/en dir to skip the docs dir.
The actual format of the .template is as follows:
- No <html><head><body> tags. Just the content. ie, everything that would be between the <body> tags. - the page title is specified via the first line in the .template file as: <!--TITLE:[Title Goes Here]-->
The benefits of this would that the docs then would then match the rest of the website.
On 22 Aug 2003, Jeremy Newman wrote: [...]
- No <html><head><body> tags. Just the content. ie, everything that
would be between the <body> tags.
I have a Perl script that does that part. Should be easy to extend to also extract the title... Here goes as a starting point. Maybe I'll work a bit more on it tomorrow but if anyone feels like hacking on it, feel free!
#!/usr/bin/perl -w use strict; use File::Copy;
my $filename=$ARGV[0]; print " $filename\n";
#FIXME:assuming that because there is a .bak file, this is what we want is #probably flawed. Or is it??? if (! -e "$filename.bak") { if (!copy("$filename","$filename.bak")) { print STDERR "error: unable to make a backup of $filename:\n"; print STDERR " $!\n"; return; } } if (!open(FILEI,"$filename.bak")) { print STDERR "error: unable to open $filename.bak for reading:\n"; print STDERR " $!\n"; return; } if (!open(FILEO,">$filename")) { print STDERR "error: unable to open $filename for writing:\n"; print STDERR " $!\n"; return; }
my $line; while ($line=<FILEI>) { if ($line =~ s/<body[^>]*>//i) { print "matched <body>: $line"; last; } elsif ($line =~ s/<body[^>]*$//i) { print "matched <body: $line"; while ($line=<FILEI>) { print "looking for > $line"; if ($line =~ s/^[^>]*>//i) { last; } } last; } }
print FILEO $line; while ($line=<FILEI>) { if ($line =~ s/</body//i) { print FILEO $line; last; } print FILEO $line; }
close FILEI; close FILEO;
exit 0;
Ok, here is yet another update. This one can be applied to the Wine CVS and modifies the make_winehq script to generate files that will hopefully be directly usable by the web site. Here is what we generate:
* the same html, ps and pdf files as before * a special set of files that contain links to 'xxx' rather than 'xxx.html'. * files called 'xxx.template' instead of 'xxx.html' * the xxx.template files start with a line indicating the title: <!--TITLE:Wine User Guide--> * then they contain the regular HTML code generated by DocBook except anything outside the <body> tags has been stripped. * this applies to all Wine's DocBook guides: wine-user, wine-devel, winelib-user and of course wine-faq. This means it should now be possible to very simply integrate the Wine documentation in the web site.
I'll upload the tgz files that I generated to my site as soon as the ftp server starts working again. In the meantime you can generate these files yourself by applying to the Wine CVS, and then do:
cd documentation ./make_winehq
The tgz files will be in www.winehq.com as usual.
(I also factorized the make_winehq code a bit which I can submit separately)
So does this look ok?
Index: documentation/make_winehq =================================================================== RCS file: /home/wine/wine/documentation/make_winehq,v retrieving revision 1.9 diff -u -r1.9 make_winehq --- documentation/make_winehq 20 Apr 2003 02:43:22 -0000 1.9 +++ documentation/make_winehq 6 Sep 2003 23:27:13 -0000 @@ -26,60 +26,57 @@ fi mkdir "$WWWDIR"
-## Create five-book HTML tarball -echo "db2html wine-user.sgml" -db2html wine-user.sgml -echo "db2html wine-devel.sgml" -db2html wine-devel.sgml -echo "db2html winelib-user.sgml" -db2html winelib-user.sgml -echo "db2html wine-faq.sgml" -db2html wine-faq.sgml -tar czf winedoc-html.tgz wine-user wine-devel winelib-user wine-faq +ALL_BOOKS="wine-user wine-devel winelib-user wine-faq" + +## Create the HTML tarball +for book in $ALL_BOOKS +do + echo "db2html $book.sgml" + db2html $book.sgml +done +tar czf winedoc-html.tgz $ALL_BOOKS cp winedoc-html.tgz "$WWWDIR"
-## Create PostScript tarball -echo "db2ps -d ./print.dsl wine-user.sgml" -db2ps -d ./print.dsl wine-user.sgml > /dev/null 2>&1 -echo "db2ps -d ./print.dsl wine-devel.sgml" -db2ps -d ./print.dsl wine-devel.sgml > /dev/null 2>&1 -echo "db2ps -d ./print.dsl winelib-user.sgml" -db2ps -d ./print.dsl winelib-user.sgml > /dev/null 2>&1 -echo "db2ps -d ./print.dsl wine-faq.sgml" -db2ps -d ./print.dsl wine-faq.sgml > /dev/null 2>&1 -tar czf winedoc-ps.tgz wine-user.ps wine-devel.ps winelib-user.ps wine-faq.ps +## Create the PostScript tarball +all_ps="" +for book in $ALL_BOOKS +do + echo "db2ps -d ./print.dsl $book.sgml" + db2ps -d ./print.dsl $book.sgml >/dev/null 2>&1 + all_ps="$all_ps $book.ps" +done +tar czf winedoc-ps.tgz $all_ps cp winedoc-ps.tgz "$WWWDIR"
-## Create PDF tarball -echo "db2pdf -d ./print.dsl wine-user.sgml" -db2pdf -d ./print.dsl wine-user.sgml > /dev/null 2>&1 -echo "db2pdf -d ./print.dsl wine-devel.sgml" -db2pdf -d ./print.dsl wine-devel.sgml > /dev/null 2>&1 -echo "db2pdf -d ./print.dsl winelib-user.sgml" -db2pdf -d ./print.dsl winelib-user.sgml > /dev/null 2>&1 -echo "db2pdf -d ./print.dsl wine-faq.sgml" -db2pdf -d ./print.dsl wine-faq.sgml > /dev/null 2>&1 -tar czf winedoc-pdf.tgz wine-user.pdf wine-devel.pdf winelib-user.pdf wine-faq.pdf +## Create the PDF tarball +all_pdf="" +for book in $ALL_BOOKS +do + echo "db2pdf -d ./print.dsl $book.sgml" + db2pdf -d ./print.dsl $book.sgml >/dev/null 2>&1 + all_pdf="$all_pdf $book.pdf" +done +tar czf winedoc-pdf.tgz $all_pdf cp winedoc-pdf.tgz "$WWWDIR"
-## Create SGML tarball +## Create the SGML tarball echo "Creating SGML package..." tar czf winedoc-sgml.tgz *.sgml *.dsl *.ent cp winedoc-sgml.tgz "$WWWDIR"
## Done creating downloadable tarballs for users. Now we want to -## create a tarball of SHTML in a slightly different form, for the -## website. These versions use special server-side includes which -## aren't appropriate outside of winehq.com. - -## Create four-book SHTML tarball -echo "db2html wine-user.sgml" -db2html wine-user.sgml -echo "db2html wine-devel.sgml" -db2html wine-devel.sgml -echo "db2html winelib-user.sgml" -db2html winelib-user.sgml -echo "db2html wine-faq.sgml" -db2html wine-faq.sgml -tar czf winehq-shtml.tgz wine-user wine-devel winelib-user wine-faq -cp winehq-shtml.tgz "$WWWDIR" +## create a tarball of templates in a slightly different form, for the +## website. +for book in $ALL_BOOKS +do + echo "db2html -d ./winehq.dsl $book.sgml" + db2html -d ./winehq.dsl $book.sgml + echo "-> converting to the .template format" + for file in $book/* + do + perl make_winehq_template "$file" >"$file.template" + rm "$file" + done +done +tar czf winehq-templates.tgz $ALL_BOOKS +cp winehq-templates.tgz "$WWWDIR" Index: documentation/winehq.dsl =================================================================== RCS file: /home/wine/wine/documentation/winehq.dsl,v retrieving revision 1.2 diff -u -r1.2 winehq.dsl --- documentation/winehq.dsl 26 Sep 2001 23:02:31 -0000 1.2 +++ documentation/winehq.dsl 6 Sep 2003 23:27:13 -0000 @@ -8,7 +8,7 @@ <style-specification-body>
(define %use-id-as-filename% #t) -(define %html-ext% ".shtml") +(define %html-ext% "") (define %html-header-tags% '())
(define %stylesheet% "../../winehq.css") @@ -16,18 +16,6 @@
(define %shade-verbatim% #t) (define %section-autolabel% #t) - -;; Define new HTML headers -(define ($html-body-start$) - (make sequence - (make formatting-instruction data: "<!--") - (literal "#include file="header.html" ") - (make formatting-instruction data: "-->"))) -(define ($html-body-end$) - (make sequence - (make formatting-instruction data: "<!--") - (literal "#include file="footer.html" ") - (make formatting-instruction data: "-->")))
;; Customize the body tag attributes ;;(define %body-attr% --- /dev/null 2003-02-03 19:32:02.000000000 +0100 +++ documentation/make_winehq_template 2003-09-06 14:15:47.000000000 +0200 @@ -0,0 +1,73 @@ +#!/usr/bin/perl -w +use strict; +use File::Copy; + +my $filename=$ARGV[0]; + +if (!open(FILEI,"$filename")) +{ + print STDERR "error: unable to open $filename.bak for reading:\n"; + print STDERR " $!\n"; + return; +} + +sub skip_to_gt($) +{ + my $line=$_[0]; + while (defined $line) + { + return $line if ($line =~ s/^[^>]*>//i); + $line=<FILEI>; + } + return undef; +} + +sub grab_cdata($) +{ + my $line=$_[0]; + my $cdata; + while (defined $line) + { + if ($line =~ s/^([^<]*)<.*$/$1/i) + { + chomp $line; + $cdata=(defined $cdata?"$cdata $line":$line); + return ($cdata,$line); + } + chomp $line; + $cdata=(defined $cdata?"$cdata $line":$line); + $line=<FILEI>; + } + return ($cdata,$line); +} + +my $line; +while ($line=<FILEI>) +{ + if ($line =~ s/^.*<title\s*//i) + { + $line=skip_to_gt($line); + my ($title,$line)=grab_cdata($line); + print "<!--TITLE:$title-->\n"; + } + elsif ($line =~ s/^.*<body//i) + { + $line=skip_to_gt($line); + last; + } +} + +print $line; +while ($line=<FILEI>) +{ + if ($line =~ s/</body.*$//i) + { + print $line; + last; + } + print $line; +} + +close FILEI; + +exit 0;
On Sun, 7 Sep 2003, Francois Gouget wrote: [...]
I'll upload the tgz files that I generated to my site as soon as the ftp server starts working again.
Ok, I managed to upload the files. See:
http://fgouget.free.fr/tmp/wine/
The most insteresting one is 'winehq-templates.tgz' which contains the templates for use on WineHQ. Le me know if something needs changing.
On September 6, 2003 07:43 pm, Francois Gouget wrote:
So does this look ok?
Pretty good -- maybe we can finally close this task which has been haunting as for a year almost...
+## create a tarball of templates in a slightly different form, for the +## website. +for book in $ALL_BOOKS +do
- echo "db2html -d ./winehq.dsl $book.sgml"
- db2html -d ./winehq.dsl $book.sgml
- echo "-> converting to the .template format"
- for file in $book/*
- do
- perl make_winehq_template "$file" >"$file.template"
- rm "$file"
- done
+done
Do we still need the winehq.dsl? It would be nice to use just the regular HTML files that we have generated already, as those use the site HTML .dsl. That would be possible with your script to trim the header and footer, plus a bit of elbow greese in the form of some URL rewritting in .htaccess.
--- /dev/null 2003-02-03 19:32:02.000000000 +0100 +++ documentation/make_winehq_template 2003-09-06 14:15:47.000000000 +0200
This one, and make_winehq script should be moved to the tools module, as we discussed before. It may make sense to place it here for now, and do the move as a separate step though.
On Mon, 8 Sep 2003, Dimitrie O. Paun wrote: [...]
Do we still need the winehq.dsl? It would be nice to use just the regular HTML files that we have generated already, as those use the site HTML .dsl. That would be possible with your script to trim the header and footer, plus a bit of elbow greese in the form of some URL rewritting in .htaccess.
As far as I can see the differences between winehq.dsl and default .dsl are: * for the extension. If that can be avoided by using .htaccess, whynot. But I'll let Jeremy decide which solution he prefers. * winehq.dsl references the WineHQ css (Cascading Style Sheets) file. That's a good thing. * default.dsl specifies a bunch of attributes to set the colors and things like this * default.dsl also specifies that some elements should be italic which maybe we should do in winehq.dsl too although with the cascading style sheets I'm not sure it's necessary.
--- /dev/null 2003-02-03 19:32:02.000000000 +0100 +++ documentation/make_winehq_template 2003-09-06 14:15:47.000000000 +0200
This one, and make_winehq script should be moved to the tools module, as we discussed before. It may make sense to place it here for now, and do the move as a separate step though.
I think it's fine in the documentation directory but if Alexandre wants to move it that's ok with me.
In any case, what we can do is merge make_winehq_template into make_winehq so that we have a single script. That is, make_winehq would become a perl script that would contain the make_winehq_template filtering code as well as code that invokes the appropriate tars and db2html operations.
Francois Gouget fgouget@free.fr writes:
I think it's fine in the documentation directory but if Alexandre wants to move it that's ok with me.
Yes it should be moved to the tools CVS module, it does not belong in the Wine tree.
On Mon, 2003-09-08 at 13:26, Alexandre Julliard wrote:
Francois Gouget fgouget@free.fr writes:
I think it's fine in the documentation directory but if Alexandre wants to move it that's ok with me.
Yes it should be moved to the tools CVS module, it does not belong in the Wine tree.
I checked the wine_release script into the tools CVS, so it can be cleaned up a bit more easily now.
I wanted to point out that some docs will need to be updated, read this page: http://www.winehq.org/site/docs/wine-devel/wine-docbook
Step 7 tells us to run make_winehq. That part needs to be corrected if the script gets pulled.
Francois, could you update the script, rename it to wine_makedocs and submit a patch for the tools CVS? The wine_release script will also need to be patched to know where this script is located. It should be in the same dir as wine_release so a "sh ./wine_makedocs" would be fine.
On September 8, 2003 01:23 pm, Francois Gouget wrote:
As far as I can see the differences between winehq.dsl and default .dsl
Well, if we keep winehq.dsl, why do we need a perl script to patch the output? The HTML stuff should be generated with the site default.dsl anyway. We should instead patch winehq.dsl to generate the required output instead. And it should be moved to the tools/ CVS module as well.
On Tue, 9 Sep 2003, Dimitrie O. Paun wrote:
On September 8, 2003 01:23 pm, Francois Gouget wrote:
As far as I can see the differences between winehq.dsl and default .dsl
Well, if we keep winehq.dsl, why do we need a perl script to patch the output? The HTML stuff should be generated with the site default.dsl anyway. We should instead patch winehq.dsl to generate the required output instead.
The problems with that are: * not everything seems easy to do by tweaking the DSL file (e.g. removing everything outside the body tag) * reciprocally some things (tweaking the URLs) are simpler (safer) to do in the .dsl file than in perl * apparently nobody knows how these .dsl files work * default.dsl specifies attributes that hard-code the coulor and style of various HTML elements. That's fine for standalone HTML files but it's wrong for a web site where such things should be specified by the cascading style sheets
And it should be moved to the tools/ CVS module as well.
No problem. I thought you guys wanted to move it to Wine's tools directory...
On September 9, 2003 05:28 am, Francois Gouget wrote:
- default.dsl specifies attributes that hard-code the coulor and style
of various HTML elements. That's fine for standalone HTML files but it's wrong for a web site where such things should be specified by the cascading style sheets
It's fine to use CSS for the .template ones that we're going to server from the site. However, for the HTML we package, we shouldn't IMO. If they need such thing, they would have a custom default.dsl or some such. That's the very point -- we should allow the user to choose the L&F, not impose one; this is the purpose of having a site wide default.dsl.
On Tue, 9 Sep 2003, Dimitrie O. Paun wrote: [...]
It's fine to use CSS for the .template ones that we're going to server from the site. However, for the HTML we package, we shouldn't IMO. If they need such thing, they would have a custom default.dsl or some such. That's the very point -- we should allow the user to choose the L&F, not impose one; this is the purpose of having a site wide default.dsl.
I think you just gave a good argument for using cascading stylesheets in the Wine documentation.
If the look and feel is set by default.dsl, then only users who have access to the Wine source and have DocBook installed on their system can change the look and feel. All other users must change each and every file manually (because default.dsl puts hardcoded html attributes all over the place).
Cascading stylesheets don't require a server. I modified our build system to use one, winedoc.css, and all it requires is that we ship that file together with the .html files.
Then users that don't have access to the Wine source can change one file, winedoc.css, to change the look and feel of the whole doc.
For instance, to make the FAQ questions red and not bold, just edit winedoc.css and replace
.question { border-top: dashed thin; font-weight: bolder; }
with
.question { border-top: dashed thin; color: #FF0000; }
Ok, submitting a patch in that direction...
On Tue, 9 Sep 2003, Francois Gouget wrote:
If the look and feel is set by default.dsl, then only users who have access to the Wine source and have DocBook installed on their system can change the look and feel. All other users must change each and every file manually (because default.dsl puts hardcoded html attributes all over the place).
Cascading stylesheets don't require a server. I modified our build system to use one, winedoc.css, and all it requires is that we ship that file together with the .html files.
Then users that don't have access to the Wine source can change one file, winedoc.css, to change the look and feel of the whole doc.
I think you are missing the point of separating content from presentation. We should not try to "fix" the SGML tools, we should provide the content, not force everybody to use our colour scheme. Any site that cares about this thing will probably have a customized default.dsl which integrates with _their_ site, not our idea how things should look. And that customized default.dsl will either hadcode the colors, or use a CSS, it's their business, not ours.
On Tue, 9 Sep 2003, Dimitrie O. Paun wrote: [...]
I think you are missing the point of separating content from presentation.
I completely get the point. The whole point of CSS is to separate content from presentation!
Do you actually know what CSS is?
I also take exception to your claim that defautl.dsl is the place to tweak the look and feel of the documentation. I'm pretty sure this is not what the DocBook guys had in mind.
We should not try to "fix" the SGML tools, we should provide the content, not force everybody to use our colour scheme.
I am not trying to fix SGML. And I am not trying to impose any color scheme on anybody either. Why do you imply that I do?
I'm just preserving what's already there. Furthermore I don't understand why you absolutely want what little there is to be hardcoded in a hard to change way and in a file that obviously noone understands, rather than in a more flexible easier to understand place that's made for this task.
Any site that cares about this thing will probably have a customized default.dsl which integrates with _their_ site, not our idea how things should look. And that customized default.dsl will either hadcode the colors, or use a CSS, it's their business, not ours.
The above should be:
Any site that cares about this thing will probably have a customized css file which integrates with _their_ site, not our idea how things should look. They will not want to try to fix the DocBook tools just to get documentation that looks like they want. So we should not hardcode the look and feel. The look and feel is their business, not ours.
On Tue, 9 Sep 2003, Francois Gouget wrote:
I completely get the point. The whole point of CSS is to separate content from presentation!
Yes, it does (in a simple way, indeed), but this was not my point. My point is that the way it's done it's up to the user. They should decide if the they want to hard code the stuff in the HTML itself or put it into a CSS. And they do that in default.dsl.
Do you actually know what CSS is?
I hope you're joking, right?
On Tue, 9 Sep 2003, Dimitrie O. Paun wrote:
On September 8, 2003 01:23 pm, Francois Gouget wrote:
As far as I can see the differences between winehq.dsl and default .dsl
Well, if we keep winehq.dsl, why do we need a perl script to patch the output?
We need the perl script to remove everything outside the <body> tag and to put <!--TITLE:[Title Goes Here]--> as the first line. I'm pretty sure this could be done by hacking the dsl file and yes, this would be much better. But I'm sure haev no idea how and I don't have the time nor the will to spend days researching it. Since nobody else voluntered to do it either I wrote a script to hack the generated html file instead.
The HTML stuff should be generated with the site default.dsl anyway. We should instead patch winehq.dsl to generate the required output instead. And it should be moved to the tools/ CVS module as well.
Either way once make_winehq is in the tools CVS, winehq.dsl and make_winehq can be removed from Wine's CVS. However I think we should keep Wine's default.dsl file (just like we have a print.dsl file).
On Sat, 2003-09-06 at 18:43, Francois Gouget wrote:
- the xxx.template files start with a line indicating the title:
<!--TITLE:Wine User Guide-->
I've been testing the tgz file you made on my local development box. So far so good. The docs integrate very nicely into the site this way. The title thing is wrong though, it needs to be: <!--TITLE:[Wine User Guide]-->
Left out the [].
So if you could generate me another tgz to test, I'll work on getting it up on the site today.
On 8 Sep 2003, Jeremy Newman wrote:
On Sat, 2003-09-06 at 18:43, Francois Gouget wrote:
- the xxx.template files start with a line indicating the title:
<!--TITLE:Wine User Guide-->
I've been testing the tgz file you made on my local development box. So far so good. The docs integrate very nicely into the site this way.
Cool.
The title thing is wrong though, it needs to be:
<!--TITLE:[Wine User Guide]-->
Left out the [].
No problem. I thought these where just in the <example>. I'll update the script and regenerate the tgz.
-
Alexandre Julliard -
Dimitrie O. Paun -
Dimitrie O. Paun -
Francois Gouget -
Jeremy Newman -
Tom