This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CVS PDF-docs


On Monday 14 October 2002 21:30, Bart Veer wrote:
> >>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:
>
>     >> You also need a file called jadetex.cfg in doc/sgml and its
>     >> subdirectories. It should contain:
>     >>
>     >> \hypersetup{pdfpagemode=None,  pdfauthor=eCos (pdfjadetex) , 
>     >> colorlinks=true, linkcolor=blue,  pdfstartview=FitH}

Without it, there's nothing about the author in the resulting PDF-s and the 
links are black, while in the resulting HTML they appear blue, as defined. 
This stuff seems to have more to do with TeX setup than with Jade itself. If 
there's a way to implement such a thing that looks like a TeX macro in sgml 
stylesheet, I'll do it.

>
>     Jifl> Wouldn't the link stuff be in a stylesheet? And other than
>     Jifl> pdfauthor (which I wouldn't have thought would be used) what
>     Jifl> are the other bits for.
>
>     >> \def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif,.gif}

That's not needed it's nearly the default;
>
>     Jifl> Why is this needed? It should work without that surely...
>     Jifl> The names are specified in the ENTITIES.

If You have a wrong name specified in ENTITY, the pdfjadetex complains, and 
does not process the picture. According to my knowledge, the valid names in 
ENTITIES should be a png or jpg or maybe something else, I haven't tested.


>
> This jadetex.cfg stuff does not feel right. It seems like a workaround
> for problems in the current implementation of the stylesheets and
> pdfjadetex. Adding lots of new jadetex.cfg files seems especially
> ugly, a single centralized file would be much more acceptable.
>
>     Jifl> And in the patch below, why the subst .html? The .sgml,
>     Jifl> .html and starting page of the .pdf should all have the same
>     Jifl> prefixes (even though it's based on the <TITLE>). And the
>     Jifl> .html file may not exist.
>
> Agreed, the new rules for MAIN_PDF does not seem to achieve anything.

Agreed, I used the subst .html .pdf to get the name for the target from 
MAIN_SGML. I should have used the MAIN_PDF, which I left undefined in the 
makefiles and makemakefile.

>
>     Jifl> Although anyway this should probably be posted on
>     Jifl> ecos-patches and discussed there. I know Bart takes quite an
>     Jifl> interest in documentation generation and I wouldn't want him
>     Jifl> to be excluded if he wants to have a say. In fact, I think
>     Jifl> I'll CC it now anyway.
>
> The basic problem is that the various tools involved (jade/openjade,
> pdfjadetex) have undergone significant development in the last couple
> of years. So different Linux distributions use significantly different
> versions, and makefile rules which work for one person may not work
> for another. I suspect there is still ongoing development, addressing
> e.g. problems with picture files being included or not.
>
> For example, the patch switches from using jade/jadetex/dvips/ps2pdf
> to jade/pdfjadetex. This may seem like a sensible change, it gets you
> to the end product more quickly and with fewer intermediate steps that
> can lose data. Unfortunately when I first started working with DocBook
> pdfjadetex was unreliable, hence the current rules.doc file uses
> alternative tools.

I did't introduce the pdfjadetex to the rules.doc, it was allready there, 
introduced by somebody else, only the make pdf did't work. Anyhow, pdfjadetex 
seems to produce PDF-s without errors that acrobat reader detects and plus it 
produces working bookmarks, while jadetex/dvipdf or jadetex/dvips/ps2pdf 
combination produces some errors and no bookmarks , at least on my platform.
 
>
> In the past I have tended to use recent Red Hat Linux releases on my
> various machines, keeping things simple. I am in the process of
> installing Debian 3.0 on one of them, to allow me to test code in more
> varied environments. However there will still be people who use older
> distributions, and hence may not have usable tools.
> I think we need to do one of:

Agreed, that's why I try to use only the default tools supplied with RH7.3 
(seem old enough) and keep asking Andrew to try to make it with his own set 
of tools on Debian Woody. 
I'm starting even to get nice high resolution pictures included into resulting 
PDF on my RH right now.

As for Autoconf/Automake, my opinion is, that the docs should be finally 
included into the autoconf/automake process up in the ecos directory, when 
the time comes.

Regards
Iztok


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]