Re: Bad CSS link in generated 10.3 documentation

[Kim Haase]

I think some piece of lore known to earlier release engineers got lost. 
To remove the absolute path from the stylesheet name, you need to add an 
empty definition of args.csspath to the docs.properties file:

args.csspath=
I learned about this by looking at the Apache Derby docs, but that must 
have been at 10.1, since the more recent releases both have the absolute 
path. If the docs.properties file is part of the Derby doc source, maybe 
this edit should be checked into the source tree (and we'd need a JIRA 
issue to do that, I guess). If it isn't, then someone should probably 
add an instruction to the "Creating output" section of 
http://db.apache.org/derby/manuals/dita.html.

The second problem -- the absence of the .css files -- is trickier. I 
have been looking through the DITA toolkit files, but I can't figure it 
out. I thought the three .css files that are in the top-level DITA 
toolkit directory used to be copied into the output directory for each 
manual. But as best I can tell, they're not there for any of the 
releases. I am not sure they would do much good, though, because not all 
the classes specified in the HTML output appear in these files. For 
instance, "codeph" does not.

Why Safari on the Mac behaves this way is a question that may be beyond 
our power to figure out. (I just installed Safari 3 Beta on my Windows 
XP system and was able to see the codeph text just fine.) I thought 
browsers generally ignored any attributes they couldn't understand, so 
the absence of the stylesheets would just cause the browser to use its 
default display behavior.

Kim

Rick Hillegas wrote:
Thanks for the additional research and for moving this conversation over 
to derby-dev, Bryan. I hope that our documentation experts can help us 
understand this behavior and let us know what the correct behavior 
should be.

Regards,
-Rick

Bryan Pendleton wrote:
I'm moving this discussion over from the derby-user list, as it
looks like a problem that originated during the documentation build
for the 10.3 docs.

If you look at the generated 10.3 HTML pages, such as:
http://db.apache.org/derby/docs/10.3/tuning/ttundepth34375.html
and look in the page source, you'll see:
<link 
href="/export/home/rh161140/derby/docs/10.3/out/tuningtemp/commonltr.css" 
type="text/css" rel="stylesheet" />

That CSS reference is to a file system path name, when it should be to
some sort of relative URL that resolves to a CSS file on
http://db.apache.org

Is this already a known, logged problem? Or should I log a new JIRA?

Note that the 10.2 docs are similar; they contain:
<link 
href="/export/home/rh161140/derby/docs/10.2/out/tuningtemp/commonltr.css" 
type="text/css" rel="stylesheet" />

The 10.1 docs, however, contain:
<link href="commonltr.css" type="text/css" rel="stylesheet" />

But even though that resolves to a more reasonable CSS link:
http://db.apache.org/derby/docs/10.1/tuning/commonltr.css
That CSS URL still does not seem to reference an actual stylesheet.

thanks,

bryan

------------------------------------------------------------------------

Subject:
Re: DevGuide: glitch in generation?
From:
Thomas Kellerer <[EMAIL PROTECTED]>
Date:
Mon, 01 Oct 2007 15:23:11 +0200
To:
[EMAIL PROTECTED]

To:
[EMAIL PROTECTED]


caston first, 30.09.2007 14:40:
I am reading the HTML PAGES dev guide, and every time
there is a reference to an actual code item in-line
with text (in Courier font), it is an obfuscated
(meaningless) word, viz.:

This base text (as a result of a copy operation):
The standard way to obtain a Connection object is to
call the method DriverManager.getConnection, which
takes a String
appears in Safari (Mac OS X, 10.4.10) as in the
attached image.  In fact, I didn't know the text would
paste correctly when I started this note!  Hmmm...

The HTML coce seems to be correct:

<p>The standard way to obtain a <samp 
class="codeph"><em>Connection</em></samp> object
is to call the method <samp 
class="codeph"><em>DriverManager.getConnection</em></samp>

But I have noticed that the reference to the css in the header is 
incorrect:

<link 
href="/export/home/rh161140/derby/docs/10.3/out/devguidetemp/commonltr.css" 
type="text/css" rel="stylesheet" />

this is taken from the 10.3 distribution archive.

As no css files are part of the distribution, the reference does not 
make sense (a relative path would make sense if the css files were 
included in the archive).

But maybe on your computere the referenced .css file does indeed exist 
and defines a font which causes the garbled output.

Thomas