Re: CSS style for the documentation pages?
Oops, my finger is dancing ... excuse me sending blank messages.
Let me answer in one message. (Also let's keep both -doc and -www in
loop.)
On Sat, Apr 26, 2014 at 12:34:06AM +0200, Stéphane Blondon wrote:
> > At that time, I raised #719000 which prevented that use.
> > I can try publican again.
>
> The bug has been closed since February 2014
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719000). So perhaps
> it's usable now.
> - Do you plan to check it?
> - Can I help you? I installed publican and publican-debian packages
> but I don't know which package includes the docbook for the
> installation-guide-xxx for example.
Maybe I misunderstand your question. This is very easy part. Just look at the
"control" file of the source package for "installation-guide". The comments in
the "control" file are used to manage the actual package dependency by using the
genbuilddeps script. But if you can not figure this out, how are you going to
integrate your solution to the package etc. Explaining all these will make
someone to finish this task.
"installation-guide" is rather a big package. Initially, other packages may be
easier to work on.
> > On Thu, Apr 24, 2014 at 01:47:15AM +0900, victory wrote:
> > > no need to introduce new tools as you already have wml for such things :)
> > Wrong. Those affected pages are not build via wml.
>
> well, you do not know me :)
> i do not mean as such; what i say is:
> there IS wml AND wml is a program to alter source html (and others),
> and the templates are already there
I am not quite sure what you mean by wml. Wml may be an option since it
has too many features. But is this the best solution for our task? I
also do not see "templates" in the wml form for these html pages
generated externally. Running XSL Transformations on the externally
generated (x)html files to insert these contents from the wml-tool-chain
seems very awkward. If you can make such a script, we might run it from
Makefile when importing such external pages to www. If you mean to
update via Makefile, that is understandable. The hard part is
essentially coming up with XSL Transformation script. If we can, we may
as well fix in the original docbook building script which use XSL
Transformations. (It is not elegant but we can also edit these html
files with some sed scripts. Yak...)
At any rate, when you come up with solution path, let us know.
On Fri, Apr 25, 2014 at 11:45:20PM +0900, Osamu Aoki wrote:
> On Wed, Apr 23, 2014 at 06:03:57PM +0000, W. Martin Borgert wrote:
> > Quoting Simon Paillard <spaillard@debian.org>:
> > >The other way I've tried some months ago was using publican for release
> > >notes,
> > >for which buxy provided a nice Debian css (publican-debian).
> >
> > I did not yet try publican myself, but it looks interesting. From the
> > dependencies it looks like they are building PDF using fop, which failed
> > for me for most non-English documents, IIRC, so I use dblatex.
Yes, its manpage states:
CONFIGURATION AND ENVIRONMENT
Publican requires access to Apache FOP for creating PDF files.
I have the same experience with FOP tool chain previously. So re-using
images and CSS files from publican while building XML files via dblatex
seems to be the current best solution. (Of course, if someone knows how
to fix FOP build issues or its problem is fixed, I will change my mind.)
It is essentially changing few lines in each generated html files and
adding few graphic files anyway.
> > Anyway, I would like to read about any results using publican!
>
> Same here.
If anyone can help me to run publican on an Docbook XML source file, for
example foo.ca.xml for language catalan (ca), I will be happy to test
the result of publican with FOP. This is rather huge tool to learn. I
guess figuring out proper publican.cfg seems to me the first task. (So
far, I gave up.) Although it is not my first choice, I am extremely
curious about publican.
> If I were to work on, I only need contents of publican-debian without
> installing publican. Then I can update current build system and it
> seems less troublesome.
Currently, developers-reference (Developers Reference Maintainers
<debian-policy@lists.debian.org>), maint-guide (me), debian-reference
(me), refcards (Martin), and installation-guide (Debian Install System
Team <debian-boot@lists.debian.org>) seem to be the primary Docbook XML
based documents to be fixed.
I think maint-guide is a good starting point since it is rather a simple
package. Just adjusting its XSL Transformation scripts such as
xslt/html.xsl while referencing equivalents(*) in publican family of
packages and copying image files from the publican-debian is the
easiest.
* Files under /usr/share/publican/Common_Content/common/en-US
(If anyone wish to test build XML from maint-guide, run "make xml" first
to get all translated XML files first.)
(Refcard may be in more complicated situation since its page needs to
fit nicely to each paper. The LaTex customization to include images from
publican-debian to each page with proper alignment may be reasonable
solution for it.)
Once we are successful doing this non-publican path, updating others are
rather trivial using the same path. It cause minimal change and no
large dependency. If no one comes up with solid path, I will eventually
do this when I feel like it. But not now.
Regards,
Osamu
Reply to: